[GUMP@vmgump-vm3]: Project tomcat-trunk-test-apr (in module tomcat-trunk) failed

[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-apr has an issue affecting its community integration.
This issue affects 1 projects,
 and has been outstanding for 9 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-apr :  Tomcat 9.x, a web server implementing the Java 
Servlet 4.0,
...


Full details are available at:
http://vmgump-vm3.apache.org/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 bnd exists, no need to add for property bndlib.jar.
 -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-vm3.apache.org/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: 27 mins 48 secs
Command Line: /usr/lib/jvm/java-8-oracle/bin/java -Djava.awt.headless=true 
-Dbuild.sysclasspath=only -Dsun.zip.disableMemoryMapping=true 
org.apache.tools.ant.Main -Dgump.merge=/srv/gump/public/gump/work/merge.xml 
-Dbase.path=/srv/gump/public/workspace/tomcat-trunk/tomcat-build-libs 
-Dbnd.jar=/srv/gump/packages/bnd/bnd-4.0.0/biz.aQute.bnd-4.0.0.jar 
-Dsaaj-api.jar=/srv/gump/packages/saaj-api/saaj-api-1.3.5.jar 
-Djaxrpc-lib.jar=/srv/gump/packages/jaxrpc/geronimo-spec-jaxrpc-1.1-rc4.jar 
-Dtest.temp=output/test-tmp-APR 
-Djunit.jar=/srv/gump/public/workspace/junit/target/junit-4.13-SNAPSHOT.jar 
-Djava.net.preferIPv4Stack=/srv/gump/public/workspace/tomcat-trunk/true 
-Dobjenesis.jar=/srv/gump/public/workspace/objenesis/main/target/objenesis-3.1-SNAPSHOT.jar
 -Dexamples.sources.skip=true 
-Dcommons-daemon.jar=/srv/gump/public/workspace/apache-commons/daemon/target/commons-daemon-1.1.1-SNAPSHOT.jar
 
-Dtest.openssl.path=/srv/gump/public/workspace/openssl-master/dest-20190516/bin/openssl
 -Dexecute.
 test.nio=false 
-Dhamcrest.jar=/srv/gump/packages/hamcrest/hamcrest-core-1.3.jar 
-Dbndlib.jar=/srv/gump/packages/bnd/bndlib-4.0.0/biz.aQute.bndlib-4.0.0.jar 
-Dexecute.test.apr=true 
-Dwsdl4j-lib.jar=/srv/gump/packages/wsdl4j/wsdl4j-1.6.3.jar 
-Dtest.reports=output/logs-APR -Dexecute.test.nio2=false 
-Djdt.jar=/srv/gump/packages/eclipse/plugins/R-4.10-201812060815/ecj-4.10.jar 
-Dtest.apr.loc=/srv/gump/public/workspace/tomcat-native-trunk/dest-20190516/lib 
-Dtest.relaxTiming=true -Dtest.excludePerformance=true -Dtest.accesslog=true 
-Deasymock.jar=/srv/gump/public/workspace/easymock/core/target/easymock-4.1-SNAPSHOT.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/outpu

[Bug 63441] Changes made to newly created session not replicated

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=63441

--- Comment #1 from Mark Thomas  ---
Just a note that the problem statement is correct but the analysis is not. I'm
still digging into what is going wrong.

-- 
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

[GitHub] [tomcat] ChristopherSchultz commented on issue #162: Add support for same-site cookie attribute

[GitBox]

ChristopherSchultz commented on issue #162: Add support for same-site cookie 
attribute
URL: https://github.com/apache/tomcat/pull/162#issuecomment-492771440
 
 
   +1 for making `SameSiteCookies` into an `enum`. It will also protect against 
a malicious application causing Tomcat to emit a broken/malicious HTTP response 
header.


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

buildbot success in on tomcat-trunk

[buildbot]

The Buildbot has detected a restored build on builder tomcat-trunk while 
building tomcat. Full details are available at:
https://ci.apache.org/builders/tomcat-trunk/builds/4358

Buildbot URL: https://ci.apache.org/

Buildslave for this Build: silvanus_ubuntu

Build Reason: The AnyBranchScheduler scheduler named 'on-tomcat-commit' 
triggered this build
Build Source Stamp: [branch master] 76830b172770aeca0d99162b50b948c7b5f3cd7a
Blamelist: remm 

Build succeeded!

Sincerely,
 -The Buildbot




-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[tomcat] branch master updated: Fix javadoc

[remm]

This is an automated email from the ASF dual-hosted git repository.

remm pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/tomcat.git


The following commit(s) were added to refs/heads/master by this push:
 new 76830b1  Fix javadoc
76830b1 is described below

commit 76830b172770aeca0d99162b50b948c7b5f3cd7a
Author: remm 
AuthorDate: Wed May 15 20:05:02 2019 +0200

Fix javadoc
---
 java/org/apache/tomcat/util/net/NioEndpoint.java | 1 +
 1 file changed, 1 insertion(+)

diff --git a/java/org/apache/tomcat/util/net/NioEndpoint.java 
b/java/org/apache/tomcat/util/net/NioEndpoint.java
index 5633c92..8f87f06 100644
--- a/java/org/apache/tomcat/util/net/NioEndpoint.java
+++ b/java/org/apache/tomcat/util/net/NioEndpoint.java
@@ -651,6 +651,7 @@ public class NioEndpoint extends 
AbstractJsseEndpoint
  * Registers a newly created socket with the poller.
  *
  * @param socketThe newly created socket
+ * @param socketWrapper The socket wrapper
  */
 public void register(final NioChannel socket, final NioSocketWrapper 
socketWrapper) {
 socketWrapper.interestOps(SelectionKey.OP_READ);//this is what 
OP_REGISTER turns into.


-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

buildbot failure in on tomcat-trunk

[buildbot]

The Buildbot has detected a new failure on builder tomcat-trunk while building 
tomcat. Full details are available at:
https://ci.apache.org/builders/tomcat-trunk/builds/4357

Buildbot URL: https://ci.apache.org/

Buildslave for this Build: silvanus_ubuntu

Build Reason: The AnyBranchScheduler scheduler named 'on-tomcat-commit' 
triggered this build
Build Source Stamp: [branch master] 7b7442d87e08f0bd1134e7872e7cd15bf3509b64
Blamelist: remm 

BUILD FAILED: failed compile

Sincerely,
 -The Buildbot




-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[tomcat] branch master updated: Remove bad looking fields access

[remm]

This is an automated email from the ASF dual-hosted git repository.

remm pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/tomcat.git


The following commit(s) were added to refs/heads/master by this push:
 new 7b7442d  Remove bad looking fields access
7b7442d is described below

commit 7b7442d87e08f0bd1134e7872e7cd15bf3509b64
Author: remm 
AuthorDate: Wed May 15 19:51:48 2019 +0200

Remove bad looking fields access

getSelectorPool public -> protected, since it's only used in the socket
wrapper. Move NIO socket wrapper init to setSocketOptions since the
poller is now known.
---
 java/org/apache/tomcat/util/net/Nio2Endpoint.java |  7 -
 java/org/apache/tomcat/util/net/NioEndpoint.java  | 35 ++-
 2 files changed, 28 insertions(+), 14 deletions(-)

diff --git a/java/org/apache/tomcat/util/net/Nio2Endpoint.java 
b/java/org/apache/tomcat/util/net/Nio2Endpoint.java
index ee6a9a1..613f057 100644
--- a/java/org/apache/tomcat/util/net/Nio2Endpoint.java
+++ b/java/org/apache/tomcat/util/net/Nio2Endpoint.java
@@ -349,6 +349,11 @@ public class Nio2Endpoint extends 
AbstractJsseEndpoint getNioChannels() {
+return nioChannels;
+}
+
+
 @Override
 protected NetworkChannel getServerSocket() {
 return serverSock;
@@ -555,7 +560,7 @@ public class Nio2Endpoint extends 
AbstractJsseEndpoint() {
diff --git a/java/org/apache/tomcat/util/net/NioEndpoint.java 
b/java/org/apache/tomcat/util/net/NioEndpoint.java
index f31a508..5633c92 100644
--- a/java/org/apache/tomcat/util/net/NioEndpoint.java
+++ b/java/org/apache/tomcat/util/net/NioEndpoint.java
@@ -358,11 +358,21 @@ public class NioEndpoint extends 
AbstractJsseEndpoint
 
 // -- Protected Methods
 
-public NioSelectorPool getSelectorPool() {
+protected NioSelectorPool getSelectorPool() {
 return selectorPool;
 }
 
 
+protected SynchronizedStack getNioChannels() {
+return nioChannels;
+}
+
+
+protected Poller getPoller() {
+return poller;
+}
+
+
 protected CountDownLatch getStopLatch() {
 return stopLatch;
 }
@@ -407,7 +417,13 @@ public class NioEndpoint extends 
AbstractJsseEndpoint
 channel.setIOChannel(socket);
 channel.reset();
 }
-poller.register(channel);
+NioSocketWrapper socketWrapper = new NioSocketWrapper(channel, 
this);
+channel.setSocketWrapper(socketWrapper);
+socketWrapper.setReadTimeout(getConnectionTimeout());
+socketWrapper.setWriteTimeout(getConnectionTimeout());
+
socketWrapper.setKeepAliveLeft(NioEndpoint.this.getMaxKeepAliveRequests());
+socketWrapper.setSecure(isSSLEnabled());
+poller.register(channel, socketWrapper);
 } catch (Throwable t) {
 ExceptionUtils.handleThrowable(t);
 try {
@@ -636,14 +652,7 @@ public class NioEndpoint extends 
AbstractJsseEndpoint
  *
  * @param socketThe newly created socket
  */
-public void register(final NioChannel socket) {
-NioSocketWrapper socketWrapper = new NioSocketWrapper(socket, 
NioEndpoint.this);
-socket.setSocketWrapper(socketWrapper);
-socketWrapper.setPoller(this);
-socketWrapper.setReadTimeout(getConnectionTimeout());
-socketWrapper.setWriteTimeout(getConnectionTimeout());
-
socketWrapper.setKeepAliveLeft(NioEndpoint.this.getMaxKeepAliveRequests());
-socketWrapper.setSecure(isSSLEnabled());
+public void register(final NioChannel socket, final NioSocketWrapper 
socketWrapper) {
 socketWrapper.interestOps(SelectionKey.OP_READ);//this is what 
OP_REGISTER turns into.
 PollerEvent r = null;
 if (eventCache != null) {
@@ -1016,8 +1025,8 @@ public class NioEndpoint extends 
AbstractJsseEndpoint
 
 private final NioSelectorPool pool;
 private final SynchronizedStack nioChannels;
+private final Poller poller;
 
-private Poller poller = null;
 private int interestOps = 0;
 private CountDownLatch readLatch = null;
 private CountDownLatch writeLatch = null;
@@ -1028,12 +1037,12 @@ public class NioEndpoint extends 
AbstractJsseEndpoint
 public NioSocketWrapper(NioChannel channel, NioEndpoint endpoint) {
 super(channel, endpoint);
 pool = endpoint.getSelectorPool();
+nioChannels = endpoint.getNioChannels();
+poller = endpoint.getPoller();
 socketBufferHandler = channel.getBufHandler();
-nioChannels = endpoint.nioChannels;
 }
 
 public Poller getPoller() { return poller; }
-public void setPoller(Poller poller) { this.poller = poller; }
 public int interestOps() { return interestOps; }
 publi

[Bug 63389] Enable Servlet Warmup for Containerization

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=63389

--- Comment #9 from Mark Thomas  ---
Since this is synchronous, we can use the exit code to signal success or
failure.

-- 
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 63389] Enable Servlet Warmup for Containerization

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=63389

--- Comment #8 from Christopher Schultz  ---
I have a slight objection to the term "warmup" being used, here.

Can we call it something else?

Nothing brilliant comes to mind.

"updown"?
"startstop"?
"launchtest"?

Perhaps such a special launch command could provide some output such as "OK" if
everything is okay, or some kind of error words/codes which describe what
happened. For example, if one of the connectors failed to start properly, we
could report that failure. Perhaps the same for any configured auto-deploy
application that failed to start cleanly.

-- 
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 63441] New: Changes made to newly created session not replicated

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=63441

Bug ID: 63441
   Summary: Changes made to newly created session not replicated
   Product: Tomcat 9
   Version: 9.0.x
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: Cluster
  Assignee: dev@tomcat.apache.org
  Reporter: ma...@apache.org
  Target Milestone: -

Reviewing the DeltaSession code I noticed that, for a newly created
DeltaSession, that a DeltaRequest is not created until the request is
completed.

That means any changes made to a newly created session in the request where the
session is created cannot be replicated as there is no DeltaRequest to record
the changes. I have confirmed this behaviour on my local test cluster.

The fix should not be too tricky and should tie in with the changes planned to
address bug 62841.

-- 
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 63362] GlobalRequestProcessor statistics in MBean does not count Websocket communication

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=63362

--- Comment #4 from marek.gregor  ---
Our code has implementation of feeding metrics with sent/received number of
bytes from web server. Generally the metrics is important to check amount of
data transferred  from/to web application in elegant way - that means we do not
need implement counting by ourselves for every API endpoint in our app (HTTP or
Websocket). We had migrated our app from Wildfly, which counts Websocket + HTTP
communication together correctly, but I understand that this is not feature
crucial to be present there. So we are ok also with decision, that the counting
will be implemented by ourselves - albeit take the numbers collected by Tomcat
is the easier option ;)

-- 
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 63362] GlobalRequestProcessor statistics in MBean does not count Websocket communication

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=63362

--- Comment #3 from Remy Maucherat  ---
I guess it would have to be counted in the SocketWrapper, but is that kind of
metric useful at all these days ? We know/expect it will be some random large
amount, and that's all it will say. At the same time, it's slightly annoying to
collect.

Access logging should give a much better idea on what's going on.

Personally, I'd rather leave it the way it is now and remove it in Tomcat.next.

-- 
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 63237] Consider processing mbeans-descriptors.xml at compile time

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=63237

--- Comment #7 from Mark Thomas  ---
Has the ability to disable JMX made this enhancement request obsolete?

-- 
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 63362] GlobalRequestProcessor statistics in MBean does not count Websocket communication

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=63362

--- Comment #2 from Mark Thomas  ---
What is the request here? Are new statistics required? Are changes to how the
existing statistics are calculated required? Specifics would help us to
evaluate the request.

The current statistics were implemented when Tomcat only implemented HTTP/1.1
(and 1.0 and 0.9). Now Tomcat supports WebSocket, HTTP/2 and generic HTTP/1/
upgrade.

Do stats need to be broken down by protocol?

Is the 'right' solution something that needs to wait for major refactoring in
Tomcat 10? (Or is there something useful we can do now for 9.0.x?)

-- 
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

buildbot success in on tomcat-trunk

[buildbot]

The Buildbot has detected a restored build on builder tomcat-trunk while 
building tomcat. Full details are available at:
https://ci.apache.org/builders/tomcat-trunk/builds/4356

Buildbot URL: https://ci.apache.org/

Buildslave for this Build: silvanus_ubuntu

Build Reason: The AnyBranchScheduler scheduler named 'on-tomcat-commit' 
triggered this build
Build Source Stamp: [branch master] bd2ed0f7e83ff2a856ee51dd94ae6f756f40aefc
Blamelist: remm 

Build succeeded!

Sincerely,
 -The Buildbot




-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Registry instance aligned on Tomcat/Server lifecycle?

[Mark Thomas]

On 15/05/2019 13:48, Romain Manni-Bucau wrote:
> Oki, I can hear it is a lot of work for a small gain, however, at least,
> it is possible to ensure the disable method is re-callable (actually
> setting the registry instance) and that there is an enableRegistry()
> method. It is ok and cheap IMO to have a global reference counting and
> force it to be == 0 to ensure we don't change the setup if a server is
> already running.
> 
> Use case is to be able to have:
> 
> lifecycle()
>   configureJMX();
>   startServer();
>   stopServer();
> 
> can call lifecycle twice with the configuration of configureJMX being
> different.
> 
> High level it looks cheaper and solves my current issue with the disable
> method too.
> 
> Does it sound better?

I'm actually not sure. It is the transition from enabled to disabled
that bothers me and ensuring that everything that should be unregistered
is unregistered. I'm wondering if it isn't just simpler to implement the
one registry per Server idea.

Mark


> 
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github
>  | LinkedIn
>  | Book
> 
> 
> 
> Le mer. 15 mai 2019 à 13:52, Mark Thomas  > a écrit :
> 
> On 15/05/2019 10:35, Romain Manni-Bucau wrote:
> > 9.0.20 got a disableRegistry method in Registry class (for JMX server
> > interaction),
> > I wonder if it is possible to enhance it a bit to make it instance
> bound
> > to the server instead of being global.
> >
> > It would enable to start/stop/restart servers potentially
> > deactivating/activating JMX without issues if multiple tomcat
> instances
> > are started in the same JVM.
> >
> > wdyt?
> 
> Currently all registrations go through a singleton Registry instance.
> 
> The process to obtain a Registry instance would need to be changed to
> obtain one per Server. That looks to be doable (there look to be just
> over 40 instances of calling the getRegistry() method). We might even be
> able to use the existing key parameter (once we restore the key related
> plumbing we only just removed).
> 
> How much user demand has there been for making this more granular? So
> far, the only requests I have seen have been from users wanting to
> disable JMX registration completely for Tomcat objects.
> 
> 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

[GitHub] [tomcat] markt-asf commented on issue #162: Add support for same-site cookie attribute

[GitBox]

markt-asf commented on issue #162: Add support for same-site cookie attribute
URL: https://github.com/apache/tomcat/pull/162#issuecomment-492644191
 
 
   Thanks for the updates. I have a few comments on the updated PR:
- You can reduce the code duplication by using CookieProcessorBase
- SameSiteCookies looks to be a good candidate for an Enum unless I am 
missing something
- Feel free to add a changelog entry for this


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [tomcat] branch master updated: Fix build

[Rémy Maucherat]

On Wed, May 15, 2019 at 2:25 PM Mark Thomas  wrote:

> On 15/05/2019 12:56, r...@apache.org wrote:
> > This is an automated email from the ASF dual-hosted git repository.
> >
> > remm pushed a commit to branch master
> > in repository https://gitbox.apache.org/repos/asf/tomcat.git
> >
> >
> > The following commit(s) were added to refs/heads/master by this push:
> >  new 4691266  Fix build
> > 4691266 is described below
> >
> > commit 4691266ee48f084e0698ef0233036c0089492248
> > Author: remm 
> > AuthorDate: Wed May 15 13:56:42 2019 +0200
> >
> > Fix build
> >
> > Maybe it isn't such a good idea to remove throws IOException ... I
> can
> > add it back depending on the feedback, even if it serves no purpose.
>
> My current thinking is that I like it. Close the socket and handle
> (i.e.log) the potential exception in a single place. It isn't as if the
> calling code is going to do anything different depending on whether the
> socket closed cleanly or not.
>

Ok. I'm pretty sure I had removed it in the previous refactoring, but I put
it back in before commit to avoid breaking the API. This time I got lead
from one change to the other and I did make some changes to doClose, so I
left it in.

I revisited the close issue again along with the multiple pollers feature,
since I had looked recently at the ApacheCon 2017 presentation from Huxing
("The Challenges Tomcat Faces in High Throughput Production Systems"), and
I understood that:
- Robust close and recycle is good (no putting channel twice in the stack
...)
- More than one poller helps mess things up
The bugs got fixed some time ago of course (and maybe refixed some more),
but ultimately it is hard to verify and I preferred to remove all that
stuff since it wasn't not needed.

Also it should do item 3 of tomcat-next, except the tracing part.

Rémy


>
> Mark
>
>
> > ---
> >  java/org/apache/coyote/http2/Http2UpgradeHandler.java   | 6
> +-
> >  .../apache/tomcat/websocket/server/WsRemoteEndpointImplServer.java  | 2
> +-
> >  2 files changed, 2 insertions(+), 6 deletions(-)
> >
> > diff --git a/java/org/apache/coyote/http2/Http2UpgradeHandler.java
> b/java/org/apache/coyote/http2/Http2UpgradeHandler.java
> > index 134e501..585a0e5 100644
> > --- a/java/org/apache/coyote/http2/Http2UpgradeHandler.java
> > +++ b/java/org/apache/coyote/http2/Http2UpgradeHandler.java
> > @@ -1066,11 +1066,7 @@ class Http2UpgradeHandler extends AbstractStream
> implements InternalHttpUpgradeH
> >  // longer required (also notifies any threads waiting for
> allocations).
> >  stream.receiveReset(Http2Error.CANCEL.getCode());
> >  }
> > -try {
> > -socketWrapper.close();
> > -} catch (IOException ioe) {
> > -log.debug(sm.getString("upgradeHandler.socketCloseFailed"),
> ioe);
> > -}
> > +socketWrapper.close();
> >  }
> >
> >
> > diff --git
> a/java/org/apache/tomcat/websocket/server/WsRemoteEndpointImplServer.java
> b/java/org/apache/tomcat/websocket/server/WsRemoteEndpointImplServer.java
> > index 301d25c..0cd91ef 100644
> > ---
> a/java/org/apache/tomcat/websocket/server/WsRemoteEndpointImplServer.java
> > +++
> b/java/org/apache/tomcat/websocket/server/WsRemoteEndpointImplServer.java
> > @@ -220,7 +220,7 @@ public class WsRemoteEndpointImplServer extends
> WsRemoteEndpointImplBase {
> >  }
> >  try {
> >  socketWrapper.close();
> > -} catch (IOException e) {
> > +} catch (Exception e) {
> >  if (log.isInfoEnabled()) {
> >  
> > log.info(sm.getString("wsRemoteEndpointServer.closeFailed"),
> e);
> >  }
> >
> >
> > -
> > 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
>
>

Re: Registry instance aligned on Tomcat/Server lifecycle?

[Romain Manni-Bucau]

Oki, I can hear it is a lot of work for a small gain, however, at least, it
is possible to ensure the disable method is re-callable (actually setting
the registry instance) and that there is an enableRegistry() method. It is
ok and cheap IMO to have a global reference counting and force it to be ==
0 to ensure we don't change the setup if a server is already running.

Use case is to be able to have:

lifecycle()
  configureJMX();
  startServer();
  stopServer();

can call lifecycle twice with the configuration of configureJMX being
different.

High level it looks cheaper and solves my current issue with the disable
method too.

Does it sound better?

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le mer. 15 mai 2019 à 13:52, Mark Thomas  a écrit :

> On 15/05/2019 10:35, Romain Manni-Bucau wrote:
> > 9.0.20 got a disableRegistry method in Registry class (for JMX server
> > interaction),
> > I wonder if it is possible to enhance it a bit to make it instance bound
> > to the server instead of being global.
> >
> > It would enable to start/stop/restart servers potentially
> > deactivating/activating JMX without issues if multiple tomcat instances
> > are started in the same JVM.
> >
> > wdyt?
>
> Currently all registrations go through a singleton Registry instance.
>
> The process to obtain a Registry instance would need to be changed to
> obtain one per Server. That looks to be doable (there look to be just
> over 40 instances of calling the getRegistry() method). We might even be
> able to use the existing key parameter (once we restore the key related
> plumbing we only just removed).
>
> How much user demand has there been for making this more granular? So
> far, the only requests I have seen have been from users wanting to
> disable JMX registration completely for Tomcat objects.
>
> Mark
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

Re: [tomcat] branch master updated: Fix build

[Mark Thomas]

On 15/05/2019 12:56, r...@apache.org wrote:
> This is an automated email from the ASF dual-hosted git repository.
> 
> remm pushed a commit to branch master
> in repository https://gitbox.apache.org/repos/asf/tomcat.git
> 
> 
> The following commit(s) were added to refs/heads/master by this push:
>  new 4691266  Fix build
> 4691266 is described below
> 
> commit 4691266ee48f084e0698ef0233036c0089492248
> Author: remm 
> AuthorDate: Wed May 15 13:56:42 2019 +0200
> 
> Fix build
> 
> Maybe it isn't such a good idea to remove throws IOException ... I can
> add it back depending on the feedback, even if it serves no purpose.

My current thinking is that I like it. Close the socket and handle
(i.e.log) the potential exception in a single place. It isn't as if the
calling code is going to do anything different depending on whether the
socket closed cleanly or not.

Mark


> ---
>  java/org/apache/coyote/http2/Http2UpgradeHandler.java   | 6 
> +-
>  .../apache/tomcat/websocket/server/WsRemoteEndpointImplServer.java  | 2 +-
>  2 files changed, 2 insertions(+), 6 deletions(-)
> 
> diff --git a/java/org/apache/coyote/http2/Http2UpgradeHandler.java 
> b/java/org/apache/coyote/http2/Http2UpgradeHandler.java
> index 134e501..585a0e5 100644
> --- a/java/org/apache/coyote/http2/Http2UpgradeHandler.java
> +++ b/java/org/apache/coyote/http2/Http2UpgradeHandler.java
> @@ -1066,11 +1066,7 @@ class Http2UpgradeHandler extends AbstractStream 
> implements InternalHttpUpgradeH
>  // longer required (also notifies any threads waiting for 
> allocations).
>  stream.receiveReset(Http2Error.CANCEL.getCode());
>  }
> -try {
> -socketWrapper.close();
> -} catch (IOException ioe) {
> -log.debug(sm.getString("upgradeHandler.socketCloseFailed"), ioe);
> -}
> +socketWrapper.close();
>  }
>  
>  
> diff --git 
> a/java/org/apache/tomcat/websocket/server/WsRemoteEndpointImplServer.java 
> b/java/org/apache/tomcat/websocket/server/WsRemoteEndpointImplServer.java
> index 301d25c..0cd91ef 100644
> --- a/java/org/apache/tomcat/websocket/server/WsRemoteEndpointImplServer.java
> +++ b/java/org/apache/tomcat/websocket/server/WsRemoteEndpointImplServer.java
> @@ -220,7 +220,7 @@ public class WsRemoteEndpointImplServer extends 
> WsRemoteEndpointImplBase {
>  }
>  try {
>  socketWrapper.close();
> -} catch (IOException e) {
> +} catch (Exception e) {
>  if (log.isInfoEnabled()) {
>  log.info(sm.getString("wsRemoteEndpointServer.closeFailed"), 
> e);
>  }
> 
> 
> -
> 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

[tomcat] branch master updated: Keep the try catch just in case

[remm]

This is an automated email from the ASF dual-hosted git repository.

remm pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/tomcat.git


The following commit(s) were added to refs/heads/master by this push:
 new bd2ed0f  Keep the try catch just in case
bd2ed0f is described below

commit bd2ed0f7e83ff2a856ee51dd94ae6f756f40aefc
Author: remm 
AuthorDate: Wed May 15 14:18:45 2019 +0200

Keep the try catch just in case
---
 java/org/apache/coyote/http2/Http2UpgradeHandler.java | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/java/org/apache/coyote/http2/Http2UpgradeHandler.java 
b/java/org/apache/coyote/http2/Http2UpgradeHandler.java
index 585a0e5..880d365 100644
--- a/java/org/apache/coyote/http2/Http2UpgradeHandler.java
+++ b/java/org/apache/coyote/http2/Http2UpgradeHandler.java
@@ -1066,7 +1066,11 @@ class Http2UpgradeHandler extends AbstractStream 
implements InternalHttpUpgradeH
 // longer required (also notifies any threads waiting for 
allocations).
 stream.receiveReset(Http2Error.CANCEL.getCode());
 }
-socketWrapper.close();
+try {
+socketWrapper.close();
+} catch (Exception e) {
+log.debug(sm.getString("upgradeHandler.socketCloseFailed"), e);
+}
 }
 
 


-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[tomcat] branch master updated: Fix build

[remm]

This is an automated email from the ASF dual-hosted git repository.

remm pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/tomcat.git


The following commit(s) were added to refs/heads/master by this push:
 new 4691266  Fix build
4691266 is described below

commit 4691266ee48f084e0698ef0233036c0089492248
Author: remm 
AuthorDate: Wed May 15 13:56:42 2019 +0200

Fix build

Maybe it isn't such a good idea to remove throws IOException ... I can
add it back depending on the feedback, even if it serves no purpose.
---
 java/org/apache/coyote/http2/Http2UpgradeHandler.java   | 6 +-
 .../apache/tomcat/websocket/server/WsRemoteEndpointImplServer.java  | 2 +-
 2 files changed, 2 insertions(+), 6 deletions(-)

diff --git a/java/org/apache/coyote/http2/Http2UpgradeHandler.java 
b/java/org/apache/coyote/http2/Http2UpgradeHandler.java
index 134e501..585a0e5 100644
--- a/java/org/apache/coyote/http2/Http2UpgradeHandler.java
+++ b/java/org/apache/coyote/http2/Http2UpgradeHandler.java
@@ -1066,11 +1066,7 @@ class Http2UpgradeHandler extends AbstractStream 
implements InternalHttpUpgradeH
 // longer required (also notifies any threads waiting for 
allocations).
 stream.receiveReset(Http2Error.CANCEL.getCode());
 }
-try {
-socketWrapper.close();
-} catch (IOException ioe) {
-log.debug(sm.getString("upgradeHandler.socketCloseFailed"), ioe);
-}
+socketWrapper.close();
 }
 
 
diff --git 
a/java/org/apache/tomcat/websocket/server/WsRemoteEndpointImplServer.java 
b/java/org/apache/tomcat/websocket/server/WsRemoteEndpointImplServer.java
index 301d25c..0cd91ef 100644
--- a/java/org/apache/tomcat/websocket/server/WsRemoteEndpointImplServer.java
+++ b/java/org/apache/tomcat/websocket/server/WsRemoteEndpointImplServer.java
@@ -220,7 +220,7 @@ public class WsRemoteEndpointImplServer extends 
WsRemoteEndpointImplBase {
 }
 try {
 socketWrapper.close();
-} catch (IOException e) {
+} catch (Exception e) {
 if (log.isInfoEnabled()) {
 log.info(sm.getString("wsRemoteEndpointServer.closeFailed"), 
e);
 }


-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Registry instance aligned on Tomcat/Server lifecycle?

[Mark Thomas]

On 15/05/2019 10:35, Romain Manni-Bucau wrote:
> 9.0.20 got a disableRegistry method in Registry class (for JMX server
> interaction),
> I wonder if it is possible to enhance it a bit to make it instance bound
> to the server instead of being global.
> 
> It would enable to start/stop/restart servers potentially
> deactivating/activating JMX without issues if multiple tomcat instances
> are started in the same JVM.
> 
> wdyt?

Currently all registrations go through a singleton Registry instance.

The process to obtain a Registry instance would need to be changed to
obtain one per Server. That looks to be doable (there look to be just
over 40 instances of calling the getRegistry() method). We might even be
able to use the existing key parameter (once we restore the key related
plumbing we only just removed).

How much user demand has there been for making this more granular? So
far, the only requests I have seen have been from users wanting to
disable JMX registration completely for Tomcat objects.

Mark

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

buildbot failure in on tomcat-trunk

[buildbot]

The Buildbot has detected a new failure on builder tomcat-trunk while building 
tomcat. Full details are available at:
https://ci.apache.org/builders/tomcat-trunk/builds/4355

Buildbot URL: https://ci.apache.org/

Buildslave for this Build: silvanus_ubuntu

Build Reason: The AnyBranchScheduler scheduler named 'on-tomcat-commit' 
triggered this build
Build Source Stamp: [branch master] c2d6278b339384f9e6679b718ceb861d0329be1d
Blamelist: remm 

BUILD FAILED: failed compile

Sincerely,
 -The Buildbot




-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[tomcat] branch master updated: Refactor socket wrapper close

[remm]

This is an automated email from the ASF dual-hosted git repository.

remm pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/tomcat.git


The following commit(s) were added to refs/heads/master by this push:
 new c2d6278  Refactor socket wrapper close
c2d6278 is described below

commit c2d6278b339384f9e6679b718ceb861d0329be1d
Author: remm 
AuthorDate: Wed May 15 13:40:49 2019 +0200

Refactor socket wrapper close

Redo again close processing using an atomic boolean and a doClose method
that subclasses will implement, with a guarantee that it will be run
only once. Improve slightly NIO close with respect to recycling the
NioChannel. APR will use atomic boolean object for locking instead of
closedLock.
Once the NIOx socket wrapper is closed, the channel will now be replaced
by a dummy closed channel. Also all the buffers linked will be replaced
with empty ones.
---
 java/org/apache/tomcat/util/net/AprEndpoint.java   | 72 --
 java/org/apache/tomcat/util/net/Nio2Channel.java   | 85 +-
 java/org/apache/tomcat/util/net/Nio2Endpoint.java  | 37 --
 java/org/apache/tomcat/util/net/NioChannel.java| 52 +++--
 java/org/apache/tomcat/util/net/NioEndpoint.java   | 74 ---
 .../tomcat/util/net/SocketBufferHandler.java   |  6 ++
 .../apache/tomcat/util/net/SocketWrapperBase.java  | 32 +++-
 java/org/apache/tomcat/util/net/WriteBuffer.java   |  3 +
 webapps/docs/changelog.xml | 12 +++
 9 files changed, 254 insertions(+), 119 deletions(-)

diff --git a/java/org/apache/tomcat/util/net/AprEndpoint.java 
b/java/org/apache/tomcat/util/net/AprEndpoint.java
index df85e6c..9551b7e 100644
--- a/java/org/apache/tomcat/util/net/AprEndpoint.java
+++ b/java/org/apache/tomcat/util/net/AprEndpoint.java
@@ -494,11 +494,7 @@ public class AprEndpoint extends 
AbstractEndpoint implements SNICallB
 running = false;
 poller.stop();
 for (SocketWrapperBase socketWrapper : connections.values()) 
{
-try {
-socketWrapper.close();
-} catch (IOException e) {
-// Ignore
-}
+socketWrapper.close();
 }
 long waitLeft = 1;
 while (waitLeft > 0 &&
@@ -2150,9 +2146,6 @@ public class AprEndpoint extends 
AbstractEndpoint implements SNICallB
 
 private final ByteBuffer sslOutputBuffer;
 
-private final Object closedLock = new Object();
-private volatile boolean closed = false;
-
 // This field should only be used by Poller#run()
 private int pollerFlags = 0;
 
@@ -2246,7 +2239,7 @@ public class AprEndpoint extends 
AbstractEndpoint implements SNICallB
 
 
 private int fillReadBuffer(boolean block, ByteBuffer to) throws 
IOException {
-if (closed) {
+if (isClosed()) {
 throw new IOException(sm.getString("socket.apr.closed", 
getSocket()));
 }
 
@@ -2343,15 +2336,18 @@ public class AprEndpoint extends 
AbstractEndpoint implements SNICallB
 
 
 @Override
-public void close() {
-getEndpoint().getHandler().release(this);
-synchronized (closedLock) {
-// APR typically crashes if the same socket is closed twice so
-// make sure that doesn't happen.
-if (closed) {
-return;
+protected void doClose() {
+try {
+getEndpoint().getHandler().release(this);
+} catch (Throwable e) {
+ExceptionUtils.handleThrowable(e);
+if (log.isDebugEnabled()) {
+log.error(sm.getString("endpoint.debug.handlerRelease"), 
e);
 }
-closed = true;
+}
+socketBufferHandler = SocketBufferHandler.EMPTY;
+nonBlockingWriteBuffer.clear();
+synchronized (closed) {
 if (sslOutputBuffer != null) {
 ByteBufferUtils.cleanDirectBuffer(sslOutputBuffer);
 }
@@ -2361,14 +2357,6 @@ public class AprEndpoint extends 
AbstractEndpoint implements SNICallB
 
 
 @Override
-public boolean isClosed() {
-synchronized (closedLock) {
-return closed;
-}
-}
-
-
-@Override
 protected void writeBlockingDirect(ByteBuffer from) throws IOException 
{
 if (from.isDirect()) {
 super.writeBlockingDirect(from);
@@ -2421,7 +2409,7 @@ public class AprEndpoint extends 
AbstractEndpoint implements SNICallB
 
 @Override
 protected void doWrite(boolean block, ByteBuffer from) throws 
IOException {
-if (closed) {
+if (isClosed()) {
 throw new IOException(sm.getString("socket.apr.closed", 
getSocke

Registry instance aligned on Tomcat/Server lifecycle?

[Romain Manni-Bucau]

Hi guys,

9.0.20 got a disableRegistry method in Registry class (for JMX server
interaction),
I wonder if it is possible to enhance it a bit to make it instance bound to
the server instead of being global.

It would enable to start/stop/restart servers potentially
deactivating/activating JMX without issues if multiple tomcat instances are
started in the same JVM.

wdyt?

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book

[tomcat] branch master updated: Fix IDE warnings

[markt]

This is an automated email from the ASF dual-hosted git repository.

markt pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/tomcat.git


The following commit(s) were added to refs/heads/master by this push:
 new 7848be1  Fix IDE warnings
7848be1 is described below

commit 7848be1f9718168fc7af6c85c2526b72103106e0
Author: Mark Thomas 
AuthorDate: Wed May 15 10:13:40 2019 +0100

Fix IDE warnings
---
 java/org/apache/tomcat/util/net/AprEndpoint.java  | 2 +-
 java/org/apache/tomcat/util/net/Nio2Endpoint.java | 2 +-
 java/org/apache/tomcat/util/net/NioEndpoint.java  | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/java/org/apache/tomcat/util/net/AprEndpoint.java 
b/java/org/apache/tomcat/util/net/AprEndpoint.java
index 2d6622f..df85e6c 100644
--- a/java/org/apache/tomcat/util/net/AprEndpoint.java
+++ b/java/org/apache/tomcat/util/net/AprEndpoint.java
@@ -2768,7 +2768,7 @@ public class AprEndpoint extends 
AbstractEndpoint implements SNICallB
 BlockingMode block, long timeout, TimeUnit unit, A attachment,
 CompletionCheck check, CompletionHandler 
handler,
 Semaphore semaphore, VectoredIOCompletionHandler 
completion) {
-return new AprOperationState(read, buffers, offset, length, 
block,
+return new AprOperationState<>(read, buffers, offset, length, 
block,
 timeout, unit, attachment, check, handler, semaphore, 
completion);
 }
 
diff --git a/java/org/apache/tomcat/util/net/Nio2Endpoint.java 
b/java/org/apache/tomcat/util/net/Nio2Endpoint.java
index 652644a..50eb996 100644
--- a/java/org/apache/tomcat/util/net/Nio2Endpoint.java
+++ b/java/org/apache/tomcat/util/net/Nio2Endpoint.java
@@ -962,7 +962,7 @@ public class Nio2Endpoint extends 
AbstractJsseEndpoint 
handler,
 Semaphore semaphore, VectoredIOCompletionHandler 
completion) {
-return new Nio2OperationState(read, buffers, offset, length, 
block,
+return new Nio2OperationState<>(read, buffers, offset, length, 
block,
 timeout, unit, attachment, check, handler, semaphore, 
completion);
 }
 
diff --git a/java/org/apache/tomcat/util/net/NioEndpoint.java 
b/java/org/apache/tomcat/util/net/NioEndpoint.java
index 621d58c..8449bf0 100644
--- a/java/org/apache/tomcat/util/net/NioEndpoint.java
+++ b/java/org/apache/tomcat/util/net/NioEndpoint.java
@@ -1421,7 +1421,7 @@ public class NioEndpoint extends 
AbstractJsseEndpoint
 BlockingMode block, long timeout, TimeUnit unit, A attachment,
 CompletionCheck check, CompletionHandler 
handler,
 Semaphore semaphore, VectoredIOCompletionHandler 
completion) {
-return new NioOperationState(read, buffers, offset, length, 
block,
+return new NioOperationState<>(read, buffers, offset, length, 
block,
 timeout, unit, attachment, check, handler, semaphore, 
completion);
 }
 


-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[Bug 63389] Enable Servlet Warmup for Containerization

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=63389

--- Comment #7 from Mark Thomas  ---
Thinking about this some more, I think the best way to handle this is with a
new "warmup" command. Implemented in a similar manner to configtest it would
call server.start() followed by server.stop().

-- 
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