[jira] [Created] (OLINGO-1413) Olingo V4 multi-thread defect in $filter/UriInfo

["Erming (Jira)" <ji...@apache.org>]

Erming created OLINGO-1413:
------------------------------

             Summary:  Olingo V4 multi-thread defect in $filter/UriInfo 
                 Key: OLINGO-1413
                 URL: https://issues.apache.org/jira/browse/OLINGO-1413
             Project: Olingo
          Issue Type: Bug
            Reporter: Erming


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.
    



--
This message was sent by Atlassian Jira
(v8.3.4#803005)