The problem resides inside the standard tomcat valve which processes every incoming request. At the very beginning the valve evaluates whether the request is already considered as asynchronous or not. In the latter case the init event is fired which activates the weld context:

if (asyncAtStart || context.fireRequestInitEvent(request)) {
...
}

The if block also contains the execution of the business code which switches the request to the async mode. The following valve code checks the request mode after its procession is finished. In case it has become asynchronous, no destroy event is dispatched which unfortunately keeps the weld context initialized within the running thread:

if (!(request.isAsync() || (asyncAtStart &&
                    request.getAttribute(
                            RequestDispatcher.ERROR_EXCEPTION) != null))) {
    // Protect against NPEs if context was destroyed during a
    // long running request.
    if (context.getState().isAvailable()) {
        ...
        context.fireRequestDestroyEvent(request);
    }
}

Once the same thread is chosen to serve a request, the "Conversation already active" exception is thrown. Is there any workaround for this? Unfortunately this problem makes it impossible to use the jsf 2.2 on tomcat when using the asynchronous tasks. It's definitely possible to change the weld code to the behaviour that in case the context is already active, it is at first deactivated and subsequentially activated, but it is an awful hack.