Multi threaded invocation

[s thomas]

Hi, I am using the research license of sparksee v5.1, Java API, for unlimited no of sessions, large size and HA disabled,

In my implementation,  I have a singleton object which initialises the DB and has methods to return the reference to the DB. I have several threads each of which, get the DB reference from the singleton, start new session using the said reference, invoke the SinglePairShortestPathDjikstra, close the session. 

My application runs well for 2-3 iterations, however it soon goes into a thread conflict.  I am unable to understand very clearly what is the issue, but it appears as if there is some synchronisation issues on the session. An extract from the hs_err_pid.log is attached inline. 

My issues:

1. I have read that sessions are not thread safe. If so and if that is the issue behind my error, then could someone please post a code describing thread-safe implementation of session.

2. Why is the error being highlighted at SinglePairShortestpathDijkstra invocation, where the session management is internally being handled and not by the user program?

Thanks

 --S Thomas

Extract from hs_err_pid.log

=======================

#

# A fatal error has been detected by the Java Runtime Environment:

#

#  SIGSEGV (0xb) at pc=0x0000000000000989, pid=3785, tid=140668134528768

#

# JRE version: 7.0_04-b20

# Java VM: Java HotSpot(TM) 64-Bit Server VM (23.0-b21 mixed mode linux-amd64 compressed oops)

# Problematic frame:

# C  0x0000000000000989

[error occurred during error reporting (printing problematic frame), id 0xb]

# Core dump written. Default location: /workspace/Benchmarking/core or core.3785

#

# If you would like to submit a bug report, please visit:

#   http://bugreport.sun.com/bugreport/crash.jsp

# The crash happened outside the Java Virtual Machine in native code.

# See problematic frame for where to report the bug.

#

---------------  T H R E A D  ---------------

Current thread (0x00007fefdc433000):  JavaThread "pool-1-thread-4" [_thread_in_native, id=3811, stack(0x00007fefda209000,0x00007fefda30a000)]

siginfo:si_signo=SIGSEGV: si_errno=0, si_code=1 (SEGV_MAPERR), si_addr=0x0000000000000989

Instructions: (pc=0x0000000000000989)

0x0000000000000969:   

[error occurred during error reporting (printing registers, top of stack, instructions near pc), id 0xb]

Register to memory mapping:

RAX=0x00007fefdc3c3370 is an unknown value

RBX=0x00007fefdc3c5210 is an unknown value

RCX=0x00007fefd4029550 is an unknown value

RDX=0x0000000000000400 is an unknown value

RSP=0x00007fefda308128 is pointing into the stack for thread: 0x00007fefdc433000

RBP=0x0000000000000400 is an unknown value

RSI=0x00007fefd400e340 is an unknown value

RDI=0x00007fefdc3c5210 is an unknown value

R8 =0x00007fefd4041790 is an unknown value

R9 =0x0000000000000403 is an unknown value

R10=0x00007fefeb326f64 is an Interpreter codelet

method entry point (kind = native)  [0x00007fefeb326d00, 0x00007fefeb327540]  2112 bytes

R11=0x00007fefefdf6460: <offset 0x7ca460> in /Software/jdk1.7.0_04/jre/lib/amd64/server/libjvm.so at 0x00007fefef62c000

R12=0x00007fefd400e340 is an unknown value

R13=0x00007fefdbfff980: _ZN13sparksee_core13_gTraceActiveE+0 in /tmp/.sparkseejava4376140857459516938.LibsDir/libsparksee.so at 0x00007fefdbab1000

R14=0x00007fefdc4331d8 is an unknown value

R15=0x00007fefdc433000 is a thread

Stack: [0x00007fefda209000,0x00007fefda30a000],  sp=0x00007fefda308128,  free space=1020k

Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)

C  0x0000000000000989

[error occurred during error reporting (printing native stack), id 0xb]

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)

j  com.sparsity.sparkseejavawrapJNI.new_sparksee_algorithms_SinglePairShortestPathDijkstra(JLcom/sparsity/sparksee/gdb/Session;JJ)J+0

j  com.sparsity.sparksee.algorithms.SinglePairShortestPathDijkstra.<init>(Lcom/sparsity/sparksee/gdb/Session;JJ)V+9

j  scheduling.aware.xcbs.agents.SEAgent.getPath(Lcom/sparsity/sparksee/gdb/Session;JJLcom/sparsity/sparksee/gdb/Objects;Lcom/sparsity/sparksee/gdb/EdgesDirection;)Ljava/lang/String;+96

j  scheduling.aware.xcbs.agents.SEAgent.generateAlternatePath(Ljava/util/LinkedHashMap;Ljava/lang/String;Lscheduling/aware/xcbs/model/ReplanNode;)V+369

j  scheduling.aware.xcbs.agents.SEAgent.createReplanTree(Ljava/util/LinkedHashMap;)V+138

j  scheduling.aware.xcbs.agents.SEAgent.generateRevisedPlan()V+42

j  scheduling.aware.xcbs.agents.SEAgent.call()Ljava/util/LinkedHashMap;+39

j  scheduling.aware.xcbs.agents.SEAgent.call()Ljava/lang/Object;+1

j  java.util.concurrent.FutureTask$Sync.innerRun()V+29

j  java.util.concurrent.FutureTask.run()V+4

j  java.util.concurrent.ThreadPoolExecutor.runWorker(Ljava/util/concurrent/ThreadPoolExecutor$Worker;)V+46

j  java.util.concurrent.ThreadPoolExecutor$Worker.run()V+5

j  java.lang.Thread.run()V+11

v  ~StubRoutines::call_stub

VM state:not at safepoint (normal execution)

VM Mutex/Monitor currently owned by a thread:  ([mutex/lock_event])

[0x00000000021aee60] CodeCache_lock - owner thread: 0x00007fefdc001000

[0x00000000021b0560] Compile_lock - owner thread: 0x00007fefdc001000

[0x00000000021b0660] MethodCompileQueue_lock - owner thread: 0x00007fefdc001000

[sparkseegdb]

Hi!

Each concurrent thread should have it's own session, so it looks precisely the approach you are going with. The problem here is most likely a known bug that was patched on version 5.1.1 back on 2015. 

We would recommend to start by upgrading to Sparksee 5.2.3, please check again and let us know. You can download the last version on the website here.

Best Regards,

Sparksee Team

[s thomas]

Hi,

I upgraded to Sparksee 5.2.3 and attempted the same, but the error remained.

  
I have now done away with the multithreading in my code, and am invoking all the objects in an iterative mode , instead of concurrently as threads. The objects are internally calling Sparksee.getShortestPathDjikstra.

When I changed my code to a sequential one, I assumed the error will go since there will only be one main thread running and hence no issue of concurrent session management. However in my sequential code is also showing the following error:

**** CRITICAL ERROR (SIGNAL NUM 6)
------- Begin of call stack ------
/tmp/.sparkseejava4247685098021558637.LibsDir/libsparksee.so(_ZN13sparksee_core21CallStackTraceHandler13SignalHandlerEi+0x28) [0x7feb636afa98]
/lib/x86_64-linux-gnu/libpthread.so.0(+0xf030) [0x7feb83d50030]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0x35) [0x7feb835cf475]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x180) [0x7feb835d26f0]
/tmp/.sparkseejava4247685098021558637.LibsDir/libsparksee.so(_ZN13sparksee_core9GraphPoolD0Ev+0x6dd) [0x7feb6372f79d]
/tmp/.sparkseejava4247685098021558637.LibsDir/libsparksee.so(_ZN13sparksee_core8SPARKSEED0Ev+0x63) [0x7feb63738313]
/tmp/.sparkseejava4247685098021558637.LibsDir/libsparksee.so(_ZN8sparksee3gdb7HandlerIN13sparksee_core8SPARKSEEEE11FreeHandlerEv+0x13) [0x7feb63653f33]
/tmp/.sparkseejava4247685098021558637.LibsDir/libsparksee.so(_ZN8sparksee3gdb8SparkseeD0Ev+0x1c) [0x7feb6365517c]
/tmp/.sparkseejava4247685098021558637.LibsDir/libsparkseejavawrap.so(Java_com_sparsity_sparkseejavawrapJNI_delete_1sparksee_1gdb_1Sparksee+0x27) [0x7feb630e418b]
[0x7feb722b8814]
-------- End of call stack -------

I am at my wits end. Please help.

thanks

S. Thomas

[sparkseegdb]

Hello,

Please provide more details about the exact part of the code where the error is raised so we can be helpful. Take into account to set the log level first at DEBUG so there is more information on the log file. If you don't want to post your code & log here, send it directly to dam...@sparsity-technologies.com

Best,

Sparksee team

[Liam Crozier]

When you used SinglePairShortestpathDijkstra, did you close it after?