closing JMS resources

[lstine]

Inject the Seam JMS resources like this example:

@In(create=true)
private transient QueueSender queueSender;
@In(create=true)
private transient QueueSession queueSession;

Do you need to manually call close() on the QueueSession and QueueSender objects or will Seam handle this for us?

[lstine]

This forum is kind of weak. Here is what I did sort of blindly but it seems to be working fine. In the function annotated @Remove I closed the JMS resources.

@Remove
    public void remove()
    {
         try {
              queueSender.close();
          } catch (JMSException e) {}
          try {
               queueSession.close();
          } catch (JMSException e) {}
}

[gena]

Hm.. Interesting, should we generally close the JMS resources within the Seam-featured-app on JBossAS or not?

[asookazian]

This is a SFSB from the chatroom Seam example:

@Stateful
@Name("chatroomAction")
@Scope(CONVERSATION)
public class ChatRoomAction implements ChatRoomActionWebRemote
{

   @In(create=true)
   private transient TopicPublisher topicPublisher;   
   @In(create=true)
   private transient TopicSession topicSession;

   @In(create=true)
   Set<String> chatroomUsers;
   
   private String username;
   
   @Begin
   public boolean connect(String username)
   {
      this.username = username;
      boolean added = chatroomUsers.add(username);
      if (added)
      {
         publish( new ChatroomEvent("connect", username) );
      }
      return added;
   }

   public void sendMessage(String message)
   {
      publish( new ChatroomEvent("message", username, message) );
   }

   @End
   public void disconnect()
   {
      chatroomUsers.remove(username);
      publish( new ChatroomEvent("disconnect", username) );
   }

   public Set<String> listUsers()
   {
      return chatroomUsers;
   }

   private void publish(ChatroomEvent message)
   {
      try
      {
         topicPublisher.publish( topicSession.createObjectMessage(message) );
      } 
      catch (Exception ex)
      {
         throw new RuntimeException(ex);
      } 
   }
   
   @Destroy
   @Remove
   public void destroy() {}

}

I don't see any close().

from the API doc:

Since a provider may allocate some resources on behalf of a session outside the JVM, clients should close the resources when they are not needed. Relying on garbage collection to eventually reclaim these resources may not be timely enough.

There is no need to close the producers and consumers of a closed session.

http://72.5.124.55/javaee/5/docs/api/javax/jms/Session.html#close%28%29

[asookazian]

lance stine wrote on Aug 11, 2009 22:04:


This forum is kind of weak.

Yeah, the Seam core devs are on permanent vacation, hitting up the Spring or RoR boards, or are plain not interested in their own framework.  Pretty sad.  They're somewhat active in the Web Beans forum but there's minimal activity in there anyways.

What ever happened to weekly rotations?

[kapitanpetko]

lance stine wrote on Aug 11, 2009 22:04:


This forum is kind of weak.

Please excuse us for not doing your homework promptly. This is a community forum, you may or you may not get answers.
You might get those late. You might get wrong answers. If you follow the advice on this forum your application may
crash, your servers burn, you might get fired and end up on the streets. The usual disclaimer applies: you get what you
pay for. How much was that again?

Having the above in mind, read on.

Here is what I did sort of blindly but it seems to be working fine. In the function annotated @Remove I closed the JMS resources.

Those are managed components, they have their own @Destroy methods, which happen to call close.
Cf. seam.jms.ManagedQueueSender, seam.jms.QueueSession and friends.

HTH

[lstine]

Hey, I finally got some responses. I must have said the magic words.

No offense to anyone. I am really pleased with Seam. I've posted here several times before. Every time, I've answered my own question. In that situation there isn't a need to come here at all and I don't contribute to other people's topics. It is disappointing. But, I must say thank you to everyone who replied.