0

We have a use case, where we need to process data from a JMS queue in the order of sending, thus we need sequential processing by 1 MDB instance. Our application runs (still on an old) WildFly 9 and according to documentation I found, we annotated the MDB with

@MessageDriven(activationConfig = { @ActivationConfigProperty(propertyName = "maxSession", propertyValue = "1") })

But it seems that this is not portable, since both Apache ActiveMQ in test environment and IBM MQ in production environment state

WFLYEJB0006: ActivationConfigProperty maxSession will be ignored since it is not allowed by resource adapter

So, what would be a portable way to ensure limitation to 1 MDB instance on the queue, so that the same solution works with different MQ vendors?

Alexander Rühl
  • 6,769
  • 9
  • 53
  • 96
  • did you figure out a way in the end? – Kavithakaran Kanapathippillai Jul 01 '20 at 11:52
  • 1
    @KavithakaranKanapathippillai: we are still experimenting - I would like to have it at the MDB level, in case of need even multiple properties where only one is applicable, but maybe we have to move it to the deployment descriptor and care for it at build level depending on the destination system – Alexander Rühl Jul 01 '20 at 13:44

2 Answers2

1

Unfortunately there is no portable way to limit the number of MDBs on a JMS queue to 1.

In most instances there are multiple "parties" involved and the implementations can vary significantly which is probably why this hasn't been standardized.

For example, in WildFly you have the MDB instance pool which is managed by WildFly itself and configured in the server's XML configuration file. Then in the ActiveMQ JCA resource adapter there is a session pool configured via an MDB's activation configuration properties. These pools can interact with each other in subtle ways and both may need to be tuned depending on the use-case.

However, the implementation of the JCA RA may not include a pool of any kind. The connectivity can be implemented however the RA's provider deems acceptable, and there's nothing in any of the EE specifications that say it must behave a particular way in regards to concurrency therefore there's no standard way to control concurrent message inflow.

Justin Bertram
  • 29,372
  • 4
  • 21
  • 43
1

In my Wildfly 20.0.1, that solution works but with the keyword "maxSessions".

I found this: https://access.redhat.com/discussions/2702311 I tried this solution by myself and I noticed that no concurrent message was elaborated.

Try to apply this configuration :

@MessageDriven(activationConfig = {
        @ActivationConfigProperty(propertyName = "maxSessions", propertyValue = "1")

...

UPDATE

Other references https://developer.jboss.org/thread/273204

DRV
  • 676
  • 1
  • 8
  • 22