Unfortunately, I have no way of knowing because I left it sitting idle and
didn't have a TCP dump running. This is not the first time I've seen that
exception. What I've seen in our testing is that this exception means that
one of the queue's we are listening to has gone off the reservation.
How
So, does it seem like it lasted all night until that time? I wonder what
could have caused that error. I take it that this is not the same error
that you were getting previously?
On Thu, Sep 11, 2008 at 7:46 AM, Bryan Murphy <[EMAIL PROTECTED]> wrote:
> It didn't survive the night. It dumped t
It didn't survive the night. It dumped this stack trace out on the console
about 10 minutes before I even tried to look at it. Don't know if this will
help down the road, but I figure it can't hurt:
[2008-09-11 00:09:27,703] [ERROR]
[Mediafly.Common.Server.MessageBus.ActiveMQMessageService`1[[Med
Great to hear! I hope the test goes well. Thanks for verifying this.
Yeah, it won't handle network outages. That's where failover comes in
(scheduled for 1.1). However, this should keep any firewalls or routers
from aggressively disconnecting the sockets.
On Wed, Sep 10, 2008 at 3:15 PM, Bryan
2.5 hours of inactivity. I just sent a message through and the service is
still responding. That's a good sign, but I'll let it run overnight to be
sure. I'm still not convinced it will survive more drastic network outages,
but this appears to be a significant step in the right direction!! :)
Br
Cool! I've updated updated my local NMS library and am currently running a
test. I'll let you know in a few hours how it turns out.
Thanks,
Bryan
On Wed, Sep 10, 2008 at 12:48 AM, Jim Gomes <[EMAIL PROTECTED]> wrote:
> FYI, the NMS trunk now has the keep alive support implemented. You can
> tu
Great stuff Jim!
2008/9/10 Jim Gomes <[EMAIL PROTECTED]>:
> FYI, the NMS trunk now has the keep alive support implemented. You can turn
> it on with the URI parameter "wireFormat.MaxInactivityDuration=" and
> "wireFormat.MaxInactivityDurationInitialDelay=" where 'n' equals the
> number of
Awesome Jim!
On 10 Sep 2008, at 06:48, Jim Gomes wrote:
FYI, the NMS trunk now has the keep alive support implemented. You
can turn
it on with the URI parameter "wireFormat.MaxInactivityDuration="
and
"wireFormat.MaxInactivityDurationInitialDelay=" where 'n' equals
the
number of
FYI, the NMS trunk now has the keep alive support implemented. You can turn
it on with the URI parameter "wireFormat.MaxInactivityDuration=" and
"wireFormat.MaxInactivityDurationInitialDelay=" where 'n' equals the
number of milliseconds. The initial delay option is optional and not
requir
Bryan,
Thanks for your trouble-shooting report. Looks like you guys were trying
everything. I logged a JIRA (AMQNET-114) to enable the KeepAlive feature in
NMS. Even though you were able to solve your issue with a work-around, you
shouldn't have to do that, and the next person may not be able
We basically run a server here in our local office behind a firewall, and
the rest of our stuff out on Amazon's EC2 cloud. We suspect there were
issues with NAT timeouts and half dead TCP connections.
The specific behaviors we saw using NMS manifested themselves in the
following ways:
1. Client b
2008/9/9 Jim Gomes <[EMAIL PROTECTED]>:
> Not yet. It's on the 1.1 schedule, and I hope to have it in within a month
> or two.
Great stuff! :)
--
James
---
http://macstrac.blogspot.com/
Open Source Integration
http://open.iona.com
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
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
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 erro
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
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
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 conn
18 matches
Mail list logo
