Hi Bryan, I can't answer all of your questions, yet. But I can answer some of them, anyway.
1. As far as the ResponseTimeout property goes, that is used for network timeouts. It's not a JMS timeout value like TimeToLive. The ResponseTimeout is used by the client to wait for a response from the broker. Since a network call is inherently a blocking operation (send request, wait for response), if we never receive a response from a dead/hung broker, the client will hang as well. The ResponseTimeout lets client abort waiting for the response from the broker. This can be set to whatever performance constraints your application requires. In a WAN environment, this might be set to something fairly high where there is a lot of latency in network round-trips. The socket connection is not dropped. The client simply stops waiting for the broker to respond and goes into its error-handling code for a non-response. 2. I see the marshalling code for the KeepAliveInfo, but like you I don't see how this is turned on or controlled from the client-side. This would need more investigation to see if it is enabled via a URI parameter, or if new code needs to be written to enable its use. 3. Can't answer the server-side socket issue. Don't know that code. On Thu, Sep 4, 2008 at 3:46 PM, Bryan Murphy <[EMAIL PROTECTED]> wrote: > Hey Guys, > We're still having problems consuming messages from an ActiveMQ service via > Apache.NMS. We've fixed a few bugs in the past week, and we're left with > one outstanding issue where we have one of our consumers in a different > data-center than the message server. It appears as if our TCP connections > are timing out while the system is idle (possibly due to NAT translation > timeouts) and we're never properly re-establishing connections back to the > message server. > > I've dug around in the in the NMS code a bit, and I have a few questions. > > 1. TcpTransport, Connection, and Session have a property called > "RequestTimeout". I'm not entirely clear on what this property dose. What > times out, and what is a "request"? What happens when one of these > requests timeout? Is the socket dropped and re-opened? > > 2. It does not appear that there is any way to turn KeepAlive on via the > NMS > client, but I do see code for handling keep alive packets. The > documentation here > http://activemq.apache.org/tcp-transport-reference.htmlseems to imply > that this is a client side option, but I was wondering if we > could configure it in the server side and how could we verify that it was > in > fact running? > > 3. If a client reconnects to the server, does the server forcefully close > the old socket? I'm not sure this is happening, but it seems like a > logical > thing to do and I was curious what the expected behavior is. > > Any other suggestions how we can deal with this? This channel is > high-latency, but very low messages, so we don't mind if it takes awhile to > handle these messages, we just need it to happen. > > Thanks, > Bryan >
