t; > >> encodeAndWriteToOutput()
>> > > >>
>> > > >>
>> > > >> >>
>> > > >>
>> > > >>
>> > > >>
>> > > >>
>> > > >>
>> > > >> On Fri, Mar 22, 2019 at 4:44 PM
nk we need to worry about why that file is added for this
> > > >> topic.
> > > >> >
> > > >> > But while we're on the subject, is there an -Xmx value you would
> > > >> recommend
> > > >> > to ensure the paren
gt;> > don't think we need to worry about why that file is added for this
> > > >> topic.
> > > >> >
> > > >> > But while we're on the subject, is there an -Xmx value you would
> > > >> recommend
> > > >> > to
c"?
> > >> > >
> > >> > > On Thu, Mar 21, 2019 at 12:05 AM Jason Young <
> > >> jason.yo...@procentive.com
> > >> > >
> > >> > > wrote:
> > >> > >
> > >> > > > Mikael, sorry I do not appear to have permission to view the
> link.
> >
t;> > > > ForkedBooter.listenToShutdownCommands(..). When it checks, it also
> >> sets
> >> > > > pingDone to false. The executor is configured to run up to 2
> threads
> >> > > > concurrently to handle the workload, and is set to run at a fixed
> >
> it's running behind schedule. This new thread checks for a ping,
> > finds
> > > > it,
> > > > > and sets pingDone to false. But then the original thread also runs,
> > > say,
> > > > 2
> > > > > seconds afterwards, c
t; > > after
>> > > > a couple of minutes we might be a full 30s behind schedule. It's
>> > possible
>> > > > the executor will create another thread to run the scheduled task
>> > because
>> > > > it's running behind schedule. This
Xmx512m"`
> > > > which cannot be undone by setting `MAVEN_OPTS` at the command line;
> you
> > > end
> > > > up with e.g. `-Xmx1g -Xmx512m`. (Note this applies to the Maven
> > (parent)
> > > > process, not the surefire/failsafe (child) pro
applies to the Maven
> (parent)
> > > process, not the surefire/failsafe (child) process.)
> > >
> > > On Wed, Mar 20, 2019 at 3:46 AM Bernd Eckenfels <
> e...@zusammenkunft.net>
> > > wrote:
> > >
> > > > I guess a timeout caused by Full
> the timeout might not be nice but does look like it would help in both
> > > cases. (Problems with stdout are more related to unexpected JVM
> messages
> > I
> > > guess)
> > >
> > > Gruss
> > > Bernd
> > > --
> > > http://bernd.
essages
> I
> > guess)
> >
> > Gruss
> > Bernd
> > --
> > http://bernd.eckenfels.net
> >
> >
> > Von: Mikael Åsberg
> > Gesendet: Mittwoch, März 20, 2019 9:40 AM
> > An: Maven Users List
> >
.eckenfels.net
>
>
> Von: Mikael Åsberg
> Gesendet: Mittwoch, März 20, 2019 9:40 AM
> An: Maven Users List
> Betreff: Re: Failsafe: Killing self fork JVM. PING timeout elapsed.
>
> These issues regarding communication with forked JVMs, won't
Von: Mikael Åsberg
Gesendet: Mittwoch, März 20, 2019 9:40 AM
An: Maven Users List
Betreff: Re: Failsafe: Killing self fork JVM. PING timeout elapsed.
These issues regarding communication with forked JVMs, won't they be
resolved once surefire moves to interprocess communication using
tcp
These issues regarding communication with forked JVMs, won't they be
resolved once surefire moves to interprocess communication using
tcp/ip sockets? This happens to be the target feature to be included
in the next surefire 3.0.0 milestone:
Getting back to my original questions, I know that "ping" means to see if a
process is there, and "NOOP" implies it's not a command to do anything. But
what do the terms "ping" and "NOOP" mean in this context, i.e. how do the
processes communicate? I assume they don't sonar. Do other processes
I upgraded failsafe and surefire to 3.0.0-M3 as advised; we encountered the
same exception. (Still using -Xmx5g, will switch to OpenJ9 soon in case
that helps.)
BTW I also asked on StackOverflow previously, for anyone interested:
Thanks again for the information.
We had increased the RAM to 3g some time ago to prevent OOMEs. More
recently, I increased the RAM again to 5g for extra headroom since we had
more headroom available; the problem hasn't happened since, but it hasn't
been very long.
We use a more customized image
>> I'll try to enable some logging about GC pauses to see what's up
Pls do not keep such setting after tuning the GC because this may sometime
break the interprocess communication between Maven process and surefire
process.
It's worth to list GC information in a file and not in the console logs.
Thanks for the information. It's good to see someone understands a little
about this.
Incidentally, we have been looking at other GCs and VMs for the application
in production environments, so I'll look into how these affect tests as
well. I'll try to enable some logging about GC pauses to see
Alonso Isidoro Roman, why you are telling me " unsubscribe", hm?
On Sat, Feb 23, 2019 at 2:07 PM Alonso Isidoro Roman
wrote:
> unsubscribe
>
> El sáb., 23 feb. 2019 a las 13:36, Tibor Digana ()
> escribió:
>
> > Hi Jason,
> >
> > We spoke about this issue on our chat in ASF Slack:
> > "I think
unsubscribe
El sáb., 23 feb. 2019 a las 13:36, Tibor Digana ()
escribió:
> Hi Jason,
>
> We spoke about this issue on our chat in ASF Slack:
> "I think his tests have been paused for a long GC periods and timed out 3x
> PING period = 30 seconds. After this period forked JVM supposed the Maven
>
Hi Jason,
We spoke about this issue on our chat in ASF Slack:
"I think his tests have been paused for a long GC periods and timed out 3x
PING period = 30 seconds. After this period forked JVM supposed the Maven
process was killed by JenkinsCI and therefore all surefire processes are
killed as
We have a CI job running Maven including tests. Sometimes the failsfae
process will exit, e.g.:
[INFO] Results:
[INFO]
[WARNING] Tests run: 8152, Failures: 0, Errors: 0, Skipped: 31
...
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-failsafe-plugin:2.22.1:verify
(integration-test)
23 matches
Mail list logo
