Hi Erming, 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. Kind Regards, Michael [1]: https://github.com/apache/olingo-odata4/blob/35e2302576748c36f3b6719dcc311019672a30a6/lib/server-tecsvc/src/main/java/org/apache/olingo/server/tecsvc/TechnicalServlet.java#L63 On Tue, Nov 26, 2019 at 9:56 PM Tuo, Erming <[email protected]> wrote: > > Hi, Ramesh and Olingo team, > > Did you get a change to look into the issue that we reported below? > > Thx > > Erming > > On 11/19/19, 4:03 PM, "Tuo, Erming" <[email protected]> wrote: > > Olingo, > > 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. > > Erming Tuo – Development Architect LMS > Global Cloud Platform| SAP SuccessFactors > [email protected]<mailto:[email protected]> | US +1-703-678-0615 > > > >
