Re: Working tc native build
On 11.07.2014 19:50, Christopher Schultz wrote: Rainer, On 7/10/14, 8:36 PM, Rainer Jung wrote: On 08.07.2014 18:14, Mark Thomas wrote: On 08/07/2014 16:39, Christopher Schultz wrote: Anyway, here's what the above tool says tcnative-1.dll requires in terms of direct dependencies: - USER32.dll - PSAPI.dll - SHLWAPI.dll - KERNEL32.dll - ADVAPI32.dll - WS2_32.dll - MSWSOCK.dll - MSVCR100.dll Is that last one the one you were concerned about? Yes. If so, what's the procedure for statically-linking that library into tcnative ... or, better yet, why is that library not necessary when using MSVS 2006 or whatever? Using VS6 or Mladen's toolkit, it builds against msvcrt.dll which is part of the base OS. For reasons I haven't dug into, later versions of Visual Studio build upon a newer version of that library and despite quite a lot of searching I haven't found a way to make later versions of Visual Studio build against the older dll. The dependency on the modern (versioned) msvcrXXX.dll only gets problematic when you need to mix binaries and libs build with different MSVC versions in the same process. For instance building modules for the Apache web server and the server itself with different MSVC versions can get you in trouble, because the msvcrXXX.dll version depends 1:1 on the MSVC version and different versions of the lib are not expected to interact nicely in the same process. In the tcnative case, this would only happen, if either the jvm itself or another native agent or library loaded into the jvm would be linked against a different msvcrXXX.dll. Concerning agents we can't be safe because we can't control what users load. Concerning the jvm I did a quick check with 1.7.0_51 64 bit on Windows 7 and depends.exe show the dependency to msvcr100.dll in bin/server/jvm.dll. The same for Java 8. Something doesn't quite add up, here: we have been producing builds against the "system" MSVCRT.dll library for .. ever, and the JVM has probably been built against MSVCR100.dll for a while, but there have been no reports of tcnative burning to the ground on Windows. Doesn't that mean that "libs built with different MSVC versions in the same process" aren't a problem.. at least .. not always? Maybe the deal is that we use only simple calls from the library and therefore it doesn't matter which one gets called at runtime. Folklore says mixing msvcrt.dll and a single numbered one is fine, mixing multiple numbered ones in the same binary not. So to me it looks one can only either use the old way of building against the old msvcrt.dll without version - which seems to be no longer really supported and might vanish - or sync on the msvc version that is used to build the jvm and hope they keep it stable per jvm major version. It can still be done using the Windows Driver Development Kit, but most people don't have the DDK sitting around for "normal" Windows development. I can't comment, I never tried that way for any build. For end users the dependency on the dll is not a big problem, because Microsoft provides it for redistribution or download. Of course we can't bundle it due to license incompatibility. Any chance that MSVCR100.dll and friends are provided by recent OSs? On my Windows 8 VM I can see these files in /windows/system32: 07/25/2012 11:06 PM77,824 msvcirt.dll 07/11/2012 10:01 PM 613,840 msvcp110_clr0400.dll 07/25/2012 11:06 PM 572,416 msvcp60.dll 08/30/2012 08:52 PM17,888 msvcr100_clr0400.dll 07/11/2012 10:01 PM 856,016 msvcr110_clr0400.dll 07/26/2012 01:26 AM 654,848 msvcrt.dll Like Konstantin said, typically it is *not* provided. In my particular case, would we need to bundle anything with tcnative? I'd say if we ever switch to building using normal MSVC, it should simply be documented, that tcnative has a dependency on msvcr100.dll (with the number 100 adopted to the version of MSVC which was used for the build) and that you can get that from MS (the redistributable download). I'd expect, that as long as we stick to the same version, that's used to build the JVM, tcnative would find the dll loaded already by the JVM (but haven't tested that assumption). If that is true, we could document that as well. Currently since we only depend on msvcrt.dll everything is fine, except that building that way is a bit more complicated and MS might stop that possibility in the future. Regards, Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 55938] clang-analyzer report for 1.1.31
https://issues.apache.org/bugzilla/show_bug.cgi?id=55938 Ville Skyttä changed: What|Removed |Added Version|1.1.29 |1.1.31 Summary|clang-analyzer report for |clang-analyzer report for |1.1.29 |1.1.31 --- Comment #4 from Ville Skyttä --- Updated report done with clang 3.4.1 found no new issues, it's at http://scop.fedorapeople.org/scan-build/tomcat-native-1.1.31/ -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 56712] New: Off-by-one second errors in time calculations in PersistenceManager
https://issues.apache.org/bugzilla/show_bug.cgi?id=56712
Bug ID: 56712
Summary: Off-by-one second errors in time calculations in
PersistenceManager
Product: Tomcat 8
Version: 8.0.9
Hardware: PC
Status: NEW
Severity: normal
Priority: P2
Component: Catalina
Assignee: dev@tomcat.apache.org
Reporter: knst.koli...@gmail.com
The fix for bug 56698 (r1608443, r1608448) implemented an automated test for
PersistenceManager. Reviewing the manager code to investigate the test
failures, I see two issues:
Checks that evaluate idle time of a session in PersistenceManagerBase typically
do the following:
> int timeIdle = (int) (session.getIdleTime() / 1000L);
> if (timeIdle > maxIdleBackup) { ... }
I see two errors in those two lines:
Error 1.
The integer division performs truncation. Comparing the code with
documentation, the condition there shall be
> if (timeIdle >= maxIdleBackup) { ... }
It does no matter much for a real-world configuration where the times are
expected to be tens of seconds, but it matters for the test case that wants to
run fast.
Error 2.
StandardSession.getIdleTime() performs a validity check and can throw an ISE
which is unexpected here. It shall be replaced with a call to
session.getIdleTimeInternal().
--
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 56712] Off-by-one second errors in time calculations in PersistenceManager
https://issues.apache.org/bugzilla/show_bug.cgi?id=56712 Konstantin Kolinko changed: What|Removed |Added OS||All --- Comment #1 from Konstantin Kolinko --- Also, s/ getLastAccessedTime() / getLastAccessedTimeInternal() / -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1609920 - in /tomcat/trunk: java/org/apache/catalina/session/PersistentManagerBase.java test/org/apache/catalina/session/TestPersistentManager.java webapps/docs/changelog.xml
Author: kkolinko
Date: Sat Jul 12 13:54:30 2014
New Revision: 1609920
URL: http://svn.apache.org/r1609920
Log:
Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=56712
Fix session time comparisons in PersistentManagerBase.
When asking for session times use internal**() methods to avoid an
IllegalStateException.
Speed up TestPersistentManager test for BZ 56698 by removing sleep(1000) and
fix occasional failures.
Modified:
tomcat/trunk/java/org/apache/catalina/session/PersistentManagerBase.java
tomcat/trunk/test/org/apache/catalina/session/TestPersistentManager.java
tomcat/trunk/webapps/docs/changelog.xml
Modified:
tomcat/trunk/java/org/apache/catalina/session/PersistentManagerBase.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/session/PersistentManagerBase.java?rev=1609920&r1=1609919&r2=1609920&view=diff
==
--- tomcat/trunk/java/org/apache/catalina/session/PersistentManagerBase.java
(original)
+++ tomcat/trunk/java/org/apache/catalina/session/PersistentManagerBase.java
Sat Jul 12 13:54:30 2014
@@ -903,8 +903,8 @@ public abstract class PersistentManagerB
synchronized (session) {
if (!session.isValid())
continue;
-int timeIdle = (int) (session.getIdleTime() / 1000L);
-if (timeIdle > maxIdleSwap && timeIdle > minIdleSwap) {
+int timeIdle = (int) (session.getIdleTimeInternal() /
1000L);
+if (timeIdle >= maxIdleSwap && timeIdle >= minIdleSwap) {
if (session.accessCount != null &&
session.accessCount.get() > 0) {
// Session is currently being accessed - skip it
@@ -952,8 +952,8 @@ public abstract class PersistentManagerB
for (int i = 0; i < sessions.length && toswap > 0; i++) {
StandardSession session = (StandardSession) sessions[i];
synchronized (session) {
-int timeIdle = (int) (session.getIdleTime() / 1000L);
-if (timeIdle > minIdleSwap) {
+int timeIdle = (int) (session.getIdleTimeInternal() / 1000L);
+if (timeIdle >= minIdleSwap) {
if (session.accessCount != null &&
session.accessCount.get() > 0) {
// Session is currently being accessed - skip it
@@ -994,14 +994,14 @@ public abstract class PersistentManagerB
synchronized (session) {
if (!session.isValid())
continue;
-long lastAccessedTime = session.getLastAccessedTime();
+long lastAccessedTime =
session.getLastAccessedTimeInternal();
Long persistedLastAccessedTime =
(Long)
session.getNote(PERSISTED_LAST_ACCESSED_TIME);
if (persistedLastAccessedTime != null &&
lastAccessedTime ==
persistedLastAccessedTime.longValue())
continue;
-int timeIdle = (int) (session.getIdleTime() / 1000L);
-if (timeIdle > maxIdleBackup) {
+int timeIdle = (int) (session.getIdleTimeInternal() /
1000L);
+if (timeIdle >= maxIdleBackup) {
if (log.isDebugEnabled())
log.debug(sm.getString
("persistentManager.backupMaxIdle",
Modified:
tomcat/trunk/test/org/apache/catalina/session/TestPersistentManager.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/test/org/apache/catalina/session/TestPersistentManager.java?rev=1609920&r1=1609919&r2=1609920&view=diff
==
--- tomcat/trunk/test/org/apache/catalina/session/TestPersistentManager.java
(original)
+++ tomcat/trunk/test/org/apache/catalina/session/TestPersistentManager.java
Sat Jul 12 13:54:30 2014
@@ -21,6 +21,7 @@ import java.io.IOException;
import java.util.ArrayList;
import java.util.Arrays;
import java.util.List;
+import java.util.concurrent.atomic.AtomicInteger;
import javax.servlet.ServletException;
import javax.servlet.http.HttpServlet;
@@ -46,6 +47,10 @@ public class TestPersistentManager exten
private String oldActivityCheck;
+/**
+ * As documented in config/manager.html, the "ACTIVITY_CHECK" property must
+ * be set to "true" for PersistentManager to function correctly.
+ */
@Before
public void setActivityCheck() {
oldActivityCheck = System.setProperty(ACTIVITY_CHECK, "true");
@@ -60,8 +65,37 @@ public class TestPersistentManager exten
}
}
+/**
+ * Wait enough for the system clock to update its value. On some systems
+ * (e.g. old Windows) the clock granularity
[Bug 56712] Off-by-one second errors in time calculations in PersistenceManager
https://issues.apache.org/bugzilla/show_bug.cgi?id=56712 --- Comment #2 from Konstantin Kolinko --- Fixed in trunk by r1609920. It will be in 8.0.11 onwards. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 56712] Off-by-one second errors in time calculations in PersistenceManager
https://issues.apache.org/bugzilla/show_bug.cgi?id=56712 Konstantin Kolinko changed: What|Removed |Added Component|Catalina|Catalina Version|8.0.9 |7.0.54 Product|Tomcat 8|Tomcat 7 Target Milestone||--- -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1609924 - in /tomcat/tc7.0.x/trunk: ./ java/org/apache/catalina/session/PersistentManagerBase.java test/org/apache/catalina/session/TestPersistentManager.java webapps/docs/changelog.xml
Author: kkolinko
Date: Sat Jul 12 14:20:24 2014
New Revision: 1609924
URL: http://svn.apache.org/r1609924
Log:
Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=56712
Fix session time comparisons in PersistentManagerBase.
When asking for session times use internal**() methods to avoid an
IllegalStateException.
Speed up TestPersistentManager test for BZ 56698 by removing sleep(1000) and
fix occasional failures.
It is backport of r1609920 from tomcat/trunk.
Modified:
tomcat/tc7.0.x/trunk/ (props changed)
tomcat/tc7.0.x/trunk/java/org/apache/catalina/session/PersistentManagerBase.java
tomcat/tc7.0.x/trunk/test/org/apache/catalina/session/TestPersistentManager.java
tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml
Propchange: tomcat/tc7.0.x/trunk/
--
Merged /tomcat/trunk:r1609920
Modified:
tomcat/tc7.0.x/trunk/java/org/apache/catalina/session/PersistentManagerBase.java
URL:
http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/java/org/apache/catalina/session/PersistentManagerBase.java?rev=1609924&r1=1609923&r2=1609924&view=diff
==
---
tomcat/tc7.0.x/trunk/java/org/apache/catalina/session/PersistentManagerBase.java
(original)
+++
tomcat/tc7.0.x/trunk/java/org/apache/catalina/session/PersistentManagerBase.java
Sat Jul 12 14:20:24 2014
@@ -926,11 +926,11 @@ public abstract class PersistentManagerB
continue;
int timeIdle;
if (StandardSession.LAST_ACCESS_AT_START) {
-timeIdle = (int) ((timeNow -
session.getLastAccessedTime()) / 1000L);
+timeIdle = (int) ((timeNow -
session.getLastAccessedTimeInternal()) / 1000L);
} else {
-timeIdle = (int) ((timeNow -
session.getThisAccessedTime()) / 1000L);
+timeIdle = (int) ((timeNow -
session.getThisAccessedTimeInternal()) / 1000L);
}
-if (timeIdle > maxIdleSwap && timeIdle > minIdleSwap) {
+if (timeIdle >= maxIdleSwap && timeIdle >= minIdleSwap) {
if (session.accessCount != null &&
session.accessCount.get() > 0) {
// Session is currently being accessed - skip it
@@ -981,11 +981,11 @@ public abstract class PersistentManagerB
synchronized (session) {
int timeIdle;
if (StandardSession.LAST_ACCESS_AT_START) {
-timeIdle = (int) ((timeNow -
session.getLastAccessedTime()) / 1000L);
+timeIdle = (int) ((timeNow -
session.getLastAccessedTimeInternal()) / 1000L);
} else {
-timeIdle = (int) ((timeNow -
session.getThisAccessedTime()) / 1000L);
+timeIdle = (int) ((timeNow -
session.getThisAccessedTimeInternal()) / 1000L);
}
-if (timeIdle > minIdleSwap) {
+if (timeIdle >= minIdleSwap) {
if (session.accessCount != null &&
session.accessCount.get() > 0) {
// Session is currently being accessed - skip it
@@ -1027,7 +1027,7 @@ public abstract class PersistentManagerB
synchronized (session) {
if (!session.isValid())
continue;
-long lastAccessedTime = session.getLastAccessedTime();
+long lastAccessedTime =
session.getLastAccessedTimeInternal();
Long persistedLastAccessedTime =
(Long)
session.getNote(PERSISTED_LAST_ACCESSED_TIME);
if (persistedLastAccessedTime != null &&
@@ -1035,11 +1035,11 @@ public abstract class PersistentManagerB
continue;
int timeIdle;
if (StandardSession.LAST_ACCESS_AT_START) {
-timeIdle = (int) ((timeNow -
session.getLastAccessedTime()) / 1000L);
+timeIdle = (int) ((timeNow -
session.getLastAccessedTimeInternal()) / 1000L);
} else {
-timeIdle = (int) ((timeNow -
session.getThisAccessedTime()) / 1000L);
+timeIdle = (int) ((timeNow -
session.getThisAccessedTimeInternal()) / 1000L);
}
-if (timeIdle > maxIdleBackup) {
+if (timeIdle >= maxIdleBackup) {
if (log.isDebugEnabled())
log.debug(sm.getString
("persistentManager.backupMaxIdle",
Modified:
tomcat/tc7.0.x/trunk/test/org/apache/catalina/session/TestPersistentManager.java
URL:
http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/test/org/apache
[Bug 56712] Off-by-one second errors in time calculations in PersistenceManager
https://issues.apache.org/bugzilla/show_bug.cgi?id=56712 Konstantin Kolinko changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Konstantin Kolinko --- Fixed in Tomcat 7 by r1609924 and will be in 7.0.55 onwards. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1609926 - /tomcat/trunk/webapps/docs/changelog.xml
Author: kkolinko Date: Sat Jul 12 14:29:55 2014 New Revision: 1609926 URL: http://svn.apache.org/r1609926 Log: Improve changelog message: be more specific on the scope of the change. Modified: tomcat/trunk/webapps/docs/changelog.xml Modified: tomcat/trunk/webapps/docs/changelog.xml URL: http://svn.apache.org/viewvc/tomcat/trunk/webapps/docs/changelog.xml?rev=1609926&r1=1609925&r2=1609926&view=diff == --- tomcat/trunk/webapps/docs/changelog.xml (original) +++ tomcat/trunk/webapps/docs/changelog.xml Sat Jul 12 14:29:55 2014 @@ -80,7 +80,8 @@ -56709: Fix property name. Submitted by Robert Kish. (remm) +56709: Fix system property name in a log message. Submitted +by Robert Kish. (remm) - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[GUMP@vmgump]: Project tomcat-trunk-test-bio (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-bio 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-bio : Tomcat 8.x, a web server implementing the Java Servlet 3.1, ... Full details are available at: http://vmgump.apache.org/gump/public/tomcat-trunk/tomcat-trunk-test-bio/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-BIO -INFO- Project Reports in: /srv/gump/public/workspace/tomcat-trunk/output/test-tmp-BIO/logs The following work was performed: http://vmgump.apache.org/gump/public/tomcat-trunk/tomcat-trunk-test-bio/gump_work/build_tomcat-trunk_tomcat-trunk-test-bio.html Work Name: build_tomcat-trunk_tomcat-trunk-test-bio (Type: Build) Work ended in a state of : Failed Elapsed: 22 mins 27 secs Command Line: /usr/lib/jvm/java-7-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.12-SNAPSHOT.jar -Dobjenesis.jar=/srv/gump/public/workspace/objenesis/main/target/objenesis-2.2-SNAPSHOT.jar -Dtest.reports=output/logs-BIO -Dtomcat-native.tar.gz=/srv/gump/public/workspace/apache-commons/daemon/dist/bin/commons-daemon-20140712-native-src.tar.gz -Dexamples.sources.skip=true -Djdt.jar=/srv/gump/packages/eclipse/plugins/P20140317-1600/ecj-P20140317-1600.jar -Dcommons-daemon.jar=/srv/gump/public/workspace/apache-commons/daemon/dist/commons-daemon-20140712.jar -Dcommons-daemon.native.src.tgz=/srv/gump/public/workspace/apache-commons/daemon/dist/bin/commons-daemon-20140712-native-src.tar.gz -Dtest.temp=output/test-tmp-BIO -Dtest.accesslog=true -Dexecute.test.nio=false -Dexecute.test.apr=false -Dexecute.test.bio=true -Dexecute.test.n io2=false -Deasymock.jar=/srv/gump/public/workspace/easymock/easymock/target/easymock-3.3-SNAPSHOT.jar -Dhamcrest.jar=/srv/gump/public/workspace/hamcrest/hamcrest-java/build/hamcrest-core-20140712.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-7-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/servle t-api.jar:/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/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/output/build/lib/catalina-tribes.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/catalina-ha.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/tomcat-api.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/tomcat-jni.jar:/srv/gump/public/workspace/tomcat -trunk/output/build/lib/tomcat-spdy.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/tomcat-util.
buildbot success in ASF Buildbot on tomcat-7-trunk
The Buildbot has detected a restored build on builder tomcat-7-trunk while building ASF Buildbot. Full details are available at: http://ci.apache.org/builders/tomcat-7-trunk/builds/182 Buildbot URL: http://ci.apache.org/ Buildslave for this Build: bb-vm_ubuntu Build Reason: scheduler Build Source Stamp: [branch tomcat/tc7.0.x/trunk] 1609924 Blamelist: kkolinko Build succeeded! sincerely, -The Buildbot - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 56713] New: Limit time that incoming request waits while webapp is reloading
https://issues.apache.org/bugzilla/show_bug.cgi?id=56713 Bug ID: 56713 Summary: Limit time that incoming request waits while webapp is reloading Product: Tomcat 8 Version: 8.0.9 Hardware: PC Status: NEW Severity: normal Priority: P2 Component: Catalina Assignee: dev@tomcat.apache.org Reporter: knst.koli...@gmail.com (Originally raised in bug 56710) There is an old feature that when web application is being reloaded, any incoming requests for that application are paused until reload completes. This feature dates back to Tomcat 4.1.x or earlier. See also bug 53024 for fixing (reimplementing) this feature in Tomcat 7. The waiting loop is implemented in CoyoteAdapter.postParseRequest(). While this feature is useful, the wait time shall not be infinite. Questions: (1) How long is the allowed wait time? (2) What to do if wait time expires? (3) What to do if Connector state changes, e.g Tomcat shuts down? Regarding (1): --- a) I thought that maybe "connectionTimeout" of a Connector is the good time to wait. b) Make it configurable on Host? c) Make it configurable on Context? d) Hard-code something? There are caveats for a): - There may be several Connectors in the same Service with different value for this attribute. - For an AJP connector this attribute is "-1" by default. Regarding (2): --- I think the best would be to unregister that context in the Mapper and let whatever other (ROOT) application there to handle the request. The ROOT application may respond with 503, 404, 302 or whatever is suitable. (Rejecting the request in CoyoteAdapter would be unfriendly, as it happens at a lower level and there is no ErrorReportValve to render an error page. The en-user will see an empty page). I think this needs update to the Mapper API. There will be race condition between this forced de-registration of context, and its re-registration after successful startup. To avoid it, a) MapperListener shall notify Mapper that the context has been paused. The Mapper shall remember the "paused" state. b) The forced de-registration shall be a separate method in the Mapper and it shall check the "paused" state of a context before removing it. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 56710] IllegalStateException: The resources may not be accessed during webapp reload
https://issues.apache.org/bugzilla/show_bug.cgi?id=56710 --- Comment #4 from Konstantin Kolinko --- (In reply to Mark Thomas from comment #3) > (In reply to Konstantin Kolinko from comment #2) > > (In reply to Remy Maucherat from comment #1) > > > It is not a good idea (...) > > > > Ack, but some people find it useful. See bug 53024 that asked for it. > > This was not a feature reuqets in bug 53024. For as long as I cam remember > (so back to Tomcat 4.1.x) the intended behaviour has been for the thread to > wait while the context reloads. I filed the wait time issue as bug 56713. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [GUMP@vmgump]: Project tomcat-trunk-test-bio (in module tomcat-trunk) failed
2014-07-11 0:53 GMT+04:00 Felix Schumacher : > > > On 10. Juli 2014 10:13:17 MESZ, Konstantin Kolinko > wrote: >>2014-07-10 7:02 GMT+04:00 Bill Barker : >>> 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-bio has an issue affecting its community >>integration. >>> This issue affects 1 projects, >>> and has been outstanding for 6 runs. >>> 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-bio : Tomcat 8.x, a web server implementing >>the Java Servlet 3.1, >>> ... >>> >>> >>> Full details are available at: >>> >>http://vmgump.apache.org/gump/public/tomcat-trunk/tomcat-trunk-test-bio/index.html >>> >> >>Test org.apache.catalina.session.TestPersistentManager FAILED >> >>[[[ >>Testsuite: org.apache.catalina.session.TestPersistentManager >>Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 2.868 >>sec >>- Standard Error - >>10-Jul-2014 02:51:45.769 INFO [main] >>org.apache.coyote.AbstractProtocol.init Initializing ProtocolHandler >>["http-bio-127.0.0.1-auto-1"] >>10-Jul-2014 02:51:45.811 INFO [main] >>org.apache.catalina.core.StandardService.startInternal Starting >>service Tomcat >>10-Jul-2014 02:51:45.822 INFO [main] >>org.apache.catalina.core.StandardEngine.startInternal Starting Servlet >>Engine: Apache Tomcat/8.0.10-dev >>10-Jul-2014 02:51:46.116 INFO [main] >>org.apache.coyote.AbstractProtocol.start Starting ProtocolHandler >>["http-bio-127.0.0.1-auto-1-45846"] >>10-Jul-2014 02:51:47.503 INFO [main] >>org.apache.coyote.AbstractProtocol.pause Pausing ProtocolHandler >>["http-bio-127.0.0.1-auto-1-45846"] >>10-Jul-2014 02:51:47.505 INFO [main] >>org.apache.catalina.core.StandardService.stopInternal Stopping service >>Tomcat >>10-Jul-2014 02:51:47.526 INFO [main] >>org.apache.coyote.AbstractProtocol.stop Stopping ProtocolHandler >>["http-bio-127.0.0.1-auto-1-45846"] >>10-Jul-2014 02:51:47.527 INFO [main] >>org.apache.coyote.AbstractProtocol.destroy Destroying ProtocolHandler >>["http-bio-127.0.0.1-auto-1-45846"] >>- --- >> >>Testcase: backsUpOnce took 2.848 sec >>FAILED >>expected:<[4AC2976017F91624B46E2D7D78F6ABE8]> but was:<[]> >>junit.framework.AssertionFailedError: >>expected:<[4AC2976017F91624B46E2D7D78F6ABE8]> but was:<[]> >>at >>org.apache.catalina.session.TestPersistentManager.backsUpOnce(TestPersistentManager.java:88) >>]]] > We might have to bump up the sleep time a little bit (one second now). > PersistentManager will save the session only if it seems to be older than one > second. > For a record: The cause for that behaviour was that there was a race condition between a) Thread.sleep(1000) call in test b) Request.recycle() -> session.endAccess() call in Tomcat that processed the HTTP request If b) occurred later than a) then after the sleep() call the idle time of the session was less than one second. Thus the session was not eligible to be written out by PersistenceManager. I fixed this in r1609924 by waiting until session activity counter reaches zero. (TestPersistentManager.waitWhileSessionIsActive() method). Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
