4 Replies Latest reply on Dec 15, 2004 8:31 PM by andyd

    MDB onMessage and catching exceptions

    andyd

      I'm having problems trying to call a local interface from an onMessage handler throughs an Exception.

      I've wrapped the call to a method on a Local interface with try/catch to catch Exception (have also tried IOException). The onMessage handler seems to complete ok, but the message remains in the queue and JBoss keeps trying to deliver it. I've set some parameters using @ConnectionConfig, as in the ejb3 examples. Are there more annotations that can be used to define the queueing behaviour?

      Priort to including exceptions in the interface all was working fine.

      Any help most appreciated.

      Thanks,
      Andy.




        • 1. Re: synchronized methods in instrumented class
          bill.burke

          Of course, J2EE TCK may not explicitly reference Aspects or AOP instrumentation. I even wonder if J2EE will ever talk about AOP as it may sound a little too invasive/disruptive to let bean developers to play with.

          But does JBoss plan to implement the strict constraints of J2EE constructs especially the ones that related to thread manipulation mandated by the TCK and so prevent the deployment of J2EE application that may blatantly violate those constraints ? Something that both weblogic and websphere try to enfore today.

          Or is it the case that the TCK does not require application servers to be so "precise" in behavior allowing JBoss to be more tolerant as it is right now ? Sorry, I have'nt really had time or patience to read through and digest all of the Specs.

          This tolerant behavior is a double-edged sword, it definitely helps developers to maybe successfully accomplish certain features via a path that J2EE may not completely agree with. But it hampers productivity of developers who most commonly use JBoss for development but may have unknowingly violated some J2EE constraints only to realize much later in the game during the porting stage. I guess the answer could lie in those J2EE verfier tools and how diligently it is used and monitored. Also most of the time the disparate class-loader architectures end up being the culprits.

          Bill - I appreciate your understanding of my problem and will await your resolution however soon you or your team would be able to provide a resolution.

          thanks again
          Rajiv

          • 2. Re: MDB onMessage and catching exceptions
            bill.burke

            I don't understand the problem. You call a local itnerface of a Session bean from within a try/catch of an MDB? That local interface is throwing an exception? The message is getting redelivered?

            • 3. Re: MDB onMessage and catching exceptions
              andyd

              Hi Bill,
              Yes, the OnMessage handler goes through and terminates, but it's like the message is stuck in the jms queue and the handler continues to receive the message from the container.
              I can only seem to get rid of the message by undeploying the bean, opening hsql and deleting the message from jms_messages, then restarting jboss.

              public void onMessage(Message msg)
              {

              try
              {
              myLocRef.function(p1);
              }
              catch(IOException e)
              {
              log.info(e.getMessage());
              // getting here means we end up with re-deliveries
              }

              // send reply back to queue
              }
              Andy

              • 4. Re: MDB onMessage and catching exceptions
                andyd

                Think I may have found the problem.

                The Exception may have been a Throwable which wasn't catched by the try/catch in the onMessage callback. So the container was submitting the message until it was handled correctly, which was never. Some more testing is required to be sure.

                Does anyone know if there are more annotations for MDB's than those listed in the EJB£ MDB example?

                Thanks,
                Andy.