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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>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 <[EMAIL PROTECTED]>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 <[EMAIL PROTECTED]>
>>> 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/
>>>
>>
>>
>
