Pascal (qrun), I have run many tests on windows. The tests always run clean with jconsole and JHS. There have been a few hiccups with Jqt. A few hangs as you describe and one crash where avast put jqt.exe in its virus chest.
Jqt is probably fine vs qrun but that is the only place I have seen problems with the latest code changes. A possible suspicion is wd'msgs'. I can't imagine why running a new Jqt session with qrun would have the effect you describe, Remember that the linger bug was fixed and so things run more reliably than in your tests with the first release. Please do the following: 1. let us know exactly what test you run (I use: qrun each 5#<99 99 2) 2. ensure you have the latest base, net, and qtide 3. run your tests in jconsole or JHS until you have a failure or are satisfied 4. run your tests in Jqt 5. let us know your findings On Wed, Oct 4, 2017 at 8:58 AM, 'Pascal Jasmin' via Programming < [email protected]> wrote: > was running with 1e2. > > The reason the different sessions were unblocking each other is that they > were using the same ports. (as best as I can guess). > > qrun hard codes the start addresses. > > > > ________________________________ > From: bill lam <[email protected]> > To: Programming forum <[email protected]> > Sent: Tuesday, October 3, 2017 10:55 PM > Subject: Re: [Jprogramming] jcs/zmq addons updated > > > > Let's take out the memory constraint factor first, say qrun with sentence > 1e3. I am not sure running in different jqt instances is a good idea since > the range of 100 ports used by jcs is hardcoded and are the same for each > jqt. > > On Oct 4, 2017 10:41 AM, "'Pascal Jasmin' via Programming" < > [email protected]> wrote: > > in a 4th jqt session, yes it hung on first run, though pretty far in. > > I started getting memory errors (without hanging), at 80 80, and 22 22. I > have 4 hung jqt sessions now, but any new one lets the others progress. > Task manager reports very low memory use. > > 99 11 finishes just fine. It seems that in order to unblock another > session, the tasks attempted have to number the same as in the blocked > session, and it has to make it up to (near) the blocked task number. > > ________________________________ > From: bill lam <[email protected]> > To: Programming forum <[email protected]> > Sent: Tuesday, October 3, 2017 10:06 PM > Subject: Re: [Jprogramming] jcs/zmq addons updated > > > > Did qrun 99 99 hang in the first run? > > > On Oct 4, 2017 9:16 AM, "'Pascal Jasmin' via Programming" < > [email protected]> wrote: > > > qrun still hangs for me. Never on the first run though. In 5 of 6 > tries, > > it hangs on the 3rd run. On other it hanged on 2nd run. 3rd parameter > > always 6. > > > > I don't think I ever breeched memory/swap issues in these or previous > > tests. > > > > I found a way to unhang it though. > > > > start 2nd jqt session, and run qrun in it. It may hang, but other > session > > will unfreeze. If it did hang, then repeat in other session until both > > unfrozen. Though, doing this enough can result in both sessions frozen > > (especially if using uneven task balances)... A 3rd jqt session to the > > rescue of both frozen ones. > > > > > > > > the show command and immediate jqt console output is a nice change. > > > > > > > > ________________________________ > > From: Eric Iverson <[email protected]> > > To: Programming forum <[email protected]> > > Sent: Tuesday, October 3, 2017 5:41 PM > > Subject: [Jprogramming] jcs/zmq addons updated > > > > > > > > A few cosmetic changes and perhaps fixes for qrun and related task > > problems. > > > > > > Note: qrun now defined in jcs/qrun.ijs > > > > > > The main problem was that a task ending could have a delayed close of the > > > > associated socket port and this could, depending on timing, prevent the > > > > proper start of the next task trying to use the same port. > > > > > > The jcs sockets now set LINGER 0. This should avoid that class of > problem. > > > > Initial stress tests all run clean on Linux and Windows. > > > > > > The other problem was that a server errror in qrun caused a hang. This > > > > wouldn't happen normally if the jobs were well defined and ran to > > > > completion. A way to trigger the qrun server error in Windows was to run > a > > > > large number of tasks with large (memory consumption) jobs. This could > > > > exhaust windows swap memory and get an out-of-memory error. > > > > > > qrun now catches the server error, reports the lse error, and continues. > > > > ---------------------------------------------------------------------- > > > > For information about J forums see http://www.jsoftware.com/forums.htm > > > > ---------------------------------------------------------------------- > > For information about J forums see http://www.jsoftware.com/forums.htm > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm > ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
