maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tibor Digana <tibordig...@apache.org>
Subject Re: Recent issues found in Surefire master/Maven Clean Plugin 3.0.0 with Maven master
Date Sun, 19 Feb 2017 11:51:35 GMT
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+s40175n5899224h84@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+s40175n142166h86@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.
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message