Hi Markus, I've seen some similar firewall issues lately, and I can make some suggestions:
"dahm" wrote : | Remarkable settings on the server side: | | in bisocket-remoting.xml: Enabled pings | | | | <attribute name="pingFrequency" isParam="true">60000</attribute> | | <attribute name="pingWindowFactor" isParam="true">2</attribute> | | | These parameters turn on a control connection test facility in the bisocket transport, and we've seen problems with it lately. The fact is that the JBossMessaging code has never used it (they turned it off, in effect, by making the ping frequency "infinite"), so it's never really been tested in the context of JBossMessaging. I assume your goal in turning it on was to keep the connection alive in the context of the firewall, and I would suggest something like: | <attribute name="pingFrequency" isParam="true">60000</attribute> | <attribute name="pingWindowFactor" isParam="true">MAX_INT / 60000</attribute> | (where, of course, MAX_INT / 60000 is replaced by an actual integer). This sets the window in which the ping is expected to "infinity", so that you get the pinging without the possibility of a late ping. "dahm" wrote : | We checked that with the firewall and network people and they said that idle connections will be closed after 1 hour. | We built an keep alive client which sends a message to itself (via the server of course) | every 3 minutes and waits for it 10 seconds. If it does not receive the message it will display a message to the user | and restart the connection to the topic. | What's happening, I guess, is that the firewall is killing a connection, but the Remoting client tries to use it anyway, right? The problem with the "keep alive client", though, is that the Remoting bisocket transport uses a pool of connections, and there's no guarantee that the keep alive client will use, and keep alive, all of them. Here's an alternative suggestion. I made it recently in another context and haven't gotten any feedback yet, but it's something to try. If a Remoting invocation results in a SocketException, the invocation will be retried if the parameter "numberOfCallRetries" is set to a value greater than 1. Now, "numberOfCallRetries" is explicitly set to 1 in the "do not change" section of remoting-bisocket-service.xml, but it seems like a reasonable thing to try. Here's yet another untested suggestion. If you set the parameter "idleTimeout" to a value "n" > 0, then a thread on the server will periodically wake up and shut down any ServerThreads that have been idle for more than "n" seconds. Since the ServerThread's socket will get closed, the client should avoid using that connection. "dahm" wrote : | We found that using remoting 2.5.2 may be an issue, should we go back to the 2.2 branch? | The fact is that AS 4.2 hasn't been tested, by us, with Remoting 2.4/2.5. I'm not aware of any reason wh AS 4.2 shouldn't work with Remoting 2.4/2.5, but going back to the 2.2 branch is a viable strategy in the face of problems. However, in this case, I suspect you'd see the same firewall issues. Let us know how it goes. -Ron View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4244173#4244173 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4244173 _______________________________________________ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
