Mailing-List: contact users-help@qpid.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@qpid.apache.org
Received-SPF: pass (athena.apache.org: domain of robbie.gemmell@gmail.com
 designates 209.85.210.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <4F897E97.40903@blueyonder.co.uk>
References: 
 <532c36b6-a6c4-4905-b3fd-d39ec31839a4@zmail02.collab.prod.int.phx2.redhat.com>
	<4f88a586-0276-4fdc-a191-416b58d00c81@zmail02.collab.prod.int.phx2.redhat.com>
	<CA+M2XzuYd1U6Xt5yU5Kc4cFJB44eLdaLjCWz7SPA1QhykBMKrg@mail.gmail.com>
	<CAOhBXQ4ZVXZVRSxmK5sg+FrTScWY2+7ZWngnTReNCh__eXPw7g@mail.gmail.com>
	<4F897E97.40903@blueyonder.co.uk>
Date: Sat, 14 Apr 2012 16:44:16 +0100
Message-ID: 
 <CAFitrpTuqKUsWJCJpOncQo591syKCrvzT-7CP7tFxebfagYgog@mail.gmail.com>
Subject: Re: Selective message acknowledgment in Java client (and C++ broker)?
From: Robbie Gemmell <robbie.gemmell@gmail.com>
To: users@qpid.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

You probably want to try the 0.16 RCs or trunk if you are interested
in using the client-side selector support (available when connecting
to AMQP 0-10 brokers) of the Java client, as several related changes
were made to that area since Qpid 0.14 (in order to improve
efficiency/correctness when connecting to the Java broker).

Although the Java broker performs server-side selection, the clients
AMQP 0-10 support was originally only used with the C++ broker which
currently does not. As a result the client was previously still
enabling its own selection support when connected to the Java broker
using AMQP 0-10, which made it incurr unecessary overheads as a
result. When addressing this by making the client able to disable the
client-side selection when connected to the Java broker, the
implementation in this area was cleaned up in general and multiple
defects with the client-side selection support were addressed in the
process. These likely play right into what you have observed
previously, so its worth testing with an up to date client version if
you havent already. If you still have issues when you do, raise a JIRA
and attach your reproducer.

0.16 RC2:
http://people.apache.org/~jross/qpid-0.16-rc2/

Trunk nightly client build:
https://builds.apache.org/view/M-R/view/Qpid/job/Qpid-Java-Artefact-Release=
/lastSuccessfulBuild/artifact/trunk/qpid/java/client/release/

Robbie

On 14 April 2012 14:41, Fraser Adams <fraser.adams@blueyonder.co.uk> wrote:
> Hi Pavel/Jakub/Rajith
> I posted ages back (March 2011) that I didn't believe that JMS Message
> Selectors were behaving correctly:
> http://qpid.2158936.n2.nabble.com/JMS-Message-Selectors-Behaving-Strangel=
y-td6158445.html
>
> My observations concur with the observations of Pavel and Jakob namely I'=
d
> expect any unselected messages to remain on the queue, but not the messag=
es
> that matched the selector.
>
> For info guys one approach that just may be useful is that the "internal"
> filter class is fairly easily accessibly so I had code that looks like.
>
> ...
> import org.apache.qpid.filter.JMSSelectorFilter;
> import org.apache.qpid.client.message.AbstractJMSMessage;
> ...
>
> private JMSSelectorFilter filter;
> ....
> // Then roundabouts where you'd create a consumer using a message selecto=
r
> do..
> // Clearly just an example but this selects a header called amqp-delivery
> with the value fadams
> // any selector could be used.
> filter =3D new JMSSelectorFilter("amqp-delivery =3D 'fadams'");
> .....
> // Later in say onMessage(Message message)
> ....
> if (filter.matches((AbstractJMSMessage)message)) {
> // Logic for matching message.
>
> }
> ...
>
> Clearly the code above isn't ideal as it isn't pure JMS and also it uses
> internal classes that could change, but it's the closest approximation th=
at
> I could get to using message selectors that gave me some finer control.
>
>
> Hope this helps you guys. I'd really like to see selectors behaving in a =
way
> that acknowledges selected messages and leaves unselected messages on the
> queue, this is what I'd intuitively expect to happen.
>
> If that's not possible at the least it would be nice to have the
> JMSSelectorFilter exposed as an "official" Qpid API so it could be used
> without fear of it suddenly disappearing.
>
> I'd be interested in thoughts on this, I've been meaning to bring it up
> again but have been distracted on other things.
>
> Frase
>
>
>
> On 13/04/12 08:55, Jakub Scholz wrote:
>>
>> Hi Rajith,
>>
>> I was playing with the JMS selectors last week. While they do work and
>> really select the messages based on the filter, it seemed to me that
>> it switched off the acknowledgments completely. The Java application
>> was getting only the selected messages, but I was unable to
>> acknowledge them and they stayed in the queues. This may be OK in some
>> situations, but in my case I wanted to get the messages really
>> acknowledged and removed from the queues on the broker.
>>
>> Then I considered to try the same trick as Pavel did - read all
>> messages and filter them manually. But unlike in the C++ API, I didn't
>> found any methods for acknowledging specific message as well as for
>> releasing or rejecting a message.
>>
>> Regards
>> Jakub
>>
>> On Fri, Apr 13, 2012 at 07:43, Rajith Attapattu<rajith77@gmail.com>
>> =A0wrote:
>>>
>>> (Note for C++ broker we do client side selectors, which does exactly wh=
at
>>> you have described).
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>> For additional commands, e-mail: users-help@qpid.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org