Thanks a lot. Appreciate your help on this issue.
Thanks.
--
View this message in context:
http://activemq.2283324.n4.nabble.com/Exception-in-thread-ActiveMQ-Transport-tcp-10-80-0-35-38499-java-lang-ClassCastException-org-apache-d-tp4665770p4667498.html
Sent from the ActiveMQ - User mailing li
Yah, port scanning sends bytes that the wire format codec does not
recognize. upgrading to a new version will not fix this.
On Mon, Apr 29, 2013 at 12:24 AM, mmg wrote:
> We dont use udp protocol. Also all the clients are at same version (4.0.1)
>
> We have found that this exception is thrown o
We dont use udp protocol. Also all the clients are at same version (4.0.1)
We have found that this exception is thrown only when Qualys vulnerability
tool is executed. It seems this tool blocks the 61616 port for few secs for
scanning. during this time, we can see IOExceptions and SocektExceptions
Well, that's a surprisingly old version :)
But what's happening is the broker is expecting a ConnectionInfo object off
the wire, and when it either pulls it from the cache or reads it off the
wire, it's not getting the correct type of object it desires (ConnectionId).
Are any of your clients using
We are using pretty old version of Active MQ. Its 4.0.1 :-(. We are planning
to upgrade to latest one. But before that want to know what causes this
exception and also if upgrading to latest version of Active MQ will resolve
this issue.
--
View this message in context:
http://activemq.2283324.
what version are you working with here?
On Tue, Apr 9, 2013 at 9:23 AM, mmg wrote:
> We are receiving the below exception after every 3 to 4 days of running.
>
> Exception in thread "ActiveMQ Transport: tcp:///10.80.0.35:38499"
> java.lang.ClassCastException: org.apache.activemq.command.ReplayC
Since I have had no luck in determining the cause of the exception, I am
trying to at least handle it gracefully. What I am considering is applying
the following patch to the InactivityMonitor in order to trigger a fail over
on the transport...
try
{
Digging through org.apache.activemq.transport.InactivityMonitor I can't
really see why this would occur and thus don't know how to prevent it. It
looks like the WRITE_CHECK_TIMER was canceled somehow, and the
CHECKER_COUNTER != 0... but why or how this occurred I do not know.
Is there any help ou
