Discussions
Categories
- 385.5K All Categories
- 5.1K Data
- 2.5K Big Data Appliance
- 2.5K Data Science
- 453.4K Databases
- 223.2K General Database Discussions
- 3.8K Java and JavaScript in the Database
- 47 Multilingual Engine
- 606 MySQL Community Space
- 486 NoSQL Database
- 7.9K Oracle Database Express Edition (XE)
- 3.2K ORDS, SODA & JSON in the Database
- 584 SQLcl
- 4K SQL Developer Data Modeler
- 188K SQL & PL/SQL
- 21.5K SQL Developer
- 46 Data Integration
- 46 GoldenGate
- 298.4K Development
- 4 Application Development
- 20 Developer Projects
- 166 Programming Languages
- 295K Development Tools
- 150 DevOps
- 3.1K QA/Testing
- 646.7K Java
- 37 Java Learning Subscription
- 37.1K Database Connectivity
- 201 Java Community Process
- 108 Java 25
- 22.2K Java APIs
- 138.3K Java Development Tools
- 165.4K Java EE (Java Enterprise Edition)
- 22 Java Essentials
- 176 Java 8 Questions
- 86K Java Programming
- 82 Java Puzzle Ball
- 65.1K New To Java
- 1.7K Training / Learning / Certification
- 13.8K Java HotSpot Virtual Machine
- 94.3K Java SE
- 13.8K Java Security
- 208 Java User Groups
- 25 JavaScript - Nashorn
- Programs
- 666 LiveLabs
- 41 Workshops
- 10.3K Software
- 6.7K Berkeley DB Family
- 3.6K JHeadstart
- 6K Other Languages
- 2.3K Chinese
- 207 Deutsche Oracle Community
- 1.1K Español
- 1.9K Japanese
- 474 Portuguese
Strange behavior with QueueBrowser

922859
Member Posts: 2
Hi,
I am using a QueueBrowser along with a QueueReceiver for my application and notice behavior that is strange. Here is the logic :
a) I create a QueueBrowser against a queue and take a snapshot of whats on the queue.
b) I loop through the enumeration of messages on the queue and determine for each message , if the message is ready to be processed now(based on some logic).
c) If in step (b), i determine that the message is ready to be processed, i create a runnable and submit the runnable to a thread pool for processing.
d) The runnable uses a queue receiver to receive a specific message off the queue using a message selector and processes the message.
What i notice is if the receiver tries to receive a message that the browser has already seen, at times the receive method returns null. But eventually after many failed attempts, the receiver can pull the message off the queue using the message selector. Also, i notice that when the receive timeout is set to NO_WAIT,
the receive call fails before succeeding eventually. But if i use the receive method with a couple of seconds timeout, it does seem to receive successfully every time.
Any thoughts on why this behavior would happen?
Raj
I am using a QueueBrowser along with a QueueReceiver for my application and notice behavior that is strange. Here is the logic :
a) I create a QueueBrowser against a queue and take a snapshot of whats on the queue.
b) I loop through the enumeration of messages on the queue and determine for each message , if the message is ready to be processed now(based on some logic).
c) If in step (b), i determine that the message is ready to be processed, i create a runnable and submit the runnable to a thread pool for processing.
d) The runnable uses a queue receiver to receive a specific message off the queue using a message selector and processes the message.
What i notice is if the receiver tries to receive a message that the browser has already seen, at times the receive method returns null. But eventually after many failed attempts, the receiver can pull the message off the queue using the message selector. Also, i notice that when the receive timeout is set to NO_WAIT,
the receive call fails before succeeding eventually. But if i use the receive method with a couple of seconds timeout, it does seem to receive successfully every time.
Any thoughts on why this behavior would happen?
Raj
Answers
-
919856 wrote:Just to check: So if you use receive(2000) your test works every time, but if you use receiveNoWait() it sometimes fails to receive the message
Any thoughts on why this behavior would happen?
If so this is because of the way your JMS provider has implemented receiveNoWait(); This method is required to return immediately, which isn't enough time for the message to arrive from the server.
Nigel -
Nigel,
Thanks for your quick response. That is exactly the behavior i see. Receive with no wait fails at times but receive with a wait of even 1 second seems to work.
I saw this with ActiveMQ using both the embedded broker and an external broker.
Rajkumar -
It's best to avoid receiveNoWait() for the reason you've discovered.
I'll try to clarify this in JMS 2.0. I've just logged this as
http://java.net/jira/browse/JMS_SPEC-85
Nigel
This discussion has been closed.