Thanks, I will check it out as soon as I have some time. Kind Regards, Michael
On Sat, Nov 30, 2019 at 5:11 PM Tuo, Erming <erming....@sap.com> wrote: > > https://issues.apache.org/jira/browse/OLINGO-1413 is created to track the > issue > > On 11/27/19, 4:43 PM, "mibo" <m...@apache.org> 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 <erming....@sap.com> 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" <m...@apache.org> 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 <erming....@sap.com> > 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" <erming....@sap.com> 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 > > > erming....@sap.com<mailto:erming....@sap.com> | US > +1-703-678-0615 > > > > > > > > > > > > > > > > > >
