You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@activemq.apache.org by greenbean1 <ur...@yahoo.com> on 2011/11/21 20:30:10 UTC

CMS 3.4.0 - Deadlock in IOTransport With Failover

Could Timothy Bish or someone else provide details on issue AMQCPP-376?  We
are running in to this issue on our production system.  Is there a good way
to work around this while keeping the Failover transport?

"The underlying deadlock issue is still there in trunk, so even though you
didn't see it that time, it could still occur if timing changes at all."

https://issues.apache.org/jira/browse/AMQCPP-376

In digging through the code I see a CMS thread is stuck on the join as shown
below because the IOTransport input stream is blocked reading from the
Socket.  However, the comment below indicates the inputStream should be
closed (closing the socket).  Why isn't this occurring?

        // We have to close the input stream before
        // we stop the thread.  this will force us to
        // wake up the thread if it's stuck in a read
        // (which is likely).  Otherwise, the join that
        // follows will block forever.
        if( inputStream != NULL ){
            inputStream->close();
            inputStream = NULL;
        }

        // Wait for the thread to die.
        if( thread != NULL ){
            thread->join();
            thread.reset( NULL );
        }

 

--
View this message in context: http://activemq.2283324.n4.nabble.com/CMS-3-4-0-Deadlock-in-IOTransport-With-Failover-tp4092829p4092829.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.

Re: CMS 3.4.0 - Deadlock in IOTransport With Failover

Posted by Oscar Pernas <os...@pernas.es>.
Hi,

I have activemq-cpp in production too, Could you explain the exactly
environment in which you fall into the bug? when the connection is
interrupted the producer cant switch to the next broker, or is the consumer?

When I had synchronous consumer, I had some problems with reconnection but
when I changed to asynchronous, I think that I've never had this problem
again.


Regards




2011/11/22 Timothy Bish <ta...@gmail.com>

> On Mon, 2011-11-21 at 11:30 -0800, greenbean1 wrote:
> > Could Timothy Bish or someone else provide details on issue AMQCPP-376?
>  We
> > are running in to this issue on our production system.  Is there a good
> way
> > to work around this while keeping the Failover transport?
> >
>
> There's been no time for me to work on this, so that status is
> unchanged.  Issue is still present on trunk.
>
> > "The underlying deadlock issue is still there in trunk, so even though
> you
> > didn't see it that time, it could still occur if timing changes at all."
> >
> > https://issues.apache.org/jira/browse/AMQCPP-376
> >
> > In digging through the code I see a CMS thread is stuck on the join as
> shown
> > below because the IOTransport input stream is blocked reading from the
> > Socket.  However, the comment below indicates the inputStream should be
> > closed (closing the socket).  Why isn't this occurring?
> >
> >         // We have to close the input stream before
> >         // we stop the thread.  this will force us to
> >         // wake up the thread if it's stuck in a read
> >         // (which is likely).  Otherwise, the join that
> >         // follows will block forever.
> >         if( inputStream != NULL ){
> >             inputStream->close();
> >             inputStream = NULL;
> >         }
> >
> >         // Wait for the thread to die.
> >         if( thread != NULL ){
> >             thread->join();
> >             thread.reset( NULL );
> >         }
> >
> >
> >
> > --
> > View this message in context:
> http://activemq.2283324.n4.nabble.com/CMS-3-4-0-Deadlock-in-IOTransport-With-Failover-tp4092829p4092829.html
> > Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>
> --
> Tim Bish
> ------------
> FuseSource
> Email: tim.bish@fusesource.com
> Web: http://fusesource.com
> Twitter: tabish121
> Blog: http://timbish.blogspot.com/
>
>
>
>


-- 
Óscar Pernas Plaza.

Re: CMS 3.4.0 - Deadlock in IOTransport With Failover

Posted by Timothy Bish <ta...@gmail.com>.
On Mon, 2011-11-21 at 11:30 -0800, greenbean1 wrote:
> Could Timothy Bish or someone else provide details on issue AMQCPP-376?  We
> are running in to this issue on our production system.  Is there a good way
> to work around this while keeping the Failover transport?
> 

There's been no time for me to work on this, so that status is
unchanged.  Issue is still present on trunk.

> "The underlying deadlock issue is still there in trunk, so even though you
> didn't see it that time, it could still occur if timing changes at all."
> 
> https://issues.apache.org/jira/browse/AMQCPP-376
> 
> In digging through the code I see a CMS thread is stuck on the join as shown
> below because the IOTransport input stream is blocked reading from the
> Socket.  However, the comment below indicates the inputStream should be
> closed (closing the socket).  Why isn't this occurring?
> 
>         // We have to close the input stream before
>         // we stop the thread.  this will force us to
>         // wake up the thread if it's stuck in a read
>         // (which is likely).  Otherwise, the join that
>         // follows will block forever.
>         if( inputStream != NULL ){
>             inputStream->close();
>             inputStream = NULL;
>         }
> 
>         // Wait for the thread to die.
>         if( thread != NULL ){
>             thread->join();
>             thread.reset( NULL );
>         }
> 
>  
> 
> --
> View this message in context: http://activemq.2283324.n4.nabble.com/CMS-3-4-0-Deadlock-in-IOTransport-With-Failover-tp4092829p4092829.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.

-- 
Tim Bish
------------
FuseSource
Email: tim.bish@fusesource.com
Web: http://fusesource.com
Twitter: tabish121
Blog: http://timbish.blogspot.com/