Not yet. It's on the 1.1 schedule, and I hope to have it in within a month or two.
On Tue, Sep 9, 2008 at 8:09 AM, James Strachan <[EMAIL PROTECTED]>wrote: > Maybe the WAN is dropping connections; we have failover in Java; am > not sure we've added that to NMS yet have we? > > 2008/9/9 Jim Gomes <[EMAIL PROTECTED]>: > > Hi Bryan, > > That's interesting. I wonder where the problem is with ActiveMQ => NMS > > connection. Without knowing your exact network topology, I can't point > to > > where the problem is. All I can do is speak to my experience and I have > > been able to keep connections alive for a very long time without errors, > > both with high- and low-activity, even going over what my infrastructure > > team has told me is a WAN connection. > > > > Best, > > Jim > > > > On Tue, Sep 9, 2008 at 7:35 AM, Bryan Murphy <[EMAIL PROTECTED]> > wrote: > > > >> 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. > >> > > >> > > >> > > > > > > -- > James > ------- > http://macstrac.blogspot.com/ > > Open Source Integration > http://open.iona.com >
