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
>
