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
>
>
>
>
