You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jena.apache.org by Andy Seaborne <an...@gmail.com> on 2013/10/05 14:28:04 UTC
Re: FW: jenkins
On 30/09/13 10:25, Rob Vesse wrote:
> Potentially useful hint from the Marmotta list about the cause of the
> random maven JVM terminations
>
> Rob
I've changed "test" and "deploy" to have -Xrs. We can see how it goes.
Sorry to come back to this but other main cause of instability is
TestRemoteEndpointResultsWithAuth.
My other through is to run less tests. Rather than the whole of the
AbstractResultSetTests just run some specifc tests. After all, it's the
same autghenticator each time so is running
e.g. results_select_objects_01, 02, 03, 04, ...
actually testing anything more?
Same for TestRemoteEndpointConnectionWithAuth.
Or set the HttpClient to stop the HttpOp code creating an HttpClient
each time?
Andy
>
>
> On 9/25/13 7:29 AM, "Sergio Fernández" <wi...@apache.org> wrote:
>
>> When randomly the build fails, usually it's with this error message:
>>
>> ERROR: Maven JVM terminated unexpectedly with exit code 143
>>
>> And it looks a known issue in Jenkins:
>>
>> https://issues.jenkins-ci.org/browse/JENKINS-5144
>>
>> So I'd try to use the solution the propose there (adding the -Xrs flag
>> in global MAVEN_OPTS). Further details about that option at:
>>
>> http://pic.dhe.ibm.com/infocenter/java7sdk/v7r0/index.jsp?topic=%2Fcom.ibm
>> .java.win.70.doc%2Fdiag%2Ftools%2Fdisablingdumpagentswith-xrs.html
>>
>> Personally I never used such option; so let's see how it behaviours...
>>
>> --
>> Sergio Fernández
>
Re: Re: FW: jenkins
Posted by Claude Warren <cl...@xenei.com>.
I didn't look. I'm busy digging around in test code. I will be looking
eventually but I figured all the devs on this list might like to think
about it.
As a side note: I do know that the following packages do use it:
htmlunit-2.8 HttpWebConnection.downloadContent()
guava-11.0.2 FileBackedOutputStream.update()
weld-se-11.0.10 FileBackedOutputStream.update()
jna-3.4.0 Native.loadNativeLibraryFromJar()
mail-1.4.7 TempFile constructor
ehcache-core-2.6.2 DiskStorePath constructor
ehcache-core-2.6.2 AgentLoader.getAgentFile()
commons-exec-1.1 VmsCommandLauncher.createCommandFile()
commons-httpclient-2.0.2 GetMethod.createTempFile()
commons-io-1.3.2 (and 1.4) FileUtils.deleteDirectioryOnExit() and
forceDeleteOnExit(), LockableFileWriter.createLock()
On Mon, Oct 7, 2013 at 10:11 AM, Chris Dollin
<ch...@epimorphics.com>wrote:
> On Monday, October 07, 2013 09:48:23 AM Claude Warren wrote:
>
> > So now, my question is for the code we are testing are there
> > File.deleteOnExit() calls? Are we using the method in the test code
> itself?
>
> Isn't this a job for `grep -r`? (Or IDE magic searches)
>
> Chris
>
> (who doesn't have the current source on his machine)
>
> --
> "I don't want to know what the Structuralists think! I want /Archer's
> Goon/
> to know what YOU think!"
>
> Epimorphics Ltd, http://www.epimorphics.com
> Registered address: Court Lodge, 105 High Street, Portishead, Bristol BS20
> 6PT
> Epimorphics Ltd. is a limited company registered in England (number
> 7016688)
>
>
--
I like: Like Like - The likeliest place on the web<http://like-like.xenei.com>
LinkedIn: http://www.linkedin.com/in/claudewarren
Re: Re: FW: jenkins
Posted by Chris Dollin <ch...@epimorphics.com>.
On Monday, October 07, 2013 09:48:23 AM Claude Warren wrote:
> So now, my question is for the code we are testing are there
> File.deleteOnExit() calls? Are we using the method in the test code itself?
Isn't this a job for `grep -r`? (Or IDE magic searches)
Chris
(who doesn't have the current source on his machine)
--
"I don't want to know what the Structuralists think! I want /Archer's Goon/
to know what YOU think!"
Epimorphics Ltd, http://www.epimorphics.com
Registered address: Court Lodge, 105 High Street, Portishead, Bristol BS20 6PT
Epimorphics Ltd. is a limited company registered in England (number 7016688)
Re: FW: jenkins
Posted by Claude Warren <cl...@xenei.com>.
I came across an interesting tidbit that generally results in OOM Perm Gen.
Any code that calls File.deleteOnExit() should not be used in a server
environment.
basically, every deleteOnExit() uses some memory to track the file and its
order for deletion. That memory is not freed until the JVM shuts down
(even if the file is deleted). There is no way to turn the flag off once
it is enabled. So in a system that "never" shuts down usage results in
memory exhaustion.
So now, my question is for the code we are testing are there
File.deleteOnExit() calls? Are we using the method in the test code itself?
Claude
On Sat, Oct 5, 2013 at 1:28 PM, Andy Seaborne <
andy.seaborne.apache@gmail.com> wrote:
> On 30/09/13 10:25, Rob Vesse wrote:
>
>> Potentially useful hint from the Marmotta list about the cause of the
>> random maven JVM terminations
>>
>> Rob
>>
>
> I've changed "test" and "deploy" to have -Xrs. We can see how it goes.
>
>
> Sorry to come back to this but other main cause of instability is
> TestRemoteEndpointResultsWithA**uth.
>
> My other through is to run less tests. Rather than the whole of the
> AbstractResultSetTests just run some specifc tests. After all, it's the
> same autghenticator each time so is running
> e.g. results_select_objects_01, 02, 03, 04, ...
> actually testing anything more?
>
> Same for TestRemoteEndpointConnectionWi**thAuth.
>
> Or set the HttpClient to stop the HttpOp code creating an HttpClient each
> time?
>
> Andy
>
>
>
>
>>
>> On 9/25/13 7:29 AM, "Sergio Fernández" <wi...@apache.org> wrote:
>>
>> When randomly the build fails, usually it's with this error message:
>>>
>>> ERROR: Maven JVM terminated unexpectedly with exit code 143
>>>
>>> And it looks a known issue in Jenkins:
>>>
>>> https://issues.jenkins-ci.org/**browse/JENKINS-5144<https://issues.jenkins-ci.org/browse/JENKINS-5144>
>>>
>>> So I'd try to use the solution the propose there (adding the -Xrs flag
>>> in global MAVEN_OPTS). Further details about that option at:
>>>
>>> http://pic.dhe.ibm.com/**infocenter/java7sdk/v7r0/**
>>> index.jsp?topic=%2Fcom.ibm<http://pic.dhe.ibm.com/infocenter/java7sdk/v7r0/index.jsp?topic=%2Fcom.ibm>
>>> .java.win.70.doc%2Fdiag%**2Ftools%**2Fdisablingdumpagentswith-xrs.**html
>>>
>>> Personally I never used such option; so let's see how it behaviours...
>>>
>>> --
>>> Sergio Fernández
>>>
>>
>>
>
--
I like: Like Like - The likeliest place on the web<http://like-like.xenei.com>
LinkedIn: http://www.linkedin.com/in/claudewarren
Re: FW: jenkins
Posted by Rob Vesse <rv...@dotnetrdf.org>.
As you probably saw I have disabled the auth related tests and the JDBC
module builds seem to be running more reliably so far
Rob
On 05/10/2013 13:28, "Andy Seaborne" <an...@gmail.com>
wrote:
>On 30/09/13 10:25, Rob Vesse wrote:
>> Potentially useful hint from the Marmotta list about the cause of the
>> random maven JVM terminations
>>
>> Rob
>
>I've changed "test" and "deploy" to have -Xrs. We can see how it goes.
>
>
>Sorry to come back to this but other main cause of instability is
>TestRemoteEndpointResultsWithAuth.
>
>My other through is to run less tests. Rather than the whole of the
>AbstractResultSetTests just run some specifc tests. After all, it's the
>same autghenticator each time so is running
>e.g. results_select_objects_01, 02, 03, 04, ...
>actually testing anything more?
>
>Same for TestRemoteEndpointConnectionWithAuth.
>
>Or set the HttpClient to stop the HttpOp code creating an HttpClient
>each time?
>
> Andy
>
>
>
>>
>>
>> On 9/25/13 7:29 AM, "Sergio Fernández" <wi...@apache.org> wrote:
>>
>>> When randomly the build fails, usually it's with this error message:
>>>
>>> ERROR: Maven JVM terminated unexpectedly with exit code 143
>>>
>>> And it looks a known issue in Jenkins:
>>>
>>> https://issues.jenkins-ci.org/browse/JENKINS-5144
>>>
>>> So I'd try to use the solution the propose there (adding the -Xrs flag
>>> in global MAVEN_OPTS). Further details about that option at:
>>>
>>>
>>>http://pic.dhe.ibm.com/infocenter/java7sdk/v7r0/index.jsp?topic=%2Fcom.i
>>>bm
>>> .java.win.70.doc%2Fdiag%2Ftools%2Fdisablingdumpagentswith-xrs.html
>>>
>>> Personally I never used such option; so let's see how it behaviours...
>>>
>>> --
>>> Sergio Fernández
>>
>