Sorry Martyn,

about the clientID lenght: it was a problem of my mqtt Client which had the 
compatibility with mqtt 3.1.1 disabled (stupid me).


Instead, I confirm to you the lack of fixing for weird chars on messages 
recovered from journal.


Francesco

________________________________
From: Francesco PADOVANI
Sent: Friday, February 10, 2017 2:58:19 PM
To: users@activemq.apache.org
Subject: Re: ARTEMIS: bad-performance behaviour after 7-10 days of usage


Hi Martyn,

we're testing your 1.6.0 snapshot.

The issues related to retained messages ACK and durable queues seem ok now. 
Great!

I noticed that this snapshot doesn't include the fix for weird chars when 
messages are recovered from journal: do you think it will be included in 1.5.3 
release?


And last question: with artemis 1.5.1 we were able to connect also by using 
clientID longer than 23 chars. Now, with 1.6.0 (and maybe also with 1.5.2 ...I 
admit I've not yet tested it) we can't.

It is changed something about clientid length support?


Thanks in advance.


Francesco

________________________________
From: Martyn Taylor <mtay...@redhat.com>
Sent: Thursday, February 9, 2017 5:36:19 PM
To: users@activemq.apache.org
Subject: Re: ARTEMIS: bad-performance behaviour after 7-10 days of usage

On Thu, Feb 9, 2017 at 3:54 PM, Francesco PADOVANI <
francesco.padov...@bticino.it> wrote:

> Hi Martyn,
>
> Thanks a lot for this!
>
> It could save us just in time...

I hope so.

>
> As soon as I can, I'll try to build artemis from your last commit and make
> some tests.
>
I've created a snapshot build you can test with:

https://repository.apache.org/content/groups/snapshots/org/apache/activemq/apache-artemis/1.6.0-SNAPSHOT/apache-artemis-1.6.0-20170209.161917-15-bin.zip

Please let me know how you get on.

Thanks

> Francesco
>
> ________________________________
> From: Martyn Taylor <mtay...@redhat.com>
> Sent: Thursday, February 9, 2017 1:22:52 PM
> To: users@activemq.apache.org
> Subject: Re: ARTEMIS: bad-performance behaviour after 7-10 days of usage
>
> Francesco,
>
> I think I've identified the cause of this problem.  There were two issues
> which are now fixed as part of:
> https://github.com/apache/activemq-artemis/pull/1002
>
> I'll get these fixes cherry-picked onto Artemis 1.x stream.
>
> I plan on doing a 1.5.3 (with these changes included) within the next
> couple of days.
>
> Cheers
> Martyn
>
> On Tue, Feb 7, 2017 at 10:33 AM, francesco81 <
> francesco.padov...@bticino.it>
> wrote:
>
> > Hi Martyn,
> > I'll be happy to enjoy the IRC chat as soon as I can.
> > Effectively, your words about the "treating as new subscription" would
> > explain the issue with retained messages.
> > However there's still something that I don't understand: for example why
> > also the non-retained messages are resent on resubscription. Regardless
> if
> > retained or not, it seems that all messages persist on queue (or, in case
> > of
> > retained, they persist on address and one more reference is added on
> queue
> > at each resubscription... I don't know, I'm trying to guess) and are
> never
> > discarded.
> > How are they managed by artemis? In a scenario where clients never
> connect
> > with "cleanSession=false" (that is our usecase), I thought:
> > - non-retained messages are removed from address (and references from
> > queues) once they are consumed by clients (or immediatly if no client is
> > connected).
> > - retained messages are removed from address when a new one arrives (and
> > the
> > reference to the new one substitutes the previous on the queue).
> > Is not so? I'm wrong somewhere?
> >
> > Again, thanks for your patience.
> >
> > Francesco
> >
> >
> >
> > --
> > View this message in context: http://activemq.2283324.n4.
> > nabble.com/ARTEMIS-bad-performance-behaviour-after-7-10-days-of-usage-
> > tp4721272p4721678.html
> > Sent from the ActiveMQ - User mailing list archive at Nabble.com.
> >
>
> ________________________________
>
> Ce message, ainsi que tous les fichiers joints ? ce message, peuvent
> contenir des informations sensibles et/ ou confidentielles ne devant pas
> ?tre divulgu?es. Si vous n'?tes pas le destinataire de ce message (ou que
> vous recevez ce message par erreur), nous vous remercions de le notifier
> imm?diatement ? son exp?diteur, et de d?truire ce message. Toute copie,
> divulgation, modification, utilisation ou diffusion, non autoris?e, directe
> ou indirecte, de tout ou partie de ce message, est strictement interdite.
>
>
> This e-mail, and any document attached hereby, may contain confidential
> and/or privileged information. If you are not the intended recipient (or
> have received this e-mail in error) please notify the sender immediately
> and destroy this e-mail. Any unauthorized, direct or indirect, copying,
> disclosure, distribution or other use of the material or parts thereof is
> strictly forbidden.
>

________________________________

Ce message, ainsi que tous les fichiers joints ? ce message, peuvent contenir 
des informations sensibles et/ ou confidentielles ne devant pas ?tre 
divulgu?es. Si vous n'?tes pas le destinataire de ce message (ou que vous 
recevez ce message par erreur), nous vous remercions de le notifier 
imm?diatement ? son exp?diteur, et de d?truire ce message. Toute copie, 
divulgation, modification, utilisation ou diffusion, non autoris?e, directe ou 
indirecte, de tout ou partie de ce message, est strictement interdite.


This e-mail, and any document attached hereby, may contain confidential and/or 
privileged information. If you are not the intended recipient (or have received 
this e-mail in error) please notify the sender immediately and destroy this 
e-mail. Any unauthorized, direct or indirect, copying, disclosure, distribution 
or other use of the material or parts thereof is strictly forbidden.

Reply via email to