perfSONAR User Q&A and Other Discussion

[Mark Feit <>]

I wrote:

    I'm not inclined to think it's something pScheduler code because almost 
nothing involved has changed.  Iperf3 hasn't seen a release since June, its 
pScheduler plugin hasn't been modified since September (pre-4.2.2), the 
runner service that oversees all of this hasn't changed in a year and the 
code in our internal library is even older than that.  That said, something 
has to be different to cause this behavior.


The major change to pScheduler in 4.2.3 was a change to the way one of the 
tables in its internal database is locked during parts of the scheduling 
process.  The locking is necessary because there has to be an atomic 
transaction where the contents of the table are examined and acted upon.  
Without it, other threads doing scheduling could make the same decision and 
cause conflicts by taking the same action.  The change we made was to 
alleviate a problem for a high-volume user.

Under the heading of no good deed going unpunished, the change appears to 
have created problems for other users.  I'd hoped this fix would be a good 
band-aid until time could be devoted to a more-thorough solution, but that 
doesn't appear to be the case, which makes that time now.  Work is underway 
to verify that this is actually the problem and a new release will be out as 
soon as something has been developed and tested.

Thanks for your patience with this.

--Mark