Hi - Apache Projects operate asynchronously. If you can provide a JIRA issue that describes how to reproduce the problem and attach the necessary patches that will help the team resolve the issue!
Best Regards, Dave > On Jan 10, 2020, at 11:34 AM, Tuo, Erming <erming....@sap.com> wrote: > > Michale and Olingo team, > > This is a critical issue, we start to have multiple customers complaining > about the same problem. Olingo library can definitely benefit from fixing > this loop hole. We already have a fix that we can share with it. > > We want to setup a meeting with you and demo the problem, we will also show > you how to fix it in the code. Please suggest your earliest convenience. > > Thx > > Erming Tuo – Development Architect LMS > Global Cloud Platform| SAP SuccessFactors > erming....@sap.com | US +1-703-678-0615 > > > > On 1/9/20, 4:00 PM, "Yogapalraj, Birla" <birla.yogapal...@sap.com> wrote: > > Hi Michael, > > Any update on this issue ? > We do have few customers started reporting this issue . > > Thanks > Birla > > -----Original Message----- > From: mibo <m...@apache.org> > Sent: Sunday, December 1, 2019 5:33 AM > To: Tuo, Erming <erming....@sap.com> > Cc: mibo <m...@apache.org>; dev@olingo.apache.org; Yogapalraj, Birla > <birla.yogapal...@sap.com> > Subject: Re: [CAUTION] Olingo V4 multi-thread defect in $filter/UriInfo > > 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 >>>> >>>> >>>> >>>> >>> >>> >> >> > >
