You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@activemq.apache.org by Devin Venable <ve...@gmail.com> on 2010/09/17 17:18:04 UTC
CMS and EINTR signal
I've got a question for the developers of CMS. If this isn't the best
forum, please direct me to the the best place to pose such questions.
I've implemented an activemq-cpp producer on a program that reads and
writes to a Linux message queue (#include <mqueue.h>). I noticed that
my program was intermittently shutting down, and the cause is logic
that reads from the queue, checks for an error, and then continues if
all is well. Since implementing activemq, a new error type is showing
up that wasn't handled by our logic: EINTR which means "Interrupted
system call".
Note that I only see this when I set CMS to run in async mode, using this flag:
useAsyncSend=true
I need to run the producer in async mode because I can't block if
ActiveMQ can't be reached for some reason.
So my questions are:
Is this behavior normal or expected?
Is there a different combination of flags that I should use when
starting the producer?
I can write code that handles the EINTR case, and from what I've read,
this code should probably already be doing that. But I wanted to
learn more about what might be causing this as well.
Re: CMS and EINTR signal
Posted by Timothy Bish <ta...@gmail.com>.
On Fri, 2010-09-17 at 11:30 -0500, Devin Venable wrote:
> >> all is well. Since implementing activemq, a new error type is showing
> >> up that wasn't handled by our logic: EINTR which means "Interrupted
> >> system call".
> >>
> >
> > What version of ActiveMQ-CPP are you using?
> > What OS and Compiler?
>
> Lib: activemq-cpp-library-3.2.3
> OS: Linux centdev 2.6.18-194.8.1.el5 #1 SMP Thu Jul 1 19:04:48 EDT
> 2010 x86_64 x86_64 x86_64 GNU/Linux
> Compiler: gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-48)
>
> >
> > Have you tracked where the EINTR signal is coming from? It shouldn't be
> > coming from CMS unless there is a bug in the code. It would be helpful
> > to know what operation is throwing the EINTR signal.
> >
>
> Yes, the EINTR signal is coming from a call to msgrcv which is apart
> from activemq-cpp. In the code I'm working with there is a polling
> loop that calls msgrcv to pull messages from a Linux message queue.
> The EINTR code only appears when I am running a producer in the same
> program in async mode. I catch my signal in my main thread. BT:
>
> (gdb) bt
> #0 0xffffe410 in __kernel_vsyscall ()
> #1 0x009f5573 in msgrcv () from /lib/libc.so.6
>
>
> There are four other threads running. Here are the back traces for
> the other four threads.
You'd need to investigate the mechanics of the msgrcv call to determine
what the conditions are that would cause it to send the EINTR signal. I
don't know of any reason why the CMS client would cause this behavior.
Regards
>
> Thread 1:
>
> (gdb) bt
> #0 0xffffe410 in __kernel_vsyscall ()
> #1 0x00ab7ef2 in pthread_cond_timedwait@@GLIBC_2.3.2 ()
> from /lib/libpthread.so.0
> #2 0x0448982b in
> decaf::internal::util::concurrent::ConditionImpl::wait(decaf::util::concurrent::ConditionHandle*,
> long long, long long) ()
> from /usr/lib/libactivemq-cpp.so.9
>
>
> Thread 2:
>
> (gdb) bt
> #0 0xffffe410 in __kernel_vsyscall ()
> #1 0x00ab7ef2 in pthread_cond_timedwait@@GLIBC_2.3.2 ()
> from /lib/libpthread.so.0
> #2 0x0448982b in
> decaf::internal::util::concurrent::ConditionImpl::wait(decaf::util::concurrent::ConditionHandle*,
> long long, long long) ()
> from /usr/lib/libactivemq-cpp.so.9
> #3 0x0450848f in decaf::util::concurrent::Mutex::wait(long long, int) ()
> from /usr/lib/libactivemq-cpp.so.9
> #4 0x0450831a in decaf::util::concurrent::Mutex::wait(long long) ()
> from /usr/lib/libactivemq-cpp.so.9
>
> Thread 3:
>
>
> #0 0xffffe410 in __kernel_vsyscall ()
> #1 0x00ab7ef2 in pthread_cond_timedwait@@GLIBC_2.3.2 ()
> from /lib/libpthread.so.0
> #2 0x0448982b in
> decaf::internal::util::concurrent::ConditionImpl::wait(decaf::util::concurrent::ConditionHandle*,
> long long, long long) ()
> from /usr/lib/libactivemq-cpp.so.9
> #3 0x0450848f in decaf::util::concurrent::Mutex::wait(long long, int) ()
> from /usr/lib/libactivemq-cpp.so.9
> #4 0x0450831a in decaf::util::concurrent::Mutex::wait(long long) ()
> from /usr/lib/libactivemq-cpp.so.9
> #5 0x0448919c in
> decaf::internal::util::concurrent::SynchronizableImpl::wait(long long)
> () from /usr/lib/libactivemq-cpp.so.9
>
>
> Thread 4:
>
> #0 0xffffe410 in __kernel_vsyscall ()
> #1 0x00ab7bc5 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0
> #2 0x0448992a in
> decaf::internal::util::concurrent::ConditionImpl::wait(decaf::util::concurrent::ConditionHandle*)
> () from /usr/lib/libactivemq-cpp.so.9
> #3 0x045084d9 in decaf::util::concurrent::Mutex::wait() ()
> from /usr/lib/libactivemq-cpp.so.9
> #4 0x041d66e2 in activemq::threads::CompositeTaskRunner::run() ()
--
Tim Bish
Open Source Integration: http://fusesource.com
Follow me on Twitter: http://twitter.com/tabish121
My Blog: http://timbish.blogspot.com/
Re: CMS and EINTR signal
Posted by Devin Venable <ve...@gmail.com>.
>> all is well. Since implementing activemq, a new error type is showing
>> up that wasn't handled by our logic: EINTR which means "Interrupted
>> system call".
>>
>
> What version of ActiveMQ-CPP are you using?
> What OS and Compiler?
Lib: activemq-cpp-library-3.2.3
OS: Linux centdev 2.6.18-194.8.1.el5 #1 SMP Thu Jul 1 19:04:48 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux
Compiler: gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-48)
>
> Have you tracked where the EINTR signal is coming from? It shouldn't be
> coming from CMS unless there is a bug in the code. It would be helpful
> to know what operation is throwing the EINTR signal.
>
Yes, the EINTR signal is coming from a call to msgrcv which is apart
from activemq-cpp. In the code I'm working with there is a polling
loop that calls msgrcv to pull messages from a Linux message queue.
The EINTR code only appears when I am running a producer in the same
program in async mode. I catch my signal in my main thread. BT:
(gdb) bt
#0 0xffffe410 in __kernel_vsyscall ()
#1 0x009f5573 in msgrcv () from /lib/libc.so.6
There are four other threads running. Here are the back traces for
the other four threads.
Thread 1:
(gdb) bt
#0 0xffffe410 in __kernel_vsyscall ()
#1 0x00ab7ef2 in pthread_cond_timedwait@@GLIBC_2.3.2 ()
from /lib/libpthread.so.0
#2 0x0448982b in
decaf::internal::util::concurrent::ConditionImpl::wait(decaf::util::concurrent::ConditionHandle*,
long long, long long) ()
from /usr/lib/libactivemq-cpp.so.9
Thread 2:
(gdb) bt
#0 0xffffe410 in __kernel_vsyscall ()
#1 0x00ab7ef2 in pthread_cond_timedwait@@GLIBC_2.3.2 ()
from /lib/libpthread.so.0
#2 0x0448982b in
decaf::internal::util::concurrent::ConditionImpl::wait(decaf::util::concurrent::ConditionHandle*,
long long, long long) ()
from /usr/lib/libactivemq-cpp.so.9
#3 0x0450848f in decaf::util::concurrent::Mutex::wait(long long, int) ()
from /usr/lib/libactivemq-cpp.so.9
#4 0x0450831a in decaf::util::concurrent::Mutex::wait(long long) ()
from /usr/lib/libactivemq-cpp.so.9
Thread 3:
#0 0xffffe410 in __kernel_vsyscall ()
#1 0x00ab7ef2 in pthread_cond_timedwait@@GLIBC_2.3.2 ()
from /lib/libpthread.so.0
#2 0x0448982b in
decaf::internal::util::concurrent::ConditionImpl::wait(decaf::util::concurrent::ConditionHandle*,
long long, long long) ()
from /usr/lib/libactivemq-cpp.so.9
#3 0x0450848f in decaf::util::concurrent::Mutex::wait(long long, int) ()
from /usr/lib/libactivemq-cpp.so.9
#4 0x0450831a in decaf::util::concurrent::Mutex::wait(long long) ()
from /usr/lib/libactivemq-cpp.so.9
#5 0x0448919c in
decaf::internal::util::concurrent::SynchronizableImpl::wait(long long)
() from /usr/lib/libactivemq-cpp.so.9
Thread 4:
#0 0xffffe410 in __kernel_vsyscall ()
#1 0x00ab7bc5 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0
#2 0x0448992a in
decaf::internal::util::concurrent::ConditionImpl::wait(decaf::util::concurrent::ConditionHandle*)
() from /usr/lib/libactivemq-cpp.so.9
#3 0x045084d9 in decaf::util::concurrent::Mutex::wait() ()
from /usr/lib/libactivemq-cpp.so.9
#4 0x041d66e2 in activemq::threads::CompositeTaskRunner::run() ()
Re: CMS and EINTR signal
Posted by Timothy Bish <ta...@gmail.com>.
On Fri, 2010-09-17 at 10:18 -0500, Devin Venable wrote:
> I've got a question for the developers of CMS. If this isn't the best
> forum, please direct me to the the best place to pose such questions.
>
> I've implemented an activemq-cpp producer on a program that reads and
> writes to a Linux message queue (#include <mqueue.h>). I noticed that
> my program was intermittently shutting down, and the cause is logic
> that reads from the queue, checks for an error, and then continues if
> all is well. Since implementing activemq, a new error type is showing
> up that wasn't handled by our logic: EINTR which means "Interrupted
> system call".
>
What version of ActiveMQ-CPP are you using?
What OS and Compiler?
Have you tracked where the EINTR signal is coming from? It shouldn't be
coming from CMS unless there is a bug in the code. It would be helpful
to know what operation is throwing the EINTR signal.
> Note that I only see this when I set CMS to run in async mode, using this flag:
>
> useAsyncSend=true
>
> I need to run the producer in async mode because I can't block if
> ActiveMQ can't be reached for some reason.
>
> So my questions are:
> Is this behavior normal or expected?
> Is there a different combination of flags that I should use when
> starting the producer?
>
> I can write code that handles the EINTR case, and from what I've read,
> this code should probably already be doing that. But I wanted to
> learn more about what might be causing this as well.
Regards
--
Tim Bish
Open Source Integration: http://fusesource.com
Follow me on Twitter: http://twitter.com/tabish121
My Blog: http://timbish.blogspot.com/