[GUMP@vmgump]: Project tomcat-trunk-test-apr (in module tomcat-trunk) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at gene...@gump.apache.org. Project tomcat-trunk-test-apr has an issue affecting its community integration. This issue affects 1 projects. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - tomcat-trunk-test-apr : Tomcat 9.x, a web server implementing the Java Servlet 4.0, ... Full details are available at: http://vmgump.apache.org/gump/public/tomcat-trunk/tomcat-trunk-test-apr/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Dependency on commons-daemon exists, no need to add for property commons-daemon.native.src.tgz. -DEBUG- Dependency on commons-daemon exists, no need to add for property tomcat-native.tar.gz. -INFO- Failed with reason build failed -INFO- Project Reports in: /srv/gump/public/workspace/tomcat-trunk/output/logs-APR -INFO- Project Reports in: /srv/gump/public/workspace/tomcat-trunk/output/test-tmp-APR/logs -WARNING- No directory [/srv/gump/public/workspace/tomcat-trunk/output/test-tmp-APR/logs] The following work was performed: http://vmgump.apache.org/gump/public/tomcat-trunk/tomcat-trunk-test-apr/gump_work/build_tomcat-trunk_tomcat-trunk-test-apr.html Work Name: build_tomcat-trunk_tomcat-trunk-test-apr (Type: Build) Work ended in a state of : Failed Elapsed: 34 mins 29 secs Command Line: /usr/lib/jvm/java-8-oracle/bin/java -Djava.awt.headless=true -Dbuild.sysclasspath=only org.apache.tools.ant.Main -Dgump.merge=/srv/gump/public/gump/work/merge.xml -Djunit.jar=/srv/gump/public/workspace/junit/target/junit-4.13-SNAPSHOT.jar -Dobjenesis.jar=/srv/gump/public/workspace/objenesis/main/target/objenesis-2.5-SNAPSHOT.jar -Dtest.reports=output/logs-APR -Dtomcat-native.tar.gz=/srv/gump/public/workspace/apache-commons/daemon/dist/bin/commons-daemon-20160903-native-src.tar.gz -Dexamples.sources.skip=true -Dbase.path=/srv/gump/public/workspace/tomcat-trunk/tomcat-build-libs -Djdt.jar=/srv/gump/packages/eclipse/plugins/R-4.5-201506032000/ecj-4.5.jar -Dtest.apr.loc=/srv/gump/public/workspace/tomcat-native-trunk/dest-20160903/lib -Dtest.relaxTiming=true -Dcommons-daemon.jar=/srv/gump/public/workspace/apache-commons/daemon/dist/commons-daemon-20160903.jar -Dcommons-daemon.native.src.tgz=/srv/gump/public/workspace/apache-commons/daemon/dist/bin/commons-daemon-20160903-nat ive-src.tar.gz -Dtest.temp=output/test-tmp-APR -Dtest.accesslog=true -Dexecute.test.nio=false -Dtest.openssl.path=/srv/gump/public/workspace/openssl-master/dest-20160903/bin/openssl -Dexecute.test.apr=true -Dtest.excludePerformance=true -Dexecute.test.nio2=false -Deasymock.jar=/srv/gump/public/workspace/easymock/core/target/easymock-3.5-SNAPSHOT.jar -Dhamcrest.jar=/srv/gump/packages/hamcrest/hamcrest-core-1.3.jar -Dcglib.jar=/srv/gump/packages/cglib/cglib-nodep-2.2.jar test [Working Directory: /srv/gump/public/workspace/tomcat-trunk] CLASSPATH: /usr/lib/jvm/java-8-oracle/lib/tools.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/webapps/examples/WEB-INF/classes:/srv/gump/public/workspace/tomcat-trunk/output/testclasses:/srv/gump/public/workspace/ant/dist/lib/ant.jar:/srv/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/srv/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/srv/gump/public/workspace/ant/dist/lib/ant-junit.jar:/srv/gump/public/workspace/ant/dist/lib/ant-junit4.jar:/srv/gump/public/workspace/ant/dist/lib/ant-swing.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-xalan2.jar:/srv/gump/public/workspace/xml-commons/java/build/resolver.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/bin/bootstrap.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/bin/tomcat-juli.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/annotations-api.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/servlet-api.ja r:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/jsp-api.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/el-api.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/websocket-api.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/jaspic-api.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/catalina.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/catalina-ant.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/catalina-storeconfig.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/tomcat-coyote.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/jasper.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/jasper-el.jar:/srv/gump/public/workspace/tomcat-trunk/outpu
Re: more protection around pauseNonContainerThread()?
On 02/09/2016 15:47, Romain Manni-Bucau wrote:
> ~business code (simplified):
>
> public void myBusiness(AsyncResponse wrapperOfAsyncContext) {
> new Thread() {
> @Override
> public void run() {
> wrapperOfAsyncContext.synchronizedDispatch();
> }
> }.start();
> wrapperOfAsyncContext.synchronizedMethod();
> }
>
> If timing is good (and encountered enough to say it is in real life) then
> both method call will lock cause:
>
> 1. for the user thread: the dispatch call will call pauseNonContainerThread
> to wait the myBusiness thread to end (actually a bit more but you get the
> idea)
> 2. synchronizedMethod will lock on synchronizedDispatch
>
> so synchronizedMethod is lock on synchronizedDispatch which is lock on
> the pauseNonContainerThread of the caller/http thread so both threads are
> locked.
Hmm.
The relevant text from the Servlet spec is (for both dispatch() and
complete()) is:
"If any of the dispatch methods are called before the
container-initiated dispatch that called startAsync has returned to the
container, then the call will not take effect until after the
container-initiated dispatch has returned to the container."
The critical question is what does "...will not take effect until..." mean.
Currently, Tomcat implements this as "...will block until...". I'll look
into what it would take to implement this as "...note the request and
execute it once...". Whether or not we change this will depend a lot on
how complicated the change would be.
Mark
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: more protection around pauseNonContainerThread()?
This is an interesting quote cause i understand as it is implemented in
tomcat but also means any usage would potentially lead to deadlocks or
container integration to ensure thread safety is done right making in both
cases the spec unusable or hard to use from a user perspective. Should it
be pushed back to the spec?
Le 3 sept. 2016 18:28, "Mark Thomas" a écrit :
> On 02/09/2016 15:47, Romain Manni-Bucau wrote:
> > ~business code (simplified):
> >
> > public void myBusiness(AsyncResponse wrapperOfAsyncContext) {
> > new Thread() {
> > @Override
> > public void run() {
> > wrapperOfAsyncContext.synchronizedDispatch();
> > }
> > }.start();
> > wrapperOfAsyncContext.synchronizedMethod();
> > }
> >
> > If timing is good (and encountered enough to say it is in real life) then
> > both method call will lock cause:
> >
> > 1. for the user thread: the dispatch call will call
> pauseNonContainerThread
> > to wait the myBusiness thread to end (actually a bit more but you get the
> > idea)
> > 2. synchronizedMethod will lock on synchronizedDispatch
> >
> > so synchronizedMethod is lock on synchronizedDispatch which is lock on
> > the pauseNonContainerThread of the caller/http thread so both threads are
> > locked.
>
> Hmm.
>
> The relevant text from the Servlet spec is (for both dispatch() and
> complete()) is:
>
> "If any of the dispatch methods are called before the
> container-initiated dispatch that called startAsync has returned to the
> container, then the call will not take effect until after the
> container-initiated dispatch has returned to the container."
>
> The critical question is what does "...will not take effect until..." mean.
>
> Currently, Tomcat implements this as "...will block until...". I'll look
> into what it would take to implement this as "...note the request and
> execute it once...". Whether or not we change this will depend a lot on
> how complicated the change would be.
>
> Mark
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>
Re: more protection around pauseNonContainerThread()?
On 03/09/2016 18:08, Romain Manni-Bucau wrote:
> This is an interesting quote cause i understand as it is implemented in
> tomcat but also means any usage would potentially lead to deadlocks or
> container integration to ensure thread safety is done right making in both
> cases the spec unusable or hard to use from a user perspective. Should it
> be pushed back to the spec?
It wouldn't hurt for the EG to clarify exactly what they meant by
"...will not take effect until...". If it is intended that it might
include blocking the thread making the call, stating that explicitly
would be good.
Meanwhile, try the following patch and let me know how you get on. It
achieves the same result (hopefully) without the blocking. The unit
tests pass but I want to think about it some more (and add some
comments) before committing.
http://people.apache.org/~markt/patches/2016-09-03-async-refactoring-tc9-v1.patch
Mark
>
> Le 3 sept. 2016 18:28, "Mark Thomas" a écrit :
>
>> On 02/09/2016 15:47, Romain Manni-Bucau wrote:
>>> ~business code (simplified):
>>>
>>> public void myBusiness(AsyncResponse wrapperOfAsyncContext) {
>>> new Thread() {
>>> @Override
>>> public void run() {
>>> wrapperOfAsyncContext.synchronizedDispatch();
>>> }
>>> }.start();
>>> wrapperOfAsyncContext.synchronizedMethod();
>>> }
>>>
>>> If timing is good (and encountered enough to say it is in real life) then
>>> both method call will lock cause:
>>>
>>> 1. for the user thread: the dispatch call will call
>> pauseNonContainerThread
>>> to wait the myBusiness thread to end (actually a bit more but you get the
>>> idea)
>>> 2. synchronizedMethod will lock on synchronizedDispatch
>>>
>>> so synchronizedMethod is lock on synchronizedDispatch which is lock on
>>> the pauseNonContainerThread of the caller/http thread so both threads are
>>> locked.
>>
>> Hmm.
>>
>> The relevant text from the Servlet spec is (for both dispatch() and
>> complete()) is:
>>
>> "If any of the dispatch methods are called before the
>> container-initiated dispatch that called startAsync has returned to the
>> container, then the call will not take effect until after the
>> container-initiated dispatch has returned to the container."
>>
>> The critical question is what does "...will not take effect until..." mean.
>>
>> Currently, Tomcat implements this as "...will block until...". I'll look
>> into what it would take to implement this as "...note the request and
>> execute it once...". Whether or not we change this will depend a lot on
>> how complicated the change would be.
>>
>> Mark
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: dev-h...@tomcat.apache.org
>>
>>
>
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
