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. However, queues that have gone off the reservation do not always throw this exception (in fact, often they throw no exceptions at all). Bryan
On Thu, Sep 11, 2008 at 10:14 AM, Jim Gomes <[EMAIL PROTECTED]> wrote: > 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 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[[Mediafly.Publisher.Tools.MediaProcessorService.TestMessage, > > Mediafly.Publisher.Tools.MediaProcessorService, Version=1.0.0.0, > > Culture=neutral, PublicKeyToken=null]]] Connection Exception > > System.IO.EndOfStreamException: Unable to read beyond the end of the > > stream. > > at System.IO.__Error.EndOfFile() > > at System.IO.BinaryReader.FillBuffer(Int32 numBytes) > > at System.IO.BinaryReader.ReadInt32() > > at Apache.NMS.ActiveMQ.OpenWire.OpenWireBinaryReader.ReadInt32() in > > > > > D:\Workspace\activemq-dotnet\Apache.NMS.ActiveMQ\trunk\src\main\csharp\OpenWire\OpenWireBinaryReader.cs:line > > 132 > > at Apache.NMS.ActiveMQ.OpenWire.OpenWireFormat.Unmarshal(BinaryReader > > dis) in > > > > > D:\Workspace\activemq-dotnet\Apache.NMS.ActiveMQ\trunk\src\main\csharp\OpenWire\OpenWireFormat.cs:line > > 218 > > at Apache.NMS.ActiveMQ.Transport.Tcp.TcpTransport.ReadLoop() in > > > > > D:\Workspace\activemq-dotnet\Apache.NMS.ActiveMQ\trunk\src\main\csharp\Transport\Tcp\TcpTransport.cs:line > > 309 > > > > The consumer count for the queue under the ActiveMQ admin console is 0. > > > > Bryan > > > > > > > > On Thu, Sep 11, 2008 at 1:02 AM, Jim Gomes <[EMAIL PROTECTED]> wrote: > > > > > 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 Murphy <[EMAIL PROTECTED]> > > > wrote: > > > > > > > 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!! :) > > > > Bryan > > > > > > > > On Wed, Sep 10, 2008 at 2:32 PM, Bryan Murphy <[EMAIL PROTECTED] > > > > > > wrote: > > > > > > > > > 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 > > > > >> turn > > > > >> it on with the URI parameter > "wireFormat.MaxInactivityDuration=nnnn" > > > and > > > > >> "wireFormat.MaxInactivityDurationInitialDelay=nnnn" where 'n' > equals > > > the > > > > >> number of milliseconds. The initial delay option is optional and > > not > > > > >> required to be used at the same time. It should operate just like > > the > > > > >> Java > > > > >> client. I observed that the server will send a KeepAliveInfo > > command > > > to > > > > >> the > > > > >> client periodically. The client then responds back. This should > > keep > > > > the > > > > >> socket connection alive even when no messages are flowing. I > would > > be > > > > >> willing to bet that this is what the two ActiveMQ servers are > doing > > to > > > > >> each > > > > >> other, which is why that solution worked for you. > > > > >> > > > > >> Best, > > > > >> Jim > > > > >> > > > > > > > > > >
