Protocol abort at high rate about ccsds

[dariol83]

The main reason was related to the size of the buffering within the API (1000 operations) causing a write session to easily go in timeout. The size of the buffers has been reduced and a backpressure test implemented.

[slux83]

Hi,

I just saw the same issue here while debugging. I blocked the tm packet processor with a break-point and somehow disrupted the processing at SLE level. This happens when too much back pressure is propagated to the SLE provider.

...
Service instance sagr=abc.spack=xyz.rsl-fg=1.raf=onlc91 status updated: ACTIVE
Service instance sagr=abc.spack=xyz.rsl-fg=1.raf=onlc91 status updated: UNBOUND
sagr=abc.spack=xyz.rsl-fg=1.raf=onlc91: Unexpected disconnection detected: UNKNOWN_TYPE_ID
sagr=abc.spack=xyz.rsl-fg=1.raf=onlc91: Discarding unhandled RAF operation: eu.dariolucia.ccsds.sle.generated.ccsds.sle.transfer.service.raf.outgoing.pdus.RafTransferBuffer
Service instance sagr=abc.spack=xyz.rsl-fg=1.raf=onlc91 status updated: UNBOUND
sagr=abc.spack=xyz.rsl-fg=1.raf=onlc91: Discarding unhandled RAF operation: eu.dariolucia.ccsds.sle.generated.ccsds.sle.transfer.service.raf.outgoing.pdus.RafTransferBuffer
Service instance sagr=abc.spack=xyz.rsl-fg=1.raf=onlc91 status updated: UNBOUND
sagr=abc.spack=xyz.rsl-fg=1.raf=onlc91: Discarding unhandled RAF operation: eu.dariolucia.ccsds.sle.generated.ccsds.sle.transfer.service.raf.outgoing.pdus.RafTransferBuffer
Service instance sagr=abc.spack=xyz.rsl-fg=1.raf=onlc91 status updated: UNBOUND
...

[slux83]

I'd like to reopen this issue because the previous fix did not completely resolve the problem. I managed to reproduce the issue by applying a lot of back pressure to the SLE provider and I think the main problem was that the class eu.dariolucia.ccsds.sle.utl/src/main/java/eu/dariolucia/ccsds/sle/utl/network/tml/TmlChannel.java does not completely protect the output stream of the socket from concurrent write access (especially the sendPdu() method).

The attached patch seems to solve the problem (applied on the branch 0.3.0).
tml_concurrency_fix.patch.txt

[dariol83]

Thank you for the patch, indeed there is a concurrency issue in writing to the socket output stream between the calling thread that sends PDUs, and the HBT thread. I implemented the suggested fix, but I did not re-use the currently defined lock: if a write becomes blocking, a lock on the lock object would prevent a shutdown of the SI and the execution of a termination. I introduced a separate lock just to protect the write() operation.