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 <patrik.blaes...@agfa.com> 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 >
