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.
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"); initializeTemporaryConversation();
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 (?) ...