Re: [Resin-interest] Message driven bean woes
Jeff Schnitzer wrote:
I can't seem to get a message driven bean hooked up to a queue up in
Resin 4.0.8. It's been a problem since at least 4.0.6. The problem
is pretty straightforward:
web-app xmlns=http://caucho.com/ns/resin;
xmlns:ee=urn:java:ee
xmlns:jms=urn:java:com.caucho.jms
xmlns:test=urn:java:test
jms:FileQueue
ee:Nameddelivery/ee:Named
/jms:FileQueue
ejb-message-bean class=test.DeliveryListener
destination#{delivery}/destination
/ejb-message-bean
/web-app
Thanks. It's a timing issue in CanDI. The jms:FileQueue was added to a
lazy-init which wasn't being evaluated when the #{delivery} was
processed. The fix will be in the next snapshot.
-- Scott
Whenever Resin tries to configure this, I get:
[10-07-19 22:13:35.994] {main} WEB-INF/resin-web.xml:14: #{delivery}
value must not be null.
com.caucho.ejb.cfg.MessageBeanConfig.setDestination():
'destination' attribute may not be null
12:
13: ejb-message-bean class=test.DeliveryListener
14: destination#{delivery}/destination
15: /ejb-message-bean
16: /web-app
Is this not the correct way to create a named FileQueue? Is there
some other way to attach an ejb-message-bean to the queue?
The isolated sample project (not much besides that resin-web.xml) is here:
http://code.google.com/p/scratchmonkey/source/browse/#svn/resin4/message_driven_beans
BTW the docs seem to be somewhat erratic. Some places
(http://www.caucho.com/resin-javadoc/com/caucho/jms/FileQueue.html)
they say the config should be like this:
jms:FileQueue
jms:namedelivery/jms:name
/jms:FileQueue
...and some places
(http://caucho.com/resin-4.0/examples/jms-ioc-listener/index.xtp) they
say it should be like this:
jms-queue name=delivery /
Neither works :-(
Thanks,
Jeff
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Message driven bean woes
On Tue, Jul 20, 2010 at 12:21 PM, Scott Ferguson f...@caucho.com wrote:
Thanks. It's a timing issue in CanDI. The jms:FileQueue was added to a
lazy-init which wasn't being evaluated when the #{delivery} was
processed. The fix will be in the next snapshot.
Cool. If you get to a point where this is checked into Resin trunk,
I'd love to help you test it :-)
Jeff
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Message driven bean woes
By the way, I was able to work past the lazy-init issue (presumably)
by using this block instead:
cfg:MessageBeanConfig
cfg:classtest.DeliveryListener/cfg:class
cfg:destination#{delivery}/cfg:destination
/cfg:MessageBeanConfig
However, enqueueing a message doesn't produce calls on my Listener.
It seems to produce some sort of spin-loop inside Resin.
Jeff
On Tue, Jul 20, 2010 at 1:17 PM, Jeff Schnitzer j...@infohazard.org wrote:
On Tue, Jul 20, 2010 at 12:21 PM, Scott Ferguson f...@caucho.com wrote:
Thanks. It's a timing issue in CanDI. The jms:FileQueue was added to a
lazy-init which wasn't being evaluated when the #{delivery} was
processed. The fix will be in the next snapshot.
Cool. If you get to a point where this is checked into Resin trunk,
I'd love to help you test it :-)
Jeff
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Message driven bean woes
Jeff Schnitzer wrote:
By the way, I was able to work past the lazy-init issue (presumably)
by using this block instead:
cfg:MessageBeanConfig
cfg:classtest.DeliveryListener/cfg:class
cfg:destination#{delivery}/cfg:destination
/cfg:MessageBeanConfig
However, enqueueing a message doesn't produce calls on my Listener.
It seems to produce some sort of spin-loop inside Resin.
Try adding a ee:Startup/ or resin:Service/. Otherwise the bean will
never get instantiated. It shouldn't spin, though.
Although, this is a pretty twisted way of working around the issue :)
-- Scott
Jeff
On Tue, Jul 20, 2010 at 1:17 PM, Jeff Schnitzer j...@infohazard.org wrote:
On Tue, Jul 20, 2010 at 12:21 PM, Scott Ferguson f...@caucho.com wrote:
Thanks. It's a timing issue in CanDI. The jms:FileQueue was added to a
lazy-init which wasn't being evaluated when the #{delivery} was
processed. The fix will be in the next snapshot.
Cool. If you get to a point where this is checked into Resin trunk,
I'd love to help you test it :-)
Jeff
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Message driven bean woes
Neither ee:Startup/ nor resin:Service/ has any observable effect. There's definitely some sort of cpu loop; as soon as I enqueue one entry, one core goes to 99% for the java process. Occasionally the thread hops between cores. * It happens with both jms:FileQueue and jms:MemoryQueue. * There seems to be a 1 or 2 second delay before the CPU pegs. There's nothing obvious to me in the thread dump, but here it is... 2010-07-20 17:01:15 Full thread dump Java HotSpot(TM) 64-Bit Server VM (16.3-b01-279 mixed mode): resin-11 daemon prio=5 tid=101aca000 nid=0x1185fb000 waiting on condition [1185fa000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:283) at com.caucho.env.thread.ResinThread.waitForTask(ResinThread.java:199) at com.caucho.env.thread.ResinThread.runTasks(ResinThread.java:157) at com.caucho.env.thread.ResinThread.run(ResinThread.java:126) resin-10 daemon prio=5 tid=101ac9000 nid=0x1184f8000 runnable [1184f7000] java.lang.Thread.State: RUNNABLE at java.net.SocketInputStream.socketRead0(Native Method) at java.net.SocketInputStream.read(SocketInputStream.java:129) at java.net.SocketInputStream.read(SocketInputStream.java:182) at com.caucho.hessian.io.Hessian2StreamingInput$StreamingInputStream.readChunkLength(Hessian2StreamingInput.java:241) at com.caucho.hessian.io.Hessian2StreamingInput$StreamingInputStream.startPacket(Hessian2StreamingInput.java:167) at com.caucho.hessian.io.Hessian2StreamingInput.startPacket(Hessian2StreamingInput.java:94) at com.caucho.hmtp.HmtpReader.readPacket(HmtpReader.java:102) at com.caucho.hmtp.HmtpLink.run(HmtpLink.java:111) at com.caucho.env.thread.ResinThread.runTasks(ResinThread.java:169) at com.caucho.env.thread.ResinThread.run(ResinThread.java:126) process reaper daemon prio=5 tid=101a89800 nid=0x1183f5000 runnable [1183f4000] java.lang.Thread.State: RUNNABLE at java.lang.UNIXProcess.waitForProcessExit(Native Method) at java.lang.UNIXProcess.access$900(UNIXProcess.java:17) at java.lang.UNIXProcess$2$1.run(UNIXProcess.java:86) watchdog- daemon prio=5 tid=10199c800 nid=0x1181a6000 in Object.wait() [1181a5000] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on 106b74888 (a java.lang.UNIXProcess) at java.lang.Object.wait(Object.java:485) at java.lang.UNIXProcess.waitFor(UNIXProcess.java:115) - locked 106b74888 (a java.lang.UNIXProcess) at com.caucho.boot.WatchdogChildProcess.run(WatchdogChildProcess.java:145) at com.caucho.boot.WatchdogChildTask.run(WatchdogChildTask.java:174) at com.caucho.env.thread.ResinThread.runTasks(ResinThread.java:169) at com.caucho.env.thread.ResinThread.run(ResinThread.java:126) watchdog-process-log-0-1 daemon prio=5 tid=10199c000 nid=0x1180a3000 runnable [1180a2000] java.lang.Thread.State: RUNNABLE at java.io.FileInputStream.readBytes(Native Method) at java.io.FileInputStream.read(FileInputStream.java:199) at java.lang.UNIXProcess$DeferredCloseInputStream.read(UNIXProcess.java:227) at java.io.BufferedInputStream.fill(BufferedInputStream.java:218) at java.io.BufferedInputStream.read1(BufferedInputStream.java:258) at java.io.BufferedInputStream.read(BufferedInputStream.java:317) - locked 106b76e48 (a java.io.BufferedInputStream) at com.caucho.boot.WatchdogChildProcess$WatchdogProcessLogThread.run(WatchdogChildProcess.java:745) at com.caucho.env.thread.ResinThread.runTasks(ResinThread.java:169) at com.caucho.env.thread.ResinThread.run(ResinThread.java:126) resin-7 daemon prio=5 tid=10199b000 nid=0x117fa waiting on condition [117f9f000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:283) at com.caucho.env.thread.ResinThread.waitForTask(ResinThread.java:199) at com.caucho.env.thread.ResinThread.runTasks(ResinThread.java:157) at com.caucho.env.thread.ResinThread.run(ResinThread.java:126) resin-6 daemon prio=5 tid=10199a800 nid=0x117e9d000 waiting on condition [117e9c000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:283) at com.caucho.env.thread.ResinThread.waitForTask(ResinThread.java:199) at com.caucho.env.thread.ResinThread.runTasks(ResinThread.java:157) at com.caucho.env.thread.ResinThread.run(ResinThread.java:126) resin-5 daemon prio=5 tid=1031c1800 nid=0x117d9a000 waiting on condition [117d99000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method)
Re: [Resin-interest] Message driven bean woes
Jeff Schnitzer wrote: Neither ee:Startup/ nor resin:Service/ has any observable effect. There's definitely some sort of cpu loop; as soon as I enqueue one entry, one core goes to 99% for the java process. Occasionally the thread hops between cores. Thanks. The loop is unrelated to EJB or JMS. The spin is related to changes in the sync/locking in the thread/alarm code, moving to atomic locks where possible. -- Scott * It happens with both jms:FileQueue and jms:MemoryQueue. * There seems to be a 1 or 2 second delay before the CPU pegs. There's nothing obvious to me in the thread dump, but here it is... 2010-07-20 17:01:15 Full thread dump Java HotSpot(TM) 64-Bit Server VM (16.3-b01-279 mixed mode): resin-11 daemon prio=5 tid=101aca000 nid=0x1185fb000 waiting on condition [1185fa000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:283) at com.caucho.env.thread.ResinThread.waitForTask(ResinThread.java:199) at com.caucho.env.thread.ResinThread.runTasks(ResinThread.java:157) at com.caucho.env.thread.ResinThread.run(ResinThread.java:126) resin-10 daemon prio=5 tid=101ac9000 nid=0x1184f8000 runnable [1184f7000] java.lang.Thread.State: RUNNABLE at java.net.SocketInputStream.socketRead0(Native Method) at java.net.SocketInputStream.read(SocketInputStream.java:129) at java.net.SocketInputStream.read(SocketInputStream.java:182) at com.caucho.hessian.io.Hessian2StreamingInput$StreamingInputStream.readChunkLength(Hessian2StreamingInput.java:241) at com.caucho.hessian.io.Hessian2StreamingInput$StreamingInputStream.startPacket(Hessian2StreamingInput.java:167) at com.caucho.hessian.io.Hessian2StreamingInput.startPacket(Hessian2StreamingInput.java:94) at com.caucho.hmtp.HmtpReader.readPacket(HmtpReader.java:102) at com.caucho.hmtp.HmtpLink.run(HmtpLink.java:111) at com.caucho.env.thread.ResinThread.runTasks(ResinThread.java:169) at com.caucho.env.thread.ResinThread.run(ResinThread.java:126) process reaper daemon prio=5 tid=101a89800 nid=0x1183f5000 runnable [1183f4000] java.lang.Thread.State: RUNNABLE at java.lang.UNIXProcess.waitForProcessExit(Native Method) at java.lang.UNIXProcess.access$900(UNIXProcess.java:17) at java.lang.UNIXProcess$2$1.run(UNIXProcess.java:86) watchdog- daemon prio=5 tid=10199c800 nid=0x1181a6000 in Object.wait() [1181a5000] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on 106b74888 (a java.lang.UNIXProcess) at java.lang.Object.wait(Object.java:485) at java.lang.UNIXProcess.waitFor(UNIXProcess.java:115) - locked 106b74888 (a java.lang.UNIXProcess) at com.caucho.boot.WatchdogChildProcess.run(WatchdogChildProcess.java:145) at com.caucho.boot.WatchdogChildTask.run(WatchdogChildTask.java:174) at com.caucho.env.thread.ResinThread.runTasks(ResinThread.java:169) at com.caucho.env.thread.ResinThread.run(ResinThread.java:126) watchdog-process-log-0-1 daemon prio=5 tid=10199c000 nid=0x1180a3000 runnable [1180a2000] java.lang.Thread.State: RUNNABLE at java.io.FileInputStream.readBytes(Native Method) at java.io.FileInputStream.read(FileInputStream.java:199) at java.lang.UNIXProcess$DeferredCloseInputStream.read(UNIXProcess.java:227) at java.io.BufferedInputStream.fill(BufferedInputStream.java:218) at java.io.BufferedInputStream.read1(BufferedInputStream.java:258) at java.io.BufferedInputStream.read(BufferedInputStream.java:317) - locked 106b76e48 (a java.io.BufferedInputStream) at com.caucho.boot.WatchdogChildProcess$WatchdogProcessLogThread.run(WatchdogChildProcess.java:745) at com.caucho.env.thread.ResinThread.runTasks(ResinThread.java:169) at com.caucho.env.thread.ResinThread.run(ResinThread.java:126) resin-7 daemon prio=5 tid=10199b000 nid=0x117fa waiting on condition [117f9f000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:283) at com.caucho.env.thread.ResinThread.waitForTask(ResinThread.java:199) at com.caucho.env.thread.ResinThread.runTasks(ResinThread.java:157) at com.caucho.env.thread.ResinThread.run(ResinThread.java:126) resin-6 daemon prio=5 tid=10199a800 nid=0x117e9d000 waiting on condition [117e9c000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:283) at com.caucho.env.thread.ResinThread.waitForTask(ResinThread.java:199) at
Re: [Resin-interest] Message driven bean woes
It works! Just got this working against trunk:
jms:JmsConnectionFactory/
jms:MemoryQueue
ee:Nameddelivery/ee:Named
/jms:MemoryQueue
ejb-message-bean class=test.DeliveryListener
destination#{delivery}/destination
/ejb-message-bean
Without the jms:JmsConnectionFactory/ deployment will produce an
error something like:
'javax.jms.ConnectionFactory' with name 'null' is an unknown JMS resource.
Thanks,
Jeff
On Tue, Jul 20, 2010 at 6:13 PM, Scott Ferguson f...@caucho.com wrote:
Jeff Schnitzer wrote:
Neither ee:Startup/ nor resin:Service/ has any observable effect.
There's definitely some sort of cpu loop; as soon as I enqueue one
entry, one core goes to 99% for the java process. Occasionally the
thread hops between cores.
Thanks. The loop is unrelated to EJB or JMS.
The spin is related to changes in the sync/locking in the thread/alarm
code, moving to atomic locks where possible.
-- Scott
* It happens with both jms:FileQueue and jms:MemoryQueue.
* There seems to be a 1 or 2 second delay before the CPU pegs.
There's nothing obvious to me in the thread dump, but here it is...
2010-07-20 17:01:15
Full thread dump Java HotSpot(TM) 64-Bit Server VM (16.3-b01-279 mixed mode):
resin-11 daemon prio=5 tid=101aca000 nid=0x1185fb000 waiting on
condition [1185fa000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:283)
at
com.caucho.env.thread.ResinThread.waitForTask(ResinThread.java:199)
at com.caucho.env.thread.ResinThread.runTasks(ResinThread.java:157)
at com.caucho.env.thread.ResinThread.run(ResinThread.java:126)
resin-10 daemon prio=5 tid=101ac9000 nid=0x1184f8000 runnable [1184f7000]
java.lang.Thread.State: RUNNABLE
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(SocketInputStream.java:129)
at java.net.SocketInputStream.read(SocketInputStream.java:182)
at
com.caucho.hessian.io.Hessian2StreamingInput$StreamingInputStream.readChunkLength(Hessian2StreamingInput.java:241)
at
com.caucho.hessian.io.Hessian2StreamingInput$StreamingInputStream.startPacket(Hessian2StreamingInput.java:167)
at
com.caucho.hessian.io.Hessian2StreamingInput.startPacket(Hessian2StreamingInput.java:94)
at com.caucho.hmtp.HmtpReader.readPacket(HmtpReader.java:102)
at com.caucho.hmtp.HmtpLink.run(HmtpLink.java:111)
at com.caucho.env.thread.ResinThread.runTasks(ResinThread.java:169)
at com.caucho.env.thread.ResinThread.run(ResinThread.java:126)
process reaper daemon prio=5 tid=101a89800 nid=0x1183f5000 runnable
[1183f4000]
java.lang.Thread.State: RUNNABLE
at java.lang.UNIXProcess.waitForProcessExit(Native Method)
at java.lang.UNIXProcess.access$900(UNIXProcess.java:17)
at java.lang.UNIXProcess$2$1.run(UNIXProcess.java:86)
watchdog- daemon prio=5 tid=10199c800 nid=0x1181a6000 in
Object.wait() [1181a5000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on 106b74888 (a java.lang.UNIXProcess)
at java.lang.Object.wait(Object.java:485)
at java.lang.UNIXProcess.waitFor(UNIXProcess.java:115)
- locked 106b74888 (a java.lang.UNIXProcess)
at
com.caucho.boot.WatchdogChildProcess.run(WatchdogChildProcess.java:145)
at com.caucho.boot.WatchdogChildTask.run(WatchdogChildTask.java:174)
at com.caucho.env.thread.ResinThread.runTasks(ResinThread.java:169)
at com.caucho.env.thread.ResinThread.run(ResinThread.java:126)
watchdog-process-log-0-1 daemon prio=5 tid=10199c000 nid=0x1180a3000
runnable [1180a2000]
java.lang.Thread.State: RUNNABLE
at java.io.FileInputStream.readBytes(Native Method)
at java.io.FileInputStream.read(FileInputStream.java:199)
at
java.lang.UNIXProcess$DeferredCloseInputStream.read(UNIXProcess.java:227)
at java.io.BufferedInputStream.fill(BufferedInputStream.java:218)
at java.io.BufferedInputStream.read1(BufferedInputStream.java:258)
at java.io.BufferedInputStream.read(BufferedInputStream.java:317)
- locked 106b76e48 (a java.io.BufferedInputStream)
at
com.caucho.boot.WatchdogChildProcess$WatchdogProcessLogThread.run(WatchdogChildProcess.java:745)
at com.caucho.env.thread.ResinThread.runTasks(ResinThread.java:169)
at com.caucho.env.thread.ResinThread.run(ResinThread.java:126)
resin-7 daemon prio=5 tid=10199b000 nid=0x117fa waiting on
condition [117f9f000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:283)
at
