You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@servicemix.apache.org by Ryan Moquin <fr...@gmail.com> on 2008/08/01 08:33:25 UTC
Re: Question about Servicemix-bean and multiple beans per service unit
Forgot to respond to this message, doh! Here is the stack trace I'm
getting. I seem to be getting this a lot lately and while the system is
under no load. It just starts doing this when I try to send out from my
bean using the delivery channel. I remember you reviewing this same code
for the same stack trace a couple weeks back, which was a result of too
small a thread pool. Now I'm getting this error lately when there is no
load on the server. I have a quartz service that invokes this bean every 15
seconds.
ERROR - JbiNotificationHandlerImpl - Error sending notification to
service: urn://service.notification.com notification-jms-service
at
com.notification.impl.JbiNotificationHandlerImpl.sendNotification(JbiNotificati
onHandlerImpl.java:83)
at
com.notification.impl.DataCollectorImpl.onMessageExchange(DataCollectorImpl.java:228)
at
org.apache.servicemix.bean.BeanEndpoint.onProviderExchange(BeanEndpoint.java:235)
at
org.apache.servicemix.bean.BeanEndpoint.process(BeanEndpoint.java:211)
at
org.apache.servicemix.common.AsyncBaseLifeCycle.doProcess(AsyncBaseLifeCycle.java:538)
at
org.apache.servicemix.common.AsyncBaseLifeCycle.processExchange(AsyncBaseLifeCycle.java:490)
at
org.apache.servicemix.common.BaseLifeCycle.onMessageExchange(BaseLifeCycle.java:46)
at
org.apache.servicemix.jbi.messaging.DeliveryChannelImpl.processInBound(DeliveryChannelImpl.java:610)
at
org.apache.servicemix.jbi.nmr.flow.AbstractFlow.doRouting(AbstractFlow.java:172)
at
org.apache.servicemix.jbi.nmr.flow.seda.SedaFlow.doRouting(SedaFlow.java:167)
at
org.apache.servicemix.jbi.nmr.flow.seda.SedaQueue$1.run(SedaQueue.java:134)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:885)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)
at java.lang.Thread.run(Thread.java:619)
Caused by: java.lang.NullPointerException
at
java.util.concurrent.ConcurrentHashMap.put(ConcurrentHashMap.java:881)
at
org.apache.servicemix.bean.BeanEndpoint$PojoChannel.send(BeanEndpoint.java:569)
at
com.notification.impl.JbiNotificationHandlerImpl.sendNotification(JbiNotificati
onHandlerImpl.java:81)
... 16 more
On Mon, Jul 28, 2008 at 3:27 AM, Guillaume Nodet <gn...@gmail.com> wrote:
> The DeliveryChannel provided by the container is thread safe.
> However, this delivery channel is wrapped by the component when used
> for a particular endpoint, so there may be a threading problem there.
> However, this wrapper is used by all components and I doubts there is
> a threading problem there. But the servicemix-bean component does
> some very specific stuff when a request arrive to a bean endpoint to
> map this request to a known bean instance (in case the bean is created
> by the endpoint for each request), so the problem could be there.
> Could you paste the full exception stack trace please ?
>
> On Mon, Jul 28, 2008 at 3:00 AM, Ryan Moquin <fr...@gmail.com>
> wrote:
> > Out of curiousity, we have a servicemix-bean component that instantiates
> 4
> > total beans. 2 of which are used by external services (they are
> considered
> > a "live" and "test" version of the bean type), but both of those bean
> > instances provide the same functionality. So my question is that if both
> of
> > those bean classes, which live in the save service unit, both execute at
> the
> > same time and use an injected DeliveryChannel, should there be a
> threading
> > problem? I would assume not, provided that request invoking each bean
> are
> > separate threads and the thread pool isn't exhausted. For some reason
> > though, if I use a quartz timer to send an invocation to each of those
> two
> > deployed beans (which of course are on different endpoints), I get the
> NPE
> > in the deliverychannel bean pojo send method that I had a ton of problems
> > with before. This test is under low load and there aren't any resource
> > issues, such as a thread pool running out like I had before. If I
> disable
> > one of the beans, then I never see this error occur, it happens
> consistently
> > any time the two beans in the same SU execute at the same time and try to
> > use the deliverychannel. I thought the servicemix code was synchronized
> to
> > prevent this, but I wanted to pick brains to see if what I'm seeing is in
> > ANY WAY possible, or if it seems more like it would be be an error in my
> > application code? The NPE definitely happens down in servicemix in a
> spot
> > that should be synchronized on the current thread. The bean invocations
> > should be on different threads and therefore this shouldn't happen, but
> want
> > to make sure.
> >
> > I can post more details if necessary, but it's pretty straightforward (I
> > think). If not, I'll go ahead and post more details. Thanks!! I can go
> > back to synchronizing the code where the DeliveryChannel is used, I'm
> just
> > not sure the best way to be sure that I don't end up causing a race
> > condition of some kind, so I hate to do it unless I know it's safe.
> >
> > Ryan
> >
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
>
Re: Question about Servicemix-bean and multiple beans per service unit
Posted by Ryan Moquin <fr...@gmail.com>.
Ok, so I really believe there is another threading problem in the
DeliveryContext somewhere. I finally was able to switch to creating a
ServicemixClient by looking it up in the JNDI context and that appears to
avoid the NPE. The situations I've run into where this bug seems to
manifest itself are the following:
Two defined servicemix beans in the same service-unit that are both invoked
at the same time by servicemix-quartz components. The cause is that when
both beans are invoked at the same time and use the DeliveryChannel (or a
servicemixclient created from an injected ComponentContext ) at the same
time, appears to cause this problem (I was sending to a JMS provider).
The other scenario is if you locally have one servicemix-bean simply do some
processing on an interval from a quartz timer it sets up itself, the NPE
will always occur when it tries to send a result message to a JMS provider
using the DeliveryChannel.
I don't know if either of these situations are invalid use cases, but they
were different things I've tried that fit my requirements (my
servicemix-bean services I created should really be service-engines, I
realize that and I will make them eventually which may help) but also
created this problem. Using a servicemix client that isn't created from an
injected resource does not appear to cause any problem.
If I can get a few minutes to create a quick boiled down example, I will and
I'll open a bug report (since I'll have replicable proof).
Thanks!!
On Fri, Aug 8, 2008 at 2:35 PM, Ryan Moquin <fr...@gmail.com> wrote:
> I almost think there has to be a threading problem. I've gone over this
> code several times and it seems to be nearly impossible to send an exchange
> from my bean component, to a JMS component while it's doing processing from
> in incoming exchange. I decided to take one of the beans out of my
> servicemix-bean component so that I only have one endpoint deployed in that
> service. I then created a servicemixclient off the ComponentContext, hoping
> somehow that would be different than using the delivery channel directly,
> yet that results in the same error:
>
> Caused by: java.lang.NullPointerException
> at
> java.util.concurrent.ConcurrentHashMap.put(ConcurrentHashMap.java:881)
> at
> org.apache.servicemix.bean.BeanEndpoint$PojoChannel.send(BeanEndpoint.java:569)
> at
> org.apache.servicemix.client.ServiceMixClientFacade.send(ServiceMixClientFacade.java:147)
> at
> com.notification.impl.JbiNotificationHandlerImpl.sendNotification(JbiNotificati
> onHandlerImpl.java:79)
>
> I guess the only thing I have left that I can do is try to look up a
> servicemixclient from JNDI since it seems like trying to send an exchange
> from anything relating to the current servicemix-bean component is easily
> interferred with.
>
> Currently my sending code looks like this:
>
> if (destinationQname == null) {
> destinationQname = new QName(getDestinationNamespace(),
> getDestinationService());
> }
> InOnly exchange = client.createInOnlyExchange();
> exchange.getInMessage().setContent(new
> StringSource(writer.toString()));
> exchange.setService(destinationQname);
> client.send(exchange);
>
> and results in the above exception, which is the same as sending from the
> deliverychannel directly.
>
>
>
> On Fri, Aug 1, 2008 at 2:38 AM, Ryan Moquin <fr...@gmail.com>wrote:
>
>> Actually I'll say that again, it seems to be happening when I have 2 beans
>> deployed in the same servicemix-bean component. I would like to say that
>> it's caused when both of them have received an exchange and are processing
>> at the same time. Both of the servicemix beans are invoked by a quartz
>> service every 15 seconds. If I comment out one of the beans, then I don't
>> get the error anymore. It's only when I have both of them uncommented that
>> I start seeing this error.
>>
>>
>> On Fri, Aug 1, 2008 at 2:33 AM, Ryan Moquin <fr...@gmail.com>wrote:
>>
>>> Forgot to respond to this message, doh! Here is the stack trace I'm
>>> getting. I seem to be getting this a lot lately and while the system is
>>> under no load. It just starts doing this when I try to send out from my
>>> bean using the delivery channel. I remember you reviewing this same code
>>> for the same stack trace a couple weeks back, which was a result of too
>>> small a thread pool. Now I'm getting this error lately when there is no
>>> load on the server. I have a quartz service that invokes this bean every 15
>>> seconds.
>>>
>>> ERROR - JbiNotificationHandlerImpl - Error sending notification
>>> to service: urn://service.notification.com notification-jms-service
>>> at
>>> com.notification.impl.JbiNotificationHandlerImpl.sendNotification(JbiNotificati
>>> onHandlerImpl.java:83)
>>> at
>>> com.notification.impl.DataCollectorImpl.onMessageExchange(DataCollectorImpl.java:228)
>>> at
>>> org.apache.servicemix.bean.BeanEndpoint.onProviderExchange(BeanEndpoint.java:235)
>>> at
>>> org.apache.servicemix.bean.BeanEndpoint.process(BeanEndpoint.java:211)
>>> at
>>> org.apache.servicemix.common.AsyncBaseLifeCycle.doProcess(AsyncBaseLifeCycle.java:538)
>>> at
>>> org.apache.servicemix.common.AsyncBaseLifeCycle.processExchange(AsyncBaseLifeCycle.java:490)
>>> at
>>> org.apache.servicemix.common.BaseLifeCycle.onMessageExchange(BaseLifeCycle.java:46)
>>> at
>>> org.apache.servicemix.jbi.messaging.DeliveryChannelImpl.processInBound(DeliveryChannelImpl.java:610)
>>> at
>>> org.apache.servicemix.jbi.nmr.flow.AbstractFlow.doRouting(AbstractFlow.java:172)
>>> at
>>> org.apache.servicemix.jbi.nmr.flow.seda.SedaFlow.doRouting(SedaFlow.java:167)
>>> at
>>> org.apache.servicemix.jbi.nmr.flow.seda.SedaQueue$1.run(SedaQueue.java:134)
>>> at
>>> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:885)
>>> at
>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)
>>> at java.lang.Thread.run(Thread.java:619)
>>> Caused by: java.lang.NullPointerException
>>> at
>>> java.util.concurrent.ConcurrentHashMap.put(ConcurrentHashMap.java:881)
>>> at
>>> org.apache.servicemix.bean.BeanEndpoint$PojoChannel.send(BeanEndpoint.java:569)
>>> at
>>> com.notification.impl.JbiNotificationHandlerImpl.sendNotification(JbiNotificati
>>> onHandlerImpl.java:81)
>>> ... 16 more
>>>
>>>
>>> On Mon, Jul 28, 2008 at 3:27 AM, Guillaume Nodet <gn...@gmail.com>wrote:
>>>
>>>> The DeliveryChannel provided by the container is thread safe.
>>>> However, this delivery channel is wrapped by the component when used
>>>> for a particular endpoint, so there may be a threading problem there.
>>>> However, this wrapper is used by all components and I doubts there is
>>>> a threading problem there. But the servicemix-bean component does
>>>> some very specific stuff when a request arrive to a bean endpoint to
>>>> map this request to a known bean instance (in case the bean is created
>>>> by the endpoint for each request), so the problem could be there.
>>>> Could you paste the full exception stack trace please ?
>>>>
>>>> On Mon, Jul 28, 2008 at 3:00 AM, Ryan Moquin <fr...@gmail.com>
>>>> wrote:
>>>> > Out of curiousity, we have a servicemix-bean component that
>>>> instantiates 4
>>>> > total beans. 2 of which are used by external services (they are
>>>> considered
>>>> > a "live" and "test" version of the bean type), but both of those bean
>>>> > instances provide the same functionality. So my question is that if
>>>> both of
>>>> > those bean classes, which live in the save service unit, both execute
>>>> at the
>>>> > same time and use an injected DeliveryChannel, should there be a
>>>> threading
>>>> > problem? I would assume not, provided that request invoking each bean
>>>> are
>>>> > separate threads and the thread pool isn't exhausted. For some reason
>>>> > though, if I use a quartz timer to send an invocation to each of those
>>>> two
>>>> > deployed beans (which of course are on different endpoints), I get the
>>>> NPE
>>>> > in the deliverychannel bean pojo send method that I had a ton of
>>>> problems
>>>> > with before. This test is under low load and there aren't any
>>>> resource
>>>> > issues, such as a thread pool running out like I had before. If I
>>>> disable
>>>> > one of the beans, then I never see this error occur, it happens
>>>> consistently
>>>> > any time the two beans in the same SU execute at the same time and try
>>>> to
>>>> > use the deliverychannel. I thought the servicemix code was
>>>> synchronized to
>>>> > prevent this, but I wanted to pick brains to see if what I'm seeing is
>>>> in
>>>> > ANY WAY possible, or if it seems more like it would be be an error in
>>>> my
>>>> > application code? The NPE definitely happens down in servicemix in a
>>>> spot
>>>> > that should be synchronized on the current thread. The bean
>>>> invocations
>>>> > should be on different threads and therefore this shouldn't happen,
>>>> but want
>>>> > to make sure.
>>>> >
>>>> > I can post more details if necessary, but it's pretty straightforward
>>>> (I
>>>> > think). If not, I'll go ahead and post more details. Thanks!! I can
>>>> go
>>>> > back to synchronizing the code where the DeliveryChannel is used, I'm
>>>> just
>>>> > not sure the best way to be sure that I don't end up causing a race
>>>> > condition of some kind, so I hate to do it unless I know it's safe.
>>>> >
>>>> > Ryan
>>>> >
>>>>
>>>>
>>>>
>>>> --
>>>> Cheers,
>>>> Guillaume Nodet
>>>> ------------------------
>>>> Blog: http://gnodet.blogspot.com/
>>>>
>>>
>>>
>>
>
Re: Question about Servicemix-bean and multiple beans per service unit
Posted by Ryan Moquin <fr...@gmail.com>.
I almost think there has to be a threading problem. I've gone over this
code several times and it seems to be nearly impossible to send an exchange
from my bean component, to a JMS component while it's doing processing from
in incoming exchange. I decided to take one of the beans out of my
servicemix-bean component so that I only have one endpoint deployed in that
service. I then created a servicemixclient off the ComponentContext, hoping
somehow that would be different than using the delivery channel directly,
yet that results in the same error:
Caused by: java.lang.NullPointerException
at
java.util.concurrent.ConcurrentHashMap.put(ConcurrentHashMap.java:881)
at
org.apache.servicemix.bean.BeanEndpoint$PojoChannel.send(BeanEndpoint.java:569)
at
org.apache.servicemix.client.ServiceMixClientFacade.send(ServiceMixClientFacade.java:147)
at
com.notification.impl.JbiNotificationHandlerImpl.sendNotification(JbiNotificati
onHandlerImpl.java:79)
I guess the only thing I have left that I can do is try to look up a
servicemixclient from JNDI since it seems like trying to send an exchange
from anything relating to the current servicemix-bean component is easily
interferred with.
Currently my sending code looks like this:
if (destinationQname == null) {
destinationQname = new QName(getDestinationNamespace(),
getDestinationService());
}
InOnly exchange = client.createInOnlyExchange();
exchange.getInMessage().setContent(new
StringSource(writer.toString()));
exchange.setService(destinationQname);
client.send(exchange);
and results in the above exception, which is the same as sending from the
deliverychannel directly.
On Fri, Aug 1, 2008 at 2:38 AM, Ryan Moquin <fr...@gmail.com> wrote:
> Actually I'll say that again, it seems to be happening when I have 2 beans
> deployed in the same servicemix-bean component. I would like to say that
> it's caused when both of them have received an exchange and are processing
> at the same time. Both of the servicemix beans are invoked by a quartz
> service every 15 seconds. If I comment out one of the beans, then I don't
> get the error anymore. It's only when I have both of them uncommented that
> I start seeing this error.
>
>
> On Fri, Aug 1, 2008 at 2:33 AM, Ryan Moquin <fr...@gmail.com>wrote:
>
>> Forgot to respond to this message, doh! Here is the stack trace I'm
>> getting. I seem to be getting this a lot lately and while the system is
>> under no load. It just starts doing this when I try to send out from my
>> bean using the delivery channel. I remember you reviewing this same code
>> for the same stack trace a couple weeks back, which was a result of too
>> small a thread pool. Now I'm getting this error lately when there is no
>> load on the server. I have a quartz service that invokes this bean every 15
>> seconds.
>>
>> ERROR - JbiNotificationHandlerImpl - Error sending notification
>> to service: urn://service.notification.com notification-jms-service
>> at
>> com.notification.impl.JbiNotificationHandlerImpl.sendNotification(JbiNotificati
>> onHandlerImpl.java:83)
>> at
>> com.notification.impl.DataCollectorImpl.onMessageExchange(DataCollectorImpl.java:228)
>> at
>> org.apache.servicemix.bean.BeanEndpoint.onProviderExchange(BeanEndpoint.java:235)
>> at
>> org.apache.servicemix.bean.BeanEndpoint.process(BeanEndpoint.java:211)
>> at
>> org.apache.servicemix.common.AsyncBaseLifeCycle.doProcess(AsyncBaseLifeCycle.java:538)
>> at
>> org.apache.servicemix.common.AsyncBaseLifeCycle.processExchange(AsyncBaseLifeCycle.java:490)
>> at
>> org.apache.servicemix.common.BaseLifeCycle.onMessageExchange(BaseLifeCycle.java:46)
>> at
>> org.apache.servicemix.jbi.messaging.DeliveryChannelImpl.processInBound(DeliveryChannelImpl.java:610)
>> at
>> org.apache.servicemix.jbi.nmr.flow.AbstractFlow.doRouting(AbstractFlow.java:172)
>> at
>> org.apache.servicemix.jbi.nmr.flow.seda.SedaFlow.doRouting(SedaFlow.java:167)
>> at
>> org.apache.servicemix.jbi.nmr.flow.seda.SedaQueue$1.run(SedaQueue.java:134)
>> at
>> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:885)
>> at
>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)
>> at java.lang.Thread.run(Thread.java:619)
>> Caused by: java.lang.NullPointerException
>> at
>> java.util.concurrent.ConcurrentHashMap.put(ConcurrentHashMap.java:881)
>> at
>> org.apache.servicemix.bean.BeanEndpoint$PojoChannel.send(BeanEndpoint.java:569)
>> at
>> com.notification.impl.JbiNotificationHandlerImpl.sendNotification(JbiNotificati
>> onHandlerImpl.java:81)
>> ... 16 more
>>
>>
>> On Mon, Jul 28, 2008 at 3:27 AM, Guillaume Nodet <gn...@gmail.com>wrote:
>>
>>> The DeliveryChannel provided by the container is thread safe.
>>> However, this delivery channel is wrapped by the component when used
>>> for a particular endpoint, so there may be a threading problem there.
>>> However, this wrapper is used by all components and I doubts there is
>>> a threading problem there. But the servicemix-bean component does
>>> some very specific stuff when a request arrive to a bean endpoint to
>>> map this request to a known bean instance (in case the bean is created
>>> by the endpoint for each request), so the problem could be there.
>>> Could you paste the full exception stack trace please ?
>>>
>>> On Mon, Jul 28, 2008 at 3:00 AM, Ryan Moquin <fr...@gmail.com>
>>> wrote:
>>> > Out of curiousity, we have a servicemix-bean component that
>>> instantiates 4
>>> > total beans. 2 of which are used by external services (they are
>>> considered
>>> > a "live" and "test" version of the bean type), but both of those bean
>>> > instances provide the same functionality. So my question is that if
>>> both of
>>> > those bean classes, which live in the save service unit, both execute
>>> at the
>>> > same time and use an injected DeliveryChannel, should there be a
>>> threading
>>> > problem? I would assume not, provided that request invoking each bean
>>> are
>>> > separate threads and the thread pool isn't exhausted. For some reason
>>> > though, if I use a quartz timer to send an invocation to each of those
>>> two
>>> > deployed beans (which of course are on different endpoints), I get the
>>> NPE
>>> > in the deliverychannel bean pojo send method that I had a ton of
>>> problems
>>> > with before. This test is under low load and there aren't any resource
>>> > issues, such as a thread pool running out like I had before. If I
>>> disable
>>> > one of the beans, then I never see this error occur, it happens
>>> consistently
>>> > any time the two beans in the same SU execute at the same time and try
>>> to
>>> > use the deliverychannel. I thought the servicemix code was
>>> synchronized to
>>> > prevent this, but I wanted to pick brains to see if what I'm seeing is
>>> in
>>> > ANY WAY possible, or if it seems more like it would be be an error in
>>> my
>>> > application code? The NPE definitely happens down in servicemix in a
>>> spot
>>> > that should be synchronized on the current thread. The bean
>>> invocations
>>> > should be on different threads and therefore this shouldn't happen, but
>>> want
>>> > to make sure.
>>> >
>>> > I can post more details if necessary, but it's pretty straightforward
>>> (I
>>> > think). If not, I'll go ahead and post more details. Thanks!! I can
>>> go
>>> > back to synchronizing the code where the DeliveryChannel is used, I'm
>>> just
>>> > not sure the best way to be sure that I don't end up causing a race
>>> > condition of some kind, so I hate to do it unless I know it's safe.
>>> >
>>> > Ryan
>>> >
>>>
>>>
>>>
>>> --
>>> Cheers,
>>> Guillaume Nodet
>>> ------------------------
>>> Blog: http://gnodet.blogspot.com/
>>>
>>
>>
>
Re: Question about Servicemix-bean and multiple beans per service unit
Posted by Ryan Moquin <fr...@gmail.com>.
Actually I'll say that again, it seems to be happening when I have 2 beans
deployed in the same servicemix-bean component. I would like to say that
it's caused when both of them have received an exchange and are processing
at the same time. Both of the servicemix beans are invoked by a quartz
service every 15 seconds. If I comment out one of the beans, then I don't
get the error anymore. It's only when I have both of them uncommented that
I start seeing this error.
On Fri, Aug 1, 2008 at 2:33 AM, Ryan Moquin <fr...@gmail.com> wrote:
> Forgot to respond to this message, doh! Here is the stack trace I'm
> getting. I seem to be getting this a lot lately and while the system is
> under no load. It just starts doing this when I try to send out from my
> bean using the delivery channel. I remember you reviewing this same code
> for the same stack trace a couple weeks back, which was a result of too
> small a thread pool. Now I'm getting this error lately when there is no
> load on the server. I have a quartz service that invokes this bean every 15
> seconds.
>
> ERROR - JbiNotificationHandlerImpl - Error sending notification
> to service: urn://service.notification.com notification-jms-service
> at
> com.notification.impl.JbiNotificationHandlerImpl.sendNotification(JbiNotificati
> onHandlerImpl.java:83)
> at
> com.notification.impl.DataCollectorImpl.onMessageExchange(DataCollectorImpl.java:228)
> at
> org.apache.servicemix.bean.BeanEndpoint.onProviderExchange(BeanEndpoint.java:235)
> at
> org.apache.servicemix.bean.BeanEndpoint.process(BeanEndpoint.java:211)
> at
> org.apache.servicemix.common.AsyncBaseLifeCycle.doProcess(AsyncBaseLifeCycle.java:538)
> at
> org.apache.servicemix.common.AsyncBaseLifeCycle.processExchange(AsyncBaseLifeCycle.java:490)
> at
> org.apache.servicemix.common.BaseLifeCycle.onMessageExchange(BaseLifeCycle.java:46)
> at
> org.apache.servicemix.jbi.messaging.DeliveryChannelImpl.processInBound(DeliveryChannelImpl.java:610)
> at
> org.apache.servicemix.jbi.nmr.flow.AbstractFlow.doRouting(AbstractFlow.java:172)
> at
> org.apache.servicemix.jbi.nmr.flow.seda.SedaFlow.doRouting(SedaFlow.java:167)
> at
> org.apache.servicemix.jbi.nmr.flow.seda.SedaQueue$1.run(SedaQueue.java:134)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:885)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)
> at java.lang.Thread.run(Thread.java:619)
> Caused by: java.lang.NullPointerException
> at
> java.util.concurrent.ConcurrentHashMap.put(ConcurrentHashMap.java:881)
> at
> org.apache.servicemix.bean.BeanEndpoint$PojoChannel.send(BeanEndpoint.java:569)
> at
> com.notification.impl.JbiNotificationHandlerImpl.sendNotification(JbiNotificati
> onHandlerImpl.java:81)
> ... 16 more
>
>
> On Mon, Jul 28, 2008 at 3:27 AM, Guillaume Nodet <gn...@gmail.com> wrote:
>
>> The DeliveryChannel provided by the container is thread safe.
>> However, this delivery channel is wrapped by the component when used
>> for a particular endpoint, so there may be a threading problem there.
>> However, this wrapper is used by all components and I doubts there is
>> a threading problem there. But the servicemix-bean component does
>> some very specific stuff when a request arrive to a bean endpoint to
>> map this request to a known bean instance (in case the bean is created
>> by the endpoint for each request), so the problem could be there.
>> Could you paste the full exception stack trace please ?
>>
>> On Mon, Jul 28, 2008 at 3:00 AM, Ryan Moquin <fr...@gmail.com>
>> wrote:
>> > Out of curiousity, we have a servicemix-bean component that instantiates
>> 4
>> > total beans. 2 of which are used by external services (they are
>> considered
>> > a "live" and "test" version of the bean type), but both of those bean
>> > instances provide the same functionality. So my question is that if
>> both of
>> > those bean classes, which live in the save service unit, both execute at
>> the
>> > same time and use an injected DeliveryChannel, should there be a
>> threading
>> > problem? I would assume not, provided that request invoking each bean
>> are
>> > separate threads and the thread pool isn't exhausted. For some reason
>> > though, if I use a quartz timer to send an invocation to each of those
>> two
>> > deployed beans (which of course are on different endpoints), I get the
>> NPE
>> > in the deliverychannel bean pojo send method that I had a ton of
>> problems
>> > with before. This test is under low load and there aren't any resource
>> > issues, such as a thread pool running out like I had before. If I
>> disable
>> > one of the beans, then I never see this error occur, it happens
>> consistently
>> > any time the two beans in the same SU execute at the same time and try
>> to
>> > use the deliverychannel. I thought the servicemix code was synchronized
>> to
>> > prevent this, but I wanted to pick brains to see if what I'm seeing is
>> in
>> > ANY WAY possible, or if it seems more like it would be be an error in my
>> > application code? The NPE definitely happens down in servicemix in a
>> spot
>> > that should be synchronized on the current thread. The bean invocations
>> > should be on different threads and therefore this shouldn't happen, but
>> want
>> > to make sure.
>> >
>> > I can post more details if necessary, but it's pretty straightforward (I
>> > think). If not, I'll go ahead and post more details. Thanks!! I can
>> go
>> > back to synchronizing the code where the DeliveryChannel is used, I'm
>> just
>> > not sure the best way to be sure that I don't end up causing a race
>> > condition of some kind, so I hate to do it unless I know it's safe.
>> >
>> > Ryan
>> >
>>
>>
>>
>> --
>> Cheers,
>> Guillaume Nodet
>> ------------------------
>> Blog: http://gnodet.blogspot.com/
>>
>
>