Too much work for socket, and port can be used by other process. But We have good news, see IRC [12:43] <tibor_> ThreadedStreamConsumer#23504796 run() :: items :: Z,0,BYE! [12:43] <tibor_> we received Z [12:44] <tibor_> now I have to find why ForkStarter is faster to check the Z event [12:45] <tibor_> because ForkStarter does not see this event for some reason, it is stored in volatile variable, so maybe timing issue
On Sun, Feb 19, 2017 at 12:32 PM, stephenconnolly [via Maven] < ml-node+s40175n5899224...@n5.nabble.com> wrote: > What about using a local host bound socket rather than studio? > > In fact a socket could open up other options like forking the tests inside > docker, or running the surefire forks on remote JVMs. > > Plus we gain more control (modulo TCP retry/timeouts) > > On Sun 19 Feb 2017 at 11:16, Tibor Digana <[hidden email] > <http:///user/SendEmail.jtp?type=node&node=5899224&i=0>> > wrote: > > > Currently I placed sleep(1sec) before child process exit(0). If the > reader > > process ThreadedStreamConsumer would read buffer entirely within 1 sec > and > > the build pass then I have to add a confirmation mechanism where the > exit > > event must be confirmed by plugin until short period of time. > > Later we should not use these pipes but standard file system, but we > have > > to take care of SecurityException thrown by JUnit3. > > > > On Sun, Feb 19, 2017 at 11:37 AM, Michael Osipov <[hidden email] > <http:///user/SendEmail.jtp?type=node&node=5899224&i=1>> > > wrote: > > > > > Am 2017-02-18 um 23:19 schrieb Christian Schulte: > > > > > >> Am 02/17/17 um 21:48 schrieb Michael Osipov: > > >> > > >>> Hi folks, > > >>> > > >>> Christian Schulte asked me a couple of days ago wether I am able to > > >>> build Surefire master with Maven master. It was constantly failing > for > > >>> him on his OpenBSD machines. Since I have several real servers with > > >>> FreeBSD 10.3-STABLE at hand I did run all Surefire ITs and I was > able > > to > > >>> reproduce it. Our entire test infrastructure wasn't unfortunately! > > >>> > > >>> @Tibor: correct me if something is wrong or missing! > > >>> > > >>> After several days of heavy testing, thread dumps and log file > analysis > > >>> with Tibor Digana and various Maven combinations (3.3.9, master, > > >>> MNG-6169, MNG-6169 + MCLEAN 3.0.0) we figured out that there are > > several > > >>> serious bugs in Surefire master, Maven Shared Utils 0.9/3.1.0 and > > likely > > >>> Maven Clean Plugin 3.0.0. > > >>> > > >>> Since crucial parts of Surefire rely on native code in the JVM > (forks, > > >>> streams), our code was not robust enough. > > >>> > > >>> As of today we have found: > > >>> > > >>> * Missing flushes in streams caused forked VM to be apparently > > >>> non-responsive > > >>> * TestNG tests mostly failed due to duplicate contradicting > properties > > >>> passed to forked VMs > > >>> * Uninitialized/too early attributes made daemon threads to kill > forked > > >>> VMs > > >>> * Code or dependency change from MCLEAN 2.6.1 to 3.0.0 cause > repeated > > >>> failures of a handful ITs > > >>> @Karl Heinz: were you able to figure out something here? > > >>> > > >>> Issues in JIRA are pending... > > >>> > > >>> Everyone's invited to take a look at the log output as well as the > > >>> target directory of surefire-integration-tests and contribute: > > >>> http://home.apache.org/~michaelo/maven/surefire/. The filenames > should > > >>> be pretty much self-explanatory. > > >>> > > >>> My big question is: how can we improve our test infrastructure? Can > we > > >>> raise with INFRA to get at least one FreeBSD and Solaris node for > > >>> Jenkins? I consider coverage on Windows and Ubuntu way to small, we > do > > >>> not even have a CentOS node. Surefire ITs and Maven ITs are > paramount > > >>> for us, we should treat them as such! > > >>> > > >>> Michael > > >>> > > >> > > >> Does any of your findings solve the following already? This is what > > >> makes the Jenkins build jobs appear unreliable. It's sending out an > > >> email about a failed job and all you see is something like the > following > > >> sporadically. I am having the same issue locally sporadically. > > >> > > >> [ERROR] Failed to execute goal > > >> org.apache.maven.plugins:maven-surefire-plugin:2.12.4:test > > >> (default-test) on project child2: Execution default-test of goal > > >> org.apache.maven.plugins:maven-surefire-plugin:2.12.4:test failed: > The > > >> forked VM terminated without saying properly goodbye. VM crash or > > >> System.exit called ? -> [Help 1] > > >> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to > > >> execute goal org.apache.maven.plugins:maven-surefire-plugin:2.12.4:test > > > >> (default-test) on project child2: Execution default-test of goal > > >> org.apache.maven.plugins:maven-surefire-plugin:2.12.4:test failed: > The > > >> forked VM terminated without saying properly goodbye. VM crash or > > >> System.exit called ? > > >> > > > > > > We were able to solve only a few cases so far: 10%. The rest is still > > > failing. > > > > > > I made some digging: it seems to be a very common problem in NodeJS > with > > > async and forking: > > > https://github.com/nodejs/node/issues/2972 > > > https://github.com/nodejs/node/issues/6456 > > > http://stackoverflow.com/q/11138355/696632 > > > http://stackoverflow.com/q/1716296/696632 > > > https://github.com/nodejs/node-v0.x-archive/issues/8329 > > > https://github.com/nodejs/node-v0.x-archive/issues/1669 > > > https://github.com/nodejs/node-v0.x-archive/issues/3737 > > > > > > > > > Especially this answer is our case: > > > > > >> That's not a bug - process.exit() is an imperative that says "exit > > now!". > > >> > > >> When stdout/stderr is a pipe (as is the case with child processes) > and > > >> said pipe is full, pending data gets lost. Waiting until the pipe > drains > > >> is not an option, that could hang the process indefinitely. > > >> > > > > > > I think if we don't gain more control over stdio, we are lost... > > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [hidden email] > <http:///user/SendEmail.jtp?type=node&node=5899224&i=2> > > > For additional commands, e-mail: [hidden email] > <http:///user/SendEmail.jtp?type=node&node=5899224&i=3> > > > > > > > > > > > > -- > > Cheers > > Tibor > > > -- > Sent from my phone > > > ------------------------------ > If you reply to this email, your message will be added to the discussion > below: > http://maven.40175.n5.nabble.com/Recent-issues-found-in- > Surefire-master-Maven-Clean-Plugin-3-0-0-with-Maven- > master-tp5898937p5899224.html > To start a new topic under Maven Developers, email > ml-node+s40175n142166...@n5.nabble.com > To unsubscribe from Maven Developers, click here > <http://maven.40175.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=142166&code=dGlib3JkaWdhbmFAYXBhY2hlLm9yZ3wxNDIxNjZ8LTI4OTQ5MjEwMg==> > . > NAML > <http://maven.40175.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml> > -- View this message in context: http://maven.40175.n5.nabble.com/Recent-issues-found-in-Surefire-master-Maven-Clean-Plugin-3-0-0-with-Maven-master-tp5898937p5899228.html Sent from the Maven Developers mailing list archive at Nabble.com.
