Re: Limit connections in multi-context environment

[Bryan Larson]

Mark,

I browsed the source code for the SemaphoreValve, and it appears that if a
Semaphore cannot be acquired the request will effectively "drop through".
Does that sound accurate?  What would I expect in terms of http status code
for the requests that are filtered out?

Thanks,
Bryan

On Tue, Oct 18, 2016 at 9:24 AM, Mark Thomas  wrote:

> On 18/10/2016 15:04, Bryan Larson wrote:
> > Good morning.  I recently posted a question on Stack Overflow that I
> think
> > would be better suited for this group.  Here is the question:
> > http://stackoverflow.com/questions/40050063/tomcat-max-
> connections-on-a-per-context-basis.
> > To summarize: Besides using multiple connectors in the server.xml file,
> is
> > there a way to limit max connections on a per context basis?
>
> http://tomcat.apache.org/tomcat-9.0-doc/config/valve.html#Semaphore_Valve
>
> Also available all the way back to Tomcat 6.
>
> > I read through the slides for Tomcat 9 here:
> > http://events.linuxfoundation.org/sites/events/files/slides/
> 2015-09-24-Tomcat-9.pdf.
> > Wording such as "Better infrastructure for the cloud"
>
> Before I even looked at the slides I thought that sounded like JavaEE 8
> waffle rather than a Tomcat feature. In the past there have been
> mutterings about this having something to do with multi-tenancy without
> any hard information on what that means for a Servlet container.
>
> > and "Tomcat 9 supports – multiple virtual hosts per connector (SNI)"
>
> That is just standard TLS virtual hosting.
>
> > lead me to believe
> > there might be changes in Tomcat 9 that support this without extensive
> > configuration changes.  Can this be confirmed?
>
> There are no Tomcat 9 specific changes to support this feature. (But you
> don't need them.)
>
> Mark
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: Details About Webapp Log in Tomcat

[Mark Thomas]

On 23/10/2016 18:24, minglei yin wrote:
> Hi all,
> 
> Recently, I want to implement a log functionality which is very similar to
> log mechanism in Tomcat. So I am here to ask some helps.
> 
> I just want to know, how Tomcat implements that different web applications
> can have different logging configurations and you do not need to worry
> about them interfering with each other. As I found some info by google
> before, Tomcat uses its own custom ClassLoaderLogManager which is
> classloader-aware. And I know this. But through my own experiment that I
> changed the ClassLoaderLogManager.java and replaced the tomcat-juli.jar, I
> found that when I called logger.info(""), it seemed that the introduced log
> interface in my web-app did not have a interaction with
> ClassLoaderLogManager. So I really just do not know how Tomcat gets this
> done.

There are multiple components to this:

- The custom LogManager that maintains a separate set of loggers
  for each class loader

- Configuring Tomcat to use this in the start-up scripts

- Ensuring that the Thread context class loader is set before obtaining
  a logger.


> Really thank you guys for any suggestions and advice.

You can learn a lot by configuring Tomcat for remote debugging and
stepping your way through the relevant code with your favourite IDE.

Mark


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

AW: 8.5.4 to 8.5.5 SSL Issue

[Kreuser, Peter]

Dear all,

> On Sun, Oct 23, 2016 at 3:15 PM, Christopher Schultz <
>  
> ch...@christopherschultz.net> wrote:  
>  
>   
>  
> > -BEGIN PGP SIGNED MESSAGE-  
> >  
> > Hash: SHA256
> >  
> > 
> >  
> > William,
> >  
> > 
> >  
> > On 10/21/16 6:08 PM, William Boyd wrote:
> >  
> > > On Fri, Oct 21, 2016 at 2:05 PM, Christopher Schultz <
> > >  
> > > ch...@christopherschultz.net> wrote:  
> > >  
> > >   
> > >  
> > > William,  
> > >  
> > >   
> > >  
> > > On 10/21/16 4:37 PM, William Boyd wrote:  
> > >  
> >  Hello, 
> >   
> > 
> >   
> >  I am attempting to upgrade from Tomcat 7 to 8.5.6. Everything  
> >   
> >  was working great until I enabled SSL with a self-signed   
> >   
> >  certificate. I am able to recreated the issue on 8.5.5. I  
> >   
> >  finally had to down graded to 8.5.4 to get SSL working with
> >   
> >  identical configuration and cert.  
> >   
> > 
> >   
> >  I want to be sure that this is not a known issue and that I'm  
> >   
> >  not doing something wrong before I create a bug report.
> >   
> > 
> >   
> >  Server version:Apache Tomcat/8.5.5 64-bit OS Name: 
> >   
> >  Windows 7 JVM Version:   1.8.0_102-b14 
> >   
> > 
> >   
> >  The cert was generated with this command: keytool  
> >   
> >  -genkeypair -keyalg RSA -alias tomcat -keystore
> >   
> >  "C:/keys/keystore.jsk" -storepass changeit -validity 360   
> >   
> >  -keysize 2048 -dname   
> >   
> >  CN=localhost,OU=ITS,O=Co,L=City,ST=AB,C=CA 
> >   
> > 
> >   
> >  Configuration includes adding  
> >   
> >  -Djavax.net.ssl.trustStore=c:/keys/keystore.jsk to JAVA_OPTS   
> >   
> > >   
> > >  
> > > I think this might be the problem. Tomcat doesn't use 
> > >  
> > > javax.net.ssl.trustStore except as a backup in case you haven't   
> > >  
> > > specified a trust store in your . You have pointed that
> > >  
> > > system property at a keystore, not a trust store. Technically,
> > >  
> > > they are the same format, but they are used for different things. 
> > >  
> > >   
> > >  
> > > If you need that for making your own outgoing TLS connections then
> > >  
> > > leave it in there and we'll try to get it to work, otherwise it's 
> > >  
> > > just confusing and might cause Tomcat to do weird things. 
> > >  
> > > 

Re: Async servlet and request recycling

[Mark Thomas]

Thanks for this.

While I haven't had a chance to look into this, there is enough
information here to justify opening a bug report. That has the added
advantage that it won't get forogtten.

Mark


On 18/10/2016 09:55, Thomas Boniface wrote:
> Just a small correction, the callback was a bit weird. The correct one is
> below (but that doesn't impact the behavior of the scenario)
> 
> @Override
> public void completed(HttpResponse result) {
> try {
> try {
> Thread.sleep(200);
> } catch (InterruptedException e) {
> e.printStackTrace();
> }
> 
> ServletOutputStream out = res.getOutputStream();
> out.print("Hello world");
> out.flush();
> out.close();
> } catch (IOException e) {
> } finally {
> req.getAsyncContext().complete();
> }
> }
> 
> 
> 2016-10-18 10:38 GMT+02:00 Thomas Boniface :
>>
>> I think I managed to narrow things down a bit.
>>
>>
>> I managed to reproduced locally the issue (it's not occuring 100% of the
> time but it appears after a very few attempt for me). I created a really
> basic webapps :
>>
>> package stickyads.tv;
>>
>> import org.apache.http.HttpResponse;
>> import org.apache.http.client.methods.HttpGet;
>> import org.apache.http.concurrent.FutureCallback;
>> import org.apache.http.impl.nio.client.CloseableHttpAsyncClient;
>> import org.apache.http.impl.nio.client.HttpAsyncClients;
>>
>> import javax.servlet.*;
>> import javax.servlet.annotation.WebServlet;
>> import java.io.IOException;
>>
>> @WebServlet(value="/hello", name="helloServlet", asyncSupported = true)
>> public class HelloServlet extends GenericServlet {
>>
>> private static final CloseableHttpAsyncClient httpclient =
> HttpAsyncClients.createDefault();
>> static {
>> httpclient.start();
>> }
>>
>> @Override
>> public void service(final ServletRequest req, final ServletResponse
> res) throws ServletException, IOException {
>> req.startAsync();
>>
>> HttpGet request = new HttpGet("http://www.apache.org/;);
>> httpclient.execute(request, new FutureCallback() {
>> @Override
>> public void completed(HttpResponse result) {
>> try {
>> try {
>> Thread.sleep(200);
>> } catch (InterruptedException e) {
>> e.printStackTrace();
>> }
>>
>> ServletOutputStream out = res.getOutputStream();
>> out.print("Hello world");
>> out.flush();
>> out.close();
>> } catch (IOException e) {
>> // this will generate an NPE
>> req.getAsyncContext().complete();
>> }
>> }
>>
>> @Override
>> public void failed(Exception ex) {
>>
>> }
>>
>> @Override
>> public void cancelled() {
>>
>> }
>> });
>> }
>> }
>>
>> I deploy the war on tomcat 7.0.72 and then call it using a simple python
> program that sends a request and closes the requests without waiting for a
> response:
>>
>> import socket
>>
>> # create an INET, STREAMing socket
>> s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
>> # now connect to the web server on port 80 - the normal http port
>> s.connect(("127.0.0.1", 8080))
>> s.send("GET /broken-pipe-1.0-SNAPSHOT/hello
> HTTP/1.1\nHost:127.0.0.1\nX-Forwarded-For: 127.0.0.1\nX-Forwarded-Protocol:
> http\n\n")
>>
>> This result in a broken pipe exception, a recycling of the async context
> but no complete:
>>
>> INFO: An error occurred in processing while on a non-container thread.
> The connection will be closed immediately
>> java.net.SocketException: Broken pipe
>> at java.net.SocketOutputStream.$$YJP$$socketWrite0(Native Method)
>> at java.net.SocketOutputStream.socketWrite0(SocketOutputStream.java)
>> at
> java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:109)
>> at java.net.SocketOutputStream.write(SocketOutputStream.java:153)
>> at
> org.apache.coyote.http11.InternalOutputBuffer.realWriteBytes(InternalOutputBuffer.java:215)
>> at
> org.apache.tomcat.util.buf.ByteChunk.flushBuffer(ByteChunk.java:480)
>> at
> org.apache.coyote.http11.InternalOutputBuffer.endRequest(InternalOutputBuffer.java:159)
>> at
> org.apache.coyote.http11.AbstractHttp11Processor.action(AbstractHttp11Processor.java:761)
>> at org.apache.coyote.Response.action(Response.java:174)
>> at org.apache.coyote.Response.finish(Response.java:274)
>> at
> org.apache.catalina.connector.OutputBuffer.close(OutputBuffer.java:322)
>> at
> org.apache.catalina.connector.CoyoteOutputStream.close(CoyoteOutputStream.java:108)
>> at stickyads.tv.HelloServlet$1.completed(HelloServlet.java:33)
>> at stickyads.tv.HelloServlet$1.completed(HelloServlet.java:26)