Re: [Artemis 2.6.2] AMQP messages going to expiry queue, redelivery off that queue is failing

[Dan Langford]

ok i wrote 3 test files. I don't know the best way to get them to you
easily. hopefully a Gist is ok.
https://gist.github.com/danlangford/071e738225ec0c68dd470816b977499b

you can copy those 3 files straight to
./tests/integration-tests/src/test/java/org/apache/activemq/artemis/tests/integration/amqp

The test JMSTransactedRedeliveryTest::testAMQPProducerAMQPConsumer proves
that a transacted client can .rollback() a handful of times and still be
able to consume the redelivered message later on.

The test JMSTransactedRedeliveryBugTest::testAMQPProducerAMQPConsumer shows
that if a message had been expired and now a transacted client is
attempting to consume it the client only has 2 chances before the broker
starts sending the message in a way that will not parse correctly

The test JMSNonTransactedRedeliveryBugTest::testAMQPProducerAMQPConsumer shows
that if a message had been expired a non-transacted client has no troubles
reliably accessing the redelivered message from broker


as you can tell i am mostly concerned about AMQP->AMQP for my use case.
some of those other combos are failing some of these tests in other ways.
naturally you can address those as you see fit but for my client the
AMQP->AMQP is a roadblocker.


let me know if you can determine why the broker is sending an extra null
character in the payload on the third time the messages attempts delivery.
maybe we are doing something incorrectly.


This has been more of an issue than i thought due to the fact that Spring
default to enabling transactions. in all of my initial tests i couldn't
reproduce it because i prefer the straight simplified jms api from 2.0 and
that defaults to sessions not being transacted. that being said nearly all
of my clients prefer using Spring Boot autoconfigurer and other spring
pieces which happen to default to transacted sessions.  i can now have some
of them workaround but others of them are requiring the transaction.


also as a reminder and for context here is a link to the initial
conversation i had with the Qpid Jms Client devs who pointed out to me the
erroneous null character in the message transfer from the broker:
https://lists.apache.org/
thread.html/b1fd9c09a1f66f5529601a8651fbb96585c011b22bbd84e07c4f23b1@%3Cusers.qpid.apache.org%3E


thank you so much for your time

On Tue, Aug 14, 2018 at 1:19 PM Timothy Bish  wrote:

> On 08/13/2018 07:12 PM, Dan Langford wrote:
> > some of my users are attempting a pattern to deduplicate messages based
> on
> > a time window instead of a fixed amount of space (a duplicate id cache)
> >
> > so far the concept has been working very well. So they send their AMQP
> > messages (qpid-jms-client) into a Last Value Queue with an appropriate
> > identifier in the _AMQ_LVQ_NAME. They also set a TimeToLive on the
> message
> > that is essentially the lag they will allow as they want to wait for
> > possible duplicates. If any duplicates come in the Last Value Queue
> > behavior is replacing the older message with the newer message until the
> > expiration. expired messages are delivered to the preconfigured expiry
> > queue where their application is listening. This is not perfect but its
> not
> > intended to be. Its just intended to reduce additional unnecessary
> > processing and they understand this is not a guarantee. It really helps
> > with a system that produces messages in a way that has flurries of
> > "notifications" about the same assetID over and over again.
> >
> > BUT where we are seeing is a problem is when we are consuming from the
> > queue used to hold expired messages and we toss some exception and the
> > message needs to be redelivered. the first time or two the message is
> > redelivered it is delivered OK. But when the JMSXDeliveryCount is about 3
> > or 4 (we use redelivery delay and multipliers to spread these out) our
> > qpid-jms-client stops being able to read the messages.
> >
> > we were only able to reproduce this when an AMQP message expired onto the
> > queue. (expired from a LVQ in case that is relevant). if we place the
> > message directly on a queue and test different exception and redelivery
> > scenarios we cannot reproduce this behavior.
> >
> > i enable the qpid-jms-client frame logging (via env variable
> > PN_TRACE_FRM=true) and i saw that in the situation when the client code
> > cannot access the payload, even though the broker WAS still sending the
> > payload. so i thought it was some odd issue with the client. The Apache
> > Qpid team responded that the issue seems to be that the broker starts to
> > send some ill formed payloads in this scenario. i dont want to repeat the
> > stack traces and their response, you can read those here
> >
> >
> https://lists.apache.org/thread.html/b1fd9c09a1f66f5529601a8651fbb96585c011b22bbd84e07c4f23b1@%3Cusers.qpid.apache.org%3E
> >
> > would it be helpful if i tested that this happens if there is not a LVQ
> > involved? i could have a message in a non-LVQ expire to another queue and
> > see if r

Redelivery of pending messages using amqp

[areddy]

I'm using activemq with an amqp library. When a long running consumer
consumes a message, the message stays in the pending state until the
consumer "rejects" the message or the connection dies. Is there a way to
change this behavior, perhaps a timeout configuration ? 

In other words, is it possible to configure activemq to redeliver pending
messages if they are not acknowledged after x seconds ?



--
Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html

Re: cipher in activemq

[Tom Hall]

I am assuming you mean on the ssl transports. You must specify the ones want 
enabled.

docs are here: http://activemq.apache.org/ssl-transport-reference.html 


Assuming you are running java 8 here are the list of cipher suites
https://docs.oracle.com/javase/8/docs/technotes/guides/security/StandardNames.html#ciphersuites

-Tom


> On Aug 28, 2018, at 4:44 AM, ankushssgb  wrote:
> 
> Hi,
> 
> I want to disable RC4 and 3DES ciphers in apache-activemq-5.9.0.
> 
> OS Version: CentOS7
> 
> Can any one help me, how to do it.
> 
> Regards,
> AB
> 
> 
> 
> --
> Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html

cipher in activemq

[ankushssgb]

Hi,

I want to disable RC4 and 3DES ciphers in apache-activemq-5.9.0.

OS Version: CentOS7

Can any one help me, how to do it.

Regards,
AB



--
Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html