RE: Terminating Timer Thread Gracefully

2011-07-13 Thread Terence M. Bandoian 

 On 1:59 PM, Bill Miller wrote:

The problem is obviously that the thread within the Timer needs time to 
properly shutdown, the
non-obvious part is "how long does it need, and how do you detect it's done?". 
Normally you would do
a Thread.join() to ensure a thread has stopped before continuing, but as you 
mentioned before you
don't have access to the true thread instance in this case.


That's how it looks to me.  Time and possibly a context switch.


I'd say that the Thread.sleep() is doing the same as a Thread.join() would in 
this case, the only
problem I see is that if your application is intended to run on different 
hardware the hardcoded
1000ms delay may not be long enough in some situations. :(


Right.


Have you checked to see if there are any methods available to indicate if the 
timer has completed
its shutdown? (My memory is unclear about this and the JavaDoc isn't handy 
either... maybe there's
another object you need to instantiate to control Timer objects??)


Nothing in Timer.  Seems like I could potentially create a Thread and 
roll my own timing mechanism and then interrupt and join the Thread in 
contextDestroyed but that may be more complexity than is warranted.  
Might be fun though.



Bill


Thanks.

-Terence


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

Re: Terminating Timer Thread Gracefully

2011-07-13 Thread Terence M. Bandoian 

 On 1:59 PM, Christopher Schultz wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Terence,

On 7/12/2011 3:47 PM, Terence M. Bandoian wrote:

executorService.shutdown();

try { while ( !executorService.awaitTermination( 1, TimeUnit.SECONDS
) );

Thread.sleep( 1000 ); } catch ( InterruptedException ie ) { }


We use a ThreadPoolExecutor (which is an ExecutorService) in one of our
projects, and we do something like the following:

 int counter = 0; // Only emit messages every 10 seconds
 while(true)
 {
 if(_executor.isTerminated())
 {
 break;
 }
 else
 {
 if(++counter>  9)
 {
 if(!_executor.isTerminated())
 {
 logger.info("Still waiting on "
 + (_executor.getQueue()
.size() + 1)
 + " jobs to complete");
 }

 counter = 0;
 }

 // Sleep
 try { Thread.sleep(1000); }
 catch (InterruptedException ie) { /* do nothing */ }
 }
 }

This will test for completion every second, but only print warning
messages every 10 seconds that the service is waiting for the jobs to
complete.

I suppose we could even do _executor.awaitTermination(1, SECOND) to
jump-out a little early, but the point is that we loop waiting and also
print job counts, too. That may help you observe what is going on.

We don't run this in a webapp context, so we aren't ever having Tomcat
try to detect these threads or anything.

It's certainly possible that you are on the unfortunate end of a race
condition where Tomcat starts it's loose-thread detection before the job
thread has fully terminated and so the warning is spurious. Note that
awaitTermination() and isTerminated() methods are only documented to
return true when all jobs have completed and mention nothing about
destruction of the actual threads that perform the jobs.



I thought this might be the case but wanted to check with the folks who 
know Tomcat much better than I do.  Apparently, the call to Thread.sleep 
provides the opportunity to destroy the Timer or 
ScheduledExecutorService thread before Tomcat makes its check.




You may be out of luck from an API perspective, so perhaps an arbitrary
Thread.sleep() may be your only option, here. You could, of course, tell
Tomcat not to check for this kind of thing and the message(s) will go
away. I think it's better to allow Tomcat to complain, but know that a
message about a particular thread (you can name your threads by
specifying a ThreadFactory) is spurious and that others should be
investigated.




I can live with this.  It's just one of those "it would be nice not to 
have to explain" things and if Thread.sleep does the trick, I'm happy. 
As I mentioned in my original post, I wanted to find out if there was a 
another way to accomplish the same thing that I'd missed.




I wonder if anyone would be interested in a regular expression for
thread names that could be used to ignore certain threads during this
loose-thread checking for cases like this.

- -chris



Thanks.

-Terence

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

Re: Set up multiple Tomcat Services with Shared tomcat

2011-07-13 Thread Anand HS 
Thanks Mark and Konstantin for tips.

On Wed, Jul 13, 2011 at 5:16 PM, Konstantin Kolinko
wrote:

> 2011/7/14 Mark Thomas :
> > On 13/07/2011 22:46, Anand HS wrote:
> >> Hi,
> >> I have a set up where there are multiple catalina bases. All share a
> single
> >> tomcat parent.
> >> In this set up, can i still set up tomcat as service such that there is
> one
> >> service for each base. ?
> >
> > Yes, just make sure you give them separate names.
> >
>
> 1. Tomcat7.exe and Tomcat7w.exe  should be copied as  .exe and
> w.exe where  is unique for every additional service that you
> are installing. The file name is used to distinguish between different
> configurations.
>
> 2. Install them as services with different service names.
>
> BTW, Tomcat installer since 7.0.19 (7.0.17) allows you to change
> service name when installing and changes the file names according to
> the service name that you specify.
>
> Best regards,
> Konstantin Kolinko
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: Terminating Timer Thread Gracefully

2011-07-13 Thread Terence M. Bandoian 

 On 1:59 PM, Pid wrote:


ATimerTask is a private instance in AServletContextListener, is this
necessary and if so, why?

What logic is contained in ATimerTask?

Are you overriding TimerTask.cancel() and do you catch InterruptedException?


p


Hi, Pid-

For the sake of clarity, I'll repeat this here:

public class AServletContextListener implements ServletContextListener
{
private Timer timer;
private ATimerTask timerTask;

public AServletContextListener()
{
}

public void contextInitialized( ServletContextEvent sce )
{
if ( timer == null )
{
Calendar firstRunTime;

timer = new Timer( true );
timerTask = new ATimerTask();

firstRunTime = new GregorianCalendar();
firstRunTime.set( Calendar.HOUR_OF_DAY, 12 );
firstRunTime.set( Calendar.MINUTE, 0 );
firstRunTime.set( Calendar.SECOND, 0 );
firstRunTime.set( Calendar.MILLISECOND, 0 );

timer.scheduleAtFixedRate(
timerTask, firstRunTime.getTime(), 1000 * 60 * 60 * 24 );
}
}

public void contextDestroyed( ServletContextEvent sce )
{
if ( timer != null )
{
timer.cancel();
timer.purge();

timer = null;
timerTask = null;

try
{
Thread.sleep( 1000 );
}
catch ( InterruptedException ie )
{
}
}
}
}

It isn't absolutely necessary but why would I make the ATimerTask 
reference anything but private?


The timer tasks in the application perform some very straightforward 
database and file system maintenance when their run methods are invoked 
that might take up to half a second each.  None override the cancel 
method.  All are scheduled to execute on a daily or weekly basis and 
none at even close to the same time of day.


Also, while testing for ways to prevent the error message from being 
written to the logs, I commented out the run method bodies of the timer 
tasks so that they returned immediately and, given that I know the 
schedule, none of the timer tasks were executing when I stopped or 
restarted Tomcat.


The InterruptedException is caught and logged if it occurs.  I've never 
seen it in the logs.


Thanks.

-Terence


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

Re: Session cookie max age

2011-07-13 Thread Konstantin Kolinko 
2011/7/14 Josh Simmons :
> Our web.xml file minus listeners and servlet config.  I also removed some 
> taglib definitions.
>
> 
>
>     PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
>    "http://java.sun.com/dtd/web-app_2_3.dtd";>

Eh...  remove the above. It isn't servlet 2.3 webapp, isn't it?

>
> http://java.sun.com/xml/ns/javaee";
>  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>  xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
>                      http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd";
>  version="3.0">

If you'll add the following line into conf/catalina.properties, Tomcat
will validate your web.xml file according to the schema:

org.apache.catalina.STRICT_SERVLET_COMPLIANCE=true

[http://tomcat.apache.org/tomcat-7.0-doc/config/systemprops.html]


You are not saying what release of Tomcat 7.0.x you are using.


AFAIK,
1) Tomcat won't send Set-Cookie when session id is already known
(either from this webapp or  from webapp on its parent path such as
ROOT).

See code that calls
o.a.c.core.ApplicationSessionCookieConfig#createSessionCookie(..)


2) The Cookie header sent by the web browser does not include neither
Path nor Expires/Max-Age values.


Best regards,
Konstantin Kolinko

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

Re: Set up multiple Tomcat Services with Shared tomcat

2011-07-13 Thread Konstantin Kolinko 
2011/7/14 Mark Thomas :
> On 13/07/2011 22:46, Anand HS wrote:
>> Hi,
>> I have a set up where there are multiple catalina bases. All share a single
>> tomcat parent.
>> In this set up, can i still set up tomcat as service such that there is one
>> service for each base. ?
>
> Yes, just make sure you give them separate names.
>

1. Tomcat7.exe and Tomcat7w.exe  should be copied as  .exe and
w.exe where  is unique for every additional service that you
are installing. The file name is used to distinguish between different
configurations.

2. Install them as services with different service names.

BTW, Tomcat installer since 7.0.19 (7.0.17) allows you to change
service name when installing and changes the file names according to
the service name that you specify.

Best regards,
Konstantin Kolinko

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

RE: Session cookie max age

2011-07-13 Thread Josh Simmons 
Our web.xml file minus listeners and servlet config.  I also removed some 
taglib definitions.



http://java.sun.com/dtd/web-app_2_3.dtd";>

http://java.sun.com/xml/ns/javaee";
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
  xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
  http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd";
  version="3.0">





org.apache.taglibs.standard.lang.jstl.exprCacheSize
100



Performance Log Filter

ourCompanyPath.PerfLogServletFilter


Performance Log Filter
/do/*



Encoding
ourCompanyPath.EncodingFilter



Encoding
/*




   180
   

10800

   
 

  
  
index.jsp
  



**

The problem with the filter you are speaking of is that it actually adds 
multiple cookies to the request.  While most people say that they haven't found 
this to cause problems - we actually did find that it caused users problems.  
Firefox accepts the last cookie sent, but I've found reports saying that IE 
accepts the first cookie.  I'm not really sure what was going on, but the 
patterns were extremely inconsistent and hard to replicate.  All I know is that 
 we had people turn off cookies completely on our website and things started 
working again.  That was the reason we upgraded to tomcat7 in the first place.

-Original Message-
From: Christopher Schultz [mailto:ch...@christopherschultz.net] 
Sent: Wednesday, July 13, 2011 5:43 PM
To: Tomcat Users List
Subject: Re: Session cookie max age

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Josh,

On 7/13/2011 5:15 PM, Josh Simmons wrote:
> I was afraid I wasn't being specific enough - sorry.
> 
>  180
>   10800   
> 

Can you post your entire web.xml? You can remove all the servlet, listener, and 
security constraint stuff.

> We do not want to use the default cookie max age of -1 for our session 
> cookie. We would like for our session to persist across browser 
> restart (I know this might be frowned upon but it’s a stepping stone 
> towards the correct solution) - so in order to do so we set the max 
> age of our session cookie to 3hours , the same as our  timeout.

Gotcha.

> While the jsessionid might not be changing for every request, the 
> timeout is changing with every request.

Okay, now I get it. You expect Tomcat to set the cookie's max age to be NOW + 
180 minutes. That's what I'd expect, too.

> As I stated previously, we can fix this by just configuring our max 
> age to be 24 hours, because ideally no one is going to perfectly keep 
> their session alive on the server for that length of time.
> 
> Hopefully this makes more sense now of what I'm after.

It does. Assuming that you don't have a misconfiguration and that this is a 
Tomcat bug, you ought to be able to get around the problem using a Filter that 
looks something like this:

public class SessionCookieMaxAgeFilter
  implements Filter
{
  public void doFilter(ServletRequest request,
   ServletResponse response,
   FilterChain chain)
  {
if(request instanceof HttpServletRequest)
{
  Cookie cookie = getCookie((HttpServletRequest)request));

  if(null != cookie)
  {
// force the cookie back on the client
cookie.setMaxAge(180);

((HttpServletResponse)response).addCookie(cookie);
  }
}
  }

  private Cookie getCookie(HttpServletRequest request)
  {
Cookie[] cookies = request.getCookies();

if(null != cookies)
{
  for(int i=0; ihttp://enigmail.mozdev.org/

iEYEARECAAYFAk4eEUgACgkQ9CaO5/Lv0PAH5gCfTJijKQNqLv3F/TPQVT9CCMCL
RiMAn2b/CDEJj+vPQrRFj5FozSATkst/
=i8JZ
-END PGP SIGNATURE-

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

RE: AJP-APR failures on Tomcat 7.0.16 with ISAPI Redirector 1.2.32

2011-07-13 Thread eurotrans-Verlag 
Hi Rainer,

> -Original Message-
> From: Rainer Jung [mailto:rainer.j...@kippdata.de]
> Sent: Thursday, July 14, 2011 12:17 AM
> At least there was trouble about Java2D for several users in the past.
> One such issue:
> 
> https://issues.apache.org/bugzilla/show_bug.cgi?id=41772
> http://nerd.dk/blogs/bug-tomcat-or-java2d
> 
> but you might find more.
> 
> Regards,
> 
> Rainer
> 

Thanks. In the meantime, I also came to that conclusion and replaced all
instances of

ImageIO.write(img, "PNG", response.getOutputStream())

in my servlets/webapps with something like

ByteArrayOutputStream bout = new ByteArrayOutputStream();
ImageIO.write(img, "PNG", bout);
bout.writeTo(response.getOutputStream());

so that the ImageIO never sees the real OutputStream, and it seems to work
fine (no more IllegalStateExceptions or "wrong message format" errors in the
isapi log when using AJP-APR).

Is that a good practice (using ByteArrayOutputStream, then copy it to the
response) to dynamically generate Images and serve them to the clients?
Also, is there any hint to this on the Tomcat documentation/wiki? Because I
don't think it would be unusual to dynamically generate images and serve
them to clients using the ImageIO, and I think it could be a bit frustrating
to find the actual problem if one doesn't know this.


Thanks!


Regards,
Konstantin Preißer


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

Re: mod_jk question about lingering close_waits

2011-07-13 Thread Rainer Jung 
On 13.07.2011 23:16, André Warnier wrote:
> Hi.
> 
> I am not the one who can really answer your question, but
> 
> 1) this is the right list for Apache/Tomcat connectors (mod_jk among them)
> 
> 2) a question : do these CLOSE_WAIT sockets bother you for some specific
> reason ?
> In a totally different context, I have had problems with Linux systems
> when hundreds of such sockets accumulated over time (entire TCP stack
> becoming unresponsive at some point), but they do not seem to have an
> impact when the number remains "reasonable" (below one hundred or so).
> In this case, as I understand things, there will be a maximum of N such
> sockets, where N is the maximum number of threads which Tomcat may have,
> at some point, running simultaneously from this AJP Connector. (And it
> is also the number of connections which mod_jk will automatically
> configure in its pool).
> On many of the sites which I take care of, I regularly see 25-50 such
> mod_jk sockets in CLOSE_WAIT state for extended periods of time, and
> they do not seem to have any negative consequences on the system.  They
> just clutter the netstat displays, but you can always "grep -v" them out.

3) Look at the extensive sample configuration provided by the mod_jk
1.2.32 source download. There are many interesting worker properties,
for example idle timeouts, which should reduce the CLOSE_WAIT counts.

Regards,

Rainer


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

Re: AJP-APR failures on Tomcat 7.0.16 with ISAPI Redirector 1.2.32

2011-07-13 Thread Rainer Jung 
On 13.07.2011 00:36, eurotrans-Verlag wrote:

> Hmm, could it be that the Java ImageIO is re-using OutputStreams after
> calling ImageIO.write(img, "PNG", out), so that I'm getting such a
> IllegalStateException? (I think I read somewhere that Tomcat is recycling
> OutputStream objects)
> Maybe that could also explain the AJP errors I got.

At least there was trouble about Java2D for several users in the past.
One such issue:

https://issues.apache.org/bugzilla/show_bug.cgi?id=41772
http://nerd.dk/blogs/bug-tomcat-or-java2d

but you might find more.

Regards,

Rainer


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

Re: Set up multiple Tomcat Services with Shared tomcat

2011-07-13 Thread Mark Thomas 
On 13/07/2011 22:46, Anand HS wrote:
> Hi,
> I have a set up where there are multiple catalina bases. All share a single
> tomcat parent.
> In this set up, can i still set up tomcat as service such that there is one
> service for each base. ?

Yes, just make sure you give them separate names.

Mark



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

Set up multiple Tomcat Services with Shared tomcat

2011-07-13 Thread Anand HS 
Hi,
I have a set up where there are multiple catalina bases. All share a single
tomcat parent.
In this set up, can i still set up tomcat as service such that there is one
service for each base. ?

I am using the Tomcat 7.0.16 if thats important.

Thanks,
Anand

Re: Session cookie max age

2011-07-13 Thread Christopher Schultz 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Josh,

On 7/13/2011 5:15 PM, Josh Simmons wrote:
> I was afraid I wasn't being specific enough - sorry.
> 
>  180 
>   10800   
> 

Can you post your entire web.xml? You can remove all the servlet,
listener, and security constraint stuff.

> We do not want to use the default cookie max age of -1 for our 
> session cookie. We would like for our session to persist across 
> browser restart (I know this might be frowned upon but it’s a 
> stepping stone towards the correct solution) - so in order to do so 
> we set the max age of our session cookie to 3hours , the same as our
>  timeout.

Gotcha.

> While the jsessionid might not be changing for every request, the 
> timeout is changing with every request.

Okay, now I get it. You expect Tomcat to set the cookie's max age to be
NOW + 180 minutes. That's what I'd expect, too.

> As I stated previously, we can fix this by just configuring our max 
> age to be 24 hours, because ideally no one is going to perfectly
> keep their session alive on the server for that length of time.
> 
> Hopefully this makes more sense now of what I'm after.

It does. Assuming that you don't have a misconfiguration and that this
is a Tomcat bug, you ought to be able to get around the problem using a
Filter that looks something like this:

public class SessionCookieMaxAgeFilter
  implements Filter
{
  public void doFilter(ServletRequest request,
   ServletResponse response,
   FilterChain chain)
  {
if(request instanceof HttpServletRequest)
{
  Cookie cookie = getCookie((HttpServletRequest)request));

  if(null != cookie)
  {
// force the cookie back on the client
cookie.setMaxAge(180);

((HttpServletResponse)response).addCookie(cookie);
  }
}
  }

  private Cookie getCookie(HttpServletRequest request)
  {
Cookie[] cookies = request.getCookies();

if(null != cookies)
{
  for(int i=0; ihttp://enigmail.mozdev.org/

iEYEARECAAYFAk4eEUgACgkQ9CaO5/Lv0PAH5gCfTJijKQNqLv3F/TPQVT9CCMCL
RiMAn2b/CDEJj+vPQrRFj5FozSATkst/
=i8JZ
-END PGP SIGNATURE-

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

Re: mod_jk question about lingering close_waits

2011-07-13 Thread André Warnier 

Hi.

I am not the one who can really answer your question, but

1) this is the right list for Apache/Tomcat connectors (mod_jk among them)

2) a question : do these CLOSE_WAIT sockets bother you for some specific reason 
?
In a totally different context, I have had problems with Linux systems when hundreds of 
such sockets accumulated over time (entire TCP stack becoming unresponsive at some point), 
but they do not seem to have an impact when the number remains "reasonable" (below one 
hundred or so).
In this case, as I understand things, there will be a maximum of N such sockets, where N 
is the maximum number of threads which Tomcat may have, at some point, running 
simultaneously from this AJP Connector. (And it is also the number of connections which 
mod_jk will automatically configure in its pool).
On many of the sites which I take care of, I regularly see 25-50 such mod_jk sockets in 
CLOSE_WAIT state for extended periods of time, and they do not seem to have any negative 
consequences on the system.  They just clutter the netstat displays, but you can always 
"grep -v" them out.



Edward Quick wrote:

Hi,

Apologies in advance if this is the wrong mailing list. I was unable to find 
one specific to mod_jk and this looked the most relevant.

I have the following apache tomcat server configuration set up: Apache  2.2.3 , 
mod_jk 1.2.32 , and tomcat 6.0.32 running HelloWorld.war
If I send a request to http://remotehost/HelloWorld/index.jsp, I observe the 
following behaviour:


1 ) My tomcat AJP connector is listening on port 8010

TEST [root@remotehost]$ netstat -an | grep 8010
tcp0  0 0.0.0.0:80100.0.0.0:*   
LISTEN


2) I make a request to http://remotehost/HelloWorld/index.jsp and see the 
apache establish a connection to tomcat. The response comes back straightaway.

TEST [root@remotehost]$ netstat -an | grep 8010
tcp0  0 0.0.0.0:80100.0.0.0:*   
LISTEN
tcp0  0 10.34.2.140:801010.34.2.140:46792   
ESTABLISHED
tcp0  0 10.34.2.140:46792   10.34.2.140:8010
ESTABLISHED

3) After reaching KeepAliveTimeout on the Tomcat AJP connector, the connections 
change state:

TEST [root@ remotehost]$ netstat -an | grep 8010
tcp0  0 0.0.0.0:80100.0.0.0:*   
LISTEN
tcp0  0 10.34.2.140:801010.34.2.140:46792   
FIN_WAIT2
tcp1  0 10.34.2.140:46792   10.34.2.140:8010
CLOSE_WAIT

4) After about another minute, the FIN_WAIT2 is cleared, but the CLOSE_WAIT 
remains (on the apache) until reaching net.ipv4.tcp_keepalive_time (which is 
set to 7200 seconds)

TEST [root@ remotehost]$ netstat -an | grep 8010
tcp0  0 0.0.0.0:80100.0.0.0:*   
LISTEN
tcp1  0 10.34.2.140:46792   10.34.2.140:8010
CLOSE_WAIT


Everything there looks fine except for the CLOSE_WAIT which lingers around for 
2 hours until it hits tcp_keepalive_time.
Adding JkOptions +DisableReuse will prevent the CLOSE_WAITs staying, but that 
is also said to have a performance impact.

My question is if this is the expected tcpip state after the thread has 
finished, because in JDBC I see the connections permanently ESTABLISHED or in 
TIME_WAIT.

Thanks for any help.

Ed.


The information contained in this email is strictly confidential and for the 
use of the addressee only, unless otherwise indicated. If you are not the 
intended recipient, please do not read, copy, use or disclose to others this 
message or any attachment. Please also notify the sender by replying to this 
email or by telephone (+44 (0)20 7896 0011) and then delete the email and any 
copies of it. Opinions, conclusions (etc) that do not relate to the official 
business of this company shall be understood as neither given nor endorsed by 
it. IG Group Holdings plc is a company registered in England and Wales under 
number 01190902. VAT registration number 761 2978 07. Registered Office: Cannon 
Bridge House, 25 Dowgate Hill, London EC4R 2YA. Authorised and regulated by the 
Financial Services Authority. FSA Register number 114059.




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

RE: Session cookie max age

2011-07-13 Thread Josh Simmons 
I was afraid I wasn't being specific enough - sorry.


   180
   

10800

   
 

We do not want to use the default cookie max age of -1 for our session cookie.  
We would like for our session to persist across browser restart (I know this 
might be frowned upon but it’s a stepping stone towards the correct solution) - 
so in order to do so we set the max age of our session cookie to 3hours , the 
same as our timeout.

While the jsessionid might not be changing for every request, the timeout is 
changing with every request.  The max age of the cookie does not however change 
to reflect this information.  Really what would be desirable for configuring 
the cookie would be something like the expires type configuration: access plus 
3hrs.

As I stated previously, we can fix this by just configuring our max age to be 
24 hours, because ideally no one is going to perfectly keep their session alive 
on the server for that length of time.   

Hopefully this makes more sense now of what I'm after.

-Original Message-
From: Christopher Schultz [mailto:ch...@christopherschultz.net] 
Sent: Wednesday, July 13, 2011 3:01 PM
To: Tomcat Users List
Subject: Re: Session cookie max age

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Josh,

On 7/13/2011 2:14 PM, Josh Simmons wrote:
> We tried to set the cookie max age to 3 hours, the exact same time as 
> our session timeout.

So, this is a non-session cookie?

> However, I was extremely surprised that the session cookie didn't get 
> updated on every request.

Why should it? The information does not change with every request.

> The cookie max age was set when the session was created and that was 
> it.

Okay.

> The end result is that our users who stay signed on for longer than
> 3 hours now appear to get logged out.

Is that because your non-session cookie is somehow expected to interact with 
the session cookie?

If a user goes 3 hours without any activity, the session expires.
JSESSIONID cookies are, by default, temporary cookies for the user agent
(browser) and do not have an expiration date (that is, they expire when the 
browser shuts down). It's up to Tomcat to determine the expiration time of the 
actual HTTP session.

> I'm curious about this functionality - why was the decision made to 
> not update the session cookie if a max age is set?  We can effectively 
> get what we want by setting the max age to 24 hours, but  that seems 
> like the wrong solution.

Can you show your configuration and/or code that is relevant?

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk4d62wACgkQ9CaO5/Lv0PAkPACfU5RRFYpswrZUk/vfEQqJfukL
HBUAn1/xJVprK2PwBd6iEHobVrwMpi91
=NHfl
-END PGP SIGNATURE-

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

RE: Comet over HTTPS: END event recieved immeidately for the first few times

2011-07-13 Thread Sudeep Pradhan 
Hi Filip,

Thanks for the reply.

I don't think that I am using BIO connector for SSL. I don't see any such 
option in the server.xml. The connector is as follows:



Also, It does *work sometimes*. I get a proper streaming output of the weather 
feeds when it works.

Hope this helps you understand the scenario better.

Thanks,
Sudeep



-Original Message-
From: Filip Hanik - Dev Lists [mailto:devli...@hanik.com] 
Sent: Wednesday, July 13, 2011 1:43 PM
To: Tomcat Users List
Subject: Re: Comet over HTTPS: END event recieved immeidately for the first few 
times

is it possible that when you turn on SSL, you are using the regular BIO 
connector when you use SSL and Comet is not supported by that connector.
best
Filip

On 7/11/2011 11:05 AM, Sudeep Pradhan wrote:
> Hi Filip,
>
> I have tried the app with tomcat 6.0.32 and 7.0.16, and the result is the 
> same. I am not able to get it working with https. Http works just fine.
>
> The use case I am trying to address is that, I want to send 
> notifications/events from a webapp to another webapp asynchronously. The 2 
> webapps communicate using REST call for other things. I want to have the same 
> model for notifications. The client webapp will send a Https GET request and 
> the server webapp will push the notifications asynchronously as a response. 
> The client can be anything not just a webapp, I will be using curl as the 
> client for testing.
>
> Please let me know if you want to know more.
>
> Thanks,
> Sudeep
>
> -Original Message-
> From: Filip Hanik - Dev Lists [mailto:devli...@hanik.com]
> Sent: Sunday, July 10, 2011 8:12 PM
> To: Tomcat Users List
> Subject: Re: Comet over HTTPS: END event recieved immeidately for the first 
> few times
>
> try the latest version of Tomcat 6, if that doesn't work, provide a test case 
> so we can take a look at it
>
> On 7/8/2011 4:07 PM, Sudeep Pradhan wrote:
>> Any insights on this?
>>
>> -Original Message-
>> From: Sudeep Pradhan [mailto:pradh...@vmware.com]
>> Sent: Wednesday, June 29, 2011 4:54 PM
>> To: users@tomcat.apache.org
>> Subject: Comet over HTTPS: END event recieved immeidately for the first few 
>> times
>>
>> Hello,
>>
>> I am  using Tomcat 6.0.20 on Ubuntu 10.04 and have written a simple 
>> TomcatWeatherServlet as presented in 
>> http://www.ibm.com/developerworks/web/library/wa-cometjava/ I modified the 
>> servlet to stream weather feed to multiple curl clients. I am using curl 
>> 7.21.6 as my client.
>>
>> When I run curl -i -k -v -trace 
>> https://:8443/Weather   from 
>> the command-line I get the following response for the first few times:
>>
>> 
>> $ curl -i -k -v -trace https://:8443/Weather
>> * About to connect() to   port 8443 (#0)
>> *   Trying... connected
>> * Connected to   () port 8443 (#0)
>> * successfully set certificate verify locations:
>> *   CAfile: none
>> CApath: /etc/ssl/certs
>> * SSLv3, TLS handshake, Client hello (1):
>> * SSLv3, TLS handshake, Server hello (2):
>> * SSLv3, TLS handshake, CERT (11):
>> * SSLv3, TLS handshake, Server key exchange (12):
>> * SSLv3, TLS handshake, Server finished (14):
>> * SSLv3, TLS handshake, Client key exchange (16):
>> * SSLv3, TLS change cipher, Client hello (1):
>> * SSLv3, TLS handshake, Finished (20):
>> * SSLv3, TLS change cipher, Client hello (1):
>> * SSLv3, TLS handshake, Finished (20):
>> * SSL connection using DHE-RSA-AES256-SHA
>> * Server certificate:
>> *  subject: 
>> *  start date: 2009-02-23 23:07:18 GMT
>> *  expire date: 2019-02-21 23:07:18 GMT
>> *  common name: XX (does not match '')
>> *  issuer: XX
>> *  SSL certificate verify result: self signed certificate (18), 
>> continuing anyway.
>>> GET /Weather HTTP/1.1
>>> User-Agent: curl/7.21.6 (x86_64-pc-linux-gnu) libcurl/7.19.7 OpenSSL/0.9.8k 
>>> zlib/1.2.3.3 libidn/1.15
>>> Host::8443
>>> Accept: */*
>>>
>> <   HTTP/1.1 200 OK
>> HTTP/1.1 200 OK
>> <   Server: Apache-Coyote/1.1
>> Server: Apache-Coyote/1.1
>> <   Content-Length: 0
>> Content-Length: 0
>> <   Date: Wed, 29 Jun 2011 23:40:17 GMT
>> Date: Wed, 29 Jun 2011 23:40:17 GMT
>>
>> <
>> * Connection #0 to host   left intact
>> * Closing connection #0
>> * SSLv3, TLS alert, Client hello (1):
>> 
>>
>> Observe that Content-Length is 0 in the response. Also when I do get the 
>> expected response which is,
>>
>> 
>>> GET /Weather HTTP/1.1
>>> User-Agent: curl/7.21.6 (x86_64-pc-linux-gnu) libcurl/7.19.7 OpenSSL/0.9.8k 
>>> zlib/1.2.3.3 libidn/1.15
>>> Host::8443
>>> Accept: */*
>>>
>> <   HTTP/1.1 200 OK
>> HTTP/1.1 200 OK
>> <   Server: Apache-Coyote/1.1
>> Server: Apache-Coyote/1.1
>> <   Transfer-Encoding: chunked
>> Transfer-Encoding: chunked
>> <   Date: Wed, 29 Jun 2011 23:46:18 GMT
>> Date: Wed, 29 Jun 2011 23:46:18 GMT
>>
>> <
>> Conditions for San Jose, CA at 3:52 pm PDT
>> h

Re: Tomcat Pool and XA datasource

2011-07-13 Thread Filip Hanik - Dev Lists 

you've misconfigured it. the driverClassName would have to be a driver.
Using XA data sources needs to create the datasource for those connections 
first.

There is an example towards the bottom of

http://www.tomcatexpert.com/blog/2010/04/01/configuring-jdbc-pool-high-concurrency

Filip

On 7/12/2011 6:27 AM, Siemback, Chris wrote:

Hello all,

Has anyone ever been able to successfully setup an Oracle XA datasource using 
the newer Tomcat Pool and running Tomcat 7?  It appears the Tomcat Pool is 
attempting to cast the oracle XA data source to a java.sql.Driver - which it 
isn't.  This needs to be an XA datasource.  Anyone have luck with this - no 
working examples that I can find?  Here's the versions/info/error:

Software:
Tomcat 7.0.16
Tomcat Pool 1.1.0.1 
http://people.apache.org/~fhanik/jdbc-pool/v1.1.0.1/apache-tomcat-jdbc-1.1.0.1-bin.zip
Oracle 11 (ojdbc6.jar)


Context.xml contents:



Exception:

SEVERE: Servlet.service() for servlet [jsp] in context with path [] threw 
exception [javax.servlet.ServletException: javax.naming.NamingException: 
oracle.jdbc.xa.client.OracleXADataSource cannot be cast to java.sql.Driver] 
with root cause
javax.naming.NamingException: oracle.jdbc.xa.client.OracleXADataSource cannot 
be cast to java.sql.Driver
 at 
org.apache.naming.NamingContext.lookup(NamingContext.java:843)
 at 
org.apache.naming.NamingContext.lookup(NamingContext.java:145)
 at 
org.apache.naming.NamingContext.lookup(NamingContext.java:814)
 at 
org.apache.naming.NamingContext.lookup(NamingContext.java:145)
 at 
org.apache.naming.NamingContext.lookup(NamingContext.java:814)
 at 
org.apache.naming.NamingContext.lookup(NamingContext.java:145)
 at 
org.apache.naming.NamingContext.lookup(NamingContext.java:814)
 at 
org.apache.naming.NamingContext.lookup(NamingContext.java:159)
 at 
org.apache.naming.SelectorContext.lookup(SelectorContext.java:158)
 at javax.naming.InitialContext.lookup(InitialContext.java:392)
 at org.apache.jsp.jdbc_jsp._jspService(jdbc_jsp.java:69)
 at 
org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
 at 
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:419)
 at 
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:389)
 at 
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:333)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
 at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:304)
 at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
 at 
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:240)
 at 
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:164)
 at 
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:164)
 at 
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:100)
 at 
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:563)
 at 
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
 at 
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:403)
 at 
org.apache.coyote.http11.Http11AprProcessor.process(Http11AprProcessor.java:286)
 at 
org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.process(Http11AprProtocol.java:272)
 at 
org.apache.tomcat.util.net.AprEndpoint$SocketProcessor.run(AprEndpoint.java:1730)
 at 
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
 at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
 at java.lang.Thread.run(Thread.java:662)

This e-mail message is being sent solely for use by the intended recipient(s) 
and may contain confidential information.  Any unauthorized review, use, 
disclosure or distribution is prohibited.  If you are not the intended 
recipient, please contact the sender by phone or reply by e-mail, delete the 
original message and destroy all copies. Thank you.



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

Re: Comet over HTTPS: END event recieved immeidately for the first few times

2011-07-13 Thread Filip Hanik - Dev Lists 

is it possible that when you turn on SSL, you are using the regular BIO 
connector when you use SSL and Comet is not supported by that connector.
best
Filip

On 7/11/2011 11:05 AM, Sudeep Pradhan wrote:

Hi Filip,

I have tried the app with tomcat 6.0.32 and 7.0.16, and the result is the same. 
I am not able to get it working with https. Http works just fine.

The use case I am trying to address is that, I want to send 
notifications/events from a webapp to another webapp asynchronously. The 2 
webapps communicate using REST call for other things. I want to have the same 
model for notifications. The client webapp will send a Https GET request and 
the server webapp will push the notifications asynchronously as a response. The 
client can be anything not just a webapp, I will be using curl as the client 
for testing.

Please let me know if you want to know more.

Thanks,
Sudeep

-Original Message-
From: Filip Hanik - Dev Lists [mailto:devli...@hanik.com]
Sent: Sunday, July 10, 2011 8:12 PM
To: Tomcat Users List
Subject: Re: Comet over HTTPS: END event recieved immeidately for the first few 
times

try the latest version of Tomcat 6, if that doesn't work, provide a test case 
so we can take a look at it

On 7/8/2011 4:07 PM, Sudeep Pradhan wrote:

Any insights on this?

-Original Message-
From: Sudeep Pradhan [mailto:pradh...@vmware.com]
Sent: Wednesday, June 29, 2011 4:54 PM
To: users@tomcat.apache.org
Subject: Comet over HTTPS: END event recieved immeidately for the first few 
times

Hello,

I am  using Tomcat 6.0.20 on Ubuntu 10.04 and have written a simple 
TomcatWeatherServlet as presented in 
http://www.ibm.com/developerworks/web/library/wa-cometjava/ I modified the 
servlet to stream weather feed to multiple curl clients. I am using curl 7.21.6 
as my client.

When I run curl -i -k -v -trace 
https://:8443/Weather   from the 
command-line I get the following response for the first few times:


$ curl -i -k -v -trace https://:8443/Weather
* About to connect() to   port 8443 (#0)
*   Trying... connected
* Connected to   () port 8443 (#0)
* successfully set certificate verify locations:
*   CAfile: none
CApath: /etc/ssl/certs
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Server key exchange (12):
* SSLv3, TLS handshake, Server finished (14):
* SSLv3, TLS handshake, Client key exchange (16):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSL connection using DHE-RSA-AES256-SHA
* Server certificate:
*  subject: 
*  start date: 2009-02-23 23:07:18 GMT
*  expire date: 2019-02-21 23:07:18 GMT
*  common name: XX (does not match '')
*  issuer: XX
*  SSL certificate verify result: self signed certificate (18), 
continuing anyway.

GET /Weather HTTP/1.1
User-Agent: curl/7.21.6 (x86_64-pc-linux-gnu) libcurl/7.19.7 OpenSSL/0.9.8k 
zlib/1.2.3.3 libidn/1.15
Host::8443
Accept: */*


<   HTTP/1.1 200 OK
HTTP/1.1 200 OK
<   Server: Apache-Coyote/1.1
Server: Apache-Coyote/1.1
<   Content-Length: 0
Content-Length: 0
<   Date: Wed, 29 Jun 2011 23:40:17 GMT
Date: Wed, 29 Jun 2011 23:40:17 GMT

<
* Connection #0 to host   left intact
* Closing connection #0
* SSLv3, TLS alert, Client hello (1):


Observe that Content-Length is 0 in the response. Also when I do get the 
expected response which is,



GET /Weather HTTP/1.1
User-Agent: curl/7.21.6 (x86_64-pc-linux-gnu) libcurl/7.19.7 OpenSSL/0.9.8k 
zlib/1.2.3.3 libidn/1.15
Host::8443
Accept: */*


<   HTTP/1.1 200 OK
HTTP/1.1 200 OK
<   Server: Apache-Coyote/1.1
Server: Apache-Coyote/1.1
<   Transfer-Encoding: chunked
Transfer-Encoding: chunked
<   Date: Wed, 29 Jun 2011 23:46:18 GMT
Date: Wed, 29 Jun 2011 23:46:18 GMT

<
Conditions for San Jose, CA at 3:52 pm PDT
http://l.yimg.com/a/i/us/we/52/30.gif"/>
Current Conditions:
Partly Cloudy, 68 F
Forecast:
Wed - Mostly Clear. High: 70 Low: 55
Thu - Partly Cloudy. High: 77 Low: 57

http://us.rd.yahoo.com/dailynews/rss/weather/San_Jose__CA/*http://weather.yahoo.com/forecast/USCA0993_f.html";>Full
 Forecast at Yahoo! Weather
(provided byhttp://www.weather.com";>The Weather Channel)



I get Transfer-Encoding as chunked and no Content-Length.

On Server logs I get for the error are:
16:40:16.916  INFO http-8443-exec-3 TomcatWeatherServlet:41 - Begin for 
session: BDD6B1808161F1DA99D5D3207F1A719B
16:40:16.959  INFO http-8443-exec-4 TomcatWeatherServlet:48 - End for session: 
BDD6B1808161F1DA99D5D3207F1A719B
16:40:17.033  INFO http-8443-exec-4 TomcatWeatherServlet:48 - End for session: 
BDD6B1808161F1DA99D5D3207F1A719B

This was working when I was on HTTP. I have tried to debug this for a lot of 
tim

Re: Sticky Session Not Working With Apache 2.0.54 and Tomcat 7.0.8

2011-07-13 Thread Christopher Schultz 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Mark,

On 7/13/2011 3:12 PM, Mark Thomas wrote:
> On 13/07/2011 19:39, Lataxes, Karl wrote:
>> We're not using cookies.
>> 
>> Our application is not web based, but accepts HTTP PUTS via client 
>> requests that enter our network from external sources.  We are not 
>> URL encoding, as our clients are not configured to accept it.  If 
>> we have to include URL encoding, both our client and server 
>> applications will have to be modified accordingly, which may be an 
>> option.
> 
> No cookies and no url encoding. OK. So how are requests associated 
> with a session?

+1

Sounds like the OP is doing it wrong.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk4d70MACgkQ9CaO5/Lv0PCx0QCcClUefau5IpF9bX796LfVah9U
oZoAnjW40iu8UL0BzxtWVf8D/G5di5N1
=mMRQ
-END PGP SIGNATURE-

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

Re: Sticky Session Not Working With Apache 2.0.54 and Tomcat 7.0.8

2011-07-13 Thread Mark Thomas 
On 13/07/2011 19:39, Lataxes, Karl wrote:
> We're not using cookies.
> 
> Our application is not web based, but accepts HTTP PUTS via client requests 
> that enter our network from external sources.  We are not URL encoding, as 
> our clients are not configured to accept it.  If we have to include URL 
> encoding, both our client and server applications will have to be modified 
> accordingly, which may be an option.

No cookies and no url encoding. OK. So how are requests associated with
a session?

Mark



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

Re: [SECURITY] CVE-2011-2526 Apache Tomcat Information disclosure and availability vulnerabilities

2011-07-13 Thread Christopher Schultz 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Mark,

On 7/13/2011 2:28 PM, Mark Thomas wrote:
> No, since all that code runs in Tomcat's security context which has
> read everything permissions (by default) anyway. Logically, if a
> system admin doesn't want Tomcat to read those files, they wouldn't
> configure them in server.xml.

Yeah, I tend to agree... I was just trying to be creative which often
pays off when hunting for security vulnerabilities. :)

> What made the sendfile case different is that web application code 
> (which in some circumstances may be untrusted) can control what
> sendfile does and it was doing it in such a way that the
> SecurityManager was bypassed.

Got it.

>> I don't think there's a disclosure here (specifying /etc/passwd for
>> a certificate file doesn't dump /etc/passwd) but there might be 
>> opportunities for a JVM crash.
> 
> Not a web application triggered one, which is what would be required
> for it to be a security vulnerability.

Good to know where the line is: if a webapp can attack the container,
it's a vulnerability. If the container itself can be configured
improperly, then that's just bad administration.

> A couple of other things that it is worth pointing out:
> 
> 1. Performance Adding the SecurityManager checks has a noticeable
> performance hit. It my *very* ad-hoc testing, it was around 20%.
> However, sendfile + SecurityManager is still faster than no sendfile
> (with or without a SecurityManager)

Honestly, I see the use of a SecurityManager to be a trade-off in the
first place: security versus performance. It's too bad the JVM doens't
let you run some code under a SecurityManager and other code without one
(per Thread might make some most sense). Sure, you can get some code all
permissions, but the SM still has to determine that at runtime, which
has an associated cost.

> 2. A SecurityManager is not a complete defence against an untrusted
> web application. There is no way of stopping an untrusted web
> application doing this: <% while (1==1) { // burn that CPU } %>
> 
> 3. Most users don't run untrusted web applications so this will not 
> affect them.

I'm fortunate that I don't have to run untrusted code :) All of our
tight loops have been accidentally coded by our own team :)

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk4d7KUACgkQ9CaO5/Lv0PAOhACeMwbQN9q3JX+FcMBWXVq2h4OY
tO4AoJWTwuGhhgWabmbdHGIwE3FXFpIF
=IITe
-END PGP SIGNATURE-

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

Re: Session cookie max age

2011-07-13 Thread Christopher Schultz 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Josh,

On 7/13/2011 2:14 PM, Josh Simmons wrote:
> We tried to set the cookie max age to 3 hours, the exact same time as
> our session timeout.

So, this is a non-session cookie?

> However, I was extremely surprised that the session cookie didn't
> get updated on every request.

Why should it? The information does not change with every request.

> The cookie max age was set when the session was created and that was 
> it.

Okay.

> The end result is that our users who stay signed on for longer than
> 3 hours now appear to get logged out.

Is that because your non-session cookie is somehow expected to interact
with the session cookie?

If a user goes 3 hours without any activity, the session expires.
JSESSIONID cookies are, by default, temporary cookies for the user agent
(browser) and do not have an expiration date (that is, they expire when
the browser shuts down). It's up to Tomcat to determine the expiration
time of the actual HTTP session.

> I'm curious about this functionality - why was the decision made to 
> not update the session cookie if a max age is set?  We can 
> effectively get what we want by setting the max age to 24 hours, but
>  that seems like the wrong solution.

Can you show your configuration and/or code that is relevant?

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk4d62wACgkQ9CaO5/Lv0PAkPACfU5RRFYpswrZUk/vfEQqJfukL
HBUAn1/xJVprK2PwBd6iEHobVrwMpi91
=NHfl
-END PGP SIGNATURE-

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

RE: Sticky Session Not Working With Apache 2.0.54 and Tomcat 7.0.8

2011-07-13 Thread Lataxes, Karl 
We're not using cookies.

Our application is not web based, but accepts HTTP PUTS via client requests 
that enter our network from external sources.  We are not URL encoding, as our 
clients are not configured to accept it.  If we have to include URL encoding, 
both our client and server applications will have to be modified accordingly, 
which may be an option.

-Original Message-
From: Pid [mailto:p...@pidster.com] 
Sent: Wednesday, July 13, 2011 11:23 AM
To: Tomcat Users List
Subject: Re: Sticky Session Not Working With Apache 2.0.54 and Tomcat 7.0.8

On 13/07/2011 14:37, Lataxes, Karl wrote:
> We are attempting to run identical servlets under several Tomcat 7.0.8 nodes 
> behind a load balancer (Apache 2.0.54 using mod_jk), but we have been unable 
> to get sticky sessions to work.  Initial requests are forwarded to a node as 
> expected, but subsequent requests from the same client are being forwarded to 
> the second node ala round robin, which triggers session not found logic in 
> our application and causes the connection to terminate.  Due to environment 
> limitations, we cannot employ session persistence to our Tomcat instances and 
> must make use of sticky sessions.  My Tomcat instances have been properly 
> configured (HTTP connector commented out, AJP 1.3 connected uncommented, 
> jvmRoute attribute in each instance set to the workers listed in 
> workers.properties file).
> 
> Here are the mod_jk entries in my httpd.conf file:
> 
> LoadModule jk_module //apache/modules/mod_jk.so
> 
> JkWorkersFile //apache/conf/workers.properties
> JkLogFile logs/mod_jk.log
> JkLogLevel debug
> 
> JkMount /* loadbalancer
> 
> Here are the entries in my workers.property file:
> 
> worker.list=loadbalancer
> 
> worker.tomcat7A.type=ajp13
> worker.tomcat7A.host=
> worker.tomcat7A.port=4911
> worker.tomcat7A.lbfactor=1
> 
> worker.tomcat7C.type=ajp13
> worker.tomcat7C.host=
> worker.tomcat7C.port=4931
> worker.tomcat7C.lbfactor=1
> 
> worker.loadbalancer.type=lb
> worker.loadbalancer.balance_workers=tomcat7A,tomcat7C
> worker.loadbalancer.sticky_session=1
> 
> worker.jkstatus.type=status
> 
> What am I doing wrong?


Are they always forwarded to the wrong node, or do some succeed?

If you monitor the response headers (look for Set-Cookie:
NN.tomcat7X) is a new session sent each time?

Is the client sending the Cookie: header with the second request?

Are you URL encoding each link in the page?


p







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

Re: [SECURITY] CVE-2011-2526 Apache Tomcat Information disclosure and availability vulnerabilities

2011-07-13 Thread Mark Thomas 
On 13/07/2011 17:14, Christopher Schultz wrote:
> All,
> 
> Great catch to all who were involved in discovery and mitigation of this
> vulnerability.

Konstantin found the problems - he deserves most of the credit.

> Since the APR flavor of this vulnerability uses native code to crash the
> JVM and/or read files without asking the SecurityManager for permission,
> does that mean that the APR SSL configuration could be similarly
> attacked by specifying certificate file, etc. paths that shouldn't be
> allowed by the SecurityManager?

No, since all that code runs in Tomcat's security context which has read
everything permissions (by default) anyway. Logically, if a system admin
doesn't want Tomcat to read those files, they wouldn't configure them in
server.xml.

What made the sendfile case different is that web application code
(which in some circumstances may be untrusted) can control what sendfile
does and it was doing it in such a way that the SecurityManager was
bypassed.

> I don't think there's a disclosure here (specifying /etc/passwd for a
> certificate file doesn't dump /etc/passwd) but there might be
> opportunities for a JVM crash.

Not a web application triggered one, which is what would be required for
it to be a security vulnerability.

A couple of other things that it is worth pointing out:

1. Performance
Adding the SecurityManager checks has a noticeable performance hit. It
my *very* ad-hoc testing, it was around 20%. However, sendfile +
SecurityManager is still faster than no sendfile (with or without a
SecurityManager)

2. A SecurityManager is not a complete defence against an untrusted web
application.
There is no way of stopping an untrusted web application doing this:
<%
while (1==1) {
  // burn that CPU
}
%>

3. Most users don't run untrusted web applications so this will not
affect them.

Mark



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

Session cookie max age

2011-07-13 Thread Josh Simmons 
Hello,

We have recently upgraded our tomcats to Tomcat7 in order to gain the new 
exposure to the configuration of the session cookie, namely the max age 
property.  I had tried reading posts about getting it to work with tomcat6 but 
writing multiple cookies to the request caused problems for quite a few of our 
end users.

We tried to set the cookie max age to 3 hours, the exact same time as our 
session timeout.  However, I was extremely surprised that the session cookie 
didn't get updated on every request.  The cookie max age was set when the 
session was created and that was it.  The end result is that our users who stay 
signed on for longer than 3 hours now appear to get logged out.

I'm curious about this functionality - why was the decision made to not update 
the session cookie if a max age is set?  We can effectively get what we want by 
setting the max age to 24 hours, but that seems like the wrong solution.

Any help on the matter is greatly appreciated.

Joshua Simmons

Re: Terminating Timer Thread Gracefully

2011-07-13 Thread Christopher Schultz 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Terence,

On 7/12/2011 3:47 PM, Terence M. Bandoian wrote:
> executorService.shutdown();
> 
> try { while ( !executorService.awaitTermination( 1, TimeUnit.SECONDS
> ) );
> 
> Thread.sleep( 1000 ); } catch ( InterruptedException ie ) { }


We use a ThreadPoolExecutor (which is an ExecutorService) in one of our
projects, and we do something like the following:

int counter = 0; // Only emit messages every 10 seconds
while(true)
{
if(_executor.isTerminated())
{
break;
}
else
{
if(++counter > 9)
{
if(!_executor.isTerminated())
{
logger.info("Still waiting on "
+ (_executor.getQueue()
   .size() + 1)
+ " jobs to complete");
}

counter = 0;
}

// Sleep
try { Thread.sleep(1000); }
catch (InterruptedException ie) { /* do nothing */ }
}
}

This will test for completion every second, but only print warning
messages every 10 seconds that the service is waiting for the jobs to
complete.

I suppose we could even do _executor.awaitTermination(1, SECOND) to
jump-out a little early, but the point is that we loop waiting and also
print job counts, too. That may help you observe what is going on.

We don't run this in a webapp context, so we aren't ever having Tomcat
try to detect these threads or anything.

It's certainly possible that you are on the unfortunate end of a race
condition where Tomcat starts it's loose-thread detection before the job
thread has fully terminated and so the warning is spurious. Note that
awaitTermination() and isTerminated() methods are only documented to
return true when all jobs have completed and mention nothing about
destruction of the actual threads that perform the jobs.

You may be out of luck from an API perspective, so perhaps an arbitrary
Thread.sleep() may be your only option, here. You could, of course, tell
Tomcat not to check for this kind of thing and the message(s) will go
away. I think it's better to allow Tomcat to complain, but know that a
message about a particular thread (you can name your threads by
specifying a ThreadFactory) is spurious and that others should be
investigated.

I wonder if anyone would be interested in a regular expression for
thread names that could be used to ignore certain threads during this
loose-thread checking for cases like this.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk4dyS0ACgkQ9CaO5/Lv0PAOpACfcPhCnHGhhC03dGcxKw5udCQZ
1NkAoKZEvqwIIYh3/sNqmdAJP7O7hKor
=HKaB
-END PGP SIGNATURE-

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

Re: [SECURITY] CVE-2011-2526 Apache Tomcat Information disclosure and availability vulnerabilities

2011-07-13 Thread Christopher Schultz 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

All,

Great catch to all who were involved in discovery and mitigation of this
vulnerability.

Since the APR flavor of this vulnerability uses native code to crash the
JVM and/or read files without asking the SecurityManager for permission,
does that mean that the APR SSL configuration could be similarly
attacked by specifying certificate file, etc. paths that shouldn't be
allowed by the SecurityManager?

I don't think there's a disclosure here (specifying /etc/passwd for a
certificate file doesn't dump /etc/passwd) but there might be
opportunities for a JVM crash.

- -chris

On 7/13/2011 11:33 AM, Mark Thomas wrote:
> CVE-2011-2526: Apache Tomcat Information disclosure and availability 
> vulnerabilities
> 
> Severity: low
> 
> Vendor: The Apache Software Foundation
> 
> Versions Affected: Tomcat 7.0.0 to 7.0.18 Tomcat 6.0.0 to 6.0.32 
> Tomcat 5.5.0 to 5.0.33 Previous, unsupported versions may be
> affected Additionally, these vulnerabilities only occur when all of
> the following are true: a) untrusted web applications are being used 
> b) the SecurityManager is used to limit the untrusted web
> applications c) the HTTP NIO or HTTP APR connector is used d)
> sendfile is enabled for the connector (this is the default)
> 
> Description: Tomcat provides support for sendfile with the HTTP NIO
> and HTTP APR connectors. sendfile is used automatically for content
> served via the DefaultServlet and deployed web applications may use
> it directly via setting request attributes. These request attributes
> were not validated. When running under a security manager, this lack
> of validation allowed a malicious web application to do one or more
> of the following that would normally be prevented by a security
> manager: a) return files to users that the security manager should
> make inaccessible b) terminate (via a crash) the JVM
> 
> Mitigation: Affected users of all versions can mitigate these
> vulnerabilities by taking any of the following actions: a) undeploy
> untrusted web applications b) switch to the HTTP BIO connector (which
> does not support sendfile) c) disable sendfile be setting
> useSendfile="false" on the connector d) apply the patch(es) listed on
> the Tomcat security pages (see references) e) upgrade to a version
> where the vulnerabilities have been fixed Tomcat 7.0.x users may
> upgrade to 7.0.19 or later once released Tomcat 6.0.x users may
> upgrade to 6.0.33 or later once released Tomcat 5.5.x users may
> upgrade to 5.5.34 or later once released
> 
> Example: Exposing the first 1000 bytes of /etc/passwd 
> HttpServletRequest.setAttribute( 
> "org.apache.tomcat.sendfile.filename","/etc/passwd"); 
> HttpServletRequest.setAttribute( 
> "org.apache.tomcat.sendfile.start",Long.valueOf(0)); 
> HttpServletRequest.setAttribute( 
> "org.apache.tomcat.sendfile.end",Long.valueOf(1000)); Specifying a
> end point after the end of the file will trigger a JVM crash with the
> HTTP APR connector and an infinite loop with the HTTP NIO connector.
> 
> Credit: These issues were identified by the Tomcat security team.
> 
> References: http://tomcat.apache.org/security.html 
> http://tomcat.apache.org/security-7.html 
> http://tomcat.apache.org/security-6.html 
> http://tomcat.apache.org/security-5.html
> 
> The Apache Tomcat Security Team
> 
> 
> 
> 
> -
>
> 
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk4dxHoACgkQ9CaO5/Lv0PDykgCeNvC61SVMsawzVre/6ZxvR/+2
tvoAnRyoZQd14OJSo7+ExfWKSMnBTRex
=jpLx
-END PGP SIGNATURE-

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

Re: Terminating Timer Thread Gracefully

2011-07-13 Thread Pid 
On 12/07/2011 20:47, Terence M. Bandoian wrote:
>  Hi, Kris-
> 
> I tried using ScheduledExecutorService but ran into the same problem. 
> After awaiting termination:
> 
> executorService.shutdown();
> 
> try
> {
> while ( !executorService.awaitTermination(
> 1, TimeUnit.SECONDS ) );
> 
> Thread.sleep( 1000 );
> }
> catch ( InterruptedException ie )
> {
> }
> 
> I still had to insert a call to Thread.sleep to prevent the error
> message from being written to the logs.

ATimerTask is a private instance in AServletContextListener, is this
necessary and if so, why?

What logic is contained in ATimerTask?

Are you overriding TimerTask.cancel() and do you catch InterruptedException?


p

> 
> Thanks.
> 
> -Terence Bandoian
> 
> On 1:59 PM, Kris Schneider wrote:
>> On Tue, Jul 12, 2011 at 7:59 AM, Caldarale, Charles R
>>   wrote:
 From: Terence M. Bandoian [mailto:tere...@tmbsw.com]
 Subject: Terminating Timer Thread Gracefully
 Finally, in contextDestroyed, I inserted a call to
 Thread.sleep after canceling the timer and the error
 message disappeared.
>>> You should be able to do a Thread.join() using the timer's Thread
>>> object rather than sleeping.
>> But Timer doesn't expose its thread. An alternative would be use
>> something like Executors.newSingleThreadScheduledExecutor() to get a
>> ScheduledExecutorService. The executor can be used to schedule a
>> Runnable with a fixed rate or delay. When the context is destroyed,
>> shutdown the executor and await its termination.
>>
>>>   - Chuck
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
> 




signature.asc
Description: OpenPGP digital signature

[SECURITY] CVE-2011-2526 Apache Tomcat Information disclosure and availability vulnerabilities

2011-07-13 Thread Mark Thomas 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

CVE-2011-2526: Apache Tomcat Information disclosure and availability
   vulnerabilities

Severity: low

Vendor:
The Apache Software Foundation

Versions Affected:
Tomcat 7.0.0 to 7.0.18
Tomcat 6.0.0 to 6.0.32
Tomcat 5.5.0 to 5.0.33
Previous, unsupported versions may be affected
Additionally, these vulnerabilities only occur when all of the following
are true:
a) untrusted web applications are being used
b) the SecurityManager is used to limit the untrusted web applications
c) the HTTP NIO or HTTP APR connector is used
d) sendfile is enabled for the connector (this is the default)

Description:
Tomcat provides support for sendfile with the HTTP NIO and HTTP APR
connectors. sendfile is used automatically for content served via the
DefaultServlet and deployed web applications may use it directly via
setting request attributes. These request attributes were not validated.
When running under a security manager, this lack of validation allowed a
malicious web application to do one or more of the following that would
normally be prevented by a security manager:
a) return files to users that the security manager should make inaccessible
b) terminate (via a crash) the JVM

Mitigation:
Affected users of all versions can mitigate these vulnerabilities by
taking any of the following actions:
a) undeploy untrusted web applications
b) switch to the HTTP BIO connector (which does not support sendfile)
c) disable sendfile be setting useSendfile="false" on the connector
d) apply the patch(es) listed on the Tomcat security pages (see references)
e) upgrade to a version where the vulnerabilities have been fixed
   Tomcat 7.0.x users may upgrade to 7.0.19 or later once released
   Tomcat 6.0.x users may upgrade to 6.0.33 or later once released
   Tomcat 5.5.x users may upgrade to 5.5.34 or later once released

Example:
Exposing the first 1000 bytes of /etc/passwd
HttpServletRequest.setAttribute(
"org.apache.tomcat.sendfile.filename","/etc/passwd");
HttpServletRequest.setAttribute(
"org.apache.tomcat.sendfile.start",Long.valueOf(0));
HttpServletRequest.setAttribute(
"org.apache.tomcat.sendfile.end",Long.valueOf(1000));
Specifying a end point after the end of the file will trigger a JVM
crash with the HTTP APR connector and an infinite loop with the HTTP NIO
connector.

Credit:
These issues were identified by the Tomcat security team.

References:
http://tomcat.apache.org/security.html
http://tomcat.apache.org/security-7.html
http://tomcat.apache.org/security-6.html
http://tomcat.apache.org/security-5.html

The Apache Tomcat Security Team

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJOHbrCAAoJEBDAHFovYFnnUZsQANIh02dK4r0cYCwsD59Xvg0R
cCpx0MCzsrVBKU/fJ5nQtVTtZnOVfH2PnZBPFlYxQXpBCgIQh+ZIp9ntGdSNP0kH
e7XgHaG6NipfIPusnQyH8yYmcfRl4BDnQdHyrl1JqApDtqnzPJ4Re9SVQC5VymJP
i9DlvuV4atAdSCgOZzBb3+wMV0uoZqjXcUZrQEXCYBhtGFtOQM/JyMUa7iu5+FhI
AuUchlHw3N+nZ+b4QeXGdFowHMTlJoj0gv5eMCEMVfiaoM5COcaQYBRQxkbNhkfN
7zkcKKyDG2ARIJ7WB3Ncj7A4RfF2KY98q69px6RU2ho8umOycl32dw3wT1AtPWUx
3TkTgkN4FXDprCLp1r/csbYO15GSoI0selWzKxmOOuMIIamQ36HreUInZzXohuOJ
VSdR/LBekdfiLNkNtIwK7oeaZoYqPT14F15C+gkzw8a7ETzN6kyYwZz2+dnnWvxM
lV5WhEksulVfrfro6OBFI4k4KVyCq/QYRUH2WfyaRyUhRB8of6tnweB46upzzoAU
+YtyLPimURofJbcw4Ut4VBvjVJTdts3air32vCKxpfnjdn9Gd3GH3phjrsYzJHTl
fg3RcqrmV9I0gxLn5oWIMx17gOGpFOgSwMyGgm/WEJLyiEV5suSPFVjMFq3znj+7
zAlePYK10YSe5XiZ9g8F
=MeHU
-END PGP SIGNATURE-



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

Re: Sticky Session Not Working With Apache 2.0.54 and Tomcat 7.0.8

2011-07-13 Thread Pid 
On 13/07/2011 14:37, Lataxes, Karl wrote:
> We are attempting to run identical servlets under several Tomcat 7.0.8 nodes 
> behind a load balancer (Apache 2.0.54 using mod_jk), but we have been unable 
> to get sticky sessions to work.  Initial requests are forwarded to a node as 
> expected, but subsequent requests from the same client are being forwarded to 
> the second node ala round robin, which triggers session not found logic in 
> our application and causes the connection to terminate.  Due to environment 
> limitations, we cannot employ session persistence to our Tomcat instances and 
> must make use of sticky sessions.  My Tomcat instances have been properly 
> configured (HTTP connector commented out, AJP 1.3 connected uncommented, 
> jvmRoute attribute in each instance set to the workers listed in 
> workers.properties file).
> 
> Here are the mod_jk entries in my httpd.conf file:
> 
> LoadModule jk_module //apache/modules/mod_jk.so
> 
> JkWorkersFile //apache/conf/workers.properties
> JkLogFile logs/mod_jk.log
> JkLogLevel debug
> 
> JkMount /* loadbalancer
> 
> Here are the entries in my workers.property file:
> 
> worker.list=loadbalancer
> 
> worker.tomcat7A.type=ajp13
> worker.tomcat7A.host=
> worker.tomcat7A.port=4911
> worker.tomcat7A.lbfactor=1
> 
> worker.tomcat7C.type=ajp13
> worker.tomcat7C.host=
> worker.tomcat7C.port=4931
> worker.tomcat7C.lbfactor=1
> 
> worker.loadbalancer.type=lb
> worker.loadbalancer.balance_workers=tomcat7A,tomcat7C
> worker.loadbalancer.sticky_session=1
> 
> worker.jkstatus.type=status
> 
> What am I doing wrong?


Are they always forwarded to the wrong node, or do some succeed?

If you monitor the response headers (look for Set-Cookie:
NN.tomcat7X) is a new session sent each time?

Is the client sending the Cookie: header with the second request?

Are you URL encoding each link in the page?


p








signature.asc
Description: OpenPGP digital signature

mod_jk question about lingering close_waits

2011-07-13 Thread Edward Quick 
Hi,

Apologies in advance if this is the wrong mailing list. I was unable to find 
one specific to mod_jk and this looked the most relevant.

I have the following apache tomcat server configuration set up: Apache  2.2.3 , 
mod_jk 1.2.32 , and tomcat 6.0.32 running HelloWorld.war
If I send a request to http://remotehost/HelloWorld/index.jsp, I observe the 
following behaviour:


1 ) My tomcat AJP connector is listening on port 8010

TEST [root@remotehost]$ netstat -an | grep 8010
tcp0  0 0.0.0.0:80100.0.0.0:*   
LISTEN


2) I make a request to http://remotehost/HelloWorld/index.jsp and see the 
apache establish a connection to tomcat. The response comes back straightaway.

TEST [root@remotehost]$ netstat -an | grep 8010
tcp0  0 0.0.0.0:80100.0.0.0:*   
LISTEN
tcp0  0 10.34.2.140:801010.34.2.140:46792   
ESTABLISHED
tcp0  0 10.34.2.140:46792   10.34.2.140:8010
ESTABLISHED

3) After reaching KeepAliveTimeout on the Tomcat AJP connector, the connections 
change state:

TEST [root@ remotehost]$ netstat -an | grep 8010
tcp0  0 0.0.0.0:80100.0.0.0:*   
LISTEN
tcp0  0 10.34.2.140:801010.34.2.140:46792   
FIN_WAIT2
tcp1  0 10.34.2.140:46792   10.34.2.140:8010
CLOSE_WAIT

4) After about another minute, the FIN_WAIT2 is cleared, but the CLOSE_WAIT 
remains (on the apache) until reaching net.ipv4.tcp_keepalive_time (which is 
set to 7200 seconds)

TEST [root@ remotehost]$ netstat -an | grep 8010
tcp0  0 0.0.0.0:80100.0.0.0:*   
LISTEN
tcp1  0 10.34.2.140:46792   10.34.2.140:8010
CLOSE_WAIT


Everything there looks fine except for the CLOSE_WAIT which lingers around for 
2 hours until it hits tcp_keepalive_time.
Adding JkOptions +DisableReuse will prevent the CLOSE_WAITs staying, but that 
is also said to have a performance impact.

My question is if this is the expected tcpip state after the thread has 
finished, because in JDBC I see the connections permanently ESTABLISHED or in 
TIME_WAIT.

Thanks for any help.

Ed.


The information contained in this email is strictly confidential and for the 
use of the addressee only, unless otherwise indicated. If you are not the 
intended recipient, please do not read, copy, use or disclose to others this 
message or any attachment. Please also notify the sender by replying to this 
email or by telephone (+44 (0)20 7896 0011) and then delete the email and any 
copies of it. Opinions, conclusions (etc) that do not relate to the official 
business of this company shall be understood as neither given nor endorsed by 
it. IG Group Holdings plc is a company registered in England and Wales under 
number 01190902. VAT registration number 761 2978 07. Registered Office: Cannon 
Bridge House, 25 Dowgate Hill, London EC4R 2YA. Authorised and regulated by the 
Financial Services Authority. FSA Register number 114059.

Sticky Session Not Working With Apache 2.0.54 and Tomcat 7.0.8

2011-07-13 Thread Lataxes, Karl 
We are attempting to run identical servlets under several Tomcat 7.0.8 nodes 
behind a load balancer (Apache 2.0.54 using mod_jk), but we have been unable to 
get sticky sessions to work.  Initial requests are forwarded to a node as 
expected, but subsequent requests from the same client are being forwarded to 
the second node ala round robin, which triggers session not found logic in our 
application and causes the connection to terminate.  Due to environment 
limitations, we cannot employ session persistence to our Tomcat instances and 
must make use of sticky sessions.  My Tomcat instances have been properly 
configured (HTTP connector commented out, AJP 1.3 connected uncommented, 
jvmRoute attribute in each instance set to the workers listed in 
workers.properties file).

Here are the mod_jk entries in my httpd.conf file:

LoadModule jk_module //apache/modules/mod_jk.so

JkWorkersFile //apache/conf/workers.properties
JkLogFile logs/mod_jk.log
JkLogLevel debug

JkMount /* loadbalancer

Here are the entries in my workers.property file:

worker.list=loadbalancer

worker.tomcat7A.type=ajp13
worker.tomcat7A.host=
worker.tomcat7A.port=4911
worker.tomcat7A.lbfactor=1

worker.tomcat7C.type=ajp13
worker.tomcat7C.host=
worker.tomcat7C.port=4931
worker.tomcat7C.lbfactor=1

worker.loadbalancer.type=lb
worker.loadbalancer.balance_workers=tomcat7A,tomcat7C
worker.loadbalancer.sticky_session=1

worker.jkstatus.type=status

What am I doing wrong?

Re: Tomcat is not able to connect to IPV4 (Tomcat Version : 7.0.14)

2011-07-13 Thread André Warnier 

Rohan Kadam wrote:

Hi André,

Yes, whatever your understanding is correct. And also the connector tag is 
inside of Tomcat B.


Ok, then Charles' earlier message was correct, and the problem has nothing to do with 
Tomcat per se.


Your web application A makes its own TCP connection to webserver C, using the Apache 
httpclient.  It does not use any of the Tomcat network code for that.

(In particular, it does not use the Tomcat ).
It would be the same if your web application A was a stand-alone Java application, running 
outside of Tomcat.


It is a mystery why, in your previous installation, changing the Tomcat  
settings was changing the behaviour, but it has nothing to do with the issue you are 
dealing with now, as far as I can see.


What you should maybe try :
Outside of Tomcat, from a console on the same host as Tomcat B, try to run a console 
application to connect to the URL on server C.
For example, use "wget" or "curl", with the same target URL as what you used with the 
browser.  Maybe the Tomcat host simply cannot access server C ?







Thanks.

-Original Message-
From: André Warnier [mailto:a...@ice-sa.com] 
Sent: Wednesday, July 13, 2011 4:52 PM

To: Tomcat Users List
Subject: Re: Tomcat is not able to connect to IPV4 (Tomcat Version : 7.0.14)

Rohan Kadam wrote:
I really apologize for the confusion created. 


We are having an application, which is deployed on tomcat. Rather we are 
shipping the application with tomcat. After extraction (complete installation), 
the application is placed under the webapps directory.

The logs that I have shared is from the console, while debugging the 
application.


Ok, so I understand that it is your web application A, running inside your 
Tomcat B, which tries to access another webserver C.  And application A, to 
connect to webserver C, is using a httpclient object for that.
Right ?

To summarize more, we were facing a similar kind of problem in an 
earlier version of tomcat when we upgraded it from 5.5.26 to 5.5.30 
(We were able to access the link through browser,


What link to where ?
Do you mean that the browser (D) can connect directly to webserver C ?
But that when application A tries to connect to webserver C, you have the error 
below ?
(java.net.ConnectException: Connection refused: connect..)

  but not through application). To solve this issue, we modified the connector 
tag in the server.xml file.

   	  connectionTimeout="2" 
disableUploadTimeout="true" address="0.0.0.0" />




Still to make things clear : is this  inside of Tomcat B, or is it 
the connector of the other webserver C ?

As, it can be seen from above we have added address="0.0.0.0" in the connector tag, by doing so we were able to connect. 


Now, as per the new requirement, we are upgrading our tomcat from 5.5.30 to 
7.0.14(Since the folder structure is changed, we are shipping the fresh copy of 
tomcat). We have modified the connector tag as we have done for 5.5.30, but 
still no success. Please let me know if I am missing something or you want more 
information for the same.

Thanks.

-Original Message-
From: André Warnier [mailto:a...@ice-sa.com]
Sent: Wednesday, July 13, 2011 3:12 PM
To: Tomcat Users List
Subject: Re: Tomcat is not able to connect to IPV4 (Tomcat Version : 
7.0.14)


Rohan,

what you have never clearly explained until now in this rather long thread, is 
what you are exactly trying to do.

Is it :

a) an external application written in Java, which is trying to connect to 
Tomcat ?
(and the log lines below are from the logfile of that application)

OR

b) is it a webapp /within Tomcat/ which is trying to connect to some other 
server ?
(and the log lines below are from a Tomcat logfile)

Then, when you have answered the above, can you show us exactly which 
parameters you are using for the org.apache.commons.httpclient connection 
method, to set up this connection ?
(host, port, URL, whatever)



Rohan Kadam wrote:

Hi All,

I tried again. And still not successful, please find the stack trace 
below -


INFO: I/O exception (java.net.ConnectException) caught when 
processing request: Connection refused: connect Jul 13, 2011 12:10:36 
PM org.apache.commons.httpclient.HttpMethodDirector executeWithRetry

INFO: Retrying request
java.net.ConnectException: Connection refused: connect
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.PlainSocketImpl.doConnect(Unknown Source)
at java.net.PlainSocketImpl.connectToAddress(Unknown Source)
at java.net.PlainSocketImpl.connect(Unknown Source)
at java.net.SocksSocketImpl.connect(Unknown Source)
at java.net.Socket.connect(Unknown Source)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)

RE: Tomcat is not able to connect to IPV4 (Tomcat Version : 7.0.14)

2011-07-13 Thread Rohan Kadam 
Hi André,

Yes, whatever your understanding is correct. And also the connector tag is 
inside of Tomcat B.

Thanks.

-Original Message-
From: André Warnier [mailto:a...@ice-sa.com] 
Sent: Wednesday, July 13, 2011 4:52 PM
To: Tomcat Users List
Subject: Re: Tomcat is not able to connect to IPV4 (Tomcat Version : 7.0.14)

Rohan Kadam wrote:
> I really apologize for the confusion created. 
> 
> We are having an application, which is deployed on tomcat. Rather we are 
> shipping the application with tomcat. After extraction (complete 
> installation), the application is placed under the webapps directory.
> 
> The logs that I have shared is from the console, while debugging the 
> application.

Ok, so I understand that it is your web application A, running inside your 
Tomcat B, which tries to access another webserver C.  And application A, to 
connect to webserver C, is using a httpclient object for that.
Right ?

> 
> To summarize more, we were facing a similar kind of problem in an 
> earlier version of tomcat when we upgraded it from 5.5.26 to 5.5.30 
> (We were able to access the link through browser,

What link to where ?
Do you mean that the browser (D) can connect directly to webserver C ?
But that when application A tries to connect to webserver C, you have the error 
below ?
(java.net.ConnectException: Connection refused: connect..)

  but not through application). To solve this issue, we modified the connector 
tag in the server.xml file.
> 
>maxThreads="150" minSpareThreads="25" 
> maxSpareThreads="75"
> enableLookups="false" redirectPort="8443" acceptCount="100"
> connectionTimeout="2" 
> disableUploadTimeout="true" address="0.0.0.0" />
> 

Still to make things clear : is this  inside of Tomcat B, or is it 
the connector of the other webserver C ?

> As, it can be seen from above we have added address="0.0.0.0" in the 
> connector tag, by doing so we were able to connect. 
> 
> Now, as per the new requirement, we are upgrading our tomcat from 5.5.30 to 
> 7.0.14(Since the folder structure is changed, we are shipping the fresh copy 
> of tomcat). We have modified the connector tag as we have done for 5.5.30, 
> but still no success. Please let me know if I am missing something or you 
> want more information for the same.
> 
> Thanks.
> 
> -Original Message-
> From: André Warnier [mailto:a...@ice-sa.com]
> Sent: Wednesday, July 13, 2011 3:12 PM
> To: Tomcat Users List
> Subject: Re: Tomcat is not able to connect to IPV4 (Tomcat Version : 
> 7.0.14)
> 
> Rohan,
> 
> what you have never clearly explained until now in this rather long thread, 
> is what you are exactly trying to do.
> 
> Is it :
> 
> a) an external application written in Java, which is trying to connect to 
> Tomcat ?
> (and the log lines below are from the logfile of that application)
> 
> OR
> 
> b) is it a webapp /within Tomcat/ which is trying to connect to some other 
> server ?
> (and the log lines below are from a Tomcat logfile)
> 
> Then, when you have answered the above, can you show us exactly which 
> parameters you are using for the org.apache.commons.httpclient connection 
> method, to set up this connection ?
> (host, port, URL, whatever)
> 
> 
> 
> Rohan Kadam wrote:
>> Hi All,
>>
>> I tried again. And still not successful, please find the stack trace 
>> below -
>>
>> INFO: I/O exception (java.net.ConnectException) caught when 
>> processing request: Connection refused: connect Jul 13, 2011 12:10:36 
>> PM org.apache.commons.httpclient.HttpMethodDirector executeWithRetry
>> INFO: Retrying request
>> java.net.ConnectException: Connection refused: connect
>> at java.net.PlainSocketImpl.socketConnect(Native Method)
>> at java.net.PlainSocketImpl.doConnect(Unknown Source)
>> at java.net.PlainSocketImpl.connectToAddress(Unknown Source)
>> at java.net.PlainSocketImpl.connect(Unknown Source)
>> at java.net.SocksSocketImpl.connect(Unknown Source)
>> at java.net.Socket.connect(Unknown Source)
>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
>> at java.lang.reflect.Method.invoke(Unknown Source)
>> at 
>> org.apache.commons.httpclient.protocol.ReflectionSocketFactory.createSocket(ReflectionSocketFactory.java:139)
>> at 
>> org.apache.commons.httpclient.protocol.DefaultProtocolSocketFactory.createSocket(DefaultProtocolSocketFactory.java:124)
>> at 
>> org.apache.commons.httpclient.HttpConnection.open(HttpConnection.java:706)
>> at 
>> org.apache.commons.httpclient.MultiThreadedHttpConnectionManager$HttpConnectionAdapter.open(MultiThreadedHttpConnectionManager.java:1321)
>> at 
>> org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(HttpMethodDirector.java:386)

Re: Tomcat is not able to connect to IPV4 (Tomcat Version : 7.0.14)

2011-07-13 Thread André Warnier 

Caldarale, Charles R wrote:
From: Rohan Kadam [mailto:roha...@cybage.com] 
Subject: RE: Tomcat is not able to connect to IPV4 (Tomcat Version : 7.0.14)



I tried again. And still not successful, please find the stack trace below -



INFO: I/O exception (java.net.ConnectException) caught when processing request: 
Connection refused: connect
Jul 13, 2011 12:10:36 PM org.apache.commons.httpclient.HttpMethodDirector 
executeWithRetry
INFO: Retrying request
java.net.ConnectException: Connection refused: connect
at java.net.PlainSocketImpl.socketConnect(Native Method)

...

at com.symantec.lua.util.rcl.HttpHelper.open(HttpHelper.java:209)
at 
com.symantec.lua.manager.config.ConfigManagerUtil.testServerConnection(ConfigManagerUtil.java:82)
at 
com.symantec.lua.manager.config.ConfigManagerUtil.testServerConnection(ConfigManagerUtil.java:30)
at 
com.symantec.lua.presentation.common.ServerStatusAction.doAction(ServerStatusAction.java:148)
at 
com.ultimatetech.console.core.presentation.action.ActionThread.run(ActionThread.java:76)
at 
com.ultimatetech.console.core.presentation.action.CoreAction.execute(CoreAction.java:184)


Note that this has _nothing_ to do with Tomcat.  Contrary to your subject line, 
it's not Tomcat that is unable to connect to some external server, it's your 
webapp, in particular code in:

com.ultimatetech.console.core.presentation.action.CoreAction



Unless the external webserver to which this web application is trying to connect, is also 
a Tomcat server, and the  shown was the one of that webserver (C in my previous 
message).  This is what I was trying to confirm (or not), because Rohan's communications 
so far were not very clear in that respect.




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

Re: Tomcat is not able to connect to IPV4 (Tomcat Version : 7.0.14)

2011-07-13 Thread André Warnier 

Rohan Kadam wrote:
I really apologize for the confusion created. 


We are having an application, which is deployed on tomcat. Rather we are 
shipping the application with tomcat. After extraction (complete installation), 
the application is placed under the webapps directory.

The logs that I have shared is from the console, while debugging the 
application.


Ok, so I understand that it is your web application A, running inside your Tomcat B, which 
tries to access another webserver C.  And application A, to connect to webserver C, is 
using a httpclient object for that.

Right ?



To summarize more, we were facing a similar kind of problem in an earlier 
version of tomcat when we upgraded it from 5.5.26 to 5.5.30 (We were able to 
access the link through browser,


What link to where ?
Do you mean that the browser (D) can connect directly to webserver C ?
But that when application A tries to connect to webserver C, you have the error 
below ?
(java.net.ConnectException: Connection refused: connect..)

 but not through application). To solve this issue, we modified the connector tag in the 
server.xml file.






Still to make things clear : is this  inside of Tomcat B, or is it the 
connector of the other webserver C ?


As, it can be seen from above we have added address="0.0.0.0" in the connector tag, by doing so we were able to connect. 


Now, as per the new requirement, we are upgrading our tomcat from 5.5.30 to 
7.0.14(Since the folder structure is changed, we are shipping the fresh copy of 
tomcat). We have modified the connector tag as we have done for 5.5.30, but 
still no success. Please let me know if I am missing something or you want more 
information for the same.

Thanks.

-Original Message-
From: André Warnier [mailto:a...@ice-sa.com] 
Sent: Wednesday, July 13, 2011 3:12 PM

To: Tomcat Users List
Subject: Re: Tomcat is not able to connect to IPV4 (Tomcat Version : 7.0.14)

Rohan,

what you have never clearly explained until now in this rather long thread, is 
what you are exactly trying to do.

Is it :

a) an external application written in Java, which is trying to connect to 
Tomcat ?
(and the log lines below are from the logfile of that application)

OR

b) is it a webapp /within Tomcat/ which is trying to connect to some other 
server ?
(and the log lines below are from a Tomcat logfile)

Then, when you have answered the above, can you show us exactly which 
parameters you are using for the org.apache.commons.httpclient connection 
method, to set up this connection ?
(host, port, URL, whatever)



Rohan Kadam wrote:

Hi All,

I tried again. And still not successful, please find the stack trace below -

INFO: I/O exception (java.net.ConnectException) caught when processing request: 
Connection refused: connect
Jul 13, 2011 12:10:36 PM org.apache.commons.httpclient.HttpMethodDirector 
executeWithRetry
INFO: Retrying request
java.net.ConnectException: Connection refused: connect
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.PlainSocketImpl.doConnect(Unknown Source)
at java.net.PlainSocketImpl.connectToAddress(Unknown Source)
at java.net.PlainSocketImpl.connect(Unknown Source)
at java.net.SocksSocketImpl.connect(Unknown Source)
at java.net.Socket.connect(Unknown Source)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at 
org.apache.commons.httpclient.protocol.ReflectionSocketFactory.createSocket(ReflectionSocketFactory.java:139)
at 
org.apache.commons.httpclient.protocol.DefaultProtocolSocketFactory.createSocket(DefaultProtocolSocketFactory.java:124)
at 
org.apache.commons.httpclient.HttpConnection.open(HttpConnection.java:706)
at 
org.apache.commons.httpclient.MultiThreadedHttpConnectionManager$HttpConnectionAdapter.open(MultiThreadedHttpConnectionManager.java:1321)
at 
org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(HttpMethodDirector.java:386)
at 
org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMethodDirector.java:170)
at 
org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:396)
at 
org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:324)
at com.symantec.lua.util.rcl.HttpHelper.open(HttpHelper.java:209)
at 
com.symantec.lua.manager.config.ConfigManagerUtil.testServerConnection(ConfigManagerUtil.java:82)
at 
com.symantec.lua.manager.config.ConfigManagerUtil.testServerConnection(ConfigManagerUtil.java:30)
at 
com.symantec.lua.presentation.common.ServerStatusAction.doAction(ServerStatusAction.java:148)
at 
com.ultimatetech.console.core.presentation.action.ActionThread.run(ActionThread.java:76)

RE: Tomcat is not able to connect to IPV4 (Tomcat Version : 7.0.14)

2011-07-13 Thread Caldarale, Charles R 
> From: Rohan Kadam [mailto:roha...@cybage.com] 
> Subject: RE: Tomcat is not able to connect to IPV4 (Tomcat Version : 7.0.14)

> I tried again. And still not successful, please find the stack trace below -

> INFO: I/O exception (java.net.ConnectException) caught when processing 
> request: Connection refused: connect
> Jul 13, 2011 12:10:36 PM org.apache.commons.httpclient.HttpMethodDirector 
> executeWithRetry
> INFO: Retrying request
> java.net.ConnectException: Connection refused: connect
> at java.net.PlainSocketImpl.socketConnect(Native Method)
...
> at com.symantec.lua.util.rcl.HttpHelper.open(HttpHelper.java:209)
> at 
> com.symantec.lua.manager.config.ConfigManagerUtil.testServerConnection(ConfigManagerUtil.java:82)
> at 
> com.symantec.lua.manager.config.ConfigManagerUtil.testServerConnection(ConfigManagerUtil.java:30)
> at 
> com.symantec.lua.presentation.common.ServerStatusAction.doAction(ServerStatusAction.java:148)
> at 
> com.ultimatetech.console.core.presentation.action.ActionThread.run(ActionThread.java:76)
> at 
> com.ultimatetech.console.core.presentation.action.CoreAction.execute(CoreAction.java:184)

Note that this has _nothing_ to do with Tomcat.  Contrary to your subject line, 
it's not Tomcat that is unable to connect to some external server, it's your 
webapp, in particular code in:

com.ultimatetech.console.core.presentation.action.CoreAction

There's nothing Tomcat can do to overcome bugs in your code.

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is thus for use only by the intended recipient. If you received 
this in error, please contact the sender and delete the e-mail and its 
attachments from all computers.

RE: Tomcat is not able to connect to IPV4 (Tomcat Version : 7.0.14)

2011-07-13 Thread Rohan Kadam 
I really apologize for the confusion created. 

We are having an application, which is deployed on tomcat. Rather we are 
shipping the application with tomcat. After extraction (complete installation), 
the application is placed under the webapps directory.

The logs that I have shared is from the console, while debugging the 
application.

To summarize more, we were facing a similar kind of problem in an earlier 
version of tomcat when we upgraded it from 5.5.26 to 5.5.30 (We were able to 
access the link through browser, but not through application). To solve this 
issue, we modified the connector tag in the server.xml file.



As, it can be seen from above we have added address="0.0.0.0" in the connector 
tag, by doing so we were able to connect. 

Now, as per the new requirement, we are upgrading our tomcat from 5.5.30 to 
7.0.14(Since the folder structure is changed, we are shipping the fresh copy of 
tomcat). We have modified the connector tag as we have done for 5.5.30, but 
still no success. Please let me know if I am missing something or you want more 
information for the same.

Thanks.

-Original Message-
From: André Warnier [mailto:a...@ice-sa.com] 
Sent: Wednesday, July 13, 2011 3:12 PM
To: Tomcat Users List
Subject: Re: Tomcat is not able to connect to IPV4 (Tomcat Version : 7.0.14)

Rohan,

what you have never clearly explained until now in this rather long thread, is 
what you are exactly trying to do.

Is it :

a) an external application written in Java, which is trying to connect to 
Tomcat ?
(and the log lines below are from the logfile of that application)

OR

b) is it a webapp /within Tomcat/ which is trying to connect to some other 
server ?
(and the log lines below are from a Tomcat logfile)

Then, when you have answered the above, can you show us exactly which 
parameters you are using for the org.apache.commons.httpclient connection 
method, to set up this connection ?
(host, port, URL, whatever)



Rohan Kadam wrote:
> Hi All,
> 
> I tried again. And still not successful, please find the stack trace below -
> 
> INFO: I/O exception (java.net.ConnectException) caught when processing 
> request: Connection refused: connect
> Jul 13, 2011 12:10:36 PM org.apache.commons.httpclient.HttpMethodDirector 
> executeWithRetry
> INFO: Retrying request
> java.net.ConnectException: Connection refused: connect
> at java.net.PlainSocketImpl.socketConnect(Native Method)
> at java.net.PlainSocketImpl.doConnect(Unknown Source)
> at java.net.PlainSocketImpl.connectToAddress(Unknown Source)
> at java.net.PlainSocketImpl.connect(Unknown Source)
> at java.net.SocksSocketImpl.connect(Unknown Source)
> at java.net.Socket.connect(Unknown Source)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> at java.lang.reflect.Method.invoke(Unknown Source)
> at 
> org.apache.commons.httpclient.protocol.ReflectionSocketFactory.createSocket(ReflectionSocketFactory.java:139)
> at 
> org.apache.commons.httpclient.protocol.DefaultProtocolSocketFactory.createSocket(DefaultProtocolSocketFactory.java:124)
> at 
> org.apache.commons.httpclient.HttpConnection.open(HttpConnection.java:706)
> at 
> org.apache.commons.httpclient.MultiThreadedHttpConnectionManager$HttpConnectionAdapter.open(MultiThreadedHttpConnectionManager.java:1321)
> at 
> org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(HttpMethodDirector.java:386)
> at 
> org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMethodDirector.java:170)
> at 
> org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:396)
> at 
> org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:324)
> at com.symantec.lua.util.rcl.HttpHelper.open(HttpHelper.java:209)
> at 
> com.symantec.lua.manager.config.ConfigManagerUtil.testServerConnection(ConfigManagerUtil.java:82)
> at 
> com.symantec.lua.manager.config.ConfigManagerUtil.testServerConnection(ConfigManagerUtil.java:30)
> at 
> com.symantec.lua.presentation.common.ServerStatusAction.doAction(ServerStatusAction.java:148)
> at 
> com.ultimatetech.console.core.presentation.action.ActionThread.run(ActionThread.java:76)
> at 
> com.ultimatetech.console.core.presentation.action.CoreAction.execute(CoreAction.java:184)
> at 
> org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:419)
> at 
> org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:224)
> at 
> org.apache.struts.action.ActionServlet.process(ActionServlet.java:1196)
> at 
> org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:414)
> at javax.servlet.http.HttpServlet.servic

Re: Tomcat is not able to connect to IPV4 (Tomcat Version : 7.0.14)

2011-07-13 Thread André Warnier 

Rohan,

what you have never clearly explained until now in this rather long thread, is what you 
are exactly trying to do.


Is it :

a) an external application written in Java, which is trying to connect to 
Tomcat ?
(and the log lines below are from the logfile of that application)

OR

b) is it a webapp /within Tomcat/ which is trying to connect to some other 
server ?
(and the log lines below are from a Tomcat logfile)

Then, when you have answered the above, can you show us exactly which parameters you are 
using for the org.apache.commons.httpclient connection method, to set up this connection ?

(host, port, URL, whatever)



Rohan Kadam wrote:

Hi All,

I tried again. And still not successful, please find the stack trace below -

INFO: I/O exception (java.net.ConnectException) caught when processing request: 
Connection refused: connect
Jul 13, 2011 12:10:36 PM org.apache.commons.httpclient.HttpMethodDirector 
executeWithRetry
INFO: Retrying request
java.net.ConnectException: Connection refused: connect
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.PlainSocketImpl.doConnect(Unknown Source)
at java.net.PlainSocketImpl.connectToAddress(Unknown Source)
at java.net.PlainSocketImpl.connect(Unknown Source)
at java.net.SocksSocketImpl.connect(Unknown Source)
at java.net.Socket.connect(Unknown Source)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at 
org.apache.commons.httpclient.protocol.ReflectionSocketFactory.createSocket(ReflectionSocketFactory.java:139)
at 
org.apache.commons.httpclient.protocol.DefaultProtocolSocketFactory.createSocket(DefaultProtocolSocketFactory.java:124)
at 
org.apache.commons.httpclient.HttpConnection.open(HttpConnection.java:706)
at 
org.apache.commons.httpclient.MultiThreadedHttpConnectionManager$HttpConnectionAdapter.open(MultiThreadedHttpConnectionManager.java:1321)
at 
org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(HttpMethodDirector.java:386)
at 
org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMethodDirector.java:170)
at 
org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:396)
at 
org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:324)
at com.symantec.lua.util.rcl.HttpHelper.open(HttpHelper.java:209)
at 
com.symantec.lua.manager.config.ConfigManagerUtil.testServerConnection(ConfigManagerUtil.java:82)
at 
com.symantec.lua.manager.config.ConfigManagerUtil.testServerConnection(ConfigManagerUtil.java:30)
at 
com.symantec.lua.presentation.common.ServerStatusAction.doAction(ServerStatusAction.java:148)
at 
com.ultimatetech.console.core.presentation.action.ActionThread.run(ActionThread.java:76)
at 
com.ultimatetech.console.core.presentation.action.CoreAction.execute(CoreAction.java:184)
at 
org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:419)
at 
org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:224)
at 
org.apache.struts.action.ActionServlet.process(ActionServlet.java:1196)
at org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:414)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:627)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:729)
at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:269)
at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
at 
com.ultimatetech.console.filters.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:82)
at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215)
at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
at 
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
at 
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:172)
at 
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at 
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117)
at 
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:108)
at 
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:174)
at 
org.apache.coyote.http11.Http11AprProcessor.process(Http11AprProcessor.java:843)
at 
org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.process(Http11AprProtocol.java:679)
at 
org.apache.tomcat.util.net.AprEnd

RE: Tomcat is not able to connect to IPV4 (Tomcat Version : 7.0.14)

2011-07-13 Thread Rohan Kadam 
Hi All,

I tried again. And still not successful, please find the stack trace below -

INFO: I/O exception (java.net.ConnectException) caught when processing request: 
Connection refused: connect
Jul 13, 2011 12:10:36 PM org.apache.commons.httpclient.HttpMethodDirector 
executeWithRetry
INFO: Retrying request
java.net.ConnectException: Connection refused: connect
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.PlainSocketImpl.doConnect(Unknown Source)
at java.net.PlainSocketImpl.connectToAddress(Unknown Source)
at java.net.PlainSocketImpl.connect(Unknown Source)
at java.net.SocksSocketImpl.connect(Unknown Source)
at java.net.Socket.connect(Unknown Source)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at 
org.apache.commons.httpclient.protocol.ReflectionSocketFactory.createSocket(ReflectionSocketFactory.java:139)
at 
org.apache.commons.httpclient.protocol.DefaultProtocolSocketFactory.createSocket(DefaultProtocolSocketFactory.java:124)
at 
org.apache.commons.httpclient.HttpConnection.open(HttpConnection.java:706)
at 
org.apache.commons.httpclient.MultiThreadedHttpConnectionManager$HttpConnectionAdapter.open(MultiThreadedHttpConnectionManager.java:1321)
at 
org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(HttpMethodDirector.java:386)
at 
org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMethodDirector.java:170)
at 
org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:396)
at 
org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:324)
at com.symantec.lua.util.rcl.HttpHelper.open(HttpHelper.java:209)
at 
com.symantec.lua.manager.config.ConfigManagerUtil.testServerConnection(ConfigManagerUtil.java:82)
at 
com.symantec.lua.manager.config.ConfigManagerUtil.testServerConnection(ConfigManagerUtil.java:30)
at 
com.symantec.lua.presentation.common.ServerStatusAction.doAction(ServerStatusAction.java:148)
at 
com.ultimatetech.console.core.presentation.action.ActionThread.run(ActionThread.java:76)
at 
com.ultimatetech.console.core.presentation.action.CoreAction.execute(CoreAction.java:184)
at 
org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:419)
at 
org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:224)
at 
org.apache.struts.action.ActionServlet.process(ActionServlet.java:1196)
at org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:414)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:627)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:729)
at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:269)
at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
at 
com.ultimatetech.console.filters.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:82)
at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215)
at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
at 
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
at 
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:172)
at 
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at 
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117)
at 
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:108)
at 
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:174)
at 
org.apache.coyote.http11.Http11AprProcessor.process(Http11AprProcessor.java:843)
at 
org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.process(Http11AprProtocol.java:679)
at 
org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:1293)
at java.lang.Thread.run(Unknown Source)

I am able to open the link through browser but not through application. Also I 
have checked firewall setting, it is not blocking any ports.

Please suggest.

Thanks,
Rohan Kadam.

-Original Message-
From: Christopher Schultz [mailto:ch...@christopherschultz.net] 
Sent: Thursday, July 07, 2011 1:55 AM
To: Tomcat Users List
Subject: Re: Tomcat is not able to connect to IPV4 (Tomcat Version : 7.0.14)

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Rohan,

On 7/5/2011 12:18 AM, Rohan Kadam wrote:
> I apologize for the typo made by me. I used  only 
> "-Djava.net