[GitHub] activemq-artemis issue #2392: ARTEMIS-2100 address routing-type overridden o...
Github user mtaylor 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 with capability 'queue' would not be seen by subscribers with capability 'topic'. That is not how it behaves though. Messages from all senders go to all bound queues. Are you sure this is the case? If it does behave in this way then it's a bug and we've broken JMS semantics. > > Two further separate points: > > (1) If the address already exists with multicast, and an amqp receiver attaches with capability 'queue' (i.e. anycast), the address is not modified and the queue is not created. The receiver is detached with an error that queue support is not configured. (To me that is sensible behaviour). However a sender requesting the same thing results in the address being changed and a queue being created. That seems inconsistent at best. Again, I don't think this is the case, but if you've experienced this with AMQP then it's clearly a bug and we should get it fixed. > > (2) Once a sender has forced a pre-defined address to support anycast, a receiver using a fully qualified queue name - myaddress::mysubscription - will get an error unless they request 'topic' capability though surely this form of address is entirely clear on what is required. I don't think I get this one. The FQQN bit is meant to bypass all checks and connect directly to the queue regardless of it's routing type. ---
[GitHub] activemq-artemis pull request #2397: ARTEMIS-2116 Extend tests on producer C...
GitHub user feuillemorte opened a pull request: https://github.com/apache/activemq-artemis/pull/2397 ARTEMIS-2116 Extend tests on producer CLI command with message body Added tests on producer cli command Cases: * Produce 10 messages with default message body * Produce 10 messages with custom message body * Produce 10 messages with default message body (FQQN) * Produce 10 messages with custom message body (FQQN) * Produce 10 messages with custom message body (long string - 500 000 symbols) You can merge this pull request into a Git repository by running: $ git pull https://github.com/feuillemorte/activemq-artemis ARTEMIS_2116_extend_tests Alternatively you can review and apply these changes as the patch at: https://github.com/apache/activemq-artemis/pull/2397.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #2397 commit 681bec7a4bae990a123b47adbedaa596bd800d72 Author: feuillemorte Date: 2018-10-26T13:35:29Z ARTEMIS-2116 Extend tests on producer CLI command with message body ---
[GitHub] activemq-artemis issue #2392: ARTEMIS-2100 address routing-type overridden o...
Github user grs commented on the issue: https://github.com/apache/activemq-artemis/pull/2392 Yes, I am sure iof all these points. ---
[GitHub] activemq-artemis issue #2392: ARTEMIS-2100 address routing-type overridden o...
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 with capability 'queue' would not be seen by subscribers with capability 'topic'. That is not how it behaves though. Messages from all senders go to all bound queues. Two further separate points: (1) If the address already exists with multicast, and an amqp receiver attaches with capability 'queue' (i.e. anycast), the address is not modified and the queue is not created. The receiver is detached with an error that queue support is not configured. (To me that is sensible behaviour). However a sender requesting the same thing results in the address being changed and a queue being created. That seems inconsistent at best. (2) Once a sender has forced a pre-defined address to support anycast, a receiver using a fully qualified queue name - myaddress::mysubscription - will get an error unless they request 'topic' capability though surely this form of address is entirely clear on what is required. ---
[GitHub] activemq-artemis issue #2399: ARTEMIS-2150 Counts the number of delivering m...
Github user michaelandrepearce commented on the issue: https://github.com/apache/activemq-artemis/pull/2399 @ArthurFritz LGTM, thanks for fixing up the commit message. Just waiting on PR build if good ill look to merge. Thanks for the contribution. ---
[GitHub] activemq-artemis pull request #2398: [ARTEMIS-2150] Counts the number of del...
Github user michaelandrepearce commented on a diff in the pull request:
https://github.com/apache/activemq-artemis/pull/2398#discussion_r228623226
--- Diff:
artemis-server/src/main/java/org/apache/activemq/artemis/core/management/impl/QueueControlImpl.java
---
@@ -740,6 +733,56 @@ public String countMessages(final String filterStr,
final String groupByProperty
}
}
+ @Override
+ public long countDeliveringMessages(final String filterStr) throws
Exception {
+ Long value = intenalCountDeliveryMessages(filterStr, null).get(null);
+ return value == null ? 0 : value;
+ }
+
+ @Override
+ public String countDeliveringMessages(final String filterStr, final
String groupByProperty) throws Exception {
+ return JsonUtil.toJsonObject(intenalCountDeliveryMessages(filterStr,
groupByProperty)).toString();
+ }
+
+ private Map intenalCountDeliveryMessages(final String
filterStr, final String groupByPropertyStr) throws Exception {
+ checkStarted();
+
+ clearIO();
+
+ Map result = new HashMap<>();
+ try {
+ Filter filter = FilterImpl.createFilter(filterStr);
+ SimpleString groupByProperty =
SimpleString.toSimpleString(groupByPropertyStr);
+ if (filter == null && groupByProperty == null) {
+result.put(null, Long.valueOf(getDeliveringCount()));
+ } else {
+Map> deliveringMessages =
queue.getDeliveringMessages();
--- End diff --
actually on further looking i see benefit in what you're doing, it keeps
management logic and features out the core queue and consumer code, so actually
+1 your approach.
---
[GitHub] activemq-artemis pull request #2388: ARTEMIS-1856 support delays before dele...
Github user asfgit closed the pull request at: https://github.com/apache/activemq-artemis/pull/2388 ---
[GitHub] activemq-artemis pull request #2399: ARTEMIS-2150 Counts the number of deliv...
GitHub user ArthurFritz opened a pull request: https://github.com/apache/activemq-artemis/pull/2399 ARTEMIS-2150 Counts the number of delivering messages in this queue Create function this counts the number of delivering messages in this queue matching the specified filter. Create a other function this counts the number of delivering messages in this queue matching the specified filter, grouped by the given property field. [JIRA](https://issues.apache.org/jira/browse/ARTEMIS-2150) You can merge this pull request into a Git repository by running: $ git pull https://github.com/ArthurFritz/activemq-artemis feature/ARTEMIS-2150 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/activemq-artemis/pull/2399.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #2399 commit 5b32235d7ca4230bfb6d4956ffdef026d5bb51cb Author: Arthur Fritz Santiago Date: 2018-10-26T18:32:34Z ARTEMIS-2150 Counts the number of delivering messages in this queue ---
[GitHub] activemq-artemis pull request #2398: ARTEMIS-2150 Counts the number of deliv...
Github user ArthurFritz closed the pull request at: https://github.com/apache/activemq-artemis/pull/2398 ---
[GitHub] activemq-artemis issue #2398: ARTEMIS-2150 Counts the number of delivering m...
Github user ArthurFritz commented on the issue: https://github.com/apache/activemq-artemis/pull/2398 Okay, i created new Merge Request, adjusted commit message :smiley: ---
[GitHub] activemq-artemis pull request #2398: [ARTEMIS-2150] Counts the number of del...
GitHub user ArthurFritz opened a pull request: https://github.com/apache/activemq-artemis/pull/2398 [ARTEMIS-2150] Counts the number of delivering messages in this queue Create function this counts the number of delivering messages in this queue matching the specified filter. Create a other function this counts the number of delivering messages in this queue matching the specified filter, grouped by the given property field. [JIRA](https://issues.apache.org/jira/browse/ARTEMIS-2150) You can merge this pull request into a Git repository by running: $ git pull https://github.com/ArthurFritz/activemq-artemis feature/ARTEMIS-2150 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/activemq-artemis/pull/2398.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #2398 commit 1396ec6d825708994fa8d680f5c42480aacd410a Author: Arthur Fritz Santiago Date: 2018-10-26T17:39:09Z [ARTEMIS-2150] Counts the number of delivering messages in this queue ---
[GitHub] activemq-artemis pull request #2398: [ARTEMIS-2150] Counts the number of del...
Github user michaelandrepearce commented on a diff in the pull request:
https://github.com/apache/activemq-artemis/pull/2398#discussion_r228619277
--- Diff:
artemis-server/src/main/java/org/apache/activemq/artemis/core/management/impl/QueueControlImpl.java
---
@@ -740,6 +733,56 @@ public String countMessages(final String filterStr,
final String groupByProperty
}
}
+ @Override
+ public long countDeliveringMessages(final String filterStr) throws
Exception {
+ Long value = intenalCountDeliveryMessages(filterStr, null).get(null);
+ return value == null ? 0 : value;
+ }
+
+ @Override
+ public String countDeliveringMessages(final String filterStr, final
String groupByProperty) throws Exception {
+ return JsonUtil.toJsonObject(intenalCountDeliveryMessages(filterStr,
groupByProperty)).toString();
+ }
+
+ private Map intenalCountDeliveryMessages(final String
filterStr, final String groupByPropertyStr) throws Exception {
+ checkStarted();
+
+ clearIO();
+
+ Map result = new HashMap<>();
+ try {
+ Filter filter = FilterImpl.createFilter(filterStr);
+ SimpleString groupByProperty =
SimpleString.toSimpleString(groupByPropertyStr);
+ if (filter == null && groupByProperty == null) {
+result.put(null, Long.valueOf(getDeliveringCount()));
+ } else {
+Map> deliveringMessages =
queue.getDeliveringMessages();
--- End diff --
getDeliveringMessages() doesn't return a thead safe reference, as such the
list can change beneath. this will expose thread safety issues
---
[GitHub] activemq-artemis issue #2388: ARTEMIS-1856 support delays before deleting ad...
Github user michaelandrepearce commented on the issue: https://github.com/apache/activemq-artemis/pull/2388 @jbertram it wasn't a biggie, i guess more important things are a foot, so merging. And can always add the extra config to the other as and when needed in future. ---
[GitHub] activemq-artemis issue #2399: ARTEMIS-2150 Counts the number of delivering m...
Github user ArthurFritz commented on the issue: https://github.com/apache/activemq-artemis/pull/2399 @michaelandrepearce Nice, Tks ---
[GitHub] activemq-artemis issue #2398: [ARTEMIS-2150] Counts the number of delivering...
Github user michaelandrepearce commented on the issue: https://github.com/apache/activemq-artemis/pull/2398 @ArthurFritz LGTM (when build passes for checkstyle etc etc) could you merge the commits? Also could you tidy the commit message to be in the form: "ARTEMIS- You Commit Subject" ---
[GitHub] activemq-artemis pull request #2399: ARTEMIS-2150 Counts the number of deliv...
Github user asfgit closed the pull request at: https://github.com/apache/activemq-artemis/pull/2399 ---
Re: Website
+1
Bruce
On Tue, Oct 23, 2018 at 2:26 PM Clebert Suconic
wrote:
> What about this. WE could :
>
> - commit this on git
> - upload a snapshot for review under our web-site.
> On Mon, Oct 22, 2018 at 8:46 AM Clebert Suconic
> wrote:
> >
> > +1000. We had that options discussed here a few times. Having the old
> website somewhere with a link is the way to go for the migration.
> >
> > On Mon, Oct 22, 2018 at 7:47 AM michael.andre.pearce <
> michael.andre.pea...@me.com.invalid> wrote:
> >>
> >> Sounds good to me.
> >>
> >>
> >> Sent from my Samsung Galaxy smartphone.
> >> Original message From: Martyn Taylor <
> mtay...@redhat.com> Date: 22/10/2018 12:38 (GMT+00:00) To:
> dev@activemq.apache.org Subject: Re: Website
> >> How about an equivalent message on the home page of the new website,
> >> directing users to the old site?
> >>
> >> On Fri, Oct 19, 2018 at 10:39 PM Bruce Snyder
> >> wrote:
> >>
> >> > Check out the Camel website and the message that they posted about
> their
> >> > website changes that are underway:
> >> >
> >> > https://camel.apache.org/
> >> >
> >> > Bruce
> >> >
> >> > On Wed, Oct 17, 2018 at 3:30 AM Martyn Taylor
> wrote:
> >> >
> >> > > On Fri, Oct 12, 2018 at 8:38 PM Bruce Snyder <
> bruce.sny...@gmail.com>
> >> > > wrote:
> >> > >
> >> > > > Fair points, Martyn. I like the idea of a combination of JIRA
> issues
> >> > > plus a
> >> > > > list of those issues that is easily visible somewhere such as the
> wiki.
> >> > > >
> >> > > > Seeing as how we are moving the website around completely, I
> believe we
> >> > > > need to include the docs to support the older versions in some
> way. So,
> >> > > the
> >> > > > first thought that came to mind is a search capability in order
> for
> >> > users
> >> > > > to find them easier. Another idea, we could also keep the old site
> >> > intact
> >> > > > and available as a sub-domain or URL, e.g.,
> 5x.activemq.apache.org,
> >> > > > activemq.apache.org/5.x, etc. However, the advantage of a search
> >> > feature
> >> > > > is
> >> > > > that it would be useful across the site, not just for older
> stuff. We
> >> > > might
> >> > > > even be able structure the search to allow users to select a
> version of
> >> > > the
> >> > > > docs that they would like to search. Anyway, just some thoughts.
> >> > > >
> >> > > > I agree that we should try to get the new site functional ASAP,
> but
> >> > that
> >> > > > should not eliminate the old site entirely. We should not abandon
> users
> >> > > of
> >> > > > older versions.
> >> > > >
> >> > > +1 Bruce.
> >> > >
> >> > > I had thought that the export of the current site into the gitbook
> had
> >> > all
> >> > > the info, but perhaps there are missing pieces. I like the idea of
> >> > keeping
> >> > > the old site running and link to it from the new site. This ensures
> >> > > existing users have all the info they need, but let's us move
> forward
> >> > with
> >> > > new content. Perhaps we can switch out the exiting home page for
> the new
> >> > > one and add a link to old website AMQ project page ("Existing users
> >> > looking
> >> > > for the original ActiveMQ website click here."). If we are able to
> get
> >> > > some stats on number of accesses to a particular page, we can use
> that
> >> > info
> >> > > to prioritise porting older content.
> >> > >
> >> > > Search, feature also a good idea, but I'm not sure how much effort
> would
> >> > be
> >> > > involved, there is already a search feature in the gitbook document
> >> > (linked
> >> > > to on the project page).
> >> > >
> >> > > How about we fill in the existing placeholder content and add links
> to
> >> > the
> >> > > old sites from each project page (and the home page)? We could go
> live
> >> > > with this? Then start working through the nice to
> haves/criticals. I
> >> > > think once we're live and the code is available, the community will
> be
> >> > more
> >> > > inclined to report/fixing issues.
> >> > >
> >> > > Cheers
> >> > >
> >> > > >
> >> > > > Bruce
> >> > > >
> >> > > > On Fri, Oct 12, 2018 at 2:44 AM Martyn Taylor >
> >> > > wrote:
> >> > > >
> >> > > > > Cheers gents, looks like we're all set with the git repos.
> >> > > > >
> >> > > > > Shall we start putting together a ToDo list for what needs to
> happen
> >> > to
> >> > > > > move to the new site? JIRA perhaps?
> >> > > > >
> >> > > > > Bruce you mentioned a search feature for older content. Can you
> >> > > > elaborate
> >> > > > > on this. Also, there's the actual content for the pages, key
> >> > features,
> >> > > > > users etc... Perhaps we can all contribute to these? I could
> take
> >> > care
> >> > > > of
> >> > > > > the Artemis side of things, if people with more experience in
> NMS,
> >> > CMS
> >> > > > and
> >> > > > > 5.x could come up with some content for the project home pages?
> >> > > > >
> >> > > > > I agree with Michael in that it'd be good to get the new site
> running
> >> > > > even
> >> > > > > if it's
[GitHub] activemq-artemis issue #2396: ARTEMIS-2149 Protecting message.sendBuffer fro...
Github user michaelandrepearce commented on the issue: https://github.com/apache/activemq-artemis/pull/2396 Another thing ive noticed is currently where validBuffer is changed its not protected its only volatile, so you could enter syncronized method do the validBuffer check, but then subsequently because the validBuffer isn't protected it could change, before you exit the synced method. ---
[GitHub] activemq-artemis issue #2392: ARTEMIS-2100 address routing-type overridden o...
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 every sender explicitly requests multicast. Dynamic creation of an address should only apply if the address does not exist, hence the word 'create'. Current behaviour is wrong and not what is documented. And I have never said an address cannot be both anycast and multicast, though the documentation explicitly describes this as an antipattern. For AMQP however the current behaviour means it cannot be both. Once a multicast address is recreated by the broker with anycast added, its use for multicast receivers is broken, though receivers connected before that change will continue to receive in multicast which does not honour the senders wishes. Nor is the senders wish honoured if it chooses multicast after that. ---
[GitHub] activemq-artemis issue #2392: ARTEMIS-2100 address routing-type overridden o...
Github user michaelandrepearce commented on the issue: https://github.com/apache/activemq-artemis/pull/2392 Disagree AMQP is just a protocol. A broker is just another client. There is nothing to say an address cannot be both anycast and multicast. And as such if you have left the setting to allow dynamic creation on the broker then youre allowing if the type is not currently on the address for that to be created is valid. If you dont want that simply disable the ability to create queues dynamically broker side ---
[GitHub] activemq-artemis issue #2392: ARTEMIS-2100 address routing-type overridden o...
Github user mtaylor commented on the issue: https://github.com/apache/activemq-artemis/pull/2392 There are two things at play here. AMQP raw protocol and extensions to AMQP that are broker specific. 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 configured on that address. If an address has a single routing type configured e.g. Multicast, the message should be routed there, it should not create a new routing type with Anycast, which is what is happening here. Artemis also implements the JMS AMQP extension, which enables additional functionality, one of which is the ability to define a sender destination type, i.e. Queue or Topic. These map to Address Anycast and Multicast respectively. In this case (with auto-create disabled), if an AMQP client using this extension e.g. QPID JMS client, sends explicitly sends to Anycast, but only a Multicast address exists, then an error should be returned. With auto-create enabled for both addresses and queues, the behaviour would be different, an Anycast address would be created and no error thrown. There is a special case here, when using the AMQP protocol raw (no extensions), so not specifying the routing type, and using auto create addresses. If the AMQP client sends to an address that does not exist, the broker has no way of know what type of routing type to create. In this case, the default routing type setting on the address setting is used. There's another case, which I think is what is happening here. If there exists a Mutlicast address the AMQP client raw sends here and the default routing type is Anycast with auto-create enabled. Instead of routing the message to the pre-existing routing type, it is instead trying to auto-create a new one. ---
[GitHub] activemq-artemis issue #2392: ARTEMIS-2100 address routing-type overridden o...
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 configured on that address. If an address has a single routing type configured e.g. Multicast, the message should be routed there, it should not create a new routing type with Anycast, which is what is happening here. agreed > Artemis also implements the JMS AMQP extension, which enables additional functionality, one of which is the ability to define a sender destination type, i.e. Queue or Topic. These map to Address Anycast and Multicast respectively. In this case (with auto-create disabled), if an AMQP client using this extension e.g. QPID JMS client, sends explicitly sends to Anycast, but only a Multicast address exists, then an error should be returned. > > With auto-create enabled for both addresses and queues, the behaviour would be different, an Anycast address would be created and no error thrown. This would make sense if anycast and multicast addresses (i.e. queue and topic) were entirely independent. They are not though. ---
[GitHub] activemq-artemis issue #2392: ARTEMIS-2100 address routing-type overridden o...
Github user mtaylor 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 configured on that address. If an address has a single routing type configured e.g. Multicast, the message should be routed there, it should not create a new routing type with Anycast, which is what is happening here. > > agreed > > > Artemis also implements the JMS AMQP extension, which enables additional functionality, one of which is the ability to define a sender destination type, i.e. Queue or Topic. These map to Address Anycast and Multicast respectively. In this case (with auto-create disabled), if an AMQP client using this extension e.g. QPID JMS client, sends explicitly sends to Anycast, but only a Multicast address exists, then an error should be returned. > > With auto-create enabled for both addresses and queues, the behaviour would be different, an Anycast address would be created and no error thrown. > > This would make sense if anycast and multicast addresses (i.e. queue and topic) were entirely independent. They are not though. I am not sure what you mean by entirely independent. Can you elaborate. ---
