RE: Error when shutting down Tomcat

[Jim Brikman (ybrikman)]

Is there any way to prevent this error? We use the windows service panel to 
start/stop Tomcat, and if we get this error, the stop command times out, the 
service panel shows an error and assumes the service has stopped, so you can't 
push stop again. 

Thanks,
Jim 

-Original Message-
From: david delbecq [mailto:[EMAIL PROTECTED] 
Sent: Thursday, January 10, 2008 5:09 PM
To: Tomcat Users List
Subject: Re: Error when shutting down Tomcat

Tomcat use a localhost binded port to receive SHUTDOWN request. However, i 
think it does start listening on that port only after the startup sequence is 
finished. What you see is not a message from the running tomcat, but a message 
from the shutdown script, that says it can't connect to tomcat administrative 
port and thus can't send the shutdown instruction. Your guess is correct, 
tomcat is still running totally unaffected. Just rerun shutdown command when 
tomcat has finished starting up.
Jim Brikman (ybrikman) a écrit :
> If I start Tomcat and let it run for ~30 seconds (ie, let my webapp 
> load completely), I can shut it down without any errors. However, if I 
> start Tomcat and very shortly after try to shut it down again (before 
> my webapp has finished loading), I get the following error in the logs:
>  
> : : Oct 26 2007 14:00:44.124 -0400: %_--: Catalina.stop:  
> java.net.ConnectException: Connection refused: connect  at 
> java.net.PlainSocketImpl.socketConnect(Native Method)  at 
> java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:333)
>  at 
> java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:195)
>  at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:182)
>  at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:366)
>  at java.net.Socket.connect(Socket.java:519)
>  at java.net.Socket.connect(Socket.java:469)
>  at java.net.Socket.(Socket.java:366)
>  at java.net.Socket.(Socket.java:179)
>  at org.apache.catalina.startup.Catalina.stopServer(Catalina.java:395)
>  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)  at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.j
> av
> a:39)
>  at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccess
> or
> Impl.java:25)
>  at java.lang.reflect.Method.invoke(Method.java:585)
>  at 
> org.apache.catalina.startup.Bootstrap.stopServer(Bootstrap.java:344)
>  at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:435)
>
> Nothing else appears in the logs afterwards, so I have no idea what's 
> happening, but I'm pretty sure Tomcat keeps running and my webapp's 
> shutdown code is never called.
>  
> Any ideas?
>  
> Thanks,
> Jim
>
>   


-
To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: 
[EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Tomcat 6 UTF-8 GET and POST - please Help..

[Jim Brikman (ybrikman)]

I found this guide to be very helpful in getting Tomcat to work with UTF-8: 
http://cagan327.blogspot.com/2006/05/utf-8-encoding-fix-tomcat-jsp-etc.html . 
It includes the filter code as well as other possible "gotchas". It is indeed a 
bit of a painful process and it would be nice if it could be simplified.

Jim

-Original Message-
From: Aleksandar Matijaca [mailto:[EMAIL PROTECTED] 
Sent: Thursday, January 10, 2008 3:25 PM
To: Tomcat Users List
Subject: Re: Tomcat 6 UTF-8 GET and POST - please Help..

The Filter worked -- now it works well with the POST as well as the GET.
David thank you so much...

Here is the filter.. nice and simple..  Maybe somebody else may need this code 
one day...

But you know, from a Philosophical Perspective, I should not have to create 
extra code, to get around these incompatibilities in Tomcat.

I don't have to do this in Jetty...

Regards, Alex.


package test.inter;

import java.io.IOException;

import javax.servlet.Filter;
import javax.servlet.FilterChain;
import javax.servlet.FilterConfig;
import javax.servlet.ServletException;
import javax.servlet.ServletRequest;
import javax.servlet.ServletResponse;

public class UTF8Filter implements Filter {

public void destroy() {
// TODO Auto-generated method stub

}

public void doFilter(ServletRequest arg0, ServletResponse arg1, FilterChain 
arg2) throws IOException, ServletException {
arg0.setCharacterEncoding("UTF-8");
arg2.doFilter(arg0,arg1);
}

public void init(FilterConfig arg0) throws ServletException {
// TODO Auto-generated method stub

}

}


in web.xml



UTF8Filter
test.inter.UTF8Filter


UTF8Filter
/*



On Jan 10, 2008 2:12 PM, David Delbecq <[EMAIL PROTECTED]> wrote:

> As you might infer, URIEncoding="UTF-8" only work on the Uri part, and 
> thus affect only GET. The post is decoded using the browser provided 
> "content-encoding". Most borwser don't bother to set that header.
> Behaviour of tomcat is to then use some default (ISO-8859-1). Best way 
> to ensure tomcat will use UTF-8 for post decoding is to force it using 
> request.setCharacterEncoding("UTF-8"), before any call to 
> getParameter(s). a filter or a valve might be a good place :)
>
> btw, be carefull, struts (i see you use struts) tends to also have his 
> default behaviour when decoding POST :)
>
>
>
> Aleksandar Matijaca a écrit :
> > Hi there,
> >
> > I am having some issue with submitting foreign language fonts in 
> > HTML
> form
> > to Tomcat.
> > If I set up the FORM with method="GET" everything works just fine.
>  However,
> > when I use
> > POST, things don't work -  I get garbled characters in my servlet 
> > from
> the
> > FORM.
> > In the example below, I am showing the headers for both GET and POST 
> > - the character being sent is a single lower case letter
> "f" in
> > cyrillic.
> >
> >
> > 
> >
> > The POST method does not work - gives garbled characters - please 
> > note
> that
> > the mytext is PROPERLY ENCODED IN BOTH methods - GET and POST, so I 
> > don't think that it is a browser issue (i think that my HTML is ok 
> > too).
> >
> >
> > http://localhost:8080/Inter/takeText.do
> >
> > POST /Inter/takeText.do HTTP/1.1
> > Host: localhost:8080
> > User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; 
> > rv:1.8.1.11)
> > Gecko/20071127 Firefox/2.0.0.11
> > Accept: 
> > text/xml,application/xml,application/xhtml+xml,text/html;q=0.9
> > ,text/plain;q=0.8,image/png,*/*;q=0.5
> > Accept-Language: en-us,en;q=0.8,sr;q=0.5,hi;q=0.3
> > Accept-Encoding: gzip,deflate
> > Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
> > Keep-Alive: 300
> > Connection: keep-alive
> > Referer: http://localhost:8080/Inter/takeText.do
> > Cookie: JSESSIONID=yhhvgybm2jfa; sensitivity=1000.0;
> > JSESSIONID=AF8D24C63CE9C16D5DF78E5CDDE26146
> > Content-Type: application/x-www-form-urlencoded
> > Content-Length: 13
> > mytext=%D1%84
> >
> >
> > 
> >
> > This is the request using GET - this works just fine - the servlet 
> > gets mytext nicely decoded...
> >
> >
> > http://localhost:8080/Inter/takeText.do?mytext=%D1%84
> >
> > GET /Inter/takeText.do?mytext=%D1%84 HTTP/1.1
> > Host: localhost:8080
> > User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; 
> > rv:1.8.1.11)
> > Gecko/20071127 Firefox/2.0.0.11
> > Accept: 
> > text/xml,application/xml,application/xhtml+xml,text/html;q=0.9
> > ,text/plain;q=0.8,image/png,*/*;q=0.5
> > Accept-Language: en-us,en;q=0.8,sr;q=0.5,hi;q=0.3
> > Accept-Encoding: gzip,deflate
> > Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
> > Keep-Alive: 300
> > Connection: keep-alive
> > Referer: http://localhost:8080/Inter/takeText.do?mytext=%D1%84
> > Cookie: JSESSIONID=yhhvgybm2jfa; sensitivity=1000.0;
> > JSESSIONID=AF8D24C63CE9C16D5DF78E5CDDE26146
> >
> >
> >
> 

Error when shutting down Tomcat

[Jim Brikman (ybrikman)]

If I start Tomcat and let it run for ~30 seconds (ie, let my webapp load
completely), I can shut it down without any errors. However, if I start
Tomcat and very shortly after try to shut it down again (before my
webapp has finished loading), I get the following error in the logs:
 
: : Oct 26 2007 14:00:44.124 -0400: %_--: Catalina.stop:  
java.net.ConnectException: Connection refused: connect
 at java.net.PlainSocketImpl.socketConnect(Native Method)
 at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:333)
 at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:195)
 at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:182)
 at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:366)
 at java.net.Socket.connect(Socket.java:519)
 at java.net.Socket.connect(Socket.java:469)
 at java.net.Socket.(Socket.java:366)
 at java.net.Socket.(Socket.java:179)
 at org.apache.catalina.startup.Catalina.stopServer(Catalina.java:395)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav
a:39)
 at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor
Impl.java:25)
 at java.lang.reflect.Method.invoke(Method.java:585)
 at org.apache.catalina.startup.Bootstrap.stopServer(Bootstrap.java:344)
 at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:435)

Nothing else appears in the logs afterwards, so I have no idea what's
happening, but I'm pretty sure Tomcat keeps running and my webapp's
shutdown code is never called. 
 
Any ideas?
 
Thanks,
Jim

RE: Tomcat + HttpClient + SSL + tcnative-1.dll issues?

[Jim Brikman (ybrikman)]

Good find Mark! It definitely does sound like the issue you linked.
We'll try building the code ourselves and see if it takes care of the
issue.

Thanks,
Jim 

-Original Message-
From: Mark Thomas [mailto:[EMAIL PROTECTED] 
Sent: Friday, January 04, 2008 5:39 PM
To: Tomcat Users List
Subject: Re: Tomcat + HttpClient + SSL + tcnative-1.dll issues?

JP Beaudry wrote:
> How do we go about debugging this? Is there any lower level tracing we

> can enable? Somewhere between the Tomcat access log and a sniffer
trace?

This sounds like http://issues.apache.org/bugzilla/show_bug.cgi?id=44087

A new native release is planned shortly to fix this. In the meantime,
you could try building from the source and seeing if the issue you are
seeing is indeed fixed.

Mark


-
To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe,
e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Apache Portable Runtime and Tomcat?

[Jim Brikman (ybrikman)]

Hi Rainer,

Thanks for the quick response! A couple more questions: if we grab the
code for APR, OpenSSL and tcnative, and compile them (yes, we are on
Windows), what will we get? Several dll's? And if so, do we just replace
the tcnative-1.dll with these dll's or is there some other configuration
that is necessary?

Thanks,
Jim


-Original Message-
From: Rainer Jung [mailto:[EMAIL PROTECTED] 
Sent: Friday, January 04, 2008 4:34 PM
To: Tomcat Users List
Subject: Re: Apache Portable Runtime and Tomcat?

Hi Jim,

APR and OpenSSL are maintained by other projects (apr.apache.org resp.
www.openssl.org).

The tcnative source can be obtained from

http://www.apache.org/dist/tomcat/tomcat-connectors/native/

The download contain a dsp file for Visual Studio (supposing you are
talking about WIN platform because you mentioned DLL), and a configure
script for Unix/Linux. The configure script of the most recent version
is 1.1.12 is broken (see mail on this list today), but the library code
is fine.

Regards,

Rainer

Jim Brikman (ybrikman) schrieb:
> The User Guide for the Apache Portable Runtime with Tomcat
> (http://tomcat.apache.org/tomcat-5.5-doc/apr.html) states the
following:
>  
> Windows binaries are provided for tcnative-1, which is a statically 
> compiled .dll which includes OpenSSL and APR. It can be downloaded 
> from here <http://tomcat.heanet.ie/native/> as 32bit or AMD x86-64
binaries.
> In security conscious production environments, it is recommended to 
> use separate shared dlls for OpenSSL, APR, and libtcnative-1, and 
> update them as needed according to security bulletins.
>  
> It may be obvious, but does anyone have step-by-step instructions on 
> where/how to download/build these "shared dlls for OpenSSL, APR and 
> libtcnative-1" and configure Tomcat to use them?
>  
> Thanks,
> Jim
>  
> 
> *Yevgeniy (Jim) Brikman*
> *Software Engineer*
> **Voice Technology Group*
> *
> [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> Phone :*978-936-0510* 
> Mobile :*617-538-2632*
> 
>   
> 
> **
> 500 Beaver Brook Road
> Boxborough, MA 01719
> United States
> www.cisco.com <http://www.cisco.com/>

-
To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe,
e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Apache Portable Runtime and Tomcat?

[Jim Brikman (ybrikman)]

The User Guide for the Apache Portable Runtime with Tomcat (
http://tomcat.apache.org/tomcat-5.5-doc/apr.html) states the following:
 
Windows binaries are provided for tcnative-1, which is a statically
compiled .dll which includes OpenSSL and APR. It can be downloaded from 
here   as 32bit or AMD x86-64 binaries.
In security conscious production environments, it is recommended to use
separate shared dlls for OpenSSL, APR, and libtcnative-1, and update
them as needed according to security bulletins.
 
It may be obvious, but does anyone have step-by-step instructions on
where/how to download/build these "shared dlls for OpenSSL, APR and
libtcnative-1" and configure Tomcat to use them?
 
Thanks,
Jim
 

Yevgeniy (Jim) Brikman
Software Engineer
Voice Technology Group

[EMAIL PROTECTED]
Phone :978-936-0510
Mobile :617-538-2632



500 Beaver Brook Road
Boxborough, MA 01719
United States
www.cisco.com  




 

Tomcat + HttpClient + SSL + tcnative-1.dll issues?

[Jim Brikman (ybrikman)]

Are there any known issues when using the Apache HttpClient to send
https requests to Tomcat running with tcnative-1.dll? Perhaps different
SSL stacks causing issues?
 
The issue we are seeing is duplicate messages: our HttpClient sends just
one copy of the message (an https request), but on the Tomcat side (with
tcnative-1.dll) we are seeing the message twice. This only happens with
https and not http.
 
Jim
 

Yevgeniy (Jim) Brikman
Software Engineer
Voice Technology Group

[EMAIL PROTECTED]
Phone :978-936-0510
Mobile :617-538-2632



500 Beaver Brook Road
Boxborough, MA 01719
United States
www.cisco.com  




 

Duplicate messages?

[Jim Brikman (ybrikman)]

Overview of the problem:
 
* We have a client computer named C and a server running Tomcat 5.5.23
called S
* Every now and then, C makes a SINGLE https request to S
* For some reason, the Tomcat access logs on S will sometimes show the
https request TWICE
 
So, we're trying to figure out why we're seeing duplicate messages. We
ran a packet sniffer (Wireshark) on both C and S and found the
following:
 
* C definitely only sends the https request ONCE
* S definitely only receives ONE https request
 
Let me restate that: both packet sniffers show only ONE https message
going across the line, yet Tomcat's access logs show the message twice.
One final thing we noticed while watching the packets going through the
sniffers:
 
* C sends one https request
* S receives one https request
* The https request appears the first time in the Tomcat access logs
* The connection between C and S is closed using the typical messages
(FIN, ACK, ACK)
* Immediately after the connection closes, we are then seeing some odd,
very small SSL packets going from S to C. We cannot decipher what these
are but they are TINY (def. not https requests).
* C responds with a RESET message to these
* At the exact time these "odd" packets are sent, the second copy of the
https request appears in the Tomcat access logs
 
Does anyone have a clue what's going on? Is there something in between
the Tomcat access log layer and the packet sniffer layer that could be
duplicating these messages? Could these odd little SSL messages somehow
make Tomcat think it got a second copy of the message?
 
Thanks,
Jim
 

Yevgeniy (Jim) Brikman
Software Engineer
Voice Technology Group

[EMAIL PROTECTED]
Phone :978-936-0510
Mobile :617-538-2632



500 Beaver Brook Road
Boxborough, MA 01719
United States
www.cisco.com