https://issues.apache.org/jira/browse/OLINGO-1413 is created to track the issue
On 11/27/19, 4:43 PM, "mibo" <[email protected]> wrote: Hi Erming, You can go to https://issues.apache.org/jira/projects/OLINGO and create an issue. Before you can create an issue you have to sign up if not done already. Kind regards, Michael On Wed, Nov 27, 2019 at 5:04 PM Tuo, Erming <[email protected]> wrote: > > Michael, > > Thanks for getting back to me. Can you please show me how to create a JIRA in your system? > > Thx > > Erming > > On 11/27/19, 2:20 AM, "mibo" <[email protected]> wrote: > > 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 > > > > > > > > > >
