In addition: I saw that this option presettles all incoming messages directly after consuming, even if initially sent unsettled. This would mean for us, that our acknowledgement of correct end to end processing wouldn't work anymore.
I think I misunderstood the initial meaning of this property. Does the jms.presettlePolicy.presettleConsumers parameter filter which messages are consumed by the connection (if set false presettled messages are dropped) on top of presettling everything incoming? Or was this filter mechanism a misunderstanding and QoS=0 messages are consumed right away, even without setting this property? Best regards David Schwilk Bosch IoT Things- Product Area IoT Platform (IOC/PAP-TH) Bosch.IO GmbH | Ziegelei 7 | 88090 Immenstaad | GERMANY | www.bosch.io david.schw...@bosch-si.com Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten Lücke; Geschäftsführung: Dr. Stefan Ferber, Dr. Aleksandar Mitrovic, Yvonne Reckling -----Original Message----- From: Schwilk David (IOC/PAP-TH) <david.schw...@bosch.io.INVALID> Sent: Montag, 22. Juni 2020 10:47 To: users@qpid.apache.org Subject: RE: Verify presettlement of incoming JmsMessages Hi Robbie, thank you for your quick answer, We have tested setting this property now. We now receive presettled messages and not settled messages (QoS 0 and 1) on the same connection with jms.presettlePolicy.presettleConsumers set as parameter. Is this the expected behavior of the property or could it be a failure in our testing? I can't exactly figure it out from the documentation. I would assume that not settled messages would not be received when setting this property. This would allow us to make a differentiation between QoS 0 and 1 messages on our side, while still consuming both. (Setting up 2 connections, one receiving only QoS 0 (with presettleMode), the other only QoS 1 messages) Thank you very much and best regards David Schwilk Bosch IoT Things- Product Area IoT Platform (IOC/PAP-TH) Bosch.IO GmbH | Ziegelei 7 | 88090 Immenstaad | GERMANY | www.bosch.io david.schw...@bosch-si.com Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten Lücke; Geschäftsführung: Dr. Stefan Ferber, Dr. Aleksandar Mitrovic, Yvonne Reckling -----Original Message----- From: Robbie Gemmell <robbie.gemm...@gmail.com> Sent: Donnerstag, 18. Juni 2020 16:01 To: users@qpid.apache.org Subject: Re: Verify presettlement of incoming JmsMessages No, there isn't any API for checking the delivery settlement status in the JMS client, and none is planned. The JMS client uses consumer link settings that specify unsettled messages be received, unless configured otherwise using the presettlePolicy connection options in which case it can request settled messages be received. Aside: for proton-j the isSettled() method returns a local settlement indication only, remotelySettled() returns the remote settlement indication. Robbie On Thu, 18 Jun 2020 at 14:16, Schwilk David (IOC/PAP-TH) <david.schw...@bosch.io.invalid> wrote: > > Hello, > > As part of the project Eclipse Ditto we use the Qpid JMS client 0.45.0. > We want to check if the incoming JmsMessages were presettled by the system, > sending the message. > > I saw that this possibility exists in Qpid Proton client via the function > Delivery.isSettled(). > Is there a similar functionality already implemented/planned for the JMS > client? > > Thank you and best regards > > David Schwilk > > Bosch IoT Things- Product Area IoT Platform (IOC/PAP-TH) Bosch.IO GmbH > | Ziegelei 7 | 88090 Immenstaad | GERMANY | www.bosch.io Tel. +49 7545 > 202-114 | Telefax +49 7545 202-301 | > david.schw...@bosch-si.com<mailto:david.schw...@bosch-si.com> > > Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 > B > Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten Lücke; Geschäftsführung: > Dr. Stefan Ferber, Dr. Aleksandar Mitrovic, Yvonne Reckling > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
