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
|