I am in the process of building a Blazor Server-Side database application.
One of my requirements is that the user can open each website page in a different tab.
I have found that after 5 tabs are opened, any new pages are blocked from rendering. If I close one page, then the 6th page can render. Apparently this is due to the fact that browsers can support a limited number of SignalR connections at one time. I have read the limit for Chrome is 6 at a time (although I can only get 5 working).
Error Messages in Chrome:
Error: Connection disconnected with error 'Error: Server returned handshake error: Handshake was canceled.'
Error: Error: Server returned handshake error: Handshake was canceled.
Uncaught (in promise) Error: Cannot send data if the connection is not in the 'Connected' State.
at e.send (blazor.server.js:1)
Is there a solution for this problem? Or do I need to explore porting to Blazor Client?
I found the following article about this topic but not sure it it can be applied to a Blazor application:
SignalR and Browser Connection limit
It's a little scary as I have already built quite a bit of code, and don't want to spend too much time trying to hack a workaround.
I finally managed to replicate it on my internal network, it seems to have been resolved now that I have installed WebSockets.
Open Server Manager
Open Add Roles and Features
Expand WebServer (IIS)
Expand Application Development
Select WebSocket Protocol
After installing this, I opened 20 tabs of my blazor server application, each one on a different page and the issue did not re-occur (I also did a couple of refreshes on each to be sure).
I came across this after reading
Blazor works best when using WebSockets as the SignalR transport due to lower latency, reliability, and security. Long Polling is used by SignalR when WebSockets isn't available or when the app is explicitly configured to use Long Polling.
From the Blazor docs.
Related
I have a Spring mvc application, and I'm using websockets to communicate a phisical device that sends data with an angular 2 front end.
the architecture is like this
device ----> Spring Mvc <-----angular 2 front end
I have a datasource listener that publish to a websocket topic everytime a new message appears and I consume that topic from angular.
My problem is that this is working properly in my local tomcat install but when I upload it to a faster server it doesn't.
The main problem I'm having is that is buffering the messages and is reaching the limit and closing the websocket session.
What I noticed checking the logs is that in my local server messages come 20 milliseconds after last one is finished but in the other server sometimes are coming at the same time and they are being buffered throwing the session limit exception.
I tried setting a higher buffer size.
Also tried a thread.sleep but it doesn't worked.
Do you have some ideas what can I do ? should I implement some kind of message queue ?
Thanks in advance
Dealing with a Flex client that needs to connect through BlazeDS to a Java backend. Currently, we have a requirement for fifty-plus clients to be attached at any given time. We need to test the load of this requirement against the server to see if we are going to have any performance issues.
So, I have written a client emulator that will act like real clients and connect to the server though Blazeds. The emulator was to make this test require less hardware for I would connect 50 client from one machine (or two 25, basically minimize hardware needs). Instead of having fifty different machines to run clients on. The issue I am running into is a limitation of emulated clients allowed from one session. There seems to be a five client limit. This goes for both IExplorer and FireFox browsers. The problem is with the JMS subscriptions. The JMS topic seem to get connected but never subscribed.
I played around with some settings on the BlazeDS server side to no avail.
- max-streaming-connections-per-session
- max-streaming-clients
After the sixth connection I start getting a
16:18:21.578 [ERROR] com.ray.sv.flex.util.SocketLogTarget SocketLogTarget failed with SecurityError: [SecurityErrorEvent type="securityError" bubbles=false cancelable=false eventPhase=2 text="Error #2048: Security sandbox violation: http://xxx.xxx.xxx.xxx:8080/ClientEmulator/clientemulator.swf cannot load data from 127.0.0.1:1337."]
Very strange, but what is stranger is that client needs to recover from server disconnects. Which was a totally different issue all together with the remote object calls and subscribing timing issues, kept getting Duplicate Session Id errors. But now I have that ironed out, but I see the same issue when the client fails a connection five times.
The sixth time always fails with the same error. And this is with only one client connected.
Has anyone seen this same issue?
Thanks for your time.
I created a web application, here is the architecture :
Tomcat7 deploy on Amazon EC2
Granite DS
nginx to redirect HTTPS throught the tomct7 port 8181
Flex application that uses RemoteObject on a secure Channel.
Occasionaly, maybye when a request takes to long time, the execution of a RemoteObject in Flex triggers this error :
faultCode:Channel.Call.Failed faultString:'error' faultDetail:'NetConnection.Call.Failed: HTTP: Status 504'
But in the most time, the response of the Remote object is correct.
Could you tell me if Nginx could block something? Or if BlazeDs has a tomeout?Any clues?
Thank you very much
We've had this issue for a long time...problem is we haven't been able to find a repeatable way to force it to disconnect.
Here the most comprehensive list of things to try that i've been able to find:
http://www.bopit.in.th/2009/10/14/flex-channel-connect-failed-error-netconnection-call-failed-http-status-200/
We've tried a couple of those solutions and it seems like we're getting less client disconnects.
There also may be a problem with AVG's linkscanner hijacking the request as it leaves the browser, and then losing it somewhere. We had one machine in our shop that would disconnect when using IE, and since uninstalling AVG, it's never happened on that machine again.
another thing you could check is the socket timeout:
NetConnection.Call.Failed happening sporadically in Flex3/Tomcat/BlazeDS/Spring
and here is a thread on adobe forum about the issue:
http://forums.adobe.com/thread/552133
We have a gaming application in which clients, all running IE make calls to web services using the API generated by the ASP.NET ScriptManager.
After a certain period of time, we start getting failures, with Fiddler showing the following error coming back from the server:
Connection to xxx.yyy.net failed.Exception Text: Only one usage of each socket address (protocol/network address/port) is normally permitted
We are not in control of the server's hardware, so altering the TCP/IP settings is not an easy option. Anyone have thoughts on how to deal with this?
This blog post seems relevant.
"Here is the scoop 1. When you make authenticated calls, the client is closing connections. And when you are making authenticated calls repeatedly to the same server, you are making and closing connections repeatedly 2. The same might happen when you are making regular http [un authenticated] calls but setting keep-alive = false."
http://blogs.msdn.com/b/dgorti/archive/2005/09/18/470766.aspx
I have a fms 3 server runing a video chat room application. It goes well except everyday it will die once or twice. After restarting the fms server, everything goes working again.
I really need to know the reason why fms server can die.
I checked its log, i saw many
"Server rejected an invalid flow."
Any hint will be greatest welcome.
This error can be caused by making an attempt to make a P2P connection to the server's peer ID. Connections to the server need to use
http://forums.adobe.com/thread/845685
i believe the problem is that you are attempting to make a P2P connection to the server's peer ID; that is, something like
var ns:NetStream = new NetStream(netConnection, netConnection.farID);
ns.play(...);
under the covers, this will open a new RTMFP flow to the server that will appear to the server as a new incoming client, but the initial handshake will be incorrect (the first/only command message is "play" instead of "connect"). i see this on Cirrus all the time.
it's possible that FMS doesn't account properly when rejecting these flows (leaving the connection count higher than it should be), or perhaps it leaves the flow open waiting for a "connect" message that will never come, so the connection count is legitimately higher than you think it is.
in any case, make sure you're not opening a P2P stream to the server's peer ID.
However, this error may not actually be related to the crashes. Additionally, are you even sure FMS is crashing and not just your application? If it's just your application, review your application logs (instead of the core FMS logs) and if you don't have anything useful add more logging to your application.