Github user grs commented on the issue:
https://github.com/apache/activemq-artemis/pull/2392
Yes, I am sure iof all these points.
---
Github user grs commented on the issue:
https://github.com/apache/activemq-artemis/pull/2392
If the queue and topic with the same name/address were independent, then
clients explicitly selecting one or the other would not see each others
messages. Messages from a sender
Github user grs commented on the issue:
https://github.com/apache/activemq-artemis/pull/2392
> With AMQP raw, there is no such thing as a routing type (this is a broker
concept). Therefore messages sent via AMQP to an address should be routed to
any routing type currently configu
Github user grs commented on the issue:
https://github.com/apache/activemq-artemis/pull/2392
I am talking only about the AMQP support. It is inconsistent. It does not
as you say 'honour the sender'. It effectively forces the behaviour of anycast
on all subsequent clients, unless
Github user grs commented on the issue:
https://github.com/apache/activemq-artemis/pull/2392
@michaelandrepearce re: "if producer explicitly sets a routing type, it
must be honoured", I'm not sure what you mean there.
At least from AMQP, the routing types is
Github user grs commented on the issue:
https://github.com/apache/activemq-artemis/pull/2392
Two points:
1) in my case, accessing over AMQP, the sender is *not* defining any
routing type
2) I would not expect a sender requesting a routing type explicitly to
redefine
Github user grs commented on the issue:
https://github.com/apache/activemq-artemis/pull/2392
@michaelandrepearce @franz1981 the issue is that if an address is defined
to be multicast only, then a sender to it over AMQP causes the address to be
redefined as multicast and anycast
Github user grs commented on the issue:
https://github.com/apache/activemq-artemis/pull/746
Ok, I think I understand now. You are only attempting the conversion if the
source message does not have the property set and additionally are catching any
failure to read the body buffer
Github user grs commented on the issue:
https://github.com/apache/activemq-artemis/pull/746
To be perfectly honest, I don't really understand the change. (Or why it
caused other tests to fail, since prior to my change the body would have simply
not been encoded at all).
I
Github user grs commented on the issue:
https://github.com/apache/activemq-artemis/pull/746
My apologies for breaking this!
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
GitHub user grs opened a pull request:
https://github.com/apache/activemq-artemis/pull/742
ARTEMIS-657: ensure management response bodies are encoded into amqp
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/grs/activemq-artemis
Github user grs commented on the issue:
https://github.com/apache/activemq-artemis/pull/712
@mtaylor sorry, I think that was because I merged rather than rebased when
syncing my fork. Will avoid that next time.
@clebertsuconic thanks!
---
If your project is set up
Github user grs commented on a diff in the pull request:
https://github.com/apache/activemq-artemis/pull/712#discussion_r74246549
--- Diff:
artemis-protocols/artemis-proton-plug/src/main/java/org/proton/plug/context/AbstractConnectionContext.java
---
@@ -73,6 +76,8 @@ public
GitHub user grs opened a pull request:
https://github.com/apache/activemq-artemis/pull/712
Artemis 447
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/grs/activemq-artemis ARTEMIS-447
Alternatively you can review and apply
GitHub user grs opened a pull request:
https://github.com/apache/activemq-artemis/pull/698
ARTEMIS-446: use name from broker.xml as container id in AMQP open frame
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/grs/activemq
15 matches
Mail list logo
