activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jason Rosenberg (JIRA)" <>
Subject [jira] Created: (AMQ-1574) FailoverTransport logs routine reconnects at INFO/WARN instead of DEBUG
Date Fri, 01 Feb 2008 14:41:36 GMT
FailoverTransport logs routine reconnects at INFO/WARN instead of DEBUG

                 Key: AMQ-1574
             Project: ActiveMQ
          Issue Type: Bug
          Components: Transport
    Affects Versions: 5.0.0
         Environment: I'm using a recent 5.1 snapshot:
            Reporter: Jason Rosenberg

Logged originally in the user forum here:

Here's the text of that again:


I've been testing with AMQ 5.1-SNAPSHOT, using the FailoverTransport.

I'm using TcpTransport as the underyling transport.

I've noticed that is seems to report more on the logging level, items that might have previously
been reported with [DEBUG] are now [INFO] or [WARN].  This is causing significant clutter
in my logs.   I'd like to normally not suppress [INFO] or [WARN] output....

I have an application that needs to support very high throughput, but also can be prone to
extended down time.  So, tcp connections have a tendency to timeout during the downtimes.
 When a subsequent connection comes through, I am seeing TCP exception level warns, that didn't
used to appear when the client is running with 4.1.1, e.g.  

I'm using a broker uri that looks like this:


Here's what I'm seeing with the client using 5.1:

WARN  [2008-01-31 10:11:00,163] thread:ActiveMQ Transport: tcp://
             FailoverTransport -- Transport failed, attempting to automatically reconnect
due to: Socket closed Socket closed
        at Method)
        at org.apache.activemq.transport.tcp.TcpBufferedInputStream.fill(
        at org.apache.activemq.openwire.OpenWireFormat.unmarshal(
        at org.apache.activemq.transport.tcp.TcpTransport.readCommand(
        at org.apache.activemq.transport.tcp.TcpTransport.doRun(
INFO  [2008-01-31 10:11:00,168] thread:ActiveMQ Task                       FailoverTransport
-- Successfully reconnected to tcp://

The same scenario with AMQ 4.1.1 only outputs info at log-level [DEBUG], which I can more
routinely suppress:

DEBUG [2008-01-31 13:23:29,288] thread:http-8080-exec-4                    FailoverTransport
-- Stopped.
DEBUG [2008-01-31 13:23:29,292] thread:http-8080-exec-4                    FailoverTransport
-- Waking up reconnect task
DEBUG [2008-01-31 13:23:29,292] thread:http-8080-exec-4                    FailoverTransport
-- Started.
DEBUG [2008-01-31 13:23:29,293] thread:ActiveMQ Task                       FailoverTransport
-- Attempting connect to: tcp://
DEBUG [2008-01-31 13:23:29,297] thread:ActiveMQ Task                    WireFormatNegotiator
-- Sending: WireFormatInfo { version=2, properties={CacheSize=1024, CacheEnabled=true, SizePrefixDisabled=false,
TcpNoDelayEnabled=true, MaxInactivityDuration=0, TightEncodingEnabled=true, StackTraceEnabled=true},
DEBUG [2008-01-31 13:23:29,297] thread:ActiveMQ Task                       FailoverTransport
-- Connection established
DEBUG [2008-01-31 13:23:29,305] thread:ActiveMQ Transport: tcp://
          WireFormatNegotiator -- Received WireFormat: WireFormatInfo { version=3, properties={CacheSize=1024,
CacheEnabled=true, SizePrefixDisabled=false, TcpNoDelayEnabled=true, MaxInactivityDuration=30000,
TightEncodingEnabled=true, StackTraceEnabled=true}, magic=[A,c,t,i,v,e,M,Q]}
DEBUG [2008-01-31 13:23:29,305] thread:ActiveMQ Transport: tcp://
          WireFormatNegotiator -- tcp:// before negotiation:
OpenWireFormat{version=2, cacheEnabled=false, stackTraceEnabled=false, tightEncodingEnabled=false,
DEBUG [2008-01-31 13:23:29,305] thread:ActiveMQ Transport: tcp://
          WireFormatNegotiator -- tcp:// after negotiation:
OpenWireFormat{version=2, cacheEnabled=true, stackTraceEnabled=true, tightEncodingEnabled=true,

Thoughts?  Is there a reason why in 5.1, the FailoverTransport passes on the underlying tcp
socket timeout due to inactivity?



This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message