[Question] Zuul2 - Filter thread safety ?

[pcabot]

Context: I am trying to write an async filter that fetches data from a service and store the result in the SessionContext to be consumed by another filter down the line. Code Here is my filter code so far:

class AuthenticationFilter extends HttpInboundFilter {
    private final CoreService coreService

    @Inject
    AuthenticationFilter(CoreService coreService) {
        this.coreService = coreService
    }

    @Override
    int filterOrder() {
        return 500
    }

    @Override
    boolean shouldFilter(HttpRequestMessage msg) {
        return true
    }

    @Override
    Observable<HttpRequestMessage> applyAsync(HttpRequestMessage httpRequestMessage) {
        final String xToken = httpRequestMessage.getHeaders().get(TOKEN_KEY).get(0)

        return Observable.fromCallable(new Callable<HttpRequestMessage>() {
            @Override
            HttpRequestMessage call() throws Exception {
                Optional<BasicUserProfile> profile = coreService.getUserProfile(xToken)

                if (profile.isPresent()) {
                    // FIXME: is this call thread safe ? 
                    httpRequestMessage.getContext().set(USER_PROFILE_KEY, profile.get())
                }

                return httpRequestMessage
            }
        }).subscribeOn(Schedulers.io());  // schedule on a separate threads to avoid blocking. 
    }
}

I actually have two questions:

1. The only way I found for the filter not to block (because the service call could take a few millis) was to schedule it on a background io scheduler. Is that correct ?
2. Because of that, the session context is being updated from a background thread. But according to the javadoc of the SessionContext class, it is not thread safe :

NOTE: Not threadsafe, and not intended to be used concurrently.

Based on my understanding, once the filter enters the applyAsync() method, no other zuul thread is interacting with the message object until the observable completes, which means that it would be ok to set the value in the SessionContext from the background thread. Is that correct ?

Bottom line, what is the recommended way to store a value in the SessionContext from an async filter ?

[pcabot]

Anyone has any suggestions ? Based on my understanding, it seems ok to change the SessionContext from a background thread, but it would be nice to have a confirmation based on the actual zuul2 design. Thanks!

[artgon]

This is a great question.

The assumption when building this code was that each request will run on a single thread and will have its own SessionContext. Most of the time it's true, except in this async case. You can find yourself in a situation where the request hops onto another thread pool, and then gets brought back to the Netty thread by the FilterRunner.

The reason this is ok in practice is because all the async operation for each request (which has its own SessionContext) are chained and will wait for each to finish before continuing to the next one. So even if you hop onto another thread pool it should be ok to use SessionContext to set values because no other filter in your request will be executing (i.e. changing the state of the map) simultaneously. It seems a bit quirky though, and non-obvious why it works. We'll take a look at improving it.

To answer your first question, yes what you did is correct. You would want to schedule the blocking task on a separate thread pool.

[dawn2zhang]

Now I have the same problem. Once there is an async filter, the context will be confusing when the concurrency is high.

[dawn2zhang]

Now I have the same problem. Once there is an async filter, the context will be confusing when the concurrency is high.

When async, it does not block. So there are multi threads hold the different SessionContext. It take the wrong SessionContext. I think it should store the relations of the SessionContext for each dealing.

[github-actions[bot]]

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 7 days.