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 2019/11/26 20:56:34 UTC
Re: [CAUTION] Olingo V4 multi-thread defect in $filter/UriInfo
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
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>
Re: [CAUTION] Olingo V4 multi-thread defect in $filter/UriInfo
Posted by "Tuo, Erming" <er...@sap.com>.
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 mibo <mi...@apache.org>.
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 "Tuo, Erming" <er...@sap.com>.
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 mibo <mi...@apache.org>.
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 "Tuo, Erming" <er...@sap.com>.
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 mibo <mi...@apache.org>.
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
>
>
>
>