I just noticed that one that one of my splitfile downloads was stuck (no data is downloaded and each try to fetch the download status using the browser causes another thread to be stuck), the cause seems to be a deadlock. The last thing the wab interface said was 'Decoding FEC block, please be patient' so it would seem that that was the last thing the node was doing before the deadlock occurred (one of the supplied stacktraces indicates that blocks are beeing enqueued for background inserting when the deadlock occurred)
Attached is two full stacktraces showing where the different threads in the JVM is stuck, one file contains the stacktraces of all threads and the second file is an extract of the stacktraces of the threads that I think is involved in the deadlock (and some small notes made by me about aquired locks for the different threads). I seem the be unable to find the exact cause of the deadlock. One of the monitors involved is a monitor on an instance of SplitfileRequestManager, the exact other monitor is not known but might possibly be the monitor on the SFRContext associated with the SplitfileRequestManager instance (or are those two actually the same object.. doesn't seem so but the relevant code isn't exactly trivial). /N
deadlock.zip
Description: Zip compressed data
