[Messaging, JMS & JBossMQ] - Re: JMSXDeliveryCount with GenericDLQHandler
by adrian@jboss.org
"svadu" wrote :
| Can someone give me a clue on the problem (I hope I described the problem more or less accurately)?
|
JMSXDeliveryCount is a property set by the JMS provider (Tibco) not JBoss.
We just use it to determine number of redeliveries when it exists (it is optional).
Perhaps it is a property Tibco doesn't support, but the message originated
in some other system that does set the property. i.e. Tibco just copied it?
anonymous wrote :
| Do I need to rely (woudl require even more vendor specific configuration) on the external JMS server (Tibco in this case) to handle redelivery counts?
|
No idea. But I'd imagine Tibco has internal support for DLQs or
some other poisened message handler?.
So you probably don't need to configure a DLQ handler in JBoss at all?
* Set the activation-config-property useDLQ=false
* Configure a DLQ (or whatever mechanism they have) for your queue/topic in Tibco.
The only reason the DLQ handler exists in the MDB is because JBossMQ
doesn't support them internally. Most other JMS providers do support them
inside the server.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4130819#4130819
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4130819
18 years, 2 months
[Clustering/JBoss] - Re: Potential issue with JGroups using JBoss 3.2.7 and Java
by ross.nelson@saic.com
Apologies for the strange text that appeared above, hopefully this notepad version works better.
Java version is 1.4.2_09b05 (cut off from title)
Hi there, first post on the site, I currently have a live application (GT-X7 running on JBoss 3.2.7) which makes use of JGroups for clustering.
We have 5 "kernels" involved in the group and both today and yesterday we have experienced a "hang" on the 1st kernel which is the originator of the group several hours after startup.
This hang renders the kernel completely inaccessible, all logging is halted (Garbage Collection halted in the middle of spooling a row), it's as if the kernel has paused itself waiting for something to happen. It would appear in the meantime that the other 4 kernels continue working away.
On the first occasion we did not manage to the get the kill -QUIT to output anything before we restarted.
Fortunately today we managed to get the kill -QUIT to go through and I will enclose the output below.
The reason I come to JGroups is the item at "waiting" on the dump appears to be part of the JGroups setup. - "MessageDispatcher up processing thread" (from google searching)
On both occasions I have observed that around 1 minute before the "hung" kernel occurs, another member of the cluster is suspected, removed and then quickly re-introduced to the cluster, from google searching I did see a bit about "simultaneous" kernel exclusion causing a problem, however this doesn't appear "simultaneous".
Thanks in advance for any assistance or even advice on areas to focus on - I'm a bit between JVM (Garbage Collection) and JGroups on this one, will be posting questions both here and on the sun site.
I'll post the dump first and then snippets from the STD Out Logs which contain the JGroups comings and goings ....
Ross
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4130806#4130806
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4130806
18 years, 2 months
[Clustering/JBoss] - Potential issue with JGroups using JBoss 3.2.7 and Java 1.4.
by ross.nelson@saic.com
Hi there, first post on the site, I currently have a live application (GT-X7 running on JBoss 3.2.7) which makes use of JGroups for clustering.
We have 5 "kernels" involved in the group and both today and yesterday we have experienced a "hang" on the 1st kernel which is the originator of the group â several hours after startup.
This hang renders the kernel completely inaccessible, all logging is halted (Garbage Collection halted in the middle of spooling a row), it's as if the kernel has paused itself waiting for something to happen. It would appear in the meantime that the other 4 kernels continue working away.
On the first occasion we did not manage to the get the kill -QUIT to output anything before we restarted.
Fortunately today on the 2nd occassion we managed to get the kill -QUIT to go through and I will enclose the output below.
The reason I come to JGroups is the item at "waiting" on the dump appears to be part of the JGroups setup. - "MessageDispatcher up processing thread" (from google searching)
On both occasions I have observed that around 1 minute before the "hung" kernel occurs, another member of the cluster is suspected, removed and then quickly re-introduced to the cluster, from google searching I did see a bit about "simultaneous" kernel exclusion causing a problem, however this doesn't appear "simultaneous".
Thanks in advance for any assistance or even advice on areas to focus on â Iâm a bit between JVM (Garbage Collection) and JGroups on this one, will be posting questions both here and on the sun site.
Iâll post the âdumpâ first and then snippets from the STD Out Logs which contain the JGroups comings and goingsâ¦..
Ross
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4130802#4130802
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4130802
18 years, 2 months