[adinn]

Hi Randall,

Randall Hauch wrote:

Just to be clear, when I run the debugger it works fine, so I can't actually debug what is going wrong (e.g., looking in Runtime.exit()). It always seems to run fine in Eclipse, and always runs fine when running Maven (Surefire) when remotely debugging or when verbose logging is turned on. It never succeeds for me when running Maven (Surefire) at the command line when no verbose logging or debugging. That does sound to me like a timing issue, and your explanation that the test script completing before the agent listener is listening sounds reasonable.

I tried running using your version of maven and it still worked ok  on my machine.

One thing I do need to check is whether you have BYTEMAN_HOME set in your environment? If it is set then the byetman jar will be picked up from that location rather than from the classpath.If you have a different version installed there then that might account for the debugger not stopping a the right place. I probably ought to change this so that the classpath is searched first before using BYTEMAN_HOME (or System  property org.jboss.byteman.home).

[rhauch]

I just checked my environment, and I don't have that environment variable set anymore in my source, in Eclipse, or in my environment.

Again, I don't have a problem when running the debugger - I'm able to connect to the remote Maven unit test run and the tests complete normally. I'm also able to run and/or debug them successfully in Eclipse. I can even run Maven from the command line, as long as I have the '...bmunit.verbose' property set to something.

However, if I remove the '...bmunit.verbose' property from my project's POM, running Maven from the command line will always result in a failure.

[adinn]

Hi Randall,

I'm really boggled here as to what is happening. The 'Connection refused' error does make it look like this is a timing problem. However, as  far as I can see the agent upload should be synchronous which means the server socket bind/listen should already have happened by the time the submit call occurs. The only thing I can think of trying now is to trace execution of the system calls in the failing case to see if/whena bind/list actually occurs relative to the socket create. Could you try running the maven comman as follows

strace -f -t -e trace=bind,listen,accept,connect mvn install -Dtest=JcrEnginePerformanceTest

The output from this ought to clarify when the bind, listen, accept andconnect requests are happening in your run. Of course, tracing might upset the timing.

[rhauch]

I guess I've made enough changes to the code recently that I can no longer get it to fail. Bother.

I could revert my code, but I'm not sure it's worth all the time and effort to track it down further. WDYT?

[adinn]

Hi Randall,

Randall Hauch wrote:

I guess I've made enough changes to the code recently that I can no longer get it to fail. Bother.

Ha, the irony! :-) As a friend once said "Sit by the river long enough and eventually you will watch the bodies of your enemies float past".

Randall Hauch wrote:

I could revert my code, but I'm not sure it's worth all the time and effort to track it down further. WDYT?

Life is probably too short to take this any further just now. If the problem ever manifests again I'll try to get whoever is the lucky victim to use strace to provide some information. Thanks very for your co-operation and patience.