You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The WAITING_FOR_DELIMITER state is not being handled in Pipe::processPipeTerm() when the function is being called a second time in response to an anomalously termination of the remote host, for example, if it terminates with a segfault or similar.
(N.B. simple ROUTER-DEALER connection with a multi-frame wire protocol).
I extended the function to print some extra information in the assertion and when the function is being called:
DEBUG - Pipe::processPipeTerm() - called with state = WAITING_FOR_DELIMITER inActive = false outActive = true
Exception in thread "iothread-2" java.lang.AssertionError: processPipeTerm received erroneous unexpected status WAITING_FOR_DELIMITER
at zmq.pipe.Pipe.processPipeTerm(Pipe.java:373)
at zmq.ZObject.processCommand(ZObject.java:87)
at zmq.Command.process(Command.java:77)
at zmq.io.IOThread.inEvent(IOThread.java:80)
at zmq.poll.Poller.run(Poller.java:273)
at java.base/java.lang.Thread.run(Thread.java:829)
After that, the pipe seems to stall/close silently and looping in other parts w/o the user being informed (other than the assertion in the user-inaccessible 'ioThread').
I presume that the original design did not include anomalously termination where part of the expected information will never be sent by the remote. Would it harm to add another case that explicitly terminates the pipe and relays that information to the user? Would there be other unexpected side effects?
Any help/insight would be much appreciated!
The text was updated successfully, but these errors were encountered:
The WAITING_FOR_DELIMITER state is not being handled in Pipe::processPipeTerm() when the function is being called a second time in response to an anomalously termination of the remote host, for example, if it terminates with a segfault or similar.
(N.B. simple ROUTER-DEALER connection with a multi-frame wire protocol).
I extended the function to print some extra information in the assertion and when the function is being called:
After that, the pipe seems to stall/close silently and looping in other parts w/o the user being informed (other than the assertion in the user-inaccessible 'ioThread').
I presume that the original design did not include anomalously termination where part of the expected information will never be sent by the remote. Would it harm to add another case that explicitly terminates the pipe and relays that information to the user? Would there be other unexpected side effects?
Any help/insight would be much appreciated!
The text was updated successfully, but these errors were encountered: