Github user michaelandrepearce commented on the issue:
https://github.com/apache/activemq-artemis/pull/2418
@gemmellr im closing this, ive split this into two now as you had suggested.
First is the minimal changes needed to fix the immediate issue
Github user michaelandrepearce commented on the issue:
https://github.com/apache/activemq-artemis/pull/2418
@gemmellr your suggestions are great, i haven't ignored your comments, im
still working on small fix, it is a good idea you suggested to have this
seperated as 2 commits/prs.
Github user michaelandrepearce commented on the issue:
https://github.com/apache/activemq-artemis/pull/2418
Just a note, not related to fixing the current sequence issue.
But if we left the setters in they would fix a regression in feature around
enforced broker side user,
Github user michaelandrepearce commented on the issue:
https://github.com/apache/activemq-artemis/pull/2418
Pushed update and build with above mentioned changes,
---
Github user michaelandrepearce commented on the issue:
https://github.com/apache/activemq-artemis/pull/2418
So i looked at this some more to see what i can do, i simply can't work
around the fact the OpenWireMessage will always return an int, as such it will
always set sequence, so
Github user gemmellr commented on the issue:
https://github.com/apache/activemq-artemis/pull/2418
> So openwire always returns a value on asking groupseq. It never gives an
ability to determine if it was set by client or not.
It does seem to return a value if you ask for one,
Github user michaelandrepearce commented on the issue:
https://github.com/apache/activemq-artemis/pull/2418
I can add tests that would show the other breaks i found. That a sticky
plaster null check solution wouldnt fix.
---
Github user michaelandrepearce commented on the issue:
https://github.com/apache/activemq-artemis/pull/2418
I would much rather we fix this proper of your adament for a sticky plaster
then fine. But i see doing that being problematic longer run as we just keep
hiding underlying
Github user michaelandrepearce commented on the issue:
https://github.com/apache/activemq-artemis/pull/2418
Re:
Oh, right. Yes, according to the changelog adding it, it deliberately
wasn't implemented in the AMQPMessage, which makes sense because per my earlier
comment using
Github user michaelandrepearce commented on the issue:
https://github.com/apache/activemq-artemis/pull/2418
So openwire always returns a value on asking groupseq. It never gives an
ability to determine if it was set by client or not.
---
Github user gemmellr commented on the issue:
https://github.com/apache/activemq-artemis/pull/2418
> Re seq not set, its an int field so its tech always set if you request
it, just should default 0 if not set.
JMSXGroupSeq is set explicitly by the application. If it isn't set
Github user michaelandrepearce commented on the issue:
https://github.com/apache/activemq-artemis/pull/2418
So the issue was sequence wasnt being transposed correctly also found other
jmsx ones werent in doing so. But just been under the cover. Thus what we fix
here.
Re the
Github user gemmellr commented on the issue:
https://github.com/apache/activemq-artemis/pull/2418
I tried the tests and they worked, but it occurred to me that though
changes might be needed in general to fix whats currently stopping the tests
passing, just making them pass is likely
Github user michaelandrepearce commented on the issue:
https://github.com/apache/activemq-artemis/pull/2418
@gemmellr this should sort the failures you're seeing out.
---
14 matches
Mail list logo
