Thanks for the info. I suspected that's what the timeout meant, but you never really know until you ask.. Anyway, we finally solved our issue. We setup two instances of ActiveMQ in the two data centers to forward messages back and forth between each other. This is working much better for us. It seems the ActiveMQ to ActiveMQ communication is a bit more robust than the ActiveMQ to Apache.NMS communication (at least when running over a WAN).
Bryan On Mon, Sep 8, 2008 at 2:49 PM, Jim Gomes <[EMAIL PROTECTED]> wrote: > 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. > >
