Tysdag 16. desember 2008 10:35:36 skreiv Claus Ibsen:
> Hi
>
> Sorry the NPE bug is fixed in 1.5.0, my bad. It was 1.4.0 that had this
> error.
>
> You might need to show how your client is configured with ActiveMQ and
> the camel routing.
> There might be an issue there. You should use the activemq component
> for AMQ instead of the generic JMS component.
After I saw this mentioned, I changed from JmsComponent to ActiveMQComponent
without any apparent differences in behaviour.
In the spring config I have this:
<amq:broker useJmx="false" persistent="false">
<amq:transportConnectors>
<amq:transportConnector uri="tcp://localhost:61617" />
</amq:transportConnectors>
</amq:broker>
-- some topics and queues
<!-- JMS ConnectionFactory to use, configuring the embedded broker
using XML
-->
<bean id="jmsConnxFactory"
class="org.apache.activemq.pool.PooledConnectionFactory" destroy-
method="stop">
<property name="connectionFactory">
<bean
class="org.apache.activemq.ActiveMQConnectionFactory">
<property name="brokerURL">
<value>failover:tcp://localhost:61617</value>
</property>
</bean>
</property>
<property name="maxConnections" value="2" />
<property name="maximumActive" value="2" />
</bean>
<camel:camelContext id="camel">
<camel:package>com.foo.bar</camel:package>
<camel:template id="camelTemplate"
defaultEndpoint="jms:topic:inbox" />
</camel:camelContext>
Further, in the routebuilder code:
@Autowired
private ConnectionFactory jmsConnxFactory;
and in configure()
JmsComponent jmsComponent =
ActiveMQComponent.jmsComponentAutoAcknowledge(
jmsConnxFactory );
jmsComponent.getConfiguration().setConsumerType(
ConsumerType.Simple );
// getContext().addInterceptStrategy(new Tracer());
getContext().addComponent( "jms", jmsComponent );
The accepting queue forwards the message to "seda:repo", where there is some
type checking before it is sent to the correct handler bean. The handler is
declared as such:
@Autowired
private DefaultProducerTemplate<Exchange> camelTemplate;
@Transactional
public void handleMessage(@Body
FooMessage msg, @Headers
Map<String, Object> headers,
Exchange exchange) {
<some logic and db retrieval>
for (Foo foo : foos) {
camelTemplate.sendBodyAndHeaders( new FooMessage(
FooAction.UPDATE, foo ),
headers );
}
}
Thanks for the help sofar.
Best,
Lars Ivar
>
> Thanks for the stacktrace. Will look into it later.
>
>
>
> On Tue, Dec 16, 2008 at 10:02 AM, Lars Ivar Igesund
>
> <[email protected]> wrote:
> > Tysdag 16. desember 2008 06:21:24 skreiv Claus Ibsen:
> >> On Tue, Dec 16, 2008 at 12:56 AM, Lars Ivar Igesund
> >>
> >> <[email protected]> wrote:
> >> > Hi!
> >> >
> >> > We have a central routing application/server using spring and camel
> >> > and AMQ, and various clients connecting to it.
> >> >
> >> > Now, for the last couple of months we've been using 1.4.0 which
> >> > generally works fine. However, fairly often after a restart of the
> >> > server app (it is still under development), it hangs as it replies to
> >> > the first client to connect.
> >> >
> >> > I've not been able to get a stack trace, but the information I do have
> >> > is that I use sendBodyAndHeaders from DefaultProducerTemplate
> >> > instance, and that it logs ">>>> endpoint + " " + exchange" in
> >> > ProducerCache.
> >>
> >> Which kind of producer is it? JMS, Http etc? Have you enabled
> >> DEBUG/TRACE logging for that producer. It might log a bit more where
> >> it "hangs".
> >
> > It is JMS using AMQ. Enabling DEBUG/TRACE for org.apache.activemq in
> > addition to CAMEL yields no more information - the next messages after
> > the one in ProducerCache are from the InactivityMonitor.
> >
> > An additional point is that this only seems to happen (don't have proof
> > for this) if I start the client immediately after the server is done
> > starting up (ie Camel and AMQ appears to be done logging) - if I wait
> > some, say 30 seconds, it seems to work fine.
> >
> > Maybe there is a deadlock if trying to send with a resource that isn't
> > fully constructed yet?
> >
> >> > Then I tried to upgrade to 1.5.0, this does however not work at all
> >> > (it compiles without problems), as I get a NullPointerException on
> >> > line 186 of component/bean/MethodInfo - seems like there is a null
> >> > expression.
> >>
> >> Could you paste the stacktrace and a bit more info on ths NPE? There
> >> is a known issue if a message contains a null body and you use the
> >> tracer to log it.
> >
> > java.lang.NullPointerException
> > at
> > org.apache.camel.component.bean.MethodInfo$2.evaluate(MethodInfo.java:186
> >) at
> > org.apache.camel.component.bean.MethodInfo.createMethodInvocation(MethodI
> >nfo.java:78) at
> > org.apache.camel.component.bean.BeanInfo.createInvocation(BeanInfo.java:1
> >21) at
> > org.apache.camel.component.bean.BeanProcessor.process(BeanProcessor.java:
> >111) at
> > org.apache.camel.impl.ProcessorEndpoint.onExchange(ProcessorEndpoint.java
> >:92) at
> > org.apache.camel.impl.ProcessorEndpoint$1.process(ProcessorEndpoint.java:
> >66) at
> > org.apache.camel.processor.SendProcessor.process(SendProcessor.java:61)
> > at
> > org.apache.camel.processor.DelegateProcessor.processNext(DelegateProcesso
> >r.java:50) at
> > org.apache.camel.processor.DelegateProcessor.proceed(DelegateProcessor.ja
> >va:79) at
> > org.apache.camel.processor.interceptor.TraceInterceptor.process(TraceInte
> >rceptor.java:84) at
> > org.apache.camel.processor.DelegateProcessor.processNext(DelegateProcesso
> >r.java:50) at
> > org.apache.camel.processor.ChoiceProcessor.process(ChoiceProcessor.java:5
> >0) at
> > org.apache.camel.processor.DelegateProcessor.processNext(DelegateProcesso
> >r.java:50) at
> > org.apache.camel.processor.DelegateProcessor.proceed(DelegateProcessor.ja
> >va:79) at
> > org.apache.camel.processor.interceptor.TraceInterceptor.process(TraceInte
> >rceptor.java:84) at
> > org.apache.camel.management.InstrumentationProcessor.process(Instrumentat
> >ionProcessor.java:75) at
> > org.apache.camel.processor.DeadLetterChannel.process(DeadLetterChannel.ja
> >va:172) at
> > org.apache.camel.processor.DeadLetterChannel.process(DeadLetterChannel.ja
> >va:93) at
> > org.apache.camel.management.InstrumentationProcessor.process(Instrumentat
> >ionProcessor.java:63) at
> > org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelper.j
> >ava:41) at
> > org.apache.camel.management.InstrumentationProcessor.process(Instrumentat
> >ionProcessor.java:50) at
> > org.apache.camel.processor.DelegateProcessor.processNext(DelegateProcesso
> >r.java:50) at
> > org.apache.camel.processor.DelegateProcessor.proceed(DelegateProcessor.ja
> >va:79) at
> > org.apache.camel.processor.interceptor.TraceInterceptor.process(TraceInte
> >rceptor.java:84) at
> > org.apache.camel.impl.converter.AsyncProcessorTypeConverter$ProcessorToAs
> >yncProcessorBridge.process(AsyncProcessorTypeConverter.java:43) at
> > org.apache.camel.processor.UnitOfWorkProcessor.process(UnitOfWorkProcesso
> >r.java:65) at
> > org.apache.camel.component.seda.SedaConsumer.run(SedaConsumer.java:69) at
> > java.lang.Thread.run(Thread.java:619)
> >
> > The Tracer and null messages bug was the reason for upgrading from 1.3.0
> > to 1.4.0 ... This issue in 1.5.0 is present even if I disable the tracer.
> > However, it is quite likely that the message object contains null
> > references.
> >
> > I did try to rebuild camel with an if (expression[i] != null) before the
> > NPE statement, something which seems to lead to a null reference to the
> > message headers instead (in my handler) (in case that is relevant
> > information).
> >
> > Best,
> > Lars Ivar
