Community
Participate
Working Groups
CDO signal after it sends data to server, starts waiting for confirmation data from BufferInputStream. It waits until data is provided or CDO protocol timeout appears. However, if connection was lost before signal invocation and CDO connector was deactivated, there are no need to wait whole protocol timeout and block thread. For example, we are using quite large protocol timeout (~3min) and thus, thread will be blocked for the 3 min., while more likely this thread is UI thread, application will be unresponsive quite long, regardless that connector with all child elements is already deactivated.
Created attachment 204887 [details] Patch v1 It is patch for issue, however it doesn't contains test. At current time I do not have idea how to write it.
There is org.eclipse.net4j.tests.signal.TestSignalProtocol, you could add a signal to it that slleps 5 seconds in indicating().
Created attachment 205483 [details] Test and patch v2
I refactored your patch a little bit and then ran the test. Is it okay/wanted that the test takes 10.x seconds to execute? Unfortunately I can not create patches anymore with EGit ;-(
It was not intended to have 10 s running test and seems this to be side effect. I found that these 10s is grabbed in "SignalProtocol.doBeforeDeactivate" method. Why 10 seconds is used to wait for signal completion but not 5s? - I can just guess... Perhaps we need to make this configurable (at least for test).
Created attachment 205974 [details] Patch v3 I found a way to create patches with EGit: I create a local branch bugs/360443, committed my changes to it and pushed everything to origin. Then I opened the history view on the entire repository (clone). Here I can see all commits nicely structured. A right-click on my latest commit opens a popup menu where I can create a patch of that commit. Can you please confirm that you can easily and correctly apply this patch? Ideally in the future we will not need patches anymore but work with the branches directly. Once we've all learned how to do that it should be easier ;-)
These 10s comes as a bug fix for "https://bugs.eclipse.org/bugs/show_bug.cgi?id=321193". There are no test case and stack trace, but from description seems fix should ensure that server needs to complete with work received from client and client gives 10s for this (before protocol is deactivated). It is odd that client takes care about server tasks and perhaps this code could be moved to server side, but it is my thought and it goes to different story. Nevertheless 321193 is irrelevant to this issue, except that we get 10s to wait for test to complete. This issue is solving problem, that protocol on client side (no mater what happens on server) must complete it task on read, release resources blocked on thread, when protocol was closed. For this it gives EOS to the signal. While from the first glance these fixes looks contradictory, but indeed they have different target. I have added Caspar into thread.
What are we going to do with this. I really don't like a test case to wait unnecessarily for 10 seconds on each execution ;-(
(In reply to comment #7) > It is odd that client takes care about server > tasks and perhaps this code could be moved to server side, but it is my thought > and it goes to different story. As we (Egidijus and I) discussed on Skype, I have no objection to moving code when that makes sense... but: I took a peak at the patch for 321193, and it looks to me like the code added there is not client- or server-specific. It's part of SignalProtocol, which is used on both sides. This makes sense: the point of the patch was simply to postpone protocol deactivation if there are still signals running, regardless of where that happens. If the signals terminate, the protocol will go ahead with deactivation within a second. So it seems to me the open question is: why doesn't the signal terminate?
Yes, fix 321193 is for both sides - client and server, and it seems to be not very bad thing to wait 10s. for signal termination as it looked for me before. In normal flow signals usually terminates before protocol deactivation takes place. The test case for this issue covers not common and rare situation. I have modified the test and it shouldn't hit 10s wait procedure. Commits in the "bugs/360443" branch: 44fb42e5272dadc94be5fe5cb2db36bedc7e3b11 2e3adbfb36e1ed7e42a139ccd15e44106c57fe59
Moving all open issues to 4.2. Open bugs can be ported to 4.1 maintenance after they've been fixed in master.
Moving all outstanding enhancements to 4.3
Moving all open enhancement requests to 4.4
Moving all open bugzillas to 4.5.
Moving all unaddressed bugzillas to 4.6.
Moving all open bugs to 4.7
Moving all unresolved issues to version 4.8-
Moving all unresolved issues to version 4.9
Moving to 4.13.
