[Installation, Configuration & DEPLOYMENT] - Re: Getting Log4j configured for an EAR: DLQHandler NullPoin
by mmichalek
Thanks for the response. I am using JBoss AS 4.2.2 and Java 1.5 (update 15) on Win XP.
anonymous wrote : Are you sure that this is the reason why your EJB2.0 fails to deploy
As far as I know, yes. There aren't any other stack traces present. The stack I posted previously was from the EJBDeployer's attempt to re-deploy the failed application, with JBoss' logging cranked up. Now that I've put the logging levels back to normal, I'm seeing WARN's and ERROR's again. Here is the first stack trace I get when started up JBoss (at WARN level).
| 14:42:34,352 WARN [JMSContainerInvoker] JMS provider failure detected for CfgEventLogConsumer
| java.lang.NullPointerException
| at org.jboss.ejb.plugins.jms.DLQHandler.createService(DLQHandler.java:187)
| at org.jboss.system.ServiceMBeanSupport.jbossInternalCreate(ServiceMBeanSupport.java:260)
| at org.jboss.system.ServiceMBeanSupport.create(ServiceMBeanSupport.java:188)
| at org.jboss.ejb.plugins.jms.JMSContainerInvoker.innerStartDelivery(JMSContainerInvoker.java:510)
| at org.jboss.ejb.plugins.jms.JMSContainerInvoker.startService(JMSContainerInvoker.java:839)
| at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289)
| at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:245)
| at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
| at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
| at java.lang.reflect.Method.invoke(Method.java:585)
| at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
| at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
| at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
| at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
| at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
| at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:978)
| . . .
|
Then I get this at a regular interval (re-deployment attempts):
| 14:46:05,963 INFO [JMSContainerInvoker] Waiting for reconnect internal 10000ms for CfgEventLogConsumer
| 14:46:15,963 INFO [JMSContainerInvoker] Trying to reconnect to JMS provider for CfgEventLogConsumer
| 14:46:15,963 ERROR [JMSContainerInvoker] Reconnect failed: JMS provider failure detected for CfgEventLogConsumer
| java.lang.NullPointerException
| at org.jboss.ejb.plugins.jms.DLQHandler.createService(DLQHandler.java:187)
| at org.jboss.system.ServiceMBeanSupport.jbossInternalCreate(ServiceMBeanSupport.java:260)
| at org.jboss.system.ServiceMBeanSupport.create(ServiceMBeanSupport.java:188)
| at org.jboss.ejb.plugins.jms.JMSContainerInvoker.innerStartDelivery(JMSContainerInvoker.java:510)
| at org.jboss.ejb.plugins.jms.JMSContainerInvoker$ExceptionListenerImpl$ExceptionListenerRunnable.run(JMSContainerInvoker.java:1428)
| at java.lang.Thread.run(Thread.java:595)
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4145619#4145619
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4145619
18 years, 2 months
[JBoss Messaging] - Re: ((BytesMessage)message).readBytes(...) on a redelivered
by plesur
Hi Jeff,
sorry wasn't available for the last two days.
I know now how I can prevent an empty byte-array on a redelivered bytemessage (redelivered by session.recover() on a non-transacted client_acknowledge-session)
which I get by invoking the previous mentioned standardoperations.
The problem 'at our site' seems to be based on the configuration attributes:
. DefaultRedeliveryDelay (messaging-service.xml) &
. RedeliveryDelay (destinations-service.xml) (overwrites ServerPeer default)
My testresults for readBytes(...) on a redelivered bytesmessage with payloadAsByteArray=[72, 73, 95, 74, 69, 70, 70, 10]:
using the standard non clustered destination: testQueue.
with 0 or 1 msec as DefaultRedeliveryDelay & RedeliveryDelay or no entry (RedeliveryDelay only of course)
are:
ServerPeer (DefaultRedeliveryDelay) --- Destination (RedeliveryDelay) --- Result (Content of byte[] after .readBytes(...))
-------------------------------------
0 --- 0 --- [0, 0, 0, 0, 0, 0, 0, 0]
1 --- 0 --- [0, 0, 0, 0, 0, 0, 0, 0]
0 --- 1 --- [72, 73, 95, 74, 69, 70, 70, 10]
1 --- 1 --- [72, 73, 95, 74, 69, 70, 70, 10]
0 --- / --- [0, 0, 0, 0, 0, 0, 0, 0]
1 --- / --- [72, 73, 95, 74, 69, 70, 70, 10]
The weird thing is that case #5 can be found as part of the default configuration.
Well it's hard to believe that 'our' problem is based only on these two attributes
(many others would have the same problem then) but I can live with it knowning
that in the end the final saying delayattribute must have an value greater or equal one msec.
lesse
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4145613#4145613
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4145613
18 years, 2 months