[
https://issues.apache.org/jira/browse/OLINGO-1413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16985390#comment-16985390
]
Erming commented on OLINGO-1413:
--------------------------------
Comments by Michael (for tracking purpose)
I had only a quick look in the hope to detect the problem and provide
> a fix which can be part of next release.
> However I'm not sure how this can happen when Olingo is used in a prober
>way.
> Because from staring with the OData.newInstance() (see TecSvc as
> sample [1]) all further objects are created once for the request and
> are not re-used (afaik).
> As result the mentioned UriInfo as well as the ODataHandler (Impl) is
> unique for a request.
>
> Nevertheless it would be really nice if you can create a related JIRA
> issue so that we can use this for further tracking any investigation
> around this.
> Olingo V4 multi-thread defect in $filter/UriInfo
> --------------------------------------------------
>
> Key: OLINGO-1413
> URL: https://issues.apache.org/jira/browse/OLINGO-1413
> Project: Olingo
> Issue Type: Bug
> Reporter: Erming
> Priority: Major
>
> We discovered a multi-thread defect surrounding the $filter operation. We are
> currently using 4.2 library, but the same issue exists in the latest 4.6
> version. Here are the details
>
> How to Reproduce
> Assume there are two threads hit the system at the same time with the
> same the API endpoint, but different user IDs in the $filter as below, we
> also have different non-Olingo parameter to earmark the thread ID so that we
> can verfiy
>
> abc.com/odatav4/user/Students?$filter=userID eq John&threadID=1
> abc.com/odatav4/user/Students?$filter=userID eq Mary&threadID=2
>
> When you parse out the value from filterOption via UriInfo, you will find
> out the user ID is mixed up in different threads - thread #1 ends up with
> Mary and vice versa
>
> Where is the Defect
> We debugged into the source code and find out the likely culprit is that
> in class ODataHandlerImpl, uriInfo is defined as a class variable, which is
> not thread-safe. In method processInternal, there is no thread-safe
> protection in the following code
>
>
> final int measurementUriParser =
> debugger.startRuntimeMeasurement("Parser", "parseUri");
> UriInfo uriInfoLocal = null;
> try {
> uriInfo = new Parser(serviceMetadata.getEdm(), odata)
> .parseUri(request.getRawODataPath(), request.getRawQueryPath(),
> null);
> } catch (final ODataLibraryException e) {
> debugger.stopRuntimeMeasurement(measurementUriParser);
> debugger.stopRuntimeMeasurement(measurementHandle);
> throw e;
> }
> ...
>
> try {
> new ODataDispatcher(uriInfoLocal, this).dispatch(request, response);
> } finally {
> debugger.stopRuntimeMeasurement(measurementDispatcher);
> debugger.stopRuntimeMeasurement(measurementHandle);
> }
>
>
> We proved it is the problem by using a local variable. Please take a look
> and raise a JIRA and let me the JIRA number so that we can track it.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
