There's a "ms" missing from the message. It should read "Failed to acquire conversation lock in 1,000 ms for Conversation with id: 1".
Since a conversation can only be associated with a single request at a time, Weld waits up to 1 second to acquire a lock. So apparently in your case, there's an existing request holding the lock for a relatively long time, while another parallel request is executed under the same conversation.
Hi Marko, thanks for the reply, what you've described makes sense. Is there away to catch the exception from the Weld when it tries to acquire the conversation lock and fails and have it retry? I'll obviously look at my requests, but if there's a poor network performance which causes a request to take longer thank 1 second, I don't want it to cause my application to fail. Also any suggestions on how to identify and which requests take are taking a long time. It seems to only occur when I'm navigating between 2 pages within a conversation.
Take a look at the spec at http://docs.jboss.org/cdi/spec/1.0/html_single/#conversationcontext
This is what it says:
The container ensures that a long-running conversation may be associated with at most one request at a time, by blocking or rejecting concurrent requests. If the container rejects a request, it must associate the request with a new transient conversation and throw an exception of typejavax.enterprise.context.BusyConversationException from the restore view phase of the JSF lifecycle. The application may handle this exception using the JSF ExceptionHandler.
I saw your other post in AS7 forum, where you give more details about what you are actually doing. You're actually performing two concurrent requests (navigation plus the <p:remoteCommand>). I'm guessing the p:remoteCommand automatically appends the conversation id, so this request is executed in the same conversation as the navigation. There's probably a way of making the remoteCommand not append the conversation id and make the request execute outside of the conversation.