You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@olingo.apache.org by "Tuo, Erming" <er...@sap.com> on 2020/01/10 19:34:58 UTC
Re: [CAUTION] Olingo V4 multi-thread defect in $filter/UriInfo
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.tuo@sap.com | US +1-703-678-0615
On 1/9/20, 4:00 PM, "Yogapalraj, Birla" <bi...@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 <mi...@apache.org>
Sent: Sunday, December 1, 2019 5:33 AM
To: Tuo, Erming <er...@sap.com>
Cc: mibo <mi...@apache.org>; dev@olingo.apache.org; Yogapalraj, Birla <bi...@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 <er...@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" <mi...@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 <er...@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" <mi...@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 <er...@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" <er...@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.tuo@sap.com<ma...@sap.com> | US +1-703-678-0615
> > >
> > >
> > >
> > >
> >
> >
>
>
Re: [CAUTION] Olingo V4 multi-thread defect in $filter/UriInfo
Posted by Dave Fisher <wa...@apache.org>.
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 <er...@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.tuo@sap.com | US +1-703-678-0615
>
>
>
> On 1/9/20, 4:00 PM, "Yogapalraj, Birla" <bi...@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 <mi...@apache.org>
> Sent: Sunday, December 1, 2019 5:33 AM
> To: Tuo, Erming <er...@sap.com>
> Cc: mibo <mi...@apache.org>; dev@olingo.apache.org; Yogapalraj, Birla <bi...@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 <er...@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" <mi...@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 <er...@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" <mi...@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 <er...@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" <er...@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.tuo@sap.com<ma...@sap.com> | US +1-703-678-0615
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>