When I login to an xpage application from a browser the connection drop is done at 5 minutes, whereas when I access a traditional domino application the connection drop is around 1 minute. I am using session based authentication on a single server and the domauthsessid is being set in both the cases. I am using netstat to track the session. Why is xpage connection timeout different from the normal application? I do not have any keepalive setting on my xpage. For testing purpose on the server document I have set the persistent connection time out to 600 seconds. But either of my applications do not reach that timeout.
The default timeout for an XPage session is 30 minutes and that can be set thru the application properties in each database. Above that the domino session timeout apply.
Related
I kinda came across a strange problem.
In our application (based on React-native) we hosted 70 concurrent clients but the peak in the monitoring page showed 380 connections.
I assume maybe clients exit and come back or reload the app somehow so Ably connections regenerates again and therefore the peak increases.
Now the question: is there any way to force Ably disconnect all unused connections so the peak decreases? (Maybe from back-end)
Thanks.
By default, the connection will stay active until closed explicitly (using connection.close()), or two minutes after the connection is disconnected unexpectedly to allow for connection state recovery.
Recent versions of ably-js in a browser environment automatically close the connection on page reload (that is, the closeOnUnload client option defaults to true) -- this is just a connection.close() added to a beforeunload handler. The trouble is that isn't going to do anything in a React Native environment, which doesn't use that event.
So you probably just need to actively manage your Ably connection using React Native app lifecycle events. If you don't want it to stay active when the app is backgroundend, then in the handler for the app being in the background (per the React Native AppState event), close the Ably connection. Then re-open it (call connect()) when the app is active again.
For other possible reasons your peak connection count may be higher than expected, see Why are my peak connection counts higher than expected? and How does Ably count peak connections?.
If any web agent at any chance falls in to infinite loop can "Web agent time out parameter"(say 5 sec) in server document prevent http hang? If the agent is called from Xpage postSaveDocument will also apply the same?
Yes, that is exactly what that parameter does - and it's been in the Domino server at least since version 5.0. See this response on the old forum.
So basically, you need to edit the server document, go to "Internet Protocols", "Domino Web Engine". Near the bottom you can set the timeout in seconds for "Web agents and Web Services Timeout".
I can't see there should be any difference in how the web agent is called :-)
/John
I have installed domino server in my system and tried; this agent is not stopped with this server parameter, but restart task http can stop it so it is not like xpage infinite loop which never stops unless sever is forcefully killed. Thanks a lot for your input.
In Chrome, Socket IO seems to stop transmitting data. Is there an internal reason for this?
I've tried a very simple client and simple server side but consistently the server stops receiving any emits after 5 minute, will then reconnect and it's fine for another 5 minutes.
On top of the internal ping mechanism I have a polling mechanism which sends back session data every 20 seconds.
I don't use WebSocket with NodeJS or Socket.io but experienced the same behaviour with Jetty. It turns out that Jetty has an idle timeout default to 5 minutes (or 300 seconds) for all WebSocket's sessions. You could change the default idle timeout value to an appropriate value or ping/pong those connections before it timed out.
In my situation, I decided to use ping/pong as it also helps determine when the connection is no longer there. I observed that in some cases, connection was not closed even when the network is down.
According to engine.io (which is used by socket.io) docs, the server seems to have default pingInterval of 25 seconds. So unless you inadvertently disabled or changed default options, the ping/pong mechanism should be in place.
In Spring Integration, if caching session factory be used for FTP, how to set the auto disconnect connection if exceeds certain IDLE time?
Background information:
My program is based on FtpOutboundGatewaySample-context.xml SI sample, I used the "ls" command in FTP Outbound gateway --> split the result --> and call "get" commandy with Ftp Outbound Gateway for each file to be downloaded.
Without CachingSessionFactory, the FTP connection will be disconnected for every file be downloaded.
I tried to add the CachingSessionFactory with an appropriate waiting timeout value. Now, the connection will be reused and won't call disconnect for every file be downloaded.
But now, I don't know how to make the FTP connection be disconnected automatically if no more file is available for download. I guess some IDLE timeout could be set somewhere.
Typically, the server will close the session after a timeout (configured on the server); the cache will detect the closed session the next time it's used and discard it.
There's no way to set a timeout on the client side.
I have added pusher to my start up web page, but there is something that is troubling me:
Since I have the sandbox plan (which says that i only have 20 maximum connections) I have been testing my web page on several computers (using pusher), but when I get in to my account it says that I am using 6 connections, even when anyone is not using my web page, so whats does this connections means? how does it counts as a connection? when a web page is closed, the connection counter decrease?
Any information about this will be great.
The connection count on pricing plans indicates the number of simultaneous connections allowed.
A connection is counted as a WebSocket connection to Pusher. When using the Pusher JavaScript library a new WebSocket connection is created when you create a new Pusher('APP_KEY'); instance.
Channel subscriptions are created over the existing WebSocket connection, and do not count towards your connection quota (there is no limit on the number allowed per connection).
Note: connections automatically close when a user navigates to another web page or closes their web browser so there is no need to do this manually.