activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jim Gomes" <e.se...@gmail.com>
Subject Re: ActiveMQ+NMS+TCP Connection Problems
Date Tue, 09 Sep 2008 15:29:55 GMT
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 <james.strachan@gmail.com>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 <e.semog@gmail.com>:
> > 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 <bmurphy1976@gmail.com>
> 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 <e.semog@gmail.com> 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
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message