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 > > > >> > > > > > >
