Author |
Message |
Topic: Multiple access to shared queue with ConnectionConsumer |
griffel
Replies: 6 Views: 5215
|
Forum: IBM MQ Java / JMS Posted: Wed Oct 17, 2007 7:32 am Subject: SOLVED |
Just in case someone reads this in search of solutions to similar problems:
Setting the property com.ibm.mq.jms.tuning.QATVersion=1 on the Java client side cause the MQQueueAgent to use the old style ... |
Topic: Multiple access to shared queue with ConnectionConsumer |
griffel
Replies: 6 Views: 5215
|
Forum: IBM MQ Java / JMS Posted: Wed Oct 10, 2007 12:27 am Subject: Multiple access to shared queue with ConnectionConsumer |
Sorry, but ...
JNDI is not about session handling. Actually, you're right - we don't
use JNDI (just adds another complexity and its not needed if you just want to get a factory for your connection ... |
Topic: Multiple access to shared queue with ConnectionConsumer |
griffel
Replies: 6 Views: 5215
|
Forum: IBM MQ Java / JMS Posted: Mon Oct 08, 2007 11:57 pm Subject: Multiple access to shared queue with ConnectionConsumer |
"ConnectionConsumer" is a Java Interface defined by the JMS standard (that's why I thought it might be a nice idea to post my problem to the Java/JMS discussion group ...).
A ConnectionCo ... |
Topic: Multiple access to shared queue with ConnectionConsumer |
griffel
Replies: 6 Views: 5215
|
Forum: IBM MQ Java / JMS Posted: Mon Oct 08, 2007 1:31 pm Subject: Multiple access to shared queue with ConnectionConsumer |
Hi,
we have two version 6 queue managers MQ1A and MQ1B serving a clustered queue-sharing group on zOS.
We have a shared queue on them, let's say QUEUE1.
We have two Java application processes get ... |
Topic: JMS message selector and z/OS CPU load for TCP stack |
griffel
Replies: 3 Views: 3484
|
Forum: IBM MQ Java / JMS Posted: Tue Oct 04, 2005 6:16 am Subject: JMS message selector and z/OS CPU load for TCP stack |
Thanks for the bit of balm for my suffering soul.
At least, your suggestions approve our other design decisions (those aside from using JMS ...).
Nonetheless I'm afraid, delivering non-matching me ... |
Topic: JMS message selector and z/OS CPU load for TCP stack |
griffel
Replies: 3 Views: 3484
|
Forum: IBM MQ Java / JMS Posted: Tue Oct 04, 2005 5:18 am Subject: JMS message selector and z/OS CPU load for TCP stack |
Just because I'm kind of frustated - to avoid "displeased" - I like to grasp some opinions here - if anyone has some on the following issue:
Some time ago we believed using "industry standards" (at ... |
Topic: JMS performance (z/OS vs. Windows) |
griffel
Replies: 0 Views: 1664
|
Forum: IBM MQ Java / JMS Posted: Wed May 25, 2005 1:05 am Subject: JMS performance (z/OS vs. Windows) |
I have a small test program that uses a message selector to get
every other message out of a queue filled with 1000 messages -
that is it gets 500 messages in a single transaction.
The test (Java ... |
Topic: UTFDataFormatException on get |
griffel
Replies: 7 Views: 6145
|
Forum: IBM MQ Java / JMS Posted: Wed May 25, 2005 12:42 am Subject: UTFDataFormatException on get |
What do you mean by "read this via a Java program"?
Do you use JMS stuff? If so, beware of using TextMessage
which do UTF8-conversion on their own. Try using a
BytesMessage. Just an idea. |
Topic: ConnectionConsumer producing wrong backout counts? |
griffel
Replies: 7 Views: 4956
|
Forum: IBM MQ Java / JMS Posted: Fri Apr 29, 2005 8:37 pm Subject: ConnectionConsumer producing wrong backout counts? |
Might be a bit too early today for me to grasp some clear thought, but:
I understood that you suggested to avoid further message delivery by calling Connection.stop() first (instead of ConnectionCons ... |
Topic: Resolve invisible (locked) message from MQI channel |
griffel
Replies: 7 Views: 5947
|
Forum: IBM MQ Java / JMS Posted: Fri Apr 29, 2005 5:01 am Subject: Resolve invisible (locked) message from MQI channel |
Right. I shaped my original question a bit more complex, since asking the concerned queues about their status gave UNCOM(NO). After a QM-restart definitely appeared a couple of hundred messages again ... |
Topic: Resolve invisible (locked) message from MQI channel |
griffel
Replies: 7 Views: 5947
|
Forum: IBM MQ Java / JMS Posted: Fri Apr 29, 2005 12:33 am Subject: Resolve invisible (locked) message from MQI channel |
So this is really a poison message problem.
No, it is not - it is a _result_ of posinoned messages occuring.
(sorry, my question seemed to be rather "compressed")
My only problem is, how to ge ... |
Topic: ConnectionConsumer producing wrong backout counts? |
griffel
Replies: 7 Views: 4956
|
Forum: IBM MQ Java / JMS Posted: Fri Apr 29, 2005 12:20 am Subject: ConnectionConsumer producing wrong backout counts? |
Also I would not use ConnectionConsumer.stop() to stop delivering the message.
Yes, this was one of my early ideas, but see
When I've seen this, it is usually because a backout threshold is suppl ... |
Topic: ConnectionConsumer producing wrong backout counts? |
griffel
Replies: 7 Views: 4956
|
Forum: IBM MQ Java / JMS Posted: Thu Apr 28, 2005 10:32 am Subject: ConnectionConsumer producing wrong backout counts? |
Some more details, since we now have built a standalone test
(former observations came from our production systems directly):
The test instantiates a ConnectionConsumer listening on a queue
confi ... |
Topic: Resolve invisible (locked) message from MQI channel |
griffel
Replies: 7 Views: 5947
|
Forum: IBM MQ Java / JMS Posted: Thu Apr 28, 2005 8:25 am Subject: Resolve invisible (locked) message from MQI channel |
Sorry, I like complex questions for complex(?) problems
What I want to know is: How can I make my messages visible again (that's getting the QM to free his lock).
Those message are locked, ... |
Topic: ConnectionConsumer producing wrong backout counts? |
griffel
Replies: 7 Views: 4956
|
Forum: IBM MQ Java / JMS Posted: Thu Apr 28, 2005 6:04 am Subject: ConnectionConsumer producing wrong backout counts? |
Our configuration:
WebSphere MQ 5.3 CSD9 for Windows (here 2000) as a Java JMS client to connect to a queue manager running as WebSphere MQ 5.3.1 on z/OS 1.6 via SSLed SVRCONN-channels.
Our proble ... |