[Beginners Corner] - Re: shutdown.bat and cntrl-c not working but web-console and
by amast
Thanks again for your persistence!
"PeterJ" wrote : Based on your netstat output, I think that you changed the JNDI port to 9099 (the default is 1099). So you should be able to shut down from the same machine using:
| shutdown -S -s localhost:9099
|
That didn't shutdown, same "pause"
"PeterJ" wrote :
| Could you try with a Sun JDK?
|
Yea, I tried that, but the same result (thread break below).
Listening for transport dt_socket at address: 8787
2008-06-26 08:30:27
Full thread dump Java HotSpot(TM) Client VM (10.0-b19 mixed mode):
"JDWP Event Helper Thread" daemon prio=6 tid=0x0aac5800 nid=0xf1c runnable [0x00000000..0x00000000]
java.lang.Thread.State: RUNNABLE
"JDWP Transport Listener: dt_socket" daemon prio=6 tid=0x0aac2800 nid=0x650 runnable [0x00000000..0x00000000]
java.lang.Thread.State: RUNNABLE
"Attach Listener" daemon prio=10 tid=0x0aab7800 nid=0x2ac runnable [0x00000000..0x00000000]
java.lang.Thread.State: RUNNABLE
"Signal Dispatcher" daemon prio=10 tid=0x0aab6c00 nid=0xfc4 waiting on condition [0x00000000..0x00000000]
java.lang.Thread.State: RUNNABLE
"Finalizer" daemon prio=8 tid=0x0aaa9000 nid=0xed8 in Object.wait() [0x0ac1f000..0x0ac1fa98]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0x02990b38> (a java.lang.ref.ReferenceQueue$Lock)
at java.lang.ref.ReferenceQueue.remove(Unknown Source)
- locked <0x02990b38> (a java.lang.ref.ReferenceQueue$Lock)
at java.lang.ref.ReferenceQueue.remove(Unknown Source)
at java.lang.ref.Finalizer$FinalizerThread.run(Unknown Source)
"Reference Handler" daemon prio=10 tid=0x0aaa4800 nid=0xf40 in Object.wait() [0x0abcf000..0x0abcfb18]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0x02990a40> (a java.lang.ref.Reference$Lock)
at java.lang.Object.wait(Object.java:485)
at java.lang.ref.Reference$ReferenceHandler.run(Unknown Source)
- locked <0x02990a40> (a java.lang.ref.Reference$Lock)
"main" prio=6 tid=0x00295c00 nid=0x204 runnable [0x00000000..0x0090fdec]
java.lang.Thread.State: RUNNABLE
"VM Thread" prio=10 tid=0x0aaa0000 nid=0x450 runnable
JNI global references: 324
Heap
def new generation total 960K, used 157K [0x02990000, 0x02a90000, 0x02e70000)
eden space 896K, 17% used [0x02990000, 0x029b7790, 0x02a70000)
from space 64K, 0% used [0x02a70000, 0x02a70000, 0x02a80000)
to space 64K, 0% used [0x02a80000, 0x02a80000, 0x02a90000)
tenured generation total 4096K, used 0K [0x02e70000, 0x03270000, 0x06990000)
the space 4096K, 0% used [0x02e70000, 0x02e70000, 0x02e70200, 0x03270000)
compacting perm gen total 12288K, used 1450K [0x06990000, 0x07590000, 0x0a990000)
the space 12288K, 11% used [0x06990000, 0x06afabb0, 0x06afac00, 0x07590000)
No shared spaces configured.
"PeterJ" wrote :
| Please don't bold your text, makes it too difficult to read.
|
Sorry!
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4160844#4160844
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4160844
17 years, 9 months
[EJB/JBoss] - send jms message after tx commit
by justkeys
Example: after the invocation of a Person insertPerson() method on a @Stateless or @Service, i would like to broadcast this new person to a jms topic. But this notification should only happen if the transaction commits, not if it rolls back.
EJB3 interceptors are always inbetween the container tx interception and the implementation, so they dont know whether the tx committed, since it has not yet been committed when they get control again, after the invocation.
1. I read about the SessionSynchronisation interface, but it's for @Stateful ejbs only. Any particular way i could enable this on @Service?
2. Perhaps the jms-sender code needs to be transaction-aware, and postpone the send until the tx commits? Is this possible?
3. I could insert an ejb3 handcoded transaction interceptor, (and annotate the ejb "supports") so that i can order it after my jms-sending interceptor. Can i re-use jboss code, or do i have to reimplement this transaction-interceptor as ejb3 interceptor?
4. Or i can make a "NotifyingEJB3" that has "supports", and takes care of forwarding to the actual implementation ("required"), and then sends out the jms message.
Other possibilities?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4160840#4160840
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4160840
17 years, 9 months
[JBoss Messaging] - Re: Messages distribution across cluster.
by fl_
Hello,
I made few tests and found out strange behavior.
Lets say that we have deployment layout like following:
| (Node0) Producer ---> @ <--- Consumer (dest = 'moduleA')
| |
| (Node1) @ <--- Consumer (dest = 'moduleB')
| |
| (Node2) @ <--- Consumer (dest = 'moduleC')
| \---- Consumer (dest = 'singleton')
|
All producers and consumer are standalone applications. So Producer and Consumer with selector dest = 'moduleA' are connected to Node0, Consumer with selector dest = 'moduleB' is connected to Node1 and two consumers are connected to Node2 with selectors like above.
So now, Producer send message with stringProperty set to dest='singleton' and this message stuck on Node0. It is not distributed to Node2 (in database it is assigned to Node0) and what is more important, it can't be received with Consumer connected to Node2.
We can send even few hundreds of such messages and they all stuck on Node0.
It is the same if we send message to moduleC, it just stuck on Node0.
Messages to moduleA can be received with consumer connected to Node0.
Now we close consumer connected to Node0, so now deployment looks like follow:
| (Node0) Producer ---> @
| |
| (Node1) @ <--- Consumer (dest = 'moduleB')
| |
| (Node2) @ <--- Consumer (dest = 'moduleC')
| \---- Consumer (dest = 'singleton')
|
Messages are not switched to another node, they stay attached to Node0. So Consumer with selector dest = 'singleton' is still not able to receive its messages (that are currently in queue).
Now, we send one message to module 'singleton'. And this trigger some kind of action, messages are switched to Node2, and now we can receive them by consumer (dest='singleton) connected to Node2.
I think that even after sending this one message, there is still some mess in database (and in behavior), because I had had messages with desc='moduleB' in queue before, and now they were transfered to Node2 instead of to Node1. So they stuck there to ;)
JBoss 4.2.1 GA
JBoss Messaging 1.4.0 SP3 CP02
I don't know it is a bug? I look inside JMS specification, but there is very little about situations where few consumers with different selectors are connected to one queue especially in clustered environment.
Nevertheless I think it is expected that above situation will be working "correctly" ;) it means each message will be received by corresponding consumer.
There are two other things that I noticed:
1) a lot of SQL updates
When messages are switching across cluster, there is a lot of database UPDATE operation. It can impact performance, can't it?
2) message order
This 'message switching' breaks any order in queue. I don't want start discussion about that order should be kept or not.
My question is: Is there chance that one of message will be extremely unlucky and will be never consumed ?
In situation where we have constantly a lot of messages in queue: producers are adding new messages and consumers are receiving them little slower; we expect that old messages will be generally consumed before new one.
I think that in current approach, it is possible that one message will be on some "switching mode" state every time when consumers request message to consume. And it stuck in queue.
BR
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4160839#4160839
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4160839
17 years, 9 months