[
https://issues.apache.org/jira/browse/AMQ-3245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13012602#comment-13012602
]
Melvin Ramos edited comment on AMQ-3245 at 3/29/11 7:23 PM:
------------------------------------------------------------
Gary,
Thanks for your help.
Ok, I've tested with 2000 maxPageSize, and I see some issues with selector.It
appears that a certain threshold where the selectors fail to apply its rules is
at 30 messages and above.
Just to be accurate, queues for the test below are 0. They don't contain any
messages at all when I start the app. So when I run #2) the messages shows me
25 and then running #3) I get 50 total messages. Then I purge them so its clean
and run the second set below with 30 messages.
If I run my test app in this sequence
1) Run consumer selector [test > 50]
2) Run producer property [test, 20], insert 25 messages
3) Run producer property [test, 60], insert 25 messages
The selector works fine! Messages gets consumed.
Using same sequence as above but send 30 or more messages, nothing gets
consumed.
1) Run consumer selector [test > 50]
2) Run producer property [test, 20], insert 30 messages
3) Run producer property [test, 60], insert 30 messages
Is there other ways to get around this? This could particularly happen, a
consumer for #2 get disconnected/crashed for some reason, and we are above the
30 threshold then nothing gets consumed at all.
Please advice.
Melvin
was (Author: jayd.lowrider):
Gary,
Thanks for your help.
Ok, I've tested with 2000 maxPageSize, and I see some issues with selector.It
appears that a certain threshold where the selectors fail to apply its rules is
at 30 messages and above.
If I run my test app in this sequence
1) Run consumer selector [test > 50]
2) Run producer property [test, 20], insert 25 messages
3) Run producer property [test, 60], insert 25 messages
The selector works fine! Messages gets consumed.
Using same sequence as above but send 30 or more messages, nothing gets
consumed.
1) Run consumer selector [test > 50]
2) Run producer property [test, 20], insert 30 messages
3) Run producer property [test, 60], insert 30 messages
Is there other ways to get around this? This could particularly happen, a
consumer for #2 get disconnected/crashed for some reason, and we are above the
30 threshold then nothing gets consumed at all.
Please advice.
Melvin
> SELECTORS doesn't work for releases 5.4.0 to current
> ----------------------------------------------------
>
> Key: AMQ-3245
> URL: https://issues.apache.org/jira/browse/AMQ-3245
> Project: ActiveMQ
> Issue Type: Bug
> Components: Selector
> Affects Versions: 5.4.1, 5.4.2
> Reporter: Melvin Ramos
>
> Is it possible that selector was broken due to new enhancement regarding REST
> selectors on 5.4.0? We are using 5.3.0 and selectors are working fine,
> however since we've upgraded our demo and test environments to 5.4.1 and
> essentially 5.4.2 it stop working for some reason. I can recreate it 100% of
> the time and below are the steps.
> 1) First create the producer with String property set to 30. i.e. test, 30:
> {code}
> String username="Me"
> String passwd = "invicible"
> String url
> ="failover:(tcp://localhost:51515)?maxReconnectDelay=5000&useExponentialBackOff=false";
> ConnectionFactory connectionFactory = new ActiveMQConnectionFactory(username,
> passwd, url);
> Connection connection = connectionFactory.createConnection();
> // connection.setUseCompression(true); set this on the URL instead
> connection.setExceptionListener(this);
> String destinationString = "Test.Dest";
> // create a session, destination, and producer
> Session session = connection.createSession(false, Session.AUTO_ACKNOWLEDGE);
> Destination destination = session.createQueue(destinationString);
> MessageProducer producer = session.createProducer(destination);
> producer.setDeliveryMode(DeliveryMode.PERSISTENT);
> Message message = session.createTextMessage("This is a test message");
> message.setIntProperty("test", 30);
> // insert the message 1000 times.
> for (long l = 0L; l < 1000; l++) {
> producer.send(message);
> }
> producer.close();
> session.close();
> connection.close();
> {code}
> Now we have 1000 message sitting on activemq, if you navigate to
> http://localhost:8161/admin and view "Test.Dest" queue you should see the
> 1000 message there.
> 2) Create the consumer with test > 50 selector.
> {code}
> public void setup() {
> String username="Me"
> String passwd = "invicible"
> String url
> ="failover:(tcp://localhost:51515)?maxReconnectDelay=5000&useExponentialBackOff=false";
> //"tcp://localhost:51515";
> ConnectionFactory connectionFactory = new ActiveMQConnectionFactory(username,
> passwd, url);
> Connection connection = connectionFactory.createConnection();
> // connection.setUseCompression(true); set this on the URL instead
> connection.setExceptionListener(this);
> // create a session, destination, and consumer
> Session session = connection.createSession(false, Session.CLIENT_ACKNOWLEDGE);
> String destinationString = "Test.Dest";
> session.createQueue(destinationString);
> MessageConsumer consumer = session.createConsumer(destination, "test > 50");
> consumer.setMessageListener(this);
> connection.start();
> }
> public void onMessage(Message message) {
> try {
> if (print && text) {
> TextMessage textMessage = (TextMessage) message;
> System.out.println(textMessage.getText());
> }
> catch (Exception ex)
> { //swallow }
> }
> {code}
> Once connected to broker, you'll see that it doesn't do anything as the
> message is not for this selector.
> 3) Edit the code to producer.
> {code}
> message.setIntProperty("test", 60);
> {code}
> And then rerun the producer to insert the 1000 records again.
> Actual: Nothing happens, the consumer just waits for any message that comes
> in that matches the selector.
> Expected: The message gets consumed, as the latter part of the producer ran
> matches the selector.
> This behavior works perfectly fine with 5.3.0. As selector is an important
> functionality of JMS as a whole this being broken is actually bad.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
