[GitHub] activemq-artemis issue #2369: ARTEMIS-2123 Paging not stopped if there are n...
Github user wy96f commented on the issue: https://github.com/apache/activemq-artemis/pull/2369 > @wy96f are you waiting a release to apply your patch? @clebertsuconic We have an internal branch. We will upgrade our cluster after a month. ---
[GitHub] activemq-artemis pull request #2396: ARTEMIS-2149 Protecting message.sendBuf...
Github user asfgit closed the pull request at: https://github.com/apache/activemq-artemis/pull/2396 ---
[GitHub] activemq-artemis issue #2396: ARTEMIS-2149 Protecting message.sendBuffer fro...
Github user clebertsuconic commented on the issue: https://github.com/apache/activemq-artemis/pull/2396 @michaelandrepearce I will merge this now.. but if you could still review it after I merged it? we can send further commits. ---
[GitHub] activemq-artemis issue #2396: ARTEMIS-2149 Protecting message.sendBuffer fro...
Github user clebertsuconic commented on the issue: https://github.com/apache/activemq-artemis/pull/2396 This is now ready to be merged.. (I had a word WIP on the name here before); ---
[GitHub] activemq-artemis issue #2396: ARTEMIS-2149 Protecting message.sendBuffer fro...
Github user clebertsuconic commented on the issue: https://github.com/apache/activemq-artemis/pull/2396 @michaelandrepearce can you review this one please. ---
[GitHub] activemq-artemis pull request #2396: ARTEMIS-2149 Protecting message.sendBuf...
GitHub user clebertsuconic opened a pull request: https://github.com/apache/activemq-artemis/pull/2396 ARTEMIS-2149 Protecting message.sendBuffer from races encoding it You can merge this pull request into a Git repository by running: $ git pull https://github.com/clebertsuconic/activemq-artemis ARTEMIS-2149 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/activemq-artemis/pull/2396.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 #2396 commit 2823cdf7e222faf4dacdc9274febb1fba3ede45c Author: Clebert Suconic Date: 2018-10-25T21:27:47Z ARTEMIS-2149 Protecting message.sendBuffer from races encoding it ---
[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 @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 a property of the address, not the sender. That is it affects the behaviour of that address for all clients using it. Let's say I create an address with --no-anycast and --multicast, bind a named durable subscription queue to it, create a receiver on that named subscription queue, and two further receivers. If I know create a sender and request the 'queue' capability' (or don't request any capability), the definition of the address is changed and a queue with the same name as the address is created. However the messages from that sender are still enqueued onto each of the queues currently bound to the address (as well as the automatically created queue with the same name as the address, which now accumulates messages sent to that address not only by senders explicitly requesting anycast behaviour, but also those from senders declaring multicast behaviour). I.e. they are *not* actually being routed with anycast semantics. If my receiver to the named subscription queue exists and reconnects, it now gets an error from the broker 'Incorrect Routing Type for queue, expecting: ANYCAST' To me this seems pretty broken behaviour. ---
[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 @grs On 2. I disagree if producer explicitly sets a routing type, it must be honoured. Rr defaults these only should be used if producer does not explicitly set. @franz1981 your newer implementation looks better, in that it only sets the type if not explicitly set. +1 ---
[GitHub] activemq-artemis issue #2369: ARTEMIS-2123 Paging not stopped if there are n...
Github user clebertsuconic commented on the issue: https://github.com/apache/activemq-artemis/pull/2369 @wy96f are you waiting a release to apply your patch? ---
Re: Aggregate subscriptions from users
I assume that "filter" here means selectors. If so, my first reaction is to warn that selectors impose a heavy load on the broker, which can be seen by monitoring CPU utilization. More subscriptions with more selectors only adds to the problem. Without selectors or message groups, I have rarely seen ActiveMQ exceed 20% CPU utilization under the heaviest of loads (and even then, usually only when there's some problem contributing to the CPU utilization). With them, I have seen the broker become CPU-bound. This makes perfect sense since the broker's main job is moving messages around - which is I/O-intensive. There is a lot of optimization that _could_ be coded into the broker to handle selectors more efficiently, but that requires significant broker development effort which is unlikely as effective alternatives exists - such as filter on the application side. Having consumers pull all of the messages and ignore those they do not want can work really well. If the application is using camel, that is an easy addition to the route. With all of that said, there are always ways - this is open source after all, and it becomes a matter of balancing where a solution lives, and the development + maintenance costs associated with the same. There are several alternatives that come to mind just thinking about this problem. For example, splitting messages across multiple destinations, or adding a custom routing engine (application) that maintains the filters. Hope this helps. Art On Thu, Oct 25, 2018 at 6:58 AM PatrikBlaesius wrote: > Hello, > > we got the problem that some of our developers are subscribing to a > specific > topic several times. Each time the filter is changed a little bit and it > uses a different ID within one of its fields. > > The problem is that those thousands of subscripions cause a lot of load at > the server and therefor everything is slowing down. The developers now say > that it is really difficult for them to change this to an "in" clause > filter > and therefor this should be done by the "subscribe" method on JMS itself. > > I wanted to answer them that they are doing it wrong, but it seems to be > too > hard to get and they suggested that the subscription to the topic should > handle that. > So I kindly ask for your help if you see any possibility to aggregate > subscriptions or if you also think that the "in" filter clause is the way > to > go! > > Thanks in advance! > > Patrik > > > > -- > Sent from: > http://activemq.2283324.n4.nabble.com/ActiveMQ-Dev-f2368404.html >
Re: [VOTE] Apache ActiveMQ 5.15.7
On 10/24/18 10:41 AM, Christopher Shannon wrote: Hi Everyone, I have created the 5.15.7 release and it is ready for a vote. The list of resolved issues is here: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210=12344049 You can get the release artifacts here: https://dist.apache.org/repos/dist/dev/activemq/activemq/5.15.7/ Maven repository is at: https://repository.apache.org/content/repositories/orgapacheactivemq-1173/ Source tag: https://git-wip-us.apache.org/repos/asf?p=activemq.git;a=commit;h=795a2533b1cd4883ca1b17e7cb86d9bbc20994c5 Please vote to approve this release. The vote will remain open for 72 hours. [ ] +1 Release the binary as Apache ActiveMQ 5.15.7 [ ] -1 (provide specific comments) Here's my +1 +1 * Validated signatures and checksums * Checked for presence of license and notice files in archives * Checked using apache-rat:check that license headers are present. * Built from source and ran the sanity tests, stomp, amqp and mqtt test suites * Ran a broker instance from the binary and checked for web console functionality. * Ran some samples from Qpid JMS against the binary broker instance. -- Tim Bish
[GitHub] activemq-artemis pull request #2395: NO-JIRA Adding log.warn statements in c...
Github user asfgit closed the pull request at: https://github.com/apache/activemq-artemis/pull/2395 ---
[GitHub] activemq-artemis pull request #2395: NO-JIRA Adding log.warn statements in c...
GitHub user clebertsuconic opened a pull request: https://github.com/apache/activemq-artemis/pull/2395 NO-JIRA Adding log.warn statements in case properties decode fails You can merge this pull request into a Git repository by running: $ git pull https://github.com/clebertsuconic/activemq-artemis NO-JIRA Alternatively you can review and apply these changes as the patch at: https://github.com/apache/activemq-artemis/pull/2395.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 #2395 commit a408bfbf9b7d347ccaa2373e02a8ce466e4f0c66 Author: Clebert Suconic Date: 2018-10-25T15:23:40Z NO-JIRA Adding log.warn statements in case properties decode fails ---
[GitHub] activemq-artemis pull request #2394: ARTEMIS-2148 Fixing typo where getDoubl...
Github user asfgit closed the pull request at: https://github.com/apache/activemq-artemis/pull/2394 ---
[GitHub] activemq-artemis pull request #2394: ARTEMIS-2148 Fixing typo where getDoubl...
GitHub user clebertsuconic opened a pull request: https://github.com/apache/activemq-artemis/pull/2394 ARTEMIS-2148 Fixing typo where getDoubleProperty marks body as changed You can merge this pull request into a Git repository by running: $ git pull https://github.com/clebertsuconic/activemq-artemis ARTEMIS-2148 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/activemq-artemis/pull/2394.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 #2394 commit 04e278cd155de0e88ab1bea659da1a2b71e96c39 Author: Clebert Suconic Date: 2018-10-25T14:41:02Z ARTEMIS-2148 Fixing typo where getDoubleProperty marks body as changed ---
Aggregate subscriptions from users
Hello, we got the problem that some of our developers are subscribing to a specific topic several times. Each time the filter is changed a little bit and it uses a different ID within one of its fields. The problem is that those thousands of subscripions cause a lot of load at the server and therefor everything is slowing down. The developers now say that it is really difficult for them to change this to an "in" clause filter and therefor this should be done by the "subscribe" method on JMS itself. I wanted to answer them that they are doing it wrong, but it seems to be too hard to get and they suggested that the subscription to the topic should handle that. So I kindly ask for your help if you see any possibility to aggregate subscriptions or if you also think that the "in" filter clause is the way to go! Thanks in advance! Patrik -- Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-Dev-f2368404.html
Re: [VOTE] Apache ActiveMQ 5.15.7
+1 (non-binding) Cheers, Jamie On Thu, Oct 25, 2018 at 12:50 AM Jean-Baptiste Onofré wrote: > > +1 > > Thanks ! > > Regards > JB > > On 24/10/2018 16:41, Christopher Shannon wrote: > > Hi Everyone, > > > > I have created the 5.15.7 release and it is ready for a vote. > > > > The list of resolved issues is here: > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210=12344049 > > > > You can get the release artifacts here: > > https://dist.apache.org/repos/dist/dev/activemq/activemq/5.15.7/ > > > > Maven repository is at: > > https://repository.apache.org/content/repositories/orgapacheactivemq-1173/ > > > > Source tag: > > https://git-wip-us.apache.org/repos/asf?p=activemq.git;a=commit;h=795a2533b1cd4883ca1b17e7cb86d9bbc20994c5 > > > > Please vote to approve this release. The vote will remain open for 72 > > hours. > > > > [ ] +1 Release the binary as Apache ActiveMQ 5.15.7 > > [ ] -1 (provide specific comments) > > > > Here's my +1 > >
[GitHub] activemq-artemis issue #2392: ARTEMIS-2100 address routing-type overridden o...
Github user franz1981 commented on the issue: https://github.com/apache/activemq-artemis/pull/2392 @michaelandrepearce I think to have misread the issue: the current behaviour is not bad, just is not taking in consideration the already existing address routingType(s) and just choosing the default one when no specific routingType is being requested...I will soon push a commit with a different way to address it ---
[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 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 a statically defined address i.e. if address pre-exists and has routing types only multicast, a sender attempting to request anycast should be informed that their intentions do not match the pre-configured semantics (of course if the address does not exist then it can be defined according to the senders desires providing auto-creation of the address is allowed). ---
[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 Point here is if the sender has specifically defined that has to be honoured. ---
[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 @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 *and* a queue is created with the same name as the address, meaning that all other use of that address over AMQP now uses the queue. What I want is the ability to define an address that reliably behaves as a topic. ---
[GitHub] activemq-artemis issue #2392: ARTEMIS-2100 address routing-type overridden o...
Github user franz1981 commented on the issue: https://github.com/apache/activemq-artemis/pull/2392 @michaelandrepearce I understand your point here, just I'm not sure is only a matter of flexibility here, but more of user expectations and I admit that it makes this a lot more subjective to be judged. The point of the issue is that if an address already exists, but without any queue on it, which routing type configuration will take precendence while creating a new one? For some users It could be the default routing type specified on the addresses settings, while for others the ones defined in the already existing address. I admit that I'm more of the idea that the latter is matching most user expectations, but is just a personal taste. ---
