@Michael-O
The issue(two errors in ForkModeIT) with commit
e0bcffd05bb04001f97bf752de56bca7137da3e2 is caused by duplicate properties
but it is not cause of that commit.
I have found the root cause (reuseForks duplicates):
-DforkMode=perthread *-DreuseForks=false -DreuseForks=true*
Am 02/23/17 um 19:20 schrieb Michael Osipov:
> So guys,
>
> I took a different approach to provide Tibor more information about the
> failures. First of all, I added another platform for the test which is
> exotic: HP-UX 11.31. The VM comes directly from HPE which is a
> repackaged Oracle JVM.
So guys,
I took a different approach to provide Tibor more information about the
failures. First of all, I added another platform for the test which is
exotic: HP-UX 11.31. The VM comes directly from HPE which is a
repackaged Oracle JVM.
I started Git bisect and discovered some broken
Am 02/20/17 um 01:10 schrieb Tibor Digana:
> Can somebody explore what is different between these two surefire builds
> (failed and successful) and why?:
> https://builds.apache.org/view/Maven%20Master%20Release%20Status/
This one is run with current Maven master using JDK 7.
>
Am 02/20/17 um 01:10 schrieb Tibor Digana:
> I meant this build which is in good conditions
> https://builds.apache.org/view/Maven%20Master%20Release%20Status/job/maven-master-release-status-test-surefire-linux/30/console
>
> Can somebody explore what is different between these two surefire
Am 02/20/17 um 01:10 schrieb Tibor Digana:
> I meant this build which is in good conditions
> https://builds.apache.org/view/Maven%20Master%20Release%20Status/job/maven-master-release-status-test-surefire-linux/30/console
This points to a console with IT failures. That build never succeeded on
@Michael
I have pushed new experimental changes with *FileDescriptor.out* in the
branch 2.19.2-experimental.
Can you pls trigger the build on FreeBSD?
I use only one IT and the build passed successfully - ForkedModeIT.
Running org.apache.maven.surefire.its.ForkModeIT
Tests run: 12, Failures: 0,
I meant this build which is in good conditions
https://builds.apache.org/view/Maven%20Master%20Release%20Status/job/maven-master-release-status-test-surefire-linux/30/console
Can somebody explore what is different between these two surefire builds
(failed and successful) and why?:
Am 02/19/17 um 23:58 schrieb Tibor Digana:
> and they are getting really nervous. So we have to make a release and later
> we will finish fix for FreeBSD. I am still facing native problem with
> reliably streaming data over standard output streams with subprocess.
> We with Kristian Roselvold were
Currently there is another issue.
Events from plugin don't arrive to forked jvm.
I have placed more logs. We will run the ITs again with Michael tomorrow. I
open to check logs in the morning and in the evening.
The Version 2.19.1 has these issues as well. So it is not a regression.
We have to
Especially as we know the forked money should *exit before* the main
process, so we should be able to flush the ACK...
The timeout would just be a fallback to prevent zombies
On Sun 19 Feb 2017 at 21:09, Michael Osipov wrote:
> I made this proposal to Tibor too. The forked
I made this proposal to Tibor too. The forked VM sends the Z, waits for
an ACK and then exits. This should be idiot proof.
Am 2017-02-19 um 22:04 schrieb Stephen Connolly:
Can we invert the sequence?
The forked process sends a Z
Then the controller sends back an ACK of some sort. If the
Can we invert the sequence?
The forked process sends a Z
Then the controller sends back an ACK of some sort. If the forked process
hasn't received the ACK say 5s after sending the Z is just says screw it
and does an exit?
On Sun 19 Feb 2017 at 20:34, Christian Schulte wrote:
>
Am 19.02.2017 um 21:10 schrieb Michael Osipov:
> Am 2017-02-19 um 19:54 schrieb Christian Schulte:
>> Am 02/19/17 um 19:52 schrieb Christian Schulte:
>>> Am 02/19/17 um 19:47 schrieb Christian Schulte:
Am 02/19/17 um 13:06 schrieb Michael Osipov:
> Socket give you, of course, a lot of
Am 2017-02-19 um 19:54 schrieb Christian Schulte:
Am 02/19/17 um 19:52 schrieb Christian Schulte:
Am 02/19/17 um 19:47 schrieb Christian Schulte:
Am 02/19/17 um 13:06 schrieb Michael Osipov:
Socket give you, of course, a lot of control, but they also impose an
overhead compares to named pipes
"Initially, the standard error stream is unbuffered; "
Maybe just use System.err instead of System.out to avoid any buffering,
if there is no other solution.
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For
Am 02/19/17 um 19:52 schrieb Christian Schulte:
> Am 02/19/17 um 19:47 schrieb Christian Schulte:
>> Am 02/19/17 um 13:06 schrieb Michael Osipov:
>>> Socket give you, of course, a lot of control, but they also impose an
>>> overhead compares to named pipes (mkfifo, CreateNamePipe).
>>>
>>> I
Am 02/19/17 um 19:47 schrieb Christian Schulte:
> Am 02/19/17 um 13:06 schrieb Michael Osipov:
>> Socket give you, of course, a lot of control, but they also impose an
>> overhead compares to named pipes (mkfifo, CreateNamePipe).
>>
>> I think our biggest problem is that stdout is subject to
Am 02/19/17 um 13:06 schrieb Michael Osipov:
> Socket give you, of course, a lot of control, but they also impose an
> overhead compares to named pipes (mkfifo, CreateNamePipe).
>
> I think our biggest problem is that stdout is subject to buffering
> issues and in case if System#exit() status Z
On Sun 19 Feb 2017 at 12:06, Michael Osipov wrote:
> Socket give you, of course, a lot of control, but they also impose an
> overhead compares to named pipes (mkfifo, CreateNamePipe).
Yep but windows restricts choice of technology. Docker for Windows (as in
where Windows
On Sun 19 Feb 2017 at 11:51, Tibor Digana wrote:
> Too much work for socket, and port can be used by other process.
Random assignment of port and pass the "secret" on launch.
Any unexpected socket connection you just reject.
Yes it is more work but how cool to have
Michael, pls try to build now. It might be multiple issues we are facing.
The threading issue workaround was pushed to 2.19.2-experimental.
On Sun, Feb 19, 2017 at 1:07 PM, Michael Osipov-2 [via Maven] <
ml-node+s40175n5899236...@n5.nabble.com> wrote:
> Socket give you, of course, a lot of
Socket give you, of course, a lot of control, but they also impose an
overhead compares to named pipes (mkfifo, CreateNamePipe).
I think our biggest problem is that stdout is subject to buffering
issues and in case if System#exit() status Z is the buffer, never
written out.
Surefire thinks
Too much work for socket, and port can be used by other process.
But We have good news, see IRC
[12:43] ThreadedStreamConsumer#23504796 run() :: items :: Z,0,BYE!
[12:43] we received Z
[12:44] now I have to find why ForkStarter is faster to check the
Z event
[12:45] because ForkStarter does
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
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
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
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
>>MNG-6169 + local revert of clean gives:
Not sure about your change (MNG-6169 + local revert of clean), but I know
that
The Clean Plugin 3.0.0 caused folder target/surefire-reports to be suddenly
deleted.
No report files found.
>> Yes but is this failing because of a regression in core or
MNG-6169 + local revert of clean gives:
Failed tests:
shouldNotBeVerbose(org.apache.maven.surefire.its.CheckTestNgReportTestIT):
log pattern does not match nTimes(..)
testSkippedSurefireReportGeneration(org.apache.maven.surefire.its.jiras.Surefire772BothReportsIT):
Expecting failsafe report
Yes but is this failing because of a regression in core or surefire?
On 18 February 2017 at 17:32, Tibor Digana wrote:
> Hi Stephen,
>
> Both branches should be merged together.
> SUREFIRE_SYSPROP_DUPLICATES
> SUREFIRE_STDOUT_FLUSH
> All tests should pass then.
> Cheers
Hi Stephen,
Both branches should be merged together.
SUREFIRE_SYSPROP_DUPLICATES
SUREFIRE_STDOUT_FLUSH
All tests should pass then.
Cheers
Tibor
On Sat, Feb 18, 2017 at 6:21 PM, Tibor Digana-2 [via Maven] <
ml-node+s40175n5899136...@n5.nabble.com> wrote:
> We had this problem and the branch
We had this problem and the branch SUREFIRE_SYSPROP_DUPLICATES should fix
it.
On Sat, Feb 18, 2017 at 6:12 PM, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:
> So Maven 3.5.0-SNAPSHOT just has one failure:
>
>
> Tests run: 3, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 14.835
Same for 3.5.0-SNAPSHOT + MNG-6169 on OS-X
Results :
Failed tests:
shouldNotBeVerbose(org.apache.maven.surefire.its.CheckTestNgReportTestIT):
log pattern does not match nTimes(..)
Tests run: 714, Failures: 1, Errors: 0, Skipped: 133
On 18 February 2017 at 17:12, Stephen Connolly <
So Maven 3.5.0-SNAPSHOT just has one failure:
Tests run: 3, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 14.835 sec
<<< FAILURE!
shouldNotBeVerbose(org.apache.maven.surefire.its.CheckTestNgReportTestIT)
Time elapsed: 0 sec <<< FAILURE!
java.lang.AssertionError: log pattern does not match
I have downloaded Michaels log for Maven 3.3.9 & Surefire 2.19.2-SNAPSHOT
http://home.apache.org/~michaelo/maven/surefire/maven-surefire-extended-patch-maven-3.3.9.tar.gz
and 27 tests failed.
On Sat, Feb 18, 2017 at 4:52 PM, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:
> So
>>That is certainly looking like a regression in Maven core
But the principle of the bug on FreeBSD should fail the build with Maven
3.3.9 as well. This I do not understand why it is ok with 3.3.9.
On Sat, Feb 18, 2017 at 4:55 PM, Tibor Digana
wrote:
> ok, let's try
ok, let's try with two surefire branches merged together.
On Sat, Feb 18, 2017 at 4:52 PM, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:
> So results so far: surefire master branch builds with 3.3.9 but fails with
> 3.5.0-SNAPSHOT when running on macOS Sierra with Oracle Java
So results so far: surefire master branch builds with 3.3.9 but fails with
3.5.0-SNAPSHOT when running on macOS Sierra with Oracle Java 1.8.0_121
That is certainly looking like a regression in Maven core
On 18 February 2017 at 10:55, Michael Osipov wrote:
> For those who
For those who would like to reproduce the issues:
1. Build Maven distribution from 3.3.9, master, MNG-6169 and MNG-6169
with locally modified
maven-core/src/main/resources/META-INF/plexus/components.xml
maven-clean-plugin 2.6.1 => 3.0.0.
You should have four distros now.
2. Clone Surefire
3.
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
41 matches
Mail list logo