2 Replies Latest reply on Feb 26, 2007 5:02 AM by Zalder R

    concurrent access to SFSB using SEAM Remoting

    Zalder R Newbie

      We encountered a problem accessing a simple SFSB from a javascript call using seam remoting.

      Concurrent js calls to a single conversational SFSB produces multiple instances of SFSB each being added to a newly created conversation context which is not what one would expect.

      We reproduced it with a minor modification to the chatroom example.
      We simply changed the sendMessage function (in ChatRoomAction.java) like this (adding a 10s delay to simulate a long process) :

      public void sendMessage(String message) {
       publish( new ChatroomEvent("message", username, message) );
       try {
       Thread.sleep(10000) ;
       } catch (InterruptedException e) {

      This breaks the chatroom example : repeated inputs lead to the creation of new "chatroomAction" SFSBs that don't hold the user object (and are located within new conversation contexts).

      This is the ouput in the chatroom :
      testuser connected.
      testuser> a
      null> a
      testuser> a
      null> a

      Thanks for any help.

        • 1. Re: concurrent access to SFSB using SEAM Remoting
          Shane Bryzak Master

          That's because the conversation is created in the first request, and if you delay the response then the remoting client won't know which conversation id was created. One alternative is to start your conversation when you first render the page and manually set the conversation id like this:


          That way the remoting calls will know which conversation context to use.

          • 2. Re: concurrent access to SFSB using SEAM Remoting
            Zalder R Newbie

            Thanks for you answer.

            Looking at the code inside the Conversation Manager we saw that if there is a concurrent call to a locked conversation context : a new temporary one is created :

            log.debug("No stored conversation, or concurrent call to the stored conversation");

            This lead to our problem since the concurrent-request-timeout is set to 1 sec by default. Setting this parameter to 20s did the trick : each request would wait enough time for the previous request to be completed.

            in components.xml :
            <core:manager concurrent-request-timeout="20000" ...

            Maybe you could add a note in section "3.1.10. Concurrency model" mentioning this parameter ...

            In our case, it was really strange to have a new temporary (and empty !) conversation created to handle requests from a long running conversation ... maybe it solves some of your use-cases (?) ...