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
