On 26/08/2015 05:20, Ryan Cuprak wrote:
> Hello, I have a couple of suggested ideas for JMS 2.1 from challenges that I ran into:
>
Suggestions are welcome.
For information, I'm collating a list of all proposals on this page
https://java.net/projects/jms-spec/pages/JMS21Planning
which is a classified list of all the open issues in the issue tracker.
The priorities for JMS 2.1 are those listed in the JSR proposal
https://jcp.org/en/jsr/detail?id=368
but it would be good to have a more general discussion about what to look at next.
> 1. Singleton MDB Recently I was working on a project where I needed a “singleton" MDB reading off of a queue. It is a
> long story why this was necessary. In GF I configured the bean so that the pool size was 1. However, the container
> would create and destroy the bean at random (perhaps a bug). The postConstruct method would take upwards of 30
> seconds to initialize which resulted in a performance problem. I felt that configuring an MDB pool to have one
> instance was a bit of a hack. It would be nice to have a "singleton MDB" construct.
Most application servers allow you to configure the size of the MDB bean pool though the EJB spec doesn't define a
standard way to do this. So perhaps that's the first thing that would be needed, with a "singleton" option as a shortcut
to this.
Since this applies to all MDBs, not just those using JMS, this is really a matter for the EJB specification.
Requests to change the EJB specification may be made to the EJB maintenance lead, using the EJB user alias.
https://java.net/projects/ejb-spec/lists
However since much of the demand for MDBs comes from JMS users I have logged this in the JMS issue tracker
https://java.net/jira/browse/JMS_SPEC-143
Feel free to add your comments to that.
>
> 2. CDI events and MDBs It isn’t clear to me in the specs whether MDBs can receive CDI events.
>
MDBs are managed by the EJB container, and their lifecycle is defined in the EJB specification. So they can't listen for
CDI events since that would require their lifecycle to be managed by CDI.
As you know I've made some proposals to allow ordinary CDI managed beans to listen for JMS messages. These will be
managed by CDI so and *will* be able to observe CDI events.
> 3. Ability to control MDBs - start/stop message delivery. If something goes awry with an MDB (application logic
> detects a problem), some mechanism to ‘stop’ MDBs from processing messages.
Starting and stopping MDBs is really an issue for the EJB spec. Were you thinking of this as something the application
code might do, or as something the administrator would do using some kind of admin console?
The EJB spec already defines what should happen when a MDB throws an exception. Normally this causes the transaction to
be rolled back and the bean instance destroyed (see the spec for details).
However there is definitely an issue for how JMS should handle a message delivery which has repeatedly been rolled back.
This is essentially the "poison message" problem.
This is certainly on the plan for JMS 2.1. JSR 368 proposes
"Providing features to allow applications to control the redelivery behaviour when a MDB or MessageListener throws an
exception. These may include redelivery delay, redelivery limits and dead message queues. In addition there may be a
need for a standard way for a non-transactional MDB to be able to force a redelivery"
Requirements are being tracked using
https://java.net/jira/browse/JMS_SPEC-117
Again, feel free to record your comments
>
> 4. Timeouts on message delivery - if an MDB processing a message exceeds a certain timeout period, fire a listener so
> that application logic can handle it.
>
Can you say a bit more about that, perhaps with an example?
Nigel