Re: Is there a way to abruptly force a connection closed without returning anything?

[Konstantin Kolinko]

2015-01-14 6:28 GMT+03:00 Christopher Schultz > Jesse,
> On 1/13/15 6:29 PM, Jesse Barnum wrote:
>> I need the ability to examine the POST data from a request,
>> examine it, and either respond to it or close the connection
>> without returning any result, not even a 200 OK status.
>>
>> The reason for this is because I’m getting overwhelmed with
>> thousands of invalid requests per second, which are racking up
>> bandwidth fees. The requests can’t be traced to an IP address, so I
>> can’t just block them in a firewall or Apache - I need to actually
>> use logic in my Tomcat app to figure out which requests to respond
>> to.
>>
>> Is there a way to force Tomcat to just drop the connection and
>> close the socket without sending a response?
>
> You can't close the stream form your code, Tomcat will ignore it, so a
> response flush, and return a 200 response anyway.
>
> I'm curious, what's wrong with an empty 200 response? It's only a
> couple of bytes, but I suppose if you are getting millions per hous,
> you could still incur bandwidth costs...

response.setHeader("Connection", "close") will cause Tomcat to close
the connection (i.e. do not use keep-alive that is default for
HTTP/1.1 requests).

Response body may be empty but by default the response includes HTTP
status code and reason phrase and some headers.
Is that too much?

> You might be able to do this with a Valve, but then you might have
> problems with your web application needing to provide the logic to
> determine whether or not to accept the request.

It can be implemented in two tiers:

a) an application sets an attribute on request or uses some specific
status code on the response.

b) a valve detects presence of the attribute or status code and closes
the connection.

You have not mentioned your version of Tomcat.

For a pointer, note the following enum value in the source code
(available in the current 7.0.x, 8.0.x):

org.apache.coyote.ErrorState.CLOSE_NOW

org.apache.coyote.ErrorState.isIoAllowed()

Best regards,
Konstantin Kolinko

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

Re: Occasional long wait for a JDBC connection

[Darren Davis]

On Tue, Jan 13, 2015 at 8:39 PM, Christopher Schultz <
ch...@christopherschultz.net> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Darren,
>
> (Sorry... just had to remove that monstrous stack trace...)
>
> On 1/13/15 5:04 PM, Darren Davis wrote:
> > Hi Christopher.  Yes, we've tried a show process list and can find
> > no evidence of the validation query running on mysql.
>
> Strange. Maybe you are waiting for the db server's buffer to flush or
> something like that.
>
>
I think this is because the client thinks it still has an open connection,
the client net stat command shows an open connection over port 3306, at
least for a few minutes after it's killed by the load balancer.  The Server
loses its connection in netstat immediately.


> > We also just tried an experiment outside of Tomcat completely, but
> > connecting to a downed web server host and manually opening up a
> > mysql client connection to the data server and executing a single
> > command.
> >
> > We left that client window idle for an hour and 5 minutes, and
> > attempted to execute a simple select count(*) command against a
> > tiny table.  The client attempted to execute the query, and a
> > NetStat on that box showed an open connection between the two
> > servers using port 3306.  We also checked the process list during
> > this time and could not find any queries at all from the sever in
> > question.
> >
> > At about the 15 minute wait mark, the client finally came back with
> > this message: "ERROR 2013 (HY000): Lost connection to MySQL server
> > during query.
>
> Was this with the MySQL command-line client? What query did you issue
> ("SELECT 1")?
>
>
Yes, it was just the command line client, and we issued a select count(*)
from a table with a couple rows in it.


> > Attempting the execute the command a 2nd time (using the up
> > arrow), re-established the connection and it ran perfectly in a few
> > milliseconds.
>
> That's interesting. I've never experienced anything like that with
> MySQL, but we use a VLAN between our application and database servers
> with no hardware firewall, so we don't have any connection timeout
> problems. Also, when connections are dropped due to inactivity, they
> re-connect without any problems.
>
> > I checked the mysql configuration and it is set to the default
> > values for keeping connections/interactive connections open (for 8
> > hours), so it seems that maybe the Cisco firewall between the two
> > servers is terminating connections out from under us, but in a way
> > what the O/S cannot detect it.
>
> What if you set that idle connection timeout to something like 5
> minutes? Can you reproduce this issue more quickly? Can you look at
> the fw configuration to see if you can change the idle timeout /down/
> to something more testable?
>
> As part of our move to the new versions of Tomcat/Java, we are in a new
cloud environment which features a different type of firewall.  The
provider confirmed to us late today, that it is configured to kill "idle"
TCP connections after an hour, which is something our old firewall didn't
do.

Because we sometimes have low traffic during this time of the year,
especially on the weekends, what we think is happening is that one or more
of the minimum 10 connections is going unused for more than an hour, and
since we didn't have any connection testing while idle turned on, they were
being killed by the firewall out from under the pool, and depending on how
soon they were used after that, we would run into the 15 minute delay
before they were deemed lost, and replaced with a new connection.


> > I've also fired up the yourKit profiler on this box and am seeing
> > other threads which have had to wait in the same
> > SocketInputStream.read code, all three started a few seconds apart,
> > it just wasn't detected as a deadlock, because it took place
> > outside of any synchronized methods.
>
> What makes you think it's deadlock? Deadlock is a very specific thing.
> Just because many threads are waiting in SocketInputStream.read
> doesn't mean there are any threading issues at all. I suspect that
> each SocketInputStream is distinct and only in use by a single thread.
> The threads are blocked on I/O, right? So they aren't waiting on a
> monitor. The best you could do would be to find the native file
> descriptor for each socket and determine that they are different from
> each other. I would be very surprised if they are the same, used
> across threads. If you *are* using Connection objects across threads,
> you should be very careful. Connection objects ought to be threadsafe
> (I think) but use of Statement and ResultSet objects across threads is
> a terrible idea.
>
> We have a couple of synchronized methods in two of our services which hold
locks in order to update a centralized record.  We realize this is a bad
design and are already working on re-factoring this code to remove this
need.  We've have a few instances where the 15 minute wait has 

Re: question on EL Lambda expression in a JSP on Tomcat 8_0_15

[Anup Aggarwal]

Thanks,
Bug 57441  if
filed for this issue.

On Tue, Jan 13, 2015 at 5:29 PM, Mark Thomas  wrote:

> On 13/01/2015 21:11, Anup Aggarwal wrote:
> > Hi,
> >
> > I am trying to run this EL Lambda expression in a JSP on Tomcat 8_0_15
> >
> > ${(incr = x->x+1; incr(10)}
> >
> > But I get this exception
> >
> > org.apache.jasper.JasperException: /TestLambda.jsp (line: 44, column: 42)
> > The function incr must be used with a prefix when a default namespace is
> > not specified
> >
> >
> org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:42)
>
> That looks like a bug in the JSP parser. Please file a Bugzilla issue.
>
> Mark
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: Occasional long wait for a JDBC connection

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Darren,

(Sorry... just had to remove that monstrous stack trace...)

On 1/13/15 5:04 PM, Darren Davis wrote:
> Hi Christopher.  Yes, we've tried a show process list and can find
> no evidence of the validation query running on mysql.

Strange. Maybe you are waiting for the db server's buffer to flush or
something like that.

> We also just tried an experiment outside of Tomcat completely, but 
> connecting to a downed web server host and manually opening up a
> mysql client connection to the data server and executing a single
> command.
> 
> We left that client window idle for an hour and 5 minutes, and
> attempted to execute a simple select count(*) command against a
> tiny table.  The client attempted to execute the query, and a
> NetStat on that box showed an open connection between the two
> servers using port 3306.  We also checked the process list during
> this time and could not find any queries at all from the sever in
> question.
> 
> At about the 15 minute wait mark, the client finally came back with
> this message: "ERROR 2013 (HY000): Lost connection to MySQL server
> during query.

Was this with the MySQL command-line client? What query did you issue
("SELECT 1")?

> Attempting the execute the command a 2nd time (using the up
> arrow), re-established the connection and it ran perfectly in a few
> milliseconds.

That's interesting. I've never experienced anything like that with
MySQL, but we use a VLAN between our application and database servers
with no hardware firewall, so we don't have any connection timeout
problems. Also, when connections are dropped due to inactivity, they
re-connect without any problems.

> I checked the mysql configuration and it is set to the default
> values for keeping connections/interactive connections open (for 8
> hours), so it seems that maybe the Cisco firewall between the two
> servers is terminating connections out from under us, but in a way
> what the O/S cannot detect it.

What if you set that idle connection timeout to something like 5
minutes? Can you reproduce this issue more quickly? Can you look at
the fw configuration to see if you can change the idle timeout /down/
to something more testable?

> I've also fired up the yourKit profiler on this box and am seeing
> other threads which have had to wait in the same
> SocketInputStream.read code, all three started a few seconds apart,
> it just wasn't detected as a deadlock, because it took place
> outside of any synchronized methods.

What makes you think it's deadlock? Deadlock is a very specific thing.
Just because many threads are waiting in SocketInputStream.read
doesn't mean there are any threading issues at all. I suspect that
each SocketInputStream is distinct and only in use by a single thread.
The threads are blocked on I/O, right? So they aren't waiting on a
monitor. The best you could do would be to find the native file
descriptor for each socket and determine that they are different from
each other. I would be very surprised if they are the same, used
across threads. If you *are* using Connection objects across threads,
you should be very careful. Connection objects ought to be threadsafe
(I think) but use of Statement and ResultSet objects across threads is
a terrible idea.

> It seems that sometime around the hour mark, connections get
> dropped, so we're thinking that either adding idle checking or
> dropping old connections may help us avoid this.  Although we are a
> little concerned by the various Connector / J alleged socket read
> issues which may as a possible problem.

I don't think you should blame Connector/J at this point. They may
have ClassLoader pinning issues (don't get me started), but the driver
is fairly robust and mature.

> We're running an older 5.1.18 version of the Connector/J driver,
> but aren't sure of moving to the latest .34 release would change
> anything.

We are also still using 5.1.18 and have never had any of these kinds
of issues. I would highly suspect the network environment. See what
you can find out by tinkering with the firewall and db idle policies.
You may find that the pipe across the network gets into a state where
the client is sure the connection is still valid, but it's simply
never going to return any data. In that case, you'll need to figure
out how to have that connection fail faster.

Do you have a read-timeout set on your driver?

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJUteT3AAoJEBzwKT+lPKRY7BUP/3IV0Xsakr3rWRpqnro1IbUl
nbNHHIm9fqG+7mbvkeIQIE5XnZvA822HZvp9whC+4499kfQZNtrT0IIj1F20YH5r
SMMkalCbY6XIzj1ST4aPf7YE2MlBtBwFZUwIGG2aT2XUKwSwHVdTcQxI2H4sG5vf
iCkvS7YdJg5h6QSj5CQHg6dnsVR2hbF42tftti33hOsRPZu3cXOe0ajrXsoimMuk
WWt+hpk8rjWtEnrMgaKlyntKGAI2tqXYVzPxraR3wwevm1tbHjHk2U3hFrq9teuV
FA57RhWTlba/OJ+ph+LEiT39IdEdzESspTI+JeQvN5LJEsaMpxmRpnmLnhD/3EXx
aNRze3eRw5M7qG0CcMduCMFe1j2i8TCwBLtHHJnplXWzve9PgqbJBtk7acJpn/Ls
54j23u5Z26TvAAJxi

Re: Is there a way to abruptly force a connection closed without returning anything?

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Jesse,

On 1/13/15 6:29 PM, Jesse Barnum wrote:
> I need the ability to examine the POST data from a request,
> examine it, and either respond to it or close the connection
> without returning any result, not even a 200 OK status.
> 
> The reason for this is because I’m getting overwhelmed with
> thousands of invalid requests per second, which are racking up
> bandwidth fees. The requests can’t be traced to an IP address, so I
> can’t just block them in a firewall or Apache - I need to actually
> use logic in my Tomcat app to figure out which requests to respond
> to.
> 
> Is there a way to force Tomcat to just drop the connection and
> close the socket without sending a response?

You can't close the stream form your code, Tomcat will ignore it, so a
response flush, and return a 200 response anyway.

I'm curious, what's wrong with an empty 200 response? It's only a
couple of bytes, but I suppose if you are getting millions per hous,
you could still incur bandwidth costs...

You might be able to do this with a Valve, but then you might have
problems with your web application needing to provide the logic to
determine whether or not to accept the request.

When you say "can't be traced to an IP address" do you mean that you
are seeing invalid requests coming from all over the place, or that
the requests don't include a source IP address (which seems fishy)?

A few options that might achieve your goal without using the technique
you describe:

1. Use client authentication; unauthorized clients can't even handshake
   Downsides: SSL overhead

2. Use a VPN (which essentially uses client authentication)
   Downsides: VPNs really, really suck

3. (As Mark E suggests) Use mod_security with httpd
   I know this will seriously separate your business logic form your
web application, but perhaps there is a simple set of criteria that
might eliminate a significant portion of the requests, thus solving
the problem "well enough"

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJUteJIAAoJEBzwKT+lPKRY13MP+gM+q3VtnKYHRwksGTnf2ZO7
mCiBZYudoYUqaWwzumIsi3bOp7dMjnFlkjw9/nG68x5O8vIIPxOY13n30gA2YXaN
4B4+Wfaf6nFTYgq84IfcNs6qJ1GOR2dfasVkeGbhfqslcgkkl/05VOBz2f5tK3mI
Kc3j1FygiXc2R8fG5KLZREgnRmVxNUwxsRDL9pZTj/okQyg2fLlljmCwDFHvuLLx
19W1x3CeeeAJD8/Akp8WCsjAsgdnYvg7r9ynC9DFBFKfjztZR+/QXK3mXxAYLziS
KadzbE/k3Am1VLA5dAD5VSFTOmCMPkt2i0INIrKvnf3Hj6QpU1B+qTr++dYTZUBb
F1n1GIXGYV1YJZFMIcZu7f4gTyJiKDCQQ6im+PJVfpG5zhVrlKv2teAttfT7qEET
pILu71NYVN5ysT11pYM8xoBj9zv1v/V9sOyvWpmLi6oPrJSnlqMKMfoXqlNRwq9q
DVGL0GkDR83MIChe+yen+/3QDnBaXnQTUGlG2U3tDns7yChAVbhu0TjT/uzxNRvc
15DUUrnvve8R8c/49tXumgPnb/fGrL/jooCk2SiKNHF2HsoxoNY5VWYybIzXw+Aw
0SpgVV/By4RMOEWGevhIagczMeakUm1y3v6dX9hVjMm+lN4Fr5C4TteKRtComrn0
KuaAooL3NTb+/yL/s49S
=zen8
-END PGP SIGNATURE-

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

RE: Slow HTTP Rquest via Tomcat

[Thone Soungpanya]

Hello Andre,

Yes sorry the logs files are not clear. We have so much traffic going through 
the Tomcat and many clients connecting which it seems to be logging for 
different sessions at different time. We really have no control to sort this 
out as the connections are simultaneous. 

Our reordering of the logs and the entries listed may be correct. I cannot tell 
myself if it is linked to the same session. We tried to use Session IDs to add 
against the entries we make for servlet code but that somehow does not follow 
in order.

As for your comment on web.xml and retriggering the redeployment of the web app 
folders, yes, I am wondering why this is happening if that is the case. There 
is a web.xml in each WEB-INF folder however nothing never change. Also, this is 
all it has in it below where it is just the servlet name and mapping. Can this 
really retrigger it if it never changes?

http://java.sun.com/xml/ns/j2ee 
http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd"; version="2.4"> 
Peoplesoft Connector 
PeopleSoft Connector Applications. 
 
PSConnectorServlet 
PSConnectorServlet 
 
 
PSConnectorServlet 
/servlet/PSConnectorServlet 
 


Also, yes, autodeploy is equal to "True". I will check with my colleague to see 
if we can test with false because this will impact all web folders. Do you see 
any impact if this was "false"? Why is it defaulted to "true"?

Thanks,

Thone

-Original Message-
From: André Warnier [mailto:a...@ice-sa.com] 
Sent: Tuesday, January 13, 2015 2:04 PM
To: Tomcat Users List
Subject: Re: Slow HTTP Rquest via Tomcat

Christopher Schultz wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> Thone,
> 
> On 1/13/15 1:05 PM, Thone Soungpanya wrote:
>> Hello Andre,
>>
>> I do not think it is an DNS lookup issue but I'll check on it.
>>
>> Yes we actually have logs but it does not tell us much. We added 
>> additional logging in our servlet code to tell us when and what the 
>> code is doing. I have attached a log for 1 connection which took 
>> about 1 minute and 23 seconds to complete. I have eliminated all 
>> sensitive information with "XX". During this 
>> time, there would be other connections too simultaneously.
>>
>> Some information on the request: 1) HTTP request initiated at
>> 16:11:06 to Tomcat.
> 
> This is a very confusing log file... from latest-to-oldest.

+10

> 
> Before #2 happens, Tomcat reloads. Many (all?) web applications were 
> re-loaded. Was that expected?
> 
>> 2) Connection to Third Party System happened at 16:12:22. You can see 
>> it on line 38 with following text "2015-01-12 16:12:22,426 INFO 
>> 06E4074221FF93C2827079EBC2102847; begin request"
> 
> Okay.
> 
>> 3) Response back to Tomcat from Third Party System at 16:12:29
> 
> This does not appear in the log.
> 
>> So it seems that between point#1 and point #2, there was about a 1 
>> minute and 16 seconds delay before connection to the third party.
>> Point #2 to Point #3 only took 7 seconds.
>>
>> Can you or anyone see what may be the issue from the logs?
> 

Maybe if you provide clearer logs, having some real information allowing to 
distinguish one request processing sequence from another.

> Tomcat is reloading in the middle of the request?

Right, that's what it looks like.
And not only this one time.
 From the (very difficult) look of it, it seems that this system is spending 
its time reloading its applications almost continuously.
Using some nifty features of Notepad++, I have extracted and re-ordered what I 
believe are log lines relating to one webapp (and I don't really know for sure 
if this is one request, or several).
See attached if it makes it, it's probably clearer.  Otherwise, I have also 
pasted these log lines below.

I have selected lines related to a webapp named "ps_1.5_8.53.10", and 
re-ordered them in a logical older-to-younger top-down sequence.

Examining thse lines, we see :
- at 2015-01-12 16:11:07,396 : what appears to be the beginning of a 
redeployment of that webapp
- at  2015-01-12 16:11:08,108 (one second later) : what appears to be the 
beginning of a request to that webapp
- at 2015-01-12 16:11:15,918 (7 seconds later), what seems to be the beginning 
of yet another redeployment of that webapp
- at 2015-01-12 16:11:21,037, another request starting

In-between, there are a lot of other lines apparently showing similar (other) 
webapps redeployments, and maybe other lines related to that same webapp, but 
all quite difficult to identify because there is no common marker.

That logfile is very confusing, and as a result take this with a grain of salt, 
but I get the funny feeling that this webapp, when it responds to a request, 
may be modifying something (it's own WEB-INF/web.xml ?) in such a way that it 
triggers a re-deployment of that same very application by Tomcat, at each 
request.
(And similarly for the other ones)

For a start, does the  tag of that Tomcat instance have an 
autodeploy="true" 
attribute ? (see in conf/server.x

Re: Is there a way to abruptly force a connection closed without returning anything?

[Mark Eggers]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 1/13/2015 4:03 PM, Jesse Barnum wrote:
>> On Jan 13, 2015, at 6:46 PM, Mark Eggers
>>  wrote:
>> 
>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1
>> 
>> On 1/13/2015 3:29 PM, Jesse Barnum wrote:
>>> I need the ability to examine the POST data from a request,
>>> examine it, and either respond to it or close the connection
>>> without returning any result, not even a 200 OK status.
>>> 
>>> The reason for this is because I’m getting overwhelmed with 
>>> thousands of invalid requests per second, which are racking up 
>>> bandwidth fees. The requests can’t be traced to an IP address,
>>> so I can’t just block them in a firewall or Apache - I need to
>>> actually use logic in my Tomcat app to figure out which
>>> requests to respond to.
>>> 
>>> Is there a way to force Tomcat to just drop the connection and 
>>> close the socket without sending a response?
>>> 
>>> --Jesse Barnum, President, 360Works
>>> 
>> 
>> Possibly with mod_security?
>> 
>> https://www.modsecurity.org/
>> 
>> You can add this to Apache HTTPD if you're fronting Tomcat with
>> it, or you can check out the Java implementation here:
>> 
>> http://blog.spiderlabs.com/2013/09/modsecurity-for-java-beta-testers-needed.html
>>
>>
>> 
I have used mod_security, and while it's somewhat a beast, it does a
>> great job at protecting web applications.
>> 
>> I have not used the Java version.
>> 
>> . . . just my two cents /mde/
> 
> Thanks for the suggestion, but that won’t do what I need. I need to
> examine the request and use business logic in my web app to
> determine whether or not to respond to the request.
> 
> --Jesse Barnum, President, 360Works http://www.360works.com Product
> updates and news on http://facebook.com/360Works (770) 234-9293 ==
> Don't lose your data! http://360works.com/safetynet/ for FileMaker
> Server ==

Yep, writing business logic as a set of custom rules might be a bit of
work. I've had to write custom rules in the past, and they can get
complicated quickly.

On the plus side, with mod_security the Apache HTTPD server does the
work, logs the requests, and you can possibly start to see patterns
where you could short-circuit the tests.

It's also in one place, so you wouldn't have to duplicate the effort
(unless each application has a different set of failure rules).

. . . just my two cents
/mde/

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBAgAGBQJUtbXRAAoJEEFGbsYNeTwt/80H/19/x+lWs1SxpkzqQv00aY35
tpTB9gxbJF3RGTvDiJpMbhh7bcue+P6upEPTNkxBLN5duuffztb+3yP6ZTa/dRa6
ACdk2ENNhp7y/aBtB2nDoCrQF2XAB+bj//E08p7Ap4H6ZjsCz60N+jZQ2cWwv48W
KGQp3iXyZBN1Fe382YzaEdRpobQ+1evG0DGTIpeV0JCxAGk686pFMm2Tiv4YQcXl
cIXjPfyhhfD7lMsxlLTNtfbrFgoLOAuw76G1V+FAOCH5VhMslA7z0QxfbumEqvR2
S37klL8QjEhYH2VeQZJDLsa5V2rELR+2Cpr2B3Wa+vH+REC4odUPkYcxMTyUJEQ=
=OZ6s
-END PGP SIGNATURE-

---
This email is free from viruses and malware because avast! Antivirus protection 
is active.
http://www.avast.com


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

Re: question on EL Lambda expression in a JSP on Tomcat 8_0_15

[Konstantin Kolinko]

2015-01-14 0:11 GMT+03:00 Anup Aggarwal :
> Hi,
>
> I am trying to run this EL Lambda expression in a JSP on Tomcat 8_0_15
>
> ${(incr = x->x+1; incr(10)}
>
> But I get this exception
>
> org.apache.jasper.JasperException: /TestLambda.jsp (line: 44, column: 42)
> The function incr must be used with a prefix when a default namespace is
> not specified
>
> org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:42)
>

An invalid EL. The '(' in '${(' has no pair.


Best regards,
Konstantin Kolinko

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

Re: Is there a way to abruptly force a connection closed without returning anything?

[Jesse Barnum]

> On Jan 13, 2015, at 6:46 PM, Mark Eggers  
> wrote:
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> On 1/13/2015 3:29 PM, Jesse Barnum wrote:
>> I need the ability to examine the POST data from a request, examine
>> it, and either respond to it or close the connection without
>> returning any result, not even a 200 OK status.
>> 
>> The reason for this is because I’m getting overwhelmed with
>> thousands of invalid requests per second, which are racking up
>> bandwidth fees. The requests can’t be traced to an IP address, so I
>> can’t just block them in a firewall or Apache - I need to actually
>> use logic in my Tomcat app to figure out which requests to respond
>> to.
>> 
>> Is there a way to force Tomcat to just drop the connection and
>> close the socket without sending a response?
>> 
>> --Jesse Barnum, President, 360Works
>> 
> 
> Possibly with mod_security?
> 
> https://www.modsecurity.org/
> 
> You can add this to Apache HTTPD if you're fronting Tomcat with it, or
> you can check out the Java implementation here:
> 
> http://blog.spiderlabs.com/2013/09/modsecurity-for-java-beta-testers-needed.html
> 
> I have used mod_security, and while it's somewhat a beast, it does a
> great job at protecting web applications.
> 
> I have not used the Java version.
> 
> . . . just my two cents
> /mde/

Thanks for the suggestion, but that won’t do what I need. I need to examine the 
request and use business logic in my web app to determine whether or not to 
respond to the request.

--Jesse Barnum, President, 360Works
http://www.360works.com
Product updates and news on http://facebook.com/360Works
(770) 234-9293
== Don't lose your data! http://360works.com/safetynet/ for FileMaker Server ==


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

Re: Is there a way to abruptly force a connection closed without returning anything?

[Mark Eggers]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 1/13/2015 3:29 PM, Jesse Barnum wrote:
> I need the ability to examine the POST data from a request, examine
> it, and either respond to it or close the connection without
> returning any result, not even a 200 OK status.
> 
> The reason for this is because I’m getting overwhelmed with
> thousands of invalid requests per second, which are racking up
> bandwidth fees. The requests can’t be traced to an IP address, so I
> can’t just block them in a firewall or Apache - I need to actually
> use logic in my Tomcat app to figure out which requests to respond
> to.
> 
> Is there a way to force Tomcat to just drop the connection and
> close the socket without sending a response?
> 
> --Jesse Barnum, President, 360Works
> 

Possibly with mod_security?

https://www.modsecurity.org/

You can add this to Apache HTTPD if you're fronting Tomcat with it, or
you can check out the Java implementation here:

http://blog.spiderlabs.com/2013/09/modsecurity-for-java-beta-testers-needed.html

I have used mod_security, and while it's somewhat a beast, it does a
great job at protecting web applications.

I have not used the Java version.

. . . just my two cents
/mde/
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBAgAGBQJUta46AAoJEEFGbsYNeTwtDI4H/iImbmftf+KIxBsPo1Gx0+ZD
mFPdlgDegHDQRRlDxGFShoyAQcKX9O/xIfy04P6SrOLdxQJ5sBVv5uEN7qYp24Ar
WLz0Iwy/zGWpA0Y7Gq1AXRK64oGvrmJJ8KMLwXu9eBUCQiK8eIJvNZdKRJi/7Ki/
FLxchfA8E9DGA3B59uebuSYgmVobj1hCK5/+z2DMNNSZh0nTWb29dbzW/BCC8/e5
y123ZapWPS1ze2bjkgC6FZmZD9eH2JN1QTC0966R4G9K3LmKpCS3SyxZisxfRPUh
AZVhvJ9tV5jzaMytveOj2MSltUlqJA/PitQIbFP3plP3hyB3lSFwacyZiePOeQ8=
=bQTB
-END PGP SIGNATURE-

---
This email is free from viruses and malware because avast! Antivirus protection 
is active.
http://www.avast.com


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

Is there a way to abruptly force a connection closed without returning anything?

[Jesse Barnum]

I need the ability to examine the POST data from a request, examine it, and 
either respond to it or close the connection without returning any result, not 
even a 200 OK status.

The reason for this is because I’m getting overwhelmed with thousands of 
invalid requests per second, which are racking up bandwidth fees. The requests 
can’t be traced to an IP address, so I can’t just block them in a firewall or 
Apache - I need to actually use logic in my Tomcat app to figure out which 
requests to respond to.

Is there a way to force Tomcat to just drop the connection and close the socket 
without sending a response?

--Jesse Barnum, President, 360Works

Re: autoDeploy underlying old failed versions

[Mark Thomas]

On 13/01/2015 22:25, Jeff Storey wrote:
> I have autoDeploy and undeployOldVersions enabled on my Tomcat server
> and I am using parallel deployments. The issue I'm having is that old
> versions that have errors in their startup are not removed. Let's say
> I deploy the following apps:
> 
> myapp##001.war
> myapp##002.war
> 
> 
> If myapp#001.war failed during startup, and I deploy myapp##002,
> requests are properly routed to the new version, by myapp#001 stays
> around. When I then deploy myapp#003, myapp#002 is removed, but
> myapp#001 is still left around.
> 
> Is there anything I can do to have deployments that failed still be removed?

There is no option that will do this automatically.

Mark


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

Re: question on EL Lambda expression in a JSP on Tomcat 8_0_15

[Mark Thomas]

On 13/01/2015 21:11, Anup Aggarwal wrote:
> Hi,
> 
> I am trying to run this EL Lambda expression in a JSP on Tomcat 8_0_15
> 
> ${(incr = x->x+1; incr(10)}
> 
> But I get this exception
> 
> org.apache.jasper.JasperException: /TestLambda.jsp (line: 44, column: 42)
> The function incr must be used with a prefix when a default namespace is
> not specified
> 
> org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:42)

That looks like a bug in the JSP parser. Please file a Bugzilla issue.

Mark



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

autoDeploy underlying old failed versions

[Jeff Storey]

I have autoDeploy and undeployOldVersions enabled on my Tomcat server
and I am using parallel deployments. The issue I'm having is that old
versions that have errors in their startup are not removed. Let's say
I deploy the following apps:

myapp##001.war
myapp##002.war


If myapp#001.war failed during startup, and I deploy myapp##002,
requests are properly routed to the new version, by myapp#001 stays
around. When I then deploy myapp#003, myapp#002 is removed, but
myapp#001 is still left around.

Is there anything I can do to have deployments that failed still be removed?

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

Re: Slow HTTP Rquest via Tomcat

[André Warnier]

Christopher Schultz wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Thone,

On 1/13/15 1:05 PM, Thone Soungpanya wrote:

Hello Andre,

I do not think it is an DNS lookup issue but I'll check on it.

Yes we actually have logs but it does not tell us much. We added 
additional logging in our servlet code to tell us when and what the

code is doing. I have attached a log for 1 connection which took
about 1 minute and 23 seconds to complete. I have eliminated all
sensitive information with "XX". During this
time, there would be other connections too simultaneously.

Some information on the request: 1) HTTP request initiated at
16:11:06 to Tomcat.


This is a very confusing log file... from latest-to-oldest.


+10



Before #2 happens, Tomcat reloads. Many (all?) web applications were
re-loaded. Was that expected?


2) Connection to Third Party System happened at 16:12:22. You can
see it on line 38 with following text "2015-01-12 16:12:22,426
INFO 06E4074221FF93C2827079EBC2102847; begin request"


Okay.


3) Response back to Tomcat from Third Party System at 16:12:29


This does not appear in the log.

So it seems that between point#1 and point #2, there was about a 1 
minute and 16 seconds delay before connection to the third party.

Point #2 to Point #3 only took 7 seconds.

Can you or anyone see what may be the issue from the logs?




Maybe if you provide clearer logs, having some real information allowing to distinguish 
one request processing sequence from another.



Tomcat is reloading in the middle of the request?


Right, that's what it looks like.
And not only this one time.
From the (very difficult) look of it, it seems that this system is spending its time 
reloading its applications almost continuously.
Using some nifty features of Notepad++, I have extracted and re-ordered what I believe are 
log lines relating to one webapp (and I don't really know for sure if this is one request, 
or several).
See attached if it makes it, it's probably clearer.  Otherwise, I have also pasted these 
log lines below.


I have selected lines related to a webapp named "ps_1.5_8.53.10", and re-ordered them in a 
logical older-to-younger top-down sequence.


Examining thse lines, we see :
- at 2015-01-12 16:11:07,396 : what appears to be the beginning of a redeployment of that 
webapp
- at  2015-01-12 16:11:08,108 (one second later) : what appears to be the beginning of a 
request to that webapp
- at 2015-01-12 16:11:15,918 (7 seconds later), what seems to be the beginning of yet 
another redeployment of that webapp

- at 2015-01-12 16:11:21,037, another request starting

In-between, there are a lot of other lines apparently showing similar (other) webapps 
redeployments, and maybe other lines related to that same webapp, but all quite difficult 
to identify because there is no common marker.


That logfile is very confusing, and as a result take this with a grain of salt, but I get 
the funny feeling that this webapp, when it responds to a request, may be modifying 
something (it's own WEB-INF/web.xml ?) in such a way that it triggers a re-deployment of 
that same very application by Tomcat, at each request.

(And similarly for the other ones)

For a start, does the  tag of that Tomcat instance have an autodeploy="true" 
attribute ? (see in conf/server.xml).
And if so, what about setting that attribute to "false", restarting this Tomcat, and 
looking at the symptoms again ?


(and read : 
http://tomcat.apache.org/tomcat-8.0-doc/config/host.html#Standard_Implementation
section : Automatic Application Deployment
)


Appendix (also attached but the attachment may be stripped by the list) :

Re-ordered selected log line :

	Line 1099: 2015-01-12 16:11:07,396 DEBUG Checking context[/ps_1.5_8.53.10] redeploy 
resource /usr/local/tomcat-instance5/webapps/ps_1.5_8.53.10.war
	Line 1098: 2015-01-12 16:11:07,396 DEBUG Checking context[/ps_1.5_8.53.10] redeploy 
resource /usr/local/tomcat-instance5/webapps/ps_1.5_8.53.10
	Line 1097: 2015-01-12 16:11:07,396 DEBUG Checking context[/ps_1.5_8.53.10] redeploy 
resource /usr/local/tomcat-instance5/conf/Catalina/localhost/ps_1.5_8.53.10.xml
	Line 1096: 2015-01-12 16:11:07,396 DEBUG Checking context[/ps_1.5_8.53.10] redeploy 
resource /usr/local/tomcat-instance5/webapps/ps_1.5_8.53.10/META-INF/context.xml
	Line 1095: 2015-01-12 16:11:07,396 DEBUG Checking context[/ps_1.5_8.53.10] redeploy 
resource /usr/local/tomcat-instance5/conf/context.xml
	Line 1094: 2015-01-12 16:11:07,396 DEBUG Checking context[/ps_1.5_8.53.10] reload 
resource /usr/local/tomcat-instance5/webapps/ps_1.5_8.53.10/WEB-INF/web.xml
	Line 972: 2015-01-12 16:11:08,108 DEBUG The variable [uriBC] has value 
[/ps_1.5_8.53.10/servlet/PSConnectorServlet]
	Line 969: 2015-01-12 16:11:08,108 DEBUG Security checking request GET 
/ps_1.5_8.53.10/servlet/PSConnectorServlet
	Line 964: 2015-01-12 16:11:08,109 DEBUG --> Returning 
'file:/usr/local/tomcat-instance5/webapps/ps_1.5_8.53.10/WEB-INF/class

Re: Occasional long wait for a JDBC connection

[Darren Davis]

On Tue, Jan 13, 2015 at 2:33 PM, Christopher Schultz <
ch...@christopherschultz.net> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Darren,
>
> On 1/13/15 1:04 PM, Christopher Schultz wrote:
> > On 1/13/15 11:49 AM, Darren Davis wrote:
> >> The problem occurred again this morning.  I was able to generate
> >> a thread dump and narrow down the source of our problem to
> >> tomcat thread 23.
> >
> >>> From 8:45:51,397 to 09:01:19,083, it was stuck in the validate
> >>> check for a
> >> newly instantiated connection:
> >
> >> I ran the thread dump several times during this interval, and
> >> the stack trace for thread 23 did not change at all.
> >
> >> I did check our database log file and determined that during the
> >> 8 hours that led up to our first error on the server yesterday,
> >> we had just a total of 12 unique connections.  The problem
> >> occurred the the creation of connection # 13, which was then used
> >> several other times later.
> >
> >> The incident this morning also coincided with creating a new
> >> connection in the pool.  It does not make any sense that the
> >> simple validation query of "SELECT 1" would require a wait of 15
> >> minutes to succeed.
> >
> > Agreed.
> >
> >> It's also strange that this only happens sporadically, and not
> >> every time a new connection is being "birthed" by the system.
> >
> >> We've tried two different pooling technologies: DBCP and the new
> >> Apache JDBC pooling on this server and both exhibit the same 15
> >> minute occasional wait.
> >
> > The problem is with the driver and/or database, not with the
> > connection pool. It's not surprising that you are experiencing
> > problems regardless of the pool being used.
> >
> >> we've come across documentation that suggests we could modify our
> >>  validation statement by prefixing it with /* ping */, which
> >> we're thinking about trying
> >
> > Using "/* ping */" is usually a good idea for MySQL, but it may
> > mask the problem. What you may find is that the next "real" query
> > you use hangs for 15 minutes. If you are going to use /* ping */
> > and you are going to use the tomcat-jdbc pool, then you may as well
> > not configure a validation query at all because Tomcat's pool will
> > use Connection.isValid which amounts to the same thing (and will
> > work for any compliant JDBC driver, not just with MySQL).
> >
> >> "http-nio-8443-exec-23" #156 daemon prio=5 os_prio=0
> >> tid=0x7f0658387000 nid=0x7a60 runnable [0x7f05e7466000]
> >> java.lang.Thread.State: RUNNABLE at
> >> java.net.SocketInputStream.$$YJP$$socketRead0(Native Method) at
> >> java.net.SocketInputStream.socketRead0(SocketInputStream.java)
> >> at java.net.SocketInputStream.read(SocketInputStream.java:150)
> >> at java.net.SocketInputStream.read(SocketInputStream.java:121) at
> >>
> >>
> com.mysql.jdbc.util.ReadAheadInputStream.fill(ReadAheadInputStream.java:114)
> >
> >>
> >
> > at
> >>
> com.mysql.jdbc.util.ReadAheadInputStream.readFromUnderlyingStreamIfNecessary(ReadAheadInputStream.java:161)
> >
> >>
> >
> > at
> >>
> com.mysql.jdbc.util.ReadAheadInputStream.read(ReadAheadInputStream.java:189)
> >
> >>
> >
> > - locked <0xbdf09420> (a
> >> com.mysql.jdbc.util.ReadAheadInputStream) at
> >> com.mysql.jdbc.MysqlIO.readFully(MysqlIO.java:2549) at
> >> com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:3002) at
> >> com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:2991) at
> >> com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3532) at
> >> com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:2002) at
> >> com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2163) at
> >> com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2618)
> >> - locked <0xbdf04df0> (a com.mysql.jdbc.JDBC4Connection)
> >> at
> >> com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2568)
> >> at com.mysql.jdbc.StatementImpl.execute(StatementImpl.java:842)
> >> - locked <0xbdf04df0> (a com.mysql.jdbc.JDBC4Connection)
> >> - locked <0xff107cd8> (a com.mysql.jdbc.StatementImpl)
> >> at com.mysql.jdbc.StatementImpl.execute(StatementImpl.java:681)
> >> at
> >>
> org.apache.tomcat.jdbc.pool.PooledConnection.validate(PooledConnection.java:503)
> >
> >>
> >
> > at
> >>
> org.apache.tomcat.jdbc.pool.PooledConnection.validate(PooledConnection.java:437)
> >
> >>
> >
> > at
> >>
> org.apache.tomcat.jdbc.pool.ConnectionPool.borrowConnection(ConnectionPool.java:763)
> >
> >>
> >
> > at
> >>
> org.apache.tomcat.jdbc.pool.ConnectionPool.borrowConnection(ConnectionPool.java:617)
> >
> >>
> >
> > at
> >>
> org.apache.tomcat.jdbc.pool.ConnectionPool.getConnection(ConnectionPool.java:186)
> >
> >>
> >
> > at
> >>
> org.apache.tomcat.jdbc.pool.DataSourceProxy.getConnection(DataSourceProxy.java:127)
> >
> >>
> >
> > at
> >>
> org.springframework.orm.hibernate3.LocalDataSourceConnectionProvider.getConnection(LocalDataSourceConnectionProvider.java:83)
> >
> >>
> >
> > at
> >>
> org.hibernate.jdbc.ConnectionManag

Re: mod_jk status worker returns 500 error with no messages, logs

[Rainer Jung]

Am 13.01.2015 um 18:59 schrieb Christopher Schultz:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

All,

On 1/10/15 2:56 PM, Christopher Schultz wrote:

I'm having a problem with mod_jk 1.2.40 under Apache 2.4.10. After
a successful start up, accessing the mod_jk status page gives me a
500 error with no errors on the screen or in the logs.


Solved.

The problem turned out to be authnz_ldap, which does not produce any
errors when it can't reach the LDAP server. A bad iptables rule
prevented this web server from reaching our LDAP server, and the
behavior was "500 server error" with no messages in any log files for
any resource protected by the module.

I spent a great deal of time trying to figure out how this web server
was configured differently than any of the others, which were of
course still working just fine. Since the problem was with an external
server (the LDAP server), it took quite a long time to track down, as
the web servers were in fact configured identically :)


Thanks for letting us know!

Hopefully the status worker activation update problem in the other 
thread will be fixed by a valid shm path. Otherwise analysis will get 
nasty ...


Regards,

Rainer


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

Re: question on EL Lambda expression in a JSP on Tomcat 8_0_15

[Anup Aggarwal]

No that is not the issue, that was my typing mistake

${incr = x->x+1; incr(10)}

throws same

*message* */TestLambda.jsp (line: 59, column: 42) The function incr must be
used with a prefix when a default namespace is not specified*

*description* *The server encountered an internal error that prevented it
from fulfilling this request.*

*exception*

org.apache.jasper.JasperException: /TestLambda.jsp (line: 59, column:
42) The function incr must be used with a prefix when a default
namespace is not specified

org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:42)




On Tue, Jan 13, 2015 at 4:34 PM, Daniel Mikusa  wrote:

> On Tue, Jan 13, 2015 at 4:11 PM, Anup Aggarwal 
> wrote:
>
> > Hi,
> >
> > I am trying to run this EL Lambda expression in a JSP on Tomcat 8_0_15
> >
> > ${(incr = x->x+1; incr(10)}
> >
>
> This could be a typo in your email, but you have an extra "(" at the
> beginning before "incr =".
>
> Dan
>
>
> >
> > But I get this exception
> >
> > org.apache.jasper.JasperException: /TestLambda.jsp (line: 44, column: 42)
> > The function incr must be used with a prefix when a default namespace is
> > not specified
> >
> >
> >
> org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:42)
> >
> >
> >
> > Thanks and help will be appreciated to resolve this.
> >
>

Re: question on EL Lambda expression in a JSP on Tomcat 8_0_15

[Daniel Mikusa]

On Tue, Jan 13, 2015 at 4:11 PM, Anup Aggarwal 
wrote:

> Hi,
>
> I am trying to run this EL Lambda expression in a JSP on Tomcat 8_0_15
>
> ${(incr = x->x+1; incr(10)}
>

This could be a typo in your email, but you have an extra "(" at the
beginning before "incr =".

Dan


>
> But I get this exception
>
> org.apache.jasper.JasperException: /TestLambda.jsp (line: 44, column: 42)
> The function incr must be used with a prefix when a default namespace is
> not specified
>
>
> org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:42)
>
>
>
> Thanks and help will be appreciated to resolve this.
>

Re: Occasional long wait for a JDBC connection

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Darren,

On 1/13/15 1:04 PM, Christopher Schultz wrote:
> On 1/13/15 11:49 AM, Darren Davis wrote:
>> The problem occurred again this morning.  I was able to generate
>> a thread dump and narrow down the source of our problem to
>> tomcat thread 23.
> 
>>> From 8:45:51,397 to 09:01:19,083, it was stuck in the validate 
>>> check for a
>> newly instantiated connection:
> 
>> I ran the thread dump several times during this interval, and
>> the stack trace for thread 23 did not change at all.
> 
>> I did check our database log file and determined that during the
>> 8 hours that led up to our first error on the server yesterday,
>> we had just a total of 12 unique connections.  The problem
>> occurred the the creation of connection # 13, which was then used
>> several other times later.
> 
>> The incident this morning also coincided with creating a new 
>> connection in the pool.  It does not make any sense that the
>> simple validation query of "SELECT 1" would require a wait of 15
>> minutes to succeed.
> 
> Agreed.
> 
>> It's also strange that this only happens sporadically, and not 
>> every time a new connection is being "birthed" by the system.
> 
>> We've tried two different pooling technologies: DBCP and the new 
>> Apache JDBC pooling on this server and both exhibit the same 15 
>> minute occasional wait.
> 
> The problem is with the driver and/or database, not with the 
> connection pool. It's not surprising that you are experiencing 
> problems regardless of the pool being used.
> 
>> we've come across documentation that suggests we could modify our
>>  validation statement by prefixing it with /* ping */, which
>> we're thinking about trying
> 
> Using "/* ping */" is usually a good idea for MySQL, but it may
> mask the problem. What you may find is that the next "real" query
> you use hangs for 15 minutes. If you are going to use /* ping */
> and you are going to use the tomcat-jdbc pool, then you may as well
> not configure a validation query at all because Tomcat's pool will
> use Connection.isValid which amounts to the same thing (and will
> work for any compliant JDBC driver, not just with MySQL).
> 
>> "http-nio-8443-exec-23" #156 daemon prio=5 os_prio=0 
>> tid=0x7f0658387000 nid=0x7a60 runnable [0x7f05e7466000] 
>> java.lang.Thread.State: RUNNABLE at 
>> java.net.SocketInputStream.$$YJP$$socketRead0(Native Method) at 
>> java.net.SocketInputStream.socketRead0(SocketInputStream.java)
>> at java.net.SocketInputStream.read(SocketInputStream.java:150)
>> at java.net.SocketInputStream.read(SocketInputStream.java:121) at
>>  
>> com.mysql.jdbc.util.ReadAheadInputStream.fill(ReadAheadInputStream.java:114)
>
>> 
> 
> at
>> com.mysql.jdbc.util.ReadAheadInputStream.readFromUnderlyingStreamIfNecessary(ReadAheadInputStream.java:161)
>
>> 
> 
> at
>> com.mysql.jdbc.util.ReadAheadInputStream.read(ReadAheadInputStream.java:189)
>
>> 
> 
> - locked <0xbdf09420> (a
>> com.mysql.jdbc.util.ReadAheadInputStream) at 
>> com.mysql.jdbc.MysqlIO.readFully(MysqlIO.java:2549) at 
>> com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:3002) at 
>> com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:2991) at 
>> com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3532) at 
>> com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:2002) at 
>> com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2163) at 
>> com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2618)
>> - locked <0xbdf04df0> (a com.mysql.jdbc.JDBC4Connection)
>> at 
>> com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2568)
>> at com.mysql.jdbc.StatementImpl.execute(StatementImpl.java:842)
>> - locked <0xbdf04df0> (a com.mysql.jdbc.JDBC4Connection)
>> - locked <0xff107cd8> (a com.mysql.jdbc.StatementImpl)
>> at com.mysql.jdbc.StatementImpl.execute(StatementImpl.java:681)
>> at 
>> org.apache.tomcat.jdbc.pool.PooledConnection.validate(PooledConnection.java:503)
>
>> 
> 
> at
>> org.apache.tomcat.jdbc.pool.PooledConnection.validate(PooledConnection.java:437)
>
>> 
> 
> at
>> org.apache.tomcat.jdbc.pool.ConnectionPool.borrowConnection(ConnectionPool.java:763)
>
>> 
> 
> at
>> org.apache.tomcat.jdbc.pool.ConnectionPool.borrowConnection(ConnectionPool.java:617)
>
>> 
> 
> at
>> org.apache.tomcat.jdbc.pool.ConnectionPool.getConnection(ConnectionPool.java:186)
>
>> 
> 
> at
>> org.apache.tomcat.jdbc.pool.DataSourceProxy.getConnection(DataSourceProxy.java:127)
>
>> 
> 
> at
>> org.springframework.orm.hibernate3.LocalDataSourceConnectionProvider.getConnection(LocalDataSourceConnectionProvider.java:83)
>
>> 
> 
> at
>> org.hibernate.jdbc.ConnectionManager.openConnection(ConnectionManager.java:446)
>
>> 
> 
> at
>> org.hibernate.jdbc.ConnectionManager.getConnection(ConnectionManager.java:167)
>
>> 
> 
> at org.hibernate.jdbc.JDBCContext.connection(JDBCContext.java:160)
>> at 
>> org.hibernate.transaction.JDBCTransaction.begin(JDBCTransaction.java:81)
>
>> 
> 
> at
>

Re: Can't make SSL work on Tomcat7 on Ubuntu Server 14.04

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Alexandre,

On 1/13/15 2:41 PM, Alexandre Lima wrote:
> On 13 January 2015 at 16:11, Christopher Schultz < 
> ch...@christopherschultz.net> wrote:
> 
> Alexandre,
> 
> On 1/13/15 1:37 PM, Alexandre Lima wrote:
 Hello! This is the first time I'm using tomcat, so I'm a
 little bit lost...
> 
> Welcome! Configuring SSL always turns out to be a pain in the
> neck.
> 
 Using the tutorials, I could make the server and the
 application I want to run with it work. The only modification
 I did until now was changing the http port from 8080 to 80, I
 did that changing the http conector on servers.xml, enabling
 authbind and executing the folowing commands:
 
 sudo touch /etc/authbind/byport/80 sudo chmod 500 
 /etc/authbind/byport/80 sudo chown tomcat7
 /etc/authbind/byport/80
 
 So, the server and the application I want to use with it are 
 actually working on port 80
> 
> You've confirmed this? I've never used authbind before, so I just 
> wanted to make sure that you have Tomcat working properly with
> non-SSL before you try to add SSL.
> 
 , but the next and last step, which is enabling an SSL
 connection, isn't working.
 
 What I did following the site's tutorial was: created my
 self signed certificate with keytools and put it on 
 /home/myuser/key.keystore
> 
> Can you outline the steps you took? Where is your keystore?
> 
 Additionally, I've created the folowing conector:
 
 >>> protocol="org.apache.coyote.http11.Http11Protocol" 
 SSLEnabled="true" maxThreads="200" scheme="https"
 secure="true" keystoreFile="/home/myuser/key.keystore"
 keystorePass="mypass" clientAuth="false" sslProtocol="TLS"
 />
> 
> That looks good so far.
> 
 Saved it, restarted server and accessed https://myip:8443,
 but it isn't working. Chrome says "No data recieved" and
 "Unable to load the webpage because the server sent no data
 and "Error code: ERR_EMPTY_RESPONSE".
 
 Firefox says that the connection was reset while the page was
 being loaded.
 
 That's where I am now. I don't know what to try anymore.
> 
> Try:
> 
> $ telnet localhost 8443
> 
> (on the server with Tomcat running)
> 
> That will tell you if the port is open (it should be, otherwise
> you'd be getting different errors from Chrome and ff) and what, if
> anything, gets dumped to it when you connect.
> 
> If you get a connection and nothing happens, try submitting a
> request like this:
> 
> $ telnet localhost 8443 GET /
> 
> [output goes here]
> 
> Post the results of the above if you get anything.
> 
> Dumb question: you restarted Tomcat after updating server.xml,
> right?
> 
> -chris
>> 
>> -
>>
>> 
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>> 
>> 
> Thank you for the reply Christopher! I've used the command: keytool
> -genkey -alias tomcat -keyalg RSA -keystore 
> /home/myuser/key.keystore to generate the keystore. I should put
> the keystore in some special directory or this one is fine? So,
> after, requesting:   telnet localhost 8443
> 
> I got some strange stuff:
> 
> ~$ telnet localhost 8443 Trying ::1... Connected to localhost. 
> Escape character is '^]'. GET / ^U^C^A^@^B^B
> 
> 
> 
> And yes, I've restarted it :)

Good. Now, try this:

$ openssl s_client -debug -connect localhost:8443

Assuming that the server is running and listening for SSL connections,
s_client should be able to connect, and it should give you tons of
good information about what's happening, there.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJUtYwOAAoJEBzwKT+lPKRYkRIQAKFA3/GpDdzT5ZVWZ8+VXjQr
AYgy42TqufEs8RicHNjB0Ey92azX4zNMau4yBxQ3dqv660vOqW3PW1XSVC8yF+ke
+QBwivtJCglep+7nsPTTL4nSM4yAOCGMzYKGXidNdczvqcnoM2XA8jg0JiM68gBx
Jxl7MdM/S2ktngs8tuG6SSaiY5eyPB1ySUwXOD3zfrVLJK7Ex4y2USt9IKAEYhBl
A3kxWHIjlV+1m+ZAf6WmwWMmsBWxtVVx6iDAiR/ZIzvY/VMpqtSZ0rSGeM7OnfhV
ER2NN+4z+2kqskj5WJ6ZX2Q6i7CbdPfrCq6RstPOLaWNZICIoqVlR43I21+BOc5o
ugORSS97XBuQy5fXfBbgOJoN0wupttBNB44We9ZmHexuInVl3uxbyDra8yRkVT8M
qT7jcDW8lMFmCxmbilelsDRpnYj55j5OA+453nI0vQap/ojZBTb/fgRsl6PnPTRG
omd+jC1wMFIfycu+2ahJB1YHNTGTfD3MWP/Wey/82u3X9QJD35TTcNt+gyVrCLtw
eLoUUqkaCSZNuudWBpm61/2gp//c9adWRZTozd9/c4Yasp8f2ruLDK3+6rA7ohM5
OZ7Mh5wEal8zNnBC7sQeuoekkiQKDRQlQdATSAthlszFMByn+k5A5IJNWUB1asUp
VPf4zB2XaBIxgnKm3qPV
=Bl3E
-END PGP SIGNATURE-

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

question on EL Lambda expression in a JSP on Tomcat 8_0_15

[Anup Aggarwal]

Hi,

I am trying to run this EL Lambda expression in a JSP on Tomcat 8_0_15

${(incr = x->x+1; incr(10)}

But I get this exception

org.apache.jasper.JasperException: /TestLambda.jsp (line: 44, column: 42)
The function incr must be used with a prefix when a default namespace is
not specified

org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:42)



Thanks and help will be appreciated to resolve this.

Re: How to debug tomcat code in eclipse

[Jim Anderson]

Hi Harmeet,

I have a setup similar to yours and I had to go through the same process 
you are right now. The good news is that with some help, I got it going 
and it works well. The bad news is that I am very busy at the moment and 
cannot help immediately, but I will try to get back to you over the 
weekend if you have not been able to get set up in Eclipse.


Please let me know if you have resolved your problem. Otherwise, I will 
get back to you over the weekend.


Jim

On 01/08/2015 11:42 AM, MyList wrote:

Hello All,

I am new to web development with tomcat. Have many years experience in  C and 
C++ on Unix.

I am newbie to tomcat too. Pardon me if my questions seem simple, just guide me 
to the source or links.

I am interested in debugging the tomcat server source code through Eclipse.I 
would like to see how/where/what of the tomcat source code and it's internals 
to get a grip on the way it handles things.


I have the following installed -
1)Eclipse Java For EE - Luna
2)Have the RC7_0_57 of the tomcat code.
3) I have tomcat 6,7,8 installed and tested. Running concurrently on three 
different port setups etc.

My intention is to write a few Servlet based projects and step into the tomcat 
source code while debugging from eclipse. I haven't found any good link to 
achieve the same.I will have to compile the tomcat source code too, don't know 
how to do that either.

I would be obliged if you could help me or point me to the sources to achieve 
this goal.

Thanks in Advance,
Harmeet




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

RE: Occasional long wait for a JDBC connection

[MWick]

> From: Christopher Schultz [mailto:ch...@christopherschultz.net]
> Sent: Tuesday, January 13, 2015 1:05 PM
> To: Tomcat Users List
> Subject: Re: Occasional long wait for a JDBC connection
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Darren,
>
> On 1/13/15 11:49 AM, Darren Davis wrote:
> > The problem occurred again this morning.  I was able to generate a
> > thread dump and narrow down the source of our problem to tomcat
> thread
> > 23.
> >
> >> From 8:45:51,397 to 09:01:19,083, it was stuck in the validate check
> >> for a
> > newly instantiated connection:
> >
> > I ran the thread dump several times during this interval, and the
> > stack trace for thread 23 did not change at all.
> >
> > I did check our database log file and determined that during the 8
> > hours that led up to our first error on the server yesterday, we had
> > just a total of 12 unique connections.  The problem occurred the the
> > creation of connection # 13, which was then used several other times
> > later.
> >
> > The incident this morning also coincided with creating a new
> > connection in the pool.  It does not make any sense that the simple
> > validation query of "SELECT 1" would require a wait of 15 minutes to
> > succeed.
>
> Agreed.
>
> > It's also strange that this only happens sporadically, and not every
> > time a new connection is being "birthed" by the system.
> >
> > We've tried two different pooling technologies: DBCP and the new
> > Apache JDBC pooling on this server and both exhibit the same 15 minute
> > occasional wait.
>
> The problem is with the driver and/or database, not with the connection
> pool. It's not surprising that you are experiencing problems regardless of the
> pool being used.
>
> > we've come across documentation that suggests we could modify our
> > validation statement by prefixing it with /* ping */, which we're
> > thinking about trying
>
> Using "/* ping */" is usually a good idea for MySQL, but it may mask the
> problem. What you may find is that the next "real" query you use hangs for
> 15 minutes. If you are going to use /* ping */ and you are going to use the
> tomcat-jdbc pool, then you may as well not configure a validation query at all
> because Tomcat's pool will use Connection.isValid which amounts to the
> same thing (and will work for any compliant JDBC driver, not just with
> MySQL).
>
> > "http-nio-8443-exec-23" #156 daemon prio=5 os_prio=0
> > tid=0x7f0658387000 nid=0x7a60 runnable [0x7f05e7466000]
> > java.lang.Thread.State: RUNNABLE at
> > java.net.SocketInputStream.$$YJP$$socketRead0(Native Method) at
> > java.net.SocketInputStream.socketRead0(SocketInputStream.java) at
> > java.net.SocketInputStream.read(SocketInputStream.java:150) at
> > java.net.SocketInputStream.read(SocketInputStream.java:121) at
> >
> com.mysql.jdbc.util.ReadAheadInputStream.fill(ReadAheadInputStream.jav
> > a:114)
> >
> >
> at
> >
> com.mysql.jdbc.util.ReadAheadInputStream.readFromUnderlyingStreamIfN
> ec
> > essary(ReadAheadInputStream.java:161)
> >
> >
> at
> >
> com.mysql.jdbc.util.ReadAheadInputStream.read(ReadAheadInputStream.j
> av
> > a:189)
> >
> >
> - - locked <0xbdf09420> (a
> > com.mysql.jdbc.util.ReadAheadInputStream) at
> > com.mysql.jdbc.MysqlIO.readFully(MysqlIO.java:2549) at
> > com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:3002) at
> > com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:2991) at
> > com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3532) at
> > com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:2002) at
> > com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2163) at
> > com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2618) -
> > locked <0xbdf04df0> (a com.mysql.jdbc.JDBC4Connection) at
> > com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2568) at
> > com.mysql.jdbc.StatementImpl.execute(StatementImpl.java:842) - locked
> > <0xbdf04df0> (a com.mysql.jdbc.JDBC4Connection) - locked
> > <0xff107cd8> (a com.mysql.jdbc.StatementImpl) at
> > com.mysql.jdbc.StatementImpl.execute(StatementImpl.java:681) at
> >
> org.apache.tomcat.jdbc.pool.PooledConnection.validate(PooledConnection
> > .java:503)
> >
> >
> at
> >
> org.apache.tomcat.jdbc.pool.PooledConnection.validate(PooledConnection
> > .java:437)
> >
> >
> at
> >
> org.apache.tomcat.jdbc.pool.ConnectionPool.borrowConnection(Connectio
> n
> > Pool.java:763)
> >
> >
> at
> >
> org.apache.tomcat.jdbc.pool.ConnectionPool.borrowConnection(Connectio
> n
> > Pool.java:617)
> >
> >
> at
> >
> org.apache.tomcat.jdbc.pool.ConnectionPool.getConnection(ConnectionPoo
> > l.java:186)
> >
> >
> at
> >
> org.apache.tomcat.jdbc.pool.DataSourceProxy.getConnection(DataSourcePr
> > oxy.java:127)
> >
> >
> at
> >
> org.springframework.orm.hibernate3.LocalDataSourceConnectionProvider.g
> > etConnection(LocalDataSourceConnectionProvider.java:83)
> >
> >
> at
> >
> org.hibernate.jdbc.ConnectionManager.openConnection(ConnectionManag
> er.
> > java:446)
> >
> >
>

Re: Can't make SSL work on Tomcat7 on Ubuntu Server 14.04

[Alexandre Lima]

On 13 January 2015 at 16:41, Alexandre Lima  wrote:

>
>
> On 13 January 2015 at 16:11, Christopher Schultz <
> ch...@christopherschultz.net> wrote:
>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA256
>>
>> Alexandre,
>>
>> On 1/13/15 1:37 PM, Alexandre Lima wrote:
>> > Hello! This is the first time I'm using tomcat, so I'm a little bit
>> > lost...
>>
>> Welcome! Configuring SSL always turns out to be a pain in the neck.
>>
>> > Using the tutorials, I could make the server and the application I
>> > want to run with it work. The only modification I did until now was
>> > changing the http port from 8080 to 80, I did that changing the
>> > http conector on servers.xml, enabling authbind and executing the
>> > folowing commands:
>> >
>> > sudo touch /etc/authbind/byport/80 sudo chmod 500
>> > /etc/authbind/byport/80 sudo chown tomcat7 /etc/authbind/byport/80
>> >
>> > So, the server and the application I want to use with it are
>> > actually working on port 80
>>
>> You've confirmed this? I've never used authbind before, so I just
>> wanted to make sure that you have Tomcat working properly with non-SSL
>> before you try to add SSL.
>>
>> > , but the next and last step, which is enabling an SSL connection,
>> > isn't working.
>> >
>> > What I did following the site's tutorial was: created my self
>> > signed certificate with keytools and put it on
>> > /home/myuser/key.keystore
>>
>> Can you outline the steps you took? Where is your keystore?
>>
>> > Additionally, I've created the folowing conector:
>> >
>> > > > protocol="org.apache.coyote.http11.Http11Protocol"
>> > SSLEnabled="true" maxThreads="200" scheme="https" secure="true"
>> > keystoreFile="/home/myuser/key.keystore" keystorePass="mypass"
>> > clientAuth="false" sslProtocol="TLS" />
>>
>> That looks good so far.
>>
>> > Saved it, restarted server and accessed https://myip:8443, but it
>> > isn't working. Chrome says "No data recieved" and "Unable to load
>> > the webpage because the server sent no data and "Error code:
>> > ERR_EMPTY_RESPONSE".
>> >
>> > Firefox says that the connection was reset while the page was being
>> > loaded.
>> >
>> > That's where I am now. I don't know what to try anymore.
>>
>> Try:
>>
>> $ telnet localhost 8443
>>
>> (on the server with Tomcat running)
>>
>> That will tell you if the port is open (it should be, otherwise you'd
>> be getting different errors from Chrome and ff) and what, if anything,
>> gets dumped to it when you connect.
>>
>> If you get a connection and nothing happens, try submitting a request
>> like this:
>>
>> $ telnet localhost 8443
>> GET /
>>
>> [output goes here]
>>
>> Post the results of the above if you get anything.
>>
>> Dumb question: you restarted Tomcat after updating server.xml, right?
>>
>> - -chris
>> -BEGIN PGP SIGNATURE-
>> Version: GnuPG v1
>> Comment: GPGTools - http://gpgtools.org
>>
>> iQIcBAEBCAAGBQJUtW3WAAoJEBzwKT+lPKRYzVMP/Rl9RP6tpuU+leyUcyNjLy+2
>> hMSmXJ1GfttVxuC6KmD+leV19uyd6dKu16dA4v/LZMX+Un7uQIfY97vUleqg1LkA
>> HnwQYv6Sond5TOJR4PeY644qULBOOh4Bi+kJuS4HFjrAUCcG6KHSJfkhLluX/w6c
>> +I4/G5MYQQ0r68TOnLAn9ijTZl957ekj3ainc4XmL1U5BA7q0/fOttgVmytuUq3k
>> q3Kh/IU1S2ovu4milc0IWGcQttlZ9cn1nZf/nGZyuyWun0gQNLL5oX6ZY5ys5x1D
>> 1LQ1TZWb6XL3TK1qBHvbs+u4qnfl3ZSWEKMWntYq0JHLDC2lvL8QcLvVkPguYN/W
>> 6HHEp4fNfmqeWLvS7aj6ugNT6UQ4iWxhPJ882YeVQ06D9sLHGL5gIqJE+OPYp8pU
>> hyA7MnGDwKpbrTRq6u+QOUUF4Z+g/j++xTsdBk/+rrzaZs4HuLsBtikRbOoNr6ZJ
>> 4c1WnuUiFkXbWYkMOEA9p3/Iy/nIay1aAmnqBEuWSBr83+WJvkB+/Nyf4HDZX6Ti
>> AElDG4K6yBVtN1bThmwFfWOPqO+zieP/RhdHUgVw7VOU7hi4xBMpcF+UZKImrkGs
>> kfN0tqSMriAQ7CL49UbrFxY4bsC0u4uVRJyoB4EOtaPy9cQH01rIrlotwOuPOwD4
>> lK/2rtEZo3uAazzi7oTP
>> =sNDG
>> -END PGP SIGNATURE-
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>
>>
> Thank you for the reply Christopher!
> I've used the command: keytool -genkey -alias tomcat -keyalg RSA -keystore
> /home/myuser/key.keystore
> to generate the keystore. I should put the keystore in some special
> directory or this one is fine?
> So, after, requesting:   telnet localhost 8443
>
> I got some strange stuff:
>
> ~$ telnet localhost 8443
> Trying ::1...
> Connected to localhost.
> Escape character is '^]'.
> GET /
> ^U^C^A^@^B^B
>
>
>
> And yes, I've restarted it :)
>
> --
> --
> Alexandre Lima
>

Oh, I forgot. Right after that I got: "Connection closed by foreign host."
And yes, it's working fine on port 80, it's even using DNS already.
-- 
--
Alexandre Lima

Re: Can't make SSL work on Tomcat7 on Ubuntu Server 14.04

[Alexandre Lima]

On 13 January 2015 at 16:11, Christopher Schultz <
ch...@christopherschultz.net> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Alexandre,
>
> On 1/13/15 1:37 PM, Alexandre Lima wrote:
> > Hello! This is the first time I'm using tomcat, so I'm a little bit
> > lost...
>
> Welcome! Configuring SSL always turns out to be a pain in the neck.
>
> > Using the tutorials, I could make the server and the application I
> > want to run with it work. The only modification I did until now was
> > changing the http port from 8080 to 80, I did that changing the
> > http conector on servers.xml, enabling authbind and executing the
> > folowing commands:
> >
> > sudo touch /etc/authbind/byport/80 sudo chmod 500
> > /etc/authbind/byport/80 sudo chown tomcat7 /etc/authbind/byport/80
> >
> > So, the server and the application I want to use with it are
> > actually working on port 80
>
> You've confirmed this? I've never used authbind before, so I just
> wanted to make sure that you have Tomcat working properly with non-SSL
> before you try to add SSL.
>
> > , but the next and last step, which is enabling an SSL connection,
> > isn't working.
> >
> > What I did following the site's tutorial was: created my self
> > signed certificate with keytools and put it on
> > /home/myuser/key.keystore
>
> Can you outline the steps you took? Where is your keystore?
>
> > Additionally, I've created the folowing conector:
> >
> >  > protocol="org.apache.coyote.http11.Http11Protocol"
> > SSLEnabled="true" maxThreads="200" scheme="https" secure="true"
> > keystoreFile="/home/myuser/key.keystore" keystorePass="mypass"
> > clientAuth="false" sslProtocol="TLS" />
>
> That looks good so far.
>
> > Saved it, restarted server and accessed https://myip:8443, but it
> > isn't working. Chrome says "No data recieved" and "Unable to load
> > the webpage because the server sent no data and "Error code:
> > ERR_EMPTY_RESPONSE".
> >
> > Firefox says that the connection was reset while the page was being
> > loaded.
> >
> > That's where I am now. I don't know what to try anymore.
>
> Try:
>
> $ telnet localhost 8443
>
> (on the server with Tomcat running)
>
> That will tell you if the port is open (it should be, otherwise you'd
> be getting different errors from Chrome and ff) and what, if anything,
> gets dumped to it when you connect.
>
> If you get a connection and nothing happens, try submitting a request
> like this:
>
> $ telnet localhost 8443
> GET /
>
> [output goes here]
>
> Post the results of the above if you get anything.
>
> Dumb question: you restarted Tomcat after updating server.xml, right?
>
> - -chris
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1
> Comment: GPGTools - http://gpgtools.org
>
> iQIcBAEBCAAGBQJUtW3WAAoJEBzwKT+lPKRYzVMP/Rl9RP6tpuU+leyUcyNjLy+2
> hMSmXJ1GfttVxuC6KmD+leV19uyd6dKu16dA4v/LZMX+Un7uQIfY97vUleqg1LkA
> HnwQYv6Sond5TOJR4PeY644qULBOOh4Bi+kJuS4HFjrAUCcG6KHSJfkhLluX/w6c
> +I4/G5MYQQ0r68TOnLAn9ijTZl957ekj3ainc4XmL1U5BA7q0/fOttgVmytuUq3k
> q3Kh/IU1S2ovu4milc0IWGcQttlZ9cn1nZf/nGZyuyWun0gQNLL5oX6ZY5ys5x1D
> 1LQ1TZWb6XL3TK1qBHvbs+u4qnfl3ZSWEKMWntYq0JHLDC2lvL8QcLvVkPguYN/W
> 6HHEp4fNfmqeWLvS7aj6ugNT6UQ4iWxhPJ882YeVQ06D9sLHGL5gIqJE+OPYp8pU
> hyA7MnGDwKpbrTRq6u+QOUUF4Z+g/j++xTsdBk/+rrzaZs4HuLsBtikRbOoNr6ZJ
> 4c1WnuUiFkXbWYkMOEA9p3/Iy/nIay1aAmnqBEuWSBr83+WJvkB+/Nyf4HDZX6Ti
> AElDG4K6yBVtN1bThmwFfWOPqO+zieP/RhdHUgVw7VOU7hi4xBMpcF+UZKImrkGs
> kfN0tqSMriAQ7CL49UbrFxY4bsC0u4uVRJyoB4EOtaPy9cQH01rIrlotwOuPOwD4
> lK/2rtEZo3uAazzi7oTP
> =sNDG
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>
Thank you for the reply Christopher!
I've used the command: keytool -genkey -alias tomcat -keyalg RSA -keystore
/home/myuser/key.keystore
to generate the keystore. I should put the keystore in some special
directory or this one is fine?
So, after, requesting:   telnet localhost 8443

I got some strange stuff:

~$ telnet localhost 8443
Trying ::1...
Connected to localhost.
Escape character is '^]'.
GET /
^U^C^A^@^B^B



And yes, I've restarted it :)

-- 
--
Alexandre Lima

RE: Slow HTTP Rquest via Tomcat

[Thone Soungpanya]

Hello Chris,

Yes, sorry when we pull from a Splunk program we have for the logs, it splits 
it out in the reverse order. 

Regarding #3, yes sorry it was missing from the logs but it basically return 
some information we request around that time.

Tomcat is reloading in the middle of the request? -- Yes I was looking into why 
this is doing so but I recall seeing on the google searches that it is done by 
default to reload all web folders? Is this not suppose to behavior this way? If 
not, where would the setting be to turn this off as I couldn't find it anywhere.

Thanks,

Thone


-Original Message-
From: Christopher Schultz [mailto:ch...@christopherschultz.net] 
Sent: Tuesday, January 13, 2015 11:01 AM
To: Tomcat Users List
Subject: Re: Slow HTTP Rquest via Tomcat

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Thone,

On 1/13/15 1:05 PM, Thone Soungpanya wrote:
> Hello Andre,
> 
> I do not think it is an DNS lookup issue but I'll check on it.
> 
> Yes we actually have logs but it does not tell us much. We added 
> additional logging in our servlet code to tell us when and what the 
> code is doing. I have attached a log for 1 connection which took about 
> 1 minute and 23 seconds to complete. I have eliminated all sensitive 
> information with "XX". During this time, there 
> would be other connections too simultaneously.
> 
> Some information on the request: 1) HTTP request initiated at
> 16:11:06 to Tomcat.

This is a very confusing log file... from latest-to-oldest.

Before #2 happens, Tomcat reloads. Many (all?) web applications were re-loaded. 
Was that expected?

> 2) Connection to Third Party System happened at 16:12:22. You can see 
> it on line 38 with following text "2015-01-12 16:12:22,426 INFO 
> 06E4074221FF93C2827079EBC2102847; begin request"

Okay.

> 3) Response back to Tomcat from Third Party System at 16:12:29

This does not appear in the log.

> So it seems that between point#1 and point #2, there was about a 1 
> minute and 16 seconds delay before connection to the third party.
> Point #2 to Point #3 only took 7 seconds.
> 
> Can you or anyone see what may be the issue from the logs?

Tomcat is reloading in the middle of the request?

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJUtWtPAAoJEBzwKT+lPKRY/m8P/i0VaL3x05kGAArWb+RL+BOL
jhfezsN5NKw3iosMFnlDkeyoD59AnWZvUqbnybqzCf9aXacT3iUeHEZHq4/mu3ew
juawm0phZl19PKYCfA/3PN0XR1jXVWdyN06QJuzA1KlpFDp7+/9WTWvMcLtG3DqC
vW3NstywZ7sPTgingHgVegEjcnKeXyDmFuhaUyyBNxo7Tgy/HaNwfB8Y7GSLBvGY
/NiJi0klkpbeyz+epbxzBe8JlYiFwosjlJIE0MpXvZgrKtiyD+cj9yaJxNGos5GS
nkiD3FGYKQ5cZ5c4dAXMs7es0bPjqRYWBRTiiaa8W2yX57t44Y7ZB6geuteep0/7
URS0NoONdCg1TbR/XE1kqG06g+IrBSzHBUZRzW3A8+NICcLQc/3i+X1zMYfnrD46
MzcBViMpsyJrBbsfpPol49zLx284/+146gYs6djhCdnWcbVNXf12QI/DA/YedThc
zJeCYy0MWQlhQ2T1FECgtgtPzSY0j+Wt06Dz+JoTAOXb5qX9kD/hvj+d2VRfWkkn
P2qBANSiOBE+JNPXQsA1JjHlWHO+HS4CIqG5VEflQ7aVzbC0zv57aRYqFFpPu1tH
Oc+S/m1AGpDdaRGBhjgdJCbtT8Pyi+WzCAA5YqeHjmEBDwo7pnnXoh9HO5t0UOb5
8hWJpjaXWxg+NxjIlv+P
=wn8y
-END PGP SIGNATURE-

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

Re: Can't make SSL work on Tomcat7 on Ubuntu Server 14.04

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Alexandre,

On 1/13/15 1:37 PM, Alexandre Lima wrote:
> Hello! This is the first time I'm using tomcat, so I'm a little bit
> lost...

Welcome! Configuring SSL always turns out to be a pain in the neck.

> Using the tutorials, I could make the server and the application I
> want to run with it work. The only modification I did until now was
> changing the http port from 8080 to 80, I did that changing the
> http conector on servers.xml, enabling authbind and executing the
> folowing commands:
> 
> sudo touch /etc/authbind/byport/80 sudo chmod 500
> /etc/authbind/byport/80 sudo chown tomcat7 /etc/authbind/byport/80
> 
> So, the server and the application I want to use with it are
> actually working on port 80

You've confirmed this? I've never used authbind before, so I just
wanted to make sure that you have Tomcat working properly with non-SSL
before you try to add SSL.

> , but the next and last step, which is enabling an SSL connection,
> isn't working.
> 
> What I did following the site's tutorial was: created my self
> signed certificate with keytools and put it on
> /home/myuser/key.keystore

Can you outline the steps you took? Where is your keystore?

> Additionally, I've created the folowing conector:
> 
>  protocol="org.apache.coyote.http11.Http11Protocol" 
> SSLEnabled="true" maxThreads="200" scheme="https" secure="true" 
> keystoreFile="/home/myuser/key.keystore" keystorePass="mypass" 
> clientAuth="false" sslProtocol="TLS" />

That looks good so far.

> Saved it, restarted server and accessed https://myip:8443, but it
> isn't working. Chrome says "No data recieved" and "Unable to load
> the webpage because the server sent no data and "Error code:
> ERR_EMPTY_RESPONSE".
> 
> Firefox says that the connection was reset while the page was being
> loaded.
> 
> That's where I am now. I don't know what to try anymore.

Try:

$ telnet localhost 8443

(on the server with Tomcat running)

That will tell you if the port is open (it should be, otherwise you'd
be getting different errors from Chrome and ff) and what, if anything,
gets dumped to it when you connect.

If you get a connection and nothing happens, try submitting a request
like this:

$ telnet localhost 8443
GET /

[output goes here]

Post the results of the above if you get anything.

Dumb question: you restarted Tomcat after updating server.xml, right?

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJUtW3WAAoJEBzwKT+lPKRYzVMP/Rl9RP6tpuU+leyUcyNjLy+2
hMSmXJ1GfttVxuC6KmD+leV19uyd6dKu16dA4v/LZMX+Un7uQIfY97vUleqg1LkA
HnwQYv6Sond5TOJR4PeY644qULBOOh4Bi+kJuS4HFjrAUCcG6KHSJfkhLluX/w6c
+I4/G5MYQQ0r68TOnLAn9ijTZl957ekj3ainc4XmL1U5BA7q0/fOttgVmytuUq3k
q3Kh/IU1S2ovu4milc0IWGcQttlZ9cn1nZf/nGZyuyWun0gQNLL5oX6ZY5ys5x1D
1LQ1TZWb6XL3TK1qBHvbs+u4qnfl3ZSWEKMWntYq0JHLDC2lvL8QcLvVkPguYN/W
6HHEp4fNfmqeWLvS7aj6ugNT6UQ4iWxhPJ882YeVQ06D9sLHGL5gIqJE+OPYp8pU
hyA7MnGDwKpbrTRq6u+QOUUF4Z+g/j++xTsdBk/+rrzaZs4HuLsBtikRbOoNr6ZJ
4c1WnuUiFkXbWYkMOEA9p3/Iy/nIay1aAmnqBEuWSBr83+WJvkB+/Nyf4HDZX6Ti
AElDG4K6yBVtN1bThmwFfWOPqO+zieP/RhdHUgVw7VOU7hi4xBMpcF+UZKImrkGs
kfN0tqSMriAQ7CL49UbrFxY4bsC0u4uVRJyoB4EOtaPy9cQH01rIrlotwOuPOwD4
lK/2rtEZo3uAazzi7oTP
=sNDG
-END PGP SIGNATURE-

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

Re: Session Clustering Monitoring

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Peter,

On 1/13/15 1:10 PM, Peter Rifel wrote:
> On 1/13/15, 6:32 AM, "Christopher Schultz"
>  wrote: On 1/12/15 4:32 PM, Peter
> Rifel wrote:
 On 1/12/15, 11:36 AM, "Christopher Schultz" 
  wrote: On 1/12/15 2:28 PM,
 Peter Rifel wrote:
>>> Chris,
>>> 
>>> On 1/12/15, 11:08 AM, "Christopher Schultz" 
>>>  wrote:
>>> 
>>> Peter,
>>> 
>>> On 1/12/15 12:51 PM, Peter Rifel wrote:
>> I'm running Tomcat 8.0.15 with Java 1.8.0_25 on
>> Ubuntu 14.04. We have 5 instances that are all
>> setup with session clustering as follows:
>> 
>> > className="org.apache.catalina.ha.tcp.SimpleTcpCluster">
>>
>>
>
>> 
> className="org.apache.catalina.ha.session.DeltaManager"
>>
>>
>
>> 
stateTransferTimeout="5" /> > className="org.apache.catalina.tribes.group.GroupChannel">
>>
>>
>
>> 
> className="org.apache.catalina.tribes.membership.McastService"
>>
>>

>>
>
>> 
address="${multicast}" />  
>> 
>> -Dmulticast=228.0.0.4
>> 
>> To help prevent accidental misconfigurations that
>> have occurred in the past, I decided to implement
>> monitoring on the session replication by checking
>> the JMX mbean 
>> Catalina/Manager///activeSessions 
>> attribute. Most of the time the values for the 5 
>> instances are all within 1 or 2 of each other.
>> Over the weekend we consistently had one instance
>> that had more sessions than the other 4. It began
>> with 102 sessions where every other instance had
>> 95. Over the next 36 hours as more sessions were
>> expiring over the weekend, the difference grew to
>> 49 vs 29. Eventually it resynced and now they all
>> report the same active session count. My question
>> is, does anyone know why this would happen, and
>> if this can be expected is there a better way to 
>> monitor session replication to ensure that there
>> isn't one instance that isn't being replicated
>> to? I believe this only happens on weekends when
>> most sessions are expiring and very few are being
>> created but I may be wrong.
>>> 
>>> How is your load-balancer configured to distribute
>>> traffic?
>>> 
 Two of the instances are behind one load balancer,
 and the other 3 are behind another.  They each
 provide a different service but are running the same
 war application and we want sessions clustered across
 both services. Each load balancer's initial
 distribution is based on the least number of
 connections, with persistence based on source IP.
 
 So basically all requests are randomly sent to back-end
 nodes? Or are you using session stickiness or anything like
 that?
 
> Sorry, I should have clarified.  Stickiness is based on
> the source ip, so requests from the same IP will be routed
> to the same instance.  With these applications we don't
> expect sessions to change Ips very often if at all, but if
> you think it would help I could stick based on the
> JSESSIONID cookie.
> 
> I was wondering, because there is an unfortunately situation with 
> session stickiness and long-lived clients where fail-over can cause
> a large number of clients to switch to a particular server and
> /stay there/ even if they have to re-login (when you'd likely
> prefer that they get re-balanced to another node if they have to
> re-login).
> 
> If you had a temporary failure of one node, perhaps the clients
> were re-assigned to another node and they "stayed there" when the
> failing node became available again. Those clients would stay there
> until either their newly-assigned node failed, or they closed their
> browser (assuming they are using cookies that live for the life of
> the client, like JSESSIONIDs typically do).
> 
> After the weekend in your scenario, perhaps all your users
> restarted their browsers (or computers) and thus were re-balanced.
> 
>> But shouldn't all sessions be replicated regardless of how
>> stickiness is (or isn't) setup?

Yes, they should. I was just considering a possible failure scenario.
With completely distributable sessions and the DeltaManager, the whole
cluster should stay in sync.

>> I assume that the DeltaManager only replicates changes to the
>> state of all sessions since its last replication.  Maybe if there
>> was a hiccup in replication by one tomcat instance, the sessions
>> that it created or extended would not have gotten replicated and
>> then never made their way to the other instances until they
>> expire on their own.

If this happened, you should be able to see some indication in the log
files.

>> If this is the

Re: Slow HTTP Rquest via Tomcat

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Thone,

On 1/13/15 1:05 PM, Thone Soungpanya wrote:
> Hello Andre,
> 
> I do not think it is an DNS lookup issue but I'll check on it.
> 
> Yes we actually have logs but it does not tell us much. We added 
> additional logging in our servlet code to tell us when and what the
> code is doing. I have attached a log for 1 connection which took
> about 1 minute and 23 seconds to complete. I have eliminated all
> sensitive information with "XX". During this
> time, there would be other connections too simultaneously.
> 
> Some information on the request: 1) HTTP request initiated at
> 16:11:06 to Tomcat.

This is a very confusing log file... from latest-to-oldest.

Before #2 happens, Tomcat reloads. Many (all?) web applications were
re-loaded. Was that expected?

> 2) Connection to Third Party System happened at 16:12:22. You can
> see it on line 38 with following text "2015-01-12 16:12:22,426
> INFO 06E4074221FF93C2827079EBC2102847; begin request"

Okay.

> 3) Response back to Tomcat from Third Party System at 16:12:29

This does not appear in the log.

> So it seems that between point#1 and point #2, there was about a 1 
> minute and 16 seconds delay before connection to the third party.
> Point #2 to Point #3 only took 7 seconds.
> 
> Can you or anyone see what may be the issue from the logs?

Tomcat is reloading in the middle of the request?

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJUtWtPAAoJEBzwKT+lPKRY/m8P/i0VaL3x05kGAArWb+RL+BOL
jhfezsN5NKw3iosMFnlDkeyoD59AnWZvUqbnybqzCf9aXacT3iUeHEZHq4/mu3ew
juawm0phZl19PKYCfA/3PN0XR1jXVWdyN06QJuzA1KlpFDp7+/9WTWvMcLtG3DqC
vW3NstywZ7sPTgingHgVegEjcnKeXyDmFuhaUyyBNxo7Tgy/HaNwfB8Y7GSLBvGY
/NiJi0klkpbeyz+epbxzBe8JlYiFwosjlJIE0MpXvZgrKtiyD+cj9yaJxNGos5GS
nkiD3FGYKQ5cZ5c4dAXMs7es0bPjqRYWBRTiiaa8W2yX57t44Y7ZB6geuteep0/7
URS0NoONdCg1TbR/XE1kqG06g+IrBSzHBUZRzW3A8+NICcLQc/3i+X1zMYfnrD46
MzcBViMpsyJrBbsfpPol49zLx284/+146gYs6djhCdnWcbVNXf12QI/DA/YedThc
zJeCYy0MWQlhQ2T1FECgtgtPzSY0j+Wt06Dz+JoTAOXb5qX9kD/hvj+d2VRfWkkn
P2qBANSiOBE+JNPXQsA1JjHlWHO+HS4CIqG5VEflQ7aVzbC0zv57aRYqFFpPu1tH
Oc+S/m1AGpDdaRGBhjgdJCbtT8Pyi+WzCAA5YqeHjmEBDwo7pnnXoh9HO5t0UOb5
8hWJpjaXWxg+NxjIlv+P
=wn8y
-END PGP SIGNATURE-

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

FarmWarDeployer not checking watchDir

[Théo Chamley]

Hello,

I have setup a Tomcat cluster and I am now trying to get the 
FarmWarDeployer to work.
However, it seems that the Deployer never checks my watchDir and 
therefore never finds my new wars to deploy.


When starting Tomcat, the logs indicate that the Deployer is started:
13-Jan-2015 19:21:43.942 INFO [Catalina-startStop-1] 
org.apache.catalina.ha.deploy.FarmWarDeployer.start Cluster deployment 
is watching [/my/watch/dir/] for changes.
13-Jan-2015 19:21:43.942 INFO [Catalina-startStop-1] 
org.apache.catalina.ha.deploy.FarmWarDeployer.start Cluster 
FarmWarDeployer started.


But nothing more, even for extended periods of time after putting my 
ROOT.war inside my watchDir.


I checked the source code 
(https://github.com/apache/tomcat80/blob/trunk/java/org/apache/catalina/ha/deploy/FarmWarDeployer.java), 
and it seems that the check must be done once every two 
"backgroundProcess" calls, but I don't understand when this function is 
supposed to be called or if there is a way to force the check.


I feel like I am missing something obvious...


Here is my config:
Oracle JDK 1.8.0_25
Tomcat 8.0.15
server.xml:

className="org.apache.catalina.ha.tcp.SimpleTcpCluster"

channelSendOptions="6">
className="org.apache.catalina.ha.session.BackupManager"

expireSessionsOnShutdown="false"
notifyListenersOnReplication="true"
mapSendOptions="6"/>
className="org.apache.catalina.tribes.group.GroupChannel">
className="org.apache.catalina.tribes.membership.McastService"

address="228.0.0.4"
port="45564"
frequency="500"
dropTime="3000"
bind="10.0.0.1"/>
className="org.apache.catalina.tribes.transport.nio.NioReceiver"

address="10.0.0.1"
port="5000"
selectorTimeout="100"
maxThreads="6"/>
className="org.apache.catalina.tribes.transport.ReplicationTransmitter">
className="org.apache.catalina.tribes.transport.nio.PooledParallelSender"/>


className="org.apache.catalina.tribes.group.interceptors.TcpFailureDetector"/>
className="org.apache.catalina.tribes.group.interceptors.MessageDispatch15Interceptor"/>
className="org.apache.catalina.tribes.group.interceptors.ThroughputInterceptor"/>


className="org.apache.catalina.ha.tcp.ReplicationValve"

filter=".*.gif|.*.js|.*.jpeg|.*.jpg|.*.png|.*.css|.*.txt"/>
className="org.apache.catalina.ha.deploy.FarmWarDeployer"

tempDir="/my/temp/dir/"
deployDir="/my/app/base/"
watchDir="/my/listen/dir/"
watchEnabled="true"/>
className="org.apache.catalina.ha.session.ClusterSessionListener"/>




Thank you in advance,

Théo

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

Can't make SSL work on Tomcat7 on Ubuntu Server 14.04

[Alexandre Lima]

Hello!
This is the first time I'm using tomcat, so I'm a little bit lost...
Using the tutorials, I could make the server and the application I want to
run with it work.
The only modification I did until now was changing the http port from 8080
to 80, I did that changing the http conector on servers.xml, enabling
authbind and executing the folowing commands:

sudo touch /etc/authbind/byport/80
sudo chmod 500 /etc/authbind/byport/80
sudo chown tomcat7 /etc/authbind/byport/80

So, the server and the application I want to use with it are actually
working on port 80, but the next and last step, which is enabling an SSL
conection, isn't working.

What I did following the site's tutorial was: created my self signed
certificate with keytools and put it on /home/myuser/key.keystore
Aditionally, I've created the folowing conector:



Saved it, restarted server and accessed https://myip:8443, but it isn't
working.
Chrome says "No data recieved" and "Unable to load the webpage because the
server sent no data and "Error code: ERR_EMPTY_RESPONSE".

Firefox says that the connection was reset while the page was being loaded.

That's where I am now. I don't know what to try anymore.
Any ideas?

Thank you!

-- 
--
Alexandre Lima

Re: Session Clustering Monitoring

[Peter Rifel]

Chris,

On 1/13/15, 6:32 AM, "Christopher Schultz" 
wrote:

>-BEGIN PGP SIGNED MESSAGE-
>Hash: SHA256
>
>Peter,
>
>On 1/12/15 4:32 PM, Peter Rifel wrote:
>> On 1/12/15, 11:36 AM, "Christopher Schultz"
>>  wrote: On 1/12/15 2:28 PM, Peter
>> Rifel wrote:
> Chris,
> 
> On 1/12/15, 11:08 AM, "Christopher Schultz"
>  wrote:
> 
> Peter,
> 
> On 1/12/15 12:51 PM, Peter Rifel wrote:
 I'm running Tomcat 8.0.15 with Java 1.8.0_25 on Ubuntu
 14.04. We have 5 instances that are all setup with
 session clustering as follows:
 
 >>> className="org.apache.catalina.ha.tcp.SimpleTcpCluster">

 
 className="org.apache.catalina.ha.session.DeltaManager"

 
>stateTransferTimeout="5" /> >>> className="org.apache.catalina.tribes.group.GroupChannel">

 
 className="org.apache.catalina.tribes.membership.McastService"


>>
 
>address="${multicast}" />  
 
 -Dmulticast=228.0.0.4
 
 To help prevent accidental misconfigurations that have
 occurred in the past, I decided to implement monitoring
 on the session replication by checking the JMX mbean
 Catalina/Manager///activeSessions
 attribute. Most of the time the values for the 5
 instances are all within 1 or 2 of each other. Over the
 weekend we consistently had one instance that had more
 sessions than the other 4. It began with 102 sessions
 where every other instance had 95. Over the next 36
 hours as more sessions were expiring over the weekend,
 the difference grew to 49 vs 29. Eventually it resynced
 and now they all report the same active session count.
 My question is, does anyone know why this would happen,
 and if this can be expected is there a better way to
 monitor session replication to ensure that there isn't
 one instance that isn't being replicated to? I believe
 this only happens on weekends when most sessions are
 expiring and very few are being created but I may be
 wrong.
> 
> How is your load-balancer configured to distribute traffic?
> 
>> Two of the instances are behind one load balancer, and the
>> other 3 are behind another.  They each provide a different
>> service but are running the same war application and we
>> want sessions clustered across both services. Each load
>> balancer's initial distribution is based on the least
>> number of connections, with persistence based on source
>> IP.
>> 
>> So basically all requests are randomly sent to back-end nodes? Or
>> are you using session stickiness or anything like that?
>> 
>>> Sorry, I should have clarified.  Stickiness is based on the
>>> source ip, so requests from the same IP will be routed to the
>>> same instance.  With these applications we don't expect sessions
>>> to change Ips very often if at all, but if you think it would
>>> help I could stick based on the JSESSIONID cookie.
>
>I was wondering, because there is an unfortunately situation with
>session stickiness and long-lived clients where fail-over can cause a
>large number of clients to switch to a particular server and /stay
>there/ even if they have to re-login (when you'd likely prefer that
>they get re-balanced to another node if they have to re-login).
>
>If you had a temporary failure of one node, perhaps the clients were
>re-assigned to another node and they "stayed there" when the failing
>node became available again. Those clients would stay there until
>either their newly-assigned node failed, or they closed their browser
>(assuming they are using cookies that live for the life of the client,
>like JSESSIONIDs typically do).
>
>After the weekend in your scenario, perhaps all your users restarted
>their browsers (or computers) and thus were re-balanced.

But shouldn't all sessions be replicated regardless of how stickiness is
(or isn't) setup?

I assume that the DeltaManager only replicates changes to the state of all
sessions since its last replication.  Maybe if there was a hiccup in
replication by one tomcat instance, the sessions that it created or
extended would not have gotten replicated and then never made their way to
the other instances until they expire on their own.

If this is the case, I may try and come up with a better method for
monitoring the clustering state, unless anyone has any suggestions on how
to fix this supposed hiccup.

Thanks for your help,

Peter

>
>- -chris
>-BEGIN PGP SIGNATURE-
>Version: GnuPG v1
>Comment: GPGTools - http://gpgtools.org
>
>iQIcBAEBCAAGBQJUtSySAAoJEBzwKT+lPKRYsy4P/3i4YqxWocydSt/gWjNv+AAG
>tiwzXYCd1MsVrnqy05nFjSJqJvdwCd027xPStf6O2m+VSO4M0+siRK11iupGdrFx
>aRAR93RQrMViX94dVxn+QSTot+Ma0me9igZ61y/YBceTkxXTjP9WGGi2KWG4zX9/
>YMQv1Wsk030jFGETQTAcEiI+LFepWuJfaoPnDtLTGJzYuA2TvMw+MTJfVeiJ+/AG
>+R1fQPo

Re: Occasional long wait for a JDBC connection

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Darren,

On 1/13/15 11:49 AM, Darren Davis wrote:
> The problem occurred again this morning.  I was able to generate a
> thread dump and narrow down the source of our problem to tomcat
> thread 23.
> 
>> From 8:45:51,397 to 09:01:19,083, it was stuck in the validate
>> check for a
> newly instantiated connection:
> 
> I ran the thread dump several times during this interval, and the
> stack trace for thread 23 did not change at all.
> 
> I did check our database log file and determined that during the 8
> hours that led up to our first error on the server yesterday, we
> had just a total of 12 unique connections.  The problem occurred
> the the creation of connection # 13, which was then used several
> other times later.
> 
> The incident this morning also coincided with creating a new
> connection in the pool.  It does not make any sense that the simple
> validation query of "SELECT 1" would require a wait of 15 minutes
> to succeed.

Agreed.

> It's also strange that this only happens sporadically, and not
> every time a new connection is being "birthed" by the system.
> 
> We've tried two different pooling technologies: DBCP and the new
> Apache JDBC pooling on this server and both exhibit the same 15
> minute occasional wait.

The problem is with the driver and/or database, not with the
connection pool. It's not surprising that you are experiencing
problems regardless of the pool being used.

> we've come across documentation that suggests we could modify our 
> validation statement by prefixing it with /* ping */, which we're
> thinking about trying

Using "/* ping */" is usually a good idea for MySQL, but it may mask
the problem. What you may find is that the next "real" query you use
hangs for 15 minutes. If you are going to use /* ping */ and you are
going to use the tomcat-jdbc pool, then you may as well not configure
a validation query at all because Tomcat's pool will use
Connection.isValid which amounts to the same thing (and will work for
any compliant JDBC driver, not just with MySQL).

> "http-nio-8443-exec-23" #156 daemon prio=5 os_prio=0
> tid=0x7f0658387000 nid=0x7a60 runnable [0x7f05e7466000] 
> java.lang.Thread.State: RUNNABLE at
> java.net.SocketInputStream.$$YJP$$socketRead0(Native Method) at
> java.net.SocketInputStream.socketRead0(SocketInputStream.java) at
> java.net.SocketInputStream.read(SocketInputStream.java:150) at
> java.net.SocketInputStream.read(SocketInputStream.java:121) at 
> com.mysql.jdbc.util.ReadAheadInputStream.fill(ReadAheadInputStream.java:114)
>
> 
at
> com.mysql.jdbc.util.ReadAheadInputStream.readFromUnderlyingStreamIfNecessary(ReadAheadInputStream.java:161)
>
> 
at
> com.mysql.jdbc.util.ReadAheadInputStream.read(ReadAheadInputStream.java:189)
>
> 
- - locked <0xbdf09420> (a
> com.mysql.jdbc.util.ReadAheadInputStream) at
> com.mysql.jdbc.MysqlIO.readFully(MysqlIO.java:2549) at
> com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:3002) at
> com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:2991) at
> com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3532) at
> com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:2002) at
> com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2163) at
> com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2618) -
> locked <0xbdf04df0> (a com.mysql.jdbc.JDBC4Connection) at
> com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2568) at
> com.mysql.jdbc.StatementImpl.execute(StatementImpl.java:842) -
> locked <0xbdf04df0> (a com.mysql.jdbc.JDBC4Connection) -
> locked <0xff107cd8> (a com.mysql.jdbc.StatementImpl) at
> com.mysql.jdbc.StatementImpl.execute(StatementImpl.java:681) at 
> org.apache.tomcat.jdbc.pool.PooledConnection.validate(PooledConnection.java:503)
>
> 
at
> org.apache.tomcat.jdbc.pool.PooledConnection.validate(PooledConnection.java:437)
>
> 
at
> org.apache.tomcat.jdbc.pool.ConnectionPool.borrowConnection(ConnectionPool.java:763)
>
> 
at
> org.apache.tomcat.jdbc.pool.ConnectionPool.borrowConnection(ConnectionPool.java:617)
>
> 
at
> org.apache.tomcat.jdbc.pool.ConnectionPool.getConnection(ConnectionPool.java:186)
>
> 
at
> org.apache.tomcat.jdbc.pool.DataSourceProxy.getConnection(DataSourceProxy.java:127)
>
> 
at
> org.springframework.orm.hibernate3.LocalDataSourceConnectionProvider.getConnection(LocalDataSourceConnectionProvider.java:83)
>
> 
at
> org.hibernate.jdbc.ConnectionManager.openConnection(ConnectionManager.java:446)
>
> 
at
> org.hibernate.jdbc.ConnectionManager.getConnection(ConnectionManager.java:167)
>
> 
at org.hibernate.jdbc.JDBCContext.connection(JDBCContext.java:160)
> at 
> org.hibernate.transaction.JDBCTransaction.begin(JDBCTransaction.java:81)
>
> 
at
> org.hibernate.impl.SessionImpl.beginTransaction(SessionImpl.java:1473)
>
> 
at
> org.springframework.orm.hibernate3.HibernateTransactionManager.doBegin(HibernateTransactionManager.java:556)
>
> 
at
> org.springframework.transaction.support.Abstra

Re: mod_jk status worker returns 500 error with no messages, logs

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

All,

On 1/10/15 2:56 PM, Christopher Schultz wrote:
> I'm having a problem with mod_jk 1.2.40 under Apache 2.4.10. After
> a successful start up, accessing the mod_jk status page gives me a
> 500 error with no errors on the screen or in the logs.

Solved.

The problem turned out to be authnz_ldap, which does not produce any
errors when it can't reach the LDAP server. A bad iptables rule
prevented this web server from reaching our LDAP server, and the
behavior was "500 server error" with no messages in any log files for
any resource protected by the module.

I spent a great deal of time trying to figure out how this web server
was configured differently than any of the others, which were of
course still working just fine. Since the problem was with an external
server (the LDAP server), it took quite a long time to track down, as
the web servers were in fact configured identically :)

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJUtV0cAAoJEBzwKT+lPKRYITgP/R+26B1ouAnuQUu9H+pg2O1n
UOabLYeZfb+yTTXXdAqTeMvYDI/7KBft8kI0Gb/VvmelXAnUpdocH3+8IhI+/G08
kVIUap5c2GA6ifO10ldgipeU/DJzQjVmon7O/2An8jZOcNF7RpVoxEbwOb3yaXWg
L6qL9vIF6hKd00XPpsES85AAlW8jgewWSP9TR1gA5Nxg2PivqtdLNO/nNlRTu0fK
M1J4gZajXpW1DnlBdBahbZ7ViwrICYhnflAkLhB7moBB4a99EfBI3tdweuGApkFU
f9JrcEHzIb1maKhbr8NHf4U7fO/71+G7DIPeFsXAGzH55ykUlo7wJVbhrF0/x4fW
ZqhrT3no+hEGNSH6Uaprk5EbBpqF08QWNJamPcQgOEo7V8ZBKvMdVYcMh1uU/+7a
c3Rn7STv1hTUT7NQ2SUXhO3Uz8kKfF3p1rkJPH5YdINokNbLX3Bg2lIuEKvcvCbC
mvnuKZP2WPuE5o8KTuHFKPfurHrb08mTQRjpS9T8I+q581ZxBcsHjsOt0b+kWc+F
8GgxRzaq550vzT4Ye8DJweqQeE7G4nvc9W1N/kktPHww91KMx4rnmvZsGpstFWQT
QTKcLxhxz2Yezt/axBRfcQDiwYADTwTORGIyWfqCzaFsZaIi9P2KktibZ/WCplWj
ZUX+ogA+eD9+49mSWunu
=eS1Y
-END PGP SIGNATURE-

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

RE: Slow HTTP Rquest via Tomcat

[Thone Soungpanya]

Hello Chris,

The average number of simultaneous requests I would say would be about 1500 
connections when this slows down. Is there a max number of connection or memory 
limitation? We have about 4 GB of memory on the system which 1 GB is set as the 
XMX value for this JVM instance. 

Jolt port is Oracle Technology which will handle all web requests and 
communicate between PeopleSoft application server and web server.

Ok, I will try the thread dump of the application and see if it will give some 
information. 

Thanks,

Thone


-Original Message-
From: Christopher Schultz [mailto:ch...@christopherschultz.net] 
Sent: Monday, January 12, 2015 7:41 PM
To: Tomcat Users List
Subject: Re: Slow HTTP Rquest via Tomcat

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Thone,

On 1/12/15 6:03 PM, Thone Soungpanya wrote:
> When connecting from Tomcat to third party, we are going through a 
> servlet code which is customized by us. We package the code into a jar 
> file which sits on the \WEB-INF\lib folder. When connection, we create 
> a session and connect through the application server IP address, jolt 
> port, username and password. The third party system we connect to is a 
> PeopleSoft ERP system.
> 
> When the problem occurs, I would estimate it to be about 200 or so 
> active sessions through just that one folder. Now, another thing I 
> forgot to mention is, we have multiple web application folders with 
> the same files but just different PeopleTools version to support for 
> different clients. These are not slowing up and they have about maybe 
> 10 - 20 sessions. Just throwing this information out there in case.
> 
> Also to note again, I do not think it is the connection to the third 
> party. While reviewing the logs, I notice when connecting to third 
> party, it takes about 10 seconds round-trip. We write logs when it 
> begin connection to end connection. Something is bottlenecking in the 
> tomcat server before trying to connect.

The number of uses sessions is largely irrelevant. What is relevant is the 
number of simultaneous requests that are being made to your own web 
application, and how many are trying to create these outgoing connections.

(Just curious: what is a "jolt port"?)

If you have a 20-50 second pause, there's enough time to trigger a thread dump 
of the application (see the wiki HOWTO section for how to do that). A thread 
dump will tell you where the code is hanging. It's not likely to be in Tomcat 
itself.

- -chris

> -Original Message- From: cjder...@gmail.com 
> [mailto:cjder...@gmail.com] On Behalf Of chris derham Sent:
> Monday, January 12, 2015 2:43 PM To: Tomcat Users List Subject: Re:
> Slow HTTP Rquest via Tomcat
> 
> On 13 January 2015 at 11:38, Thone Soungpanya 
>  wrote:
>> Hello,
>> 
>> Can anyone give some advice on what the issue may be? We have a web 
>> application folder in Tomcat that have been slowing the http 
>> request's connection to another third party system when there are 
>> high traffic. It seems to be halting in the Tomcat server for about 
>> 20 - 50 seconds before attempting to connect to the third party 
>> system. Once it tries to connect to the third party system, the 
>> response time is only about 6 - 10 seconds which is normal.
>> It does not seem to be an issue at the third party's end as the 
>> response time is quick once we get connected.
>> 
>> Here are the specs that we have and additional information...
>> 
>> 1) Apache Tomcat 7.0.56 2) JVM version 1.7 3) Running on Linux OS 
>> Version 2.6.32
>> 
>> Connection Flow: 1) User submits a HTTP request from web application 
>> to Tomcat 2) Tomcat calls Java's servlet code along with HTTP request 
>> parameters 3) Java servlet code connects to third party system via 
>> application server and jolt port 4) Third party system returns 
>> requested information
>> 
>> We thought it would be a session issue which we lowered the session 
>> timeout (just for that folder) in WEB-INF folder to 5 minutes from 
>> defaulted 30 minutes but it is still doing the same thing.
>> 
>> Any advice on what it may be? Let me know if you need additional 
>> information.
> 
> How does your code connect to the 3rd party? There are libraries that 
> do this, please elaborate which you use. I recall using one, and it 
> had a limit on the number of concurrent connections to a 3rd party. 
> Perhaps you hit this limit? How many connections are you talking about 
> when the problem occurs - 10s, 100s, 1000s or more?
> 
> Chris
> 
>> Thank you in advance!
>> 
>> Thone
> 
> -
>
>
> 
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
> 
> 
> -
>
>
> 
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
> 
-BEGIN PGP SIGNAT

Re: Occasional long wait for a JDBC connection

[Daniel Mikusa]

On Tue, Jan 13, 2015 at 11:49 AM, Darren Davis 
wrote:

First thing, please don't top post.  The convention followed on this list
is to either reply inline, like this, or reply at the bottom.

The problem occurred again this morning.  I was able to generate a thread
> dump and narrow down the source of our problem to tomcat thread 23.
>
> From 8:45:51,397 to 09:01:19,083, it was stuck in the validate check for a
> newly instantiated connection:
>
> I ran the thread dump several times during this interval, and the stack
> trace for thread 23 did not change at all.
>
> I did check our database log file and determined that during the 8 hours
> that led up to our first error on the server yesterday, we had just a total
> of 12 unique connections.  The problem occurred the the creation of
> connection # 13, which was then used several other times later.
>
> The incident this morning also coincided with creating a new connection in
> the pool.  It does not make any sense that the simple validation query of
> "SELECT 1" would require a wait of 15 minutes to succeed.
>

I would agree.  If things are working properly the validation request
should return very quickly.  As to what's happening here I can't say
exactly, but do you by chance have a firewall in between Tomcat and the
database?

What can sometimes happen when there's a firewall between Tomcat and the
database that causes similar behavior is that the firewall will disconnect
persistent idle connections (your db connections) after a certain period of
time (often 30 or 60 minutes).  Depending on how the firewall is configured
it may just passively drop packets for that connection.  In this case,
there's no way to know what's happened and it can take a considerable
amount of time for the connection to timeout.

If this is what's happening, you have a couple possibilities for working
around it.

   - configure an idle validation test (i.e. testWhileIdle and friends).
This should periodically send traffic, in the form of a validation query,
to each connection sitting idle in the pool.

   - set maxAge to something less than the limit set by the firewall.  If
using Tomcat's jdbc-pool (not sure if this is supported by other pools), it
will throw out connections older than this value (in ms).

   - reconfigure your idle limits so you don't have as many idle
connections.  You've likely got connections sitting idle in the pool for a
very long time, which means you probably don't need that many idle
connections.  If you lower this, the connections might get used more and
not be closed by the firewall.

There's probably other possible fixes as well, those are in no particular
order and just the first ones that came to mind.


> It's also strange that this only happens sporadically, and not every time a
> new connection is being "birthed" by the system.
>
> We've tried two different pooling technologies: DBCP and the new Apache
> JDBC pooling on this server and both exhibit the same 15 minute occasional
> wait.
>
> we've come across documentation that suggests we could modify our
> validation statement by prefixing it with /* ping */, which we're thinking
> about trying
>

I don't think this will help here, but it's a good idea.  It's an
optimization for the MySQL jdbc driver that should make your validation
queries faster.

Dan


>
>
> "http-nio-8443-exec-23" #156 daemon prio=5 os_prio=0 tid=0x7f0658387000
> nid=0x7a60 runnable [0x7f05e7466000]
>java.lang.Thread.State: RUNNABLE
> at java.net.SocketInputStream.$$YJP$$socketRead0(Native Method)
> at java.net.SocketInputStream.socketRead0(SocketInputStream.java)
> at java.net.SocketInputStream.read(SocketInputStream.java:150)
> at java.net.SocketInputStream.read(SocketInputStream.java:121)
> at
>
> com.mysql.jdbc.util.ReadAheadInputStream.fill(ReadAheadInputStream.java:114)
> at
>
> com.mysql.jdbc.util.ReadAheadInputStream.readFromUnderlyingStreamIfNecessary(ReadAheadInputStream.java:161)
> at
>
> com.mysql.jdbc.util.ReadAheadInputStream.read(ReadAheadInputStream.java:189)
> - locked <0xbdf09420> (a
> com.mysql.jdbc.util.ReadAheadInputStream)
> at com.mysql.jdbc.MysqlIO.readFully(MysqlIO.java:2549)
> at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:3002)
> at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:2991)
> at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3532)
> at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:2002)
> at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2163)
> at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2618)
> - locked <0xbdf04df0> (a com.mysql.jdbc.JDBC4Connection)
> at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2568)
> at com.mysql.jdbc.StatementImpl.execute(StatementImpl.java:842)
> - locked <0xbdf04df0> (a com.mysql.jdbc.JDBC4Connection)
> -

Re: Occasional long wait for a JDBC connection

[Darren Davis]

The problem occurred again this morning.  I was able to generate a thread
dump and narrow down the source of our problem to tomcat thread 23.

>From 8:45:51,397 to 09:01:19,083, it was stuck in the validate check for a
newly instantiated connection:

I ran the thread dump several times during this interval, and the stack
trace for thread 23 did not change at all.

I did check our database log file and determined that during the 8 hours
that led up to our first error on the server yesterday, we had just a total
of 12 unique connections.  The problem occurred the the creation of
connection # 13, which was then used several other times later.

The incident this morning also coincided with creating a new connection in
the pool.  It does not make any sense that the simple validation query of
"SELECT 1" would require a wait of 15 minutes to succeed.

It's also strange that this only happens sporadically, and not every time a
new connection is being "birthed" by the system.

We've tried two different pooling technologies: DBCP and the new Apache
JDBC pooling on this server and both exhibit the same 15 minute occasional
wait.

we've come across documentation that suggests we could modify our
validation statement by prefixing it with /* ping */, which we're thinking
about trying


"http-nio-8443-exec-23" #156 daemon prio=5 os_prio=0 tid=0x7f0658387000
nid=0x7a60 runnable [0x7f05e7466000]
   java.lang.Thread.State: RUNNABLE
at java.net.SocketInputStream.$$YJP$$socketRead0(Native Method)
at java.net.SocketInputStream.socketRead0(SocketInputStream.java)
at java.net.SocketInputStream.read(SocketInputStream.java:150)
at java.net.SocketInputStream.read(SocketInputStream.java:121)
at
com.mysql.jdbc.util.ReadAheadInputStream.fill(ReadAheadInputStream.java:114)
at
com.mysql.jdbc.util.ReadAheadInputStream.readFromUnderlyingStreamIfNecessary(ReadAheadInputStream.java:161)
at
com.mysql.jdbc.util.ReadAheadInputStream.read(ReadAheadInputStream.java:189)
- locked <0xbdf09420> (a
com.mysql.jdbc.util.ReadAheadInputStream)
at com.mysql.jdbc.MysqlIO.readFully(MysqlIO.java:2549)
at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:3002)
at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:2991)
at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3532)
at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:2002)
at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2163)
at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2618)
- locked <0xbdf04df0> (a com.mysql.jdbc.JDBC4Connection)
at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2568)
at com.mysql.jdbc.StatementImpl.execute(StatementImpl.java:842)
- locked <0xbdf04df0> (a com.mysql.jdbc.JDBC4Connection)
- locked <0xff107cd8> (a com.mysql.jdbc.StatementImpl)
at com.mysql.jdbc.StatementImpl.execute(StatementImpl.java:681)
at
org.apache.tomcat.jdbc.pool.PooledConnection.validate(PooledConnection.java:503)
at
org.apache.tomcat.jdbc.pool.PooledConnection.validate(PooledConnection.java:437)
at
org.apache.tomcat.jdbc.pool.ConnectionPool.borrowConnection(ConnectionPool.java:763)
at
org.apache.tomcat.jdbc.pool.ConnectionPool.borrowConnection(ConnectionPool.java:617)
at
org.apache.tomcat.jdbc.pool.ConnectionPool.getConnection(ConnectionPool.java:186)
at
org.apache.tomcat.jdbc.pool.DataSourceProxy.getConnection(DataSourceProxy.java:127)
at
org.springframework.orm.hibernate3.LocalDataSourceConnectionProvider.getConnection(LocalDataSourceConnectionProvider.java:83)
at
org.hibernate.jdbc.ConnectionManager.openConnection(ConnectionManager.java:446)
at
org.hibernate.jdbc.ConnectionManager.getConnection(ConnectionManager.java:167)
at org.hibernate.jdbc.JDBCContext.connection(JDBCContext.java:160)
at
org.hibernate.transaction.JDBCTransaction.begin(JDBCTransaction.java:81)
at
org.hibernate.impl.SessionImpl.beginTransaction(SessionImpl.java:1473)
at
org.springframework.orm.hibernate3.HibernateTransactionManager.doBegin(HibernateTransactionManager.java:556)
at
org.springframework.transaction.support.AbstractPlatformTransactionManager.handleExistingTransaction(AbstractPlatformTransactionManager.java:424)
at
org.springframework.transaction.support.AbstractPlatformTransactionManager.getTransaction(AbstractPlatformTransactionManager.java:348)
at
org.springframework.transaction.interceptor.TransactionAspectSupport.createTransactionIfNecessary(TransactionAspectSupport.java:417)
at
org.springframework.transaction.interceptor.TransactionAspectSupport.invokeWithinTransaction(TransactionAspectSupport.java:255)
at
org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:94)
at
org.sprin

Re: Occasional long wait for a JDBC connection

[Daniel Mikusa]

On Tue, Jan 13, 2015 at 9:51 AM, Darren Davis 
wrote:

> Recently we deployed our production application on a Tomcat 8.0.14 web
> server.  We are using the Tomcat JDBC Connection pool against MySQL 5.  Our
> web application uses Spring (3.2.11.RELEASE) /Hibernate (3.6.10.Final) for
> transaction management.  We are using a Cent OS 6 linux server in the cloud
> running the 2.6.32-504 kernel.  We're using the 1.8.0_25 jdk.
>
>
>
> Ever since deployment, we've noticed that a couple of times per day, when
> Spring is attempting to prepare/open a new JDBC Connection, the thread in
> question times out for about 15 minutes, and then resumes as if everything
> is fine.
>

What's the CPU usage like at this time?  Seems unlikely, but maybe your in
the middle of a massive full GC.


>
> The line that appears to be hanging from the hibernate side is
> factory.getConnectionProvider().getConnection(), which I think simply asks
> for a connection from the pool.
>

Out of curiosity how did you determine this?  Did you take a thread dump?
If not, that would be a good place to start.  Grab three or four thread
dumps during that 15 minute window.  The thread dump will tell you exactly
what's happening in the thread at the time.  Looking at multiple dumps will
also show you if the thread has progressed from one dump to the next.

Instructions for taking at thread dump can be found here:


http://wiki.apache.org/tomcat/HowTo#How_do_I_obtain_a_thread_dump_of_my_running_webapp_.3F

Dan


>
> The following options are defined in the Resource definition:
> auth="Container"
> factory="org.apache.tomcat.jdbc.pool.DataSourceFactory"
> type="javax.sql.DataSource"
> driverClassName="com.mysql.jdbc.Driver"
> maxActive=500
> maxIdle=55
> maxWait=15000
> validationQuery="Select 1"
> testOnBorrow="true"
> defaultAutoCommit="false"
>
> At this time of year, our user load peaks around 150, so we shouldn't be
> coming close to the maxActive defined.  MySql is configured to allow for
> 1010 maximum connections (we have two Tomcat instances that point to it,
> configured similarly)


> This application has ran for years without a problem against a Tomcat 6
> instance, but after moving to Jdk 8 and Tomcat 8, we're seeing this 15
> minute wait.
>
> Any ideas on what could cause this sort of thing, and as there additional
> logging we could turn on to try and figure out what is happening inside the
> pool to make it wait so long?
>

Occasional long wait for a JDBC connection

[Darren Davis]

Recently we deployed our production application on a Tomcat 8.0.14 web
server.  We are using the Tomcat JDBC Connection pool against MySQL 5.  Our
web application uses Spring (3.2.11.RELEASE) /Hibernate (3.6.10.Final) for
transaction management.  We are using a Cent OS 6 linux server in the cloud
running the 2.6.32-504 kernel.  We're using the 1.8.0_25 jdk.



Ever since deployment, we've noticed that a couple of times per day, when
Spring is attempting to prepare/open a new JDBC Connection, the thread in
question times out for about 15 minutes, and then resumes as if everything
is fine.

The line that appears to be hanging from the hibernate side is
factory.getConnectionProvider().getConnection(), which I think simply asks
for a connection from the pool.

The following options are defined in the Resource definition:
auth="Container"
factory="org.apache.tomcat.jdbc.pool.DataSourceFactory"
type="javax.sql.DataSource"
driverClassName="com.mysql.jdbc.Driver"
maxActive=500
maxIdle=55
maxWait=15000
validationQuery="Select 1"
testOnBorrow="true"
defaultAutoCommit="false"

At this time of year, our user load peaks around 150, so we shouldn't be
coming close to the maxActive defined.  MySql is configured to allow for
1010 maximum connections (we have two Tomcat instances that point to it,
configured similarly)

This application has ran for years without a problem against a Tomcat 6
instance, but after moving to Jdk 8 and Tomcat 8, we're seeing this 15
minute wait.

Any ideas on what could cause this sort of thing, and as there additional
logging we could turn on to try and figure out what is happening inside the
pool to make it wait so long?

Re: Scripting mod_jk load-balancer member changes

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Rainer,

On 1/12/15 5:41 PM, Rainer Jung wrote:
> Am 12.01.2015 um 20:12 schrieb Christopher Schultz:
>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA256
>> 
>> All,
>> 
>> On 1/12/15 2:01 PM, Christopher Schultz wrote:
>>> I'm running into a bit of difficulty scripting updates for 
>>> load-balancer members and thought I'd ask here before slogging 
>>> through the code to see if there are any requirements I'm
>>> missing.
>>> 
>>> Long story short, I'd like to script setting the "activation" 
>>> status for a particular load-balanced worker to something, like
>>> ACT or DIS.
>>> 
>>> I've written a python script to do this for me and I can
>>> confirm with Wireshark that it's sending what I expect. Here is
>>> the HTTP request that is being sent:
>>> 
>>> " POST /jk-status HTTP/1.1 Accept-Encoding: identity 
>>> Content-Length: 43 Host: localhost Content-Type: 
>>> application/x-www-form-urlencoded Connection: close
>>> User-Agent: mod_jk.py / Python-urllib
>>> 
>>> 
>>> from=list&cmd=update&sw=myworker&vwa=1&w=lb "
>>> 
>>> That's the whole request. The response I get is a 200
>>> response, but it's got the form content in it again, and not
>>> the "you will be redirected in 3 seconds" response that I get
>>> from the web UI.
>>> 
>>> I can think of a few things that I just wanted to sanity
>>> check:
>>> 
>>> 1. I need to provide all of the various values and not just
>>> the "vwa" value (which is the short-code request parameter
>>> value for the "activation" status).
>>> 
>>> 2. The status worker can't handle POST requests (the web
>>> interface uses GET).
>>> 
>>> 3. I've broken something else.
>>> 
>>> Can anyone confirm either 2 or 3 above, or both?
>> 
>> I tried switching to GET and so I'm using this URL, now:
>> 
>> GET /jk-status?from=list&cmd=update&sw=myworker&vwa=0&w=lb
>> HTTP/1.1 Accept-Encoding: identity Host: localhost Connection:
>> close User-Agent: mod_jk.py / Python-urllib
>> 
>> (Note that the load balancer worker's name is "lb" and the
>> balanced worker is called "myworker")
>> 
>> I'm getting a 200 response with the expected "You will be
>> redirected in 3 seconds" page, but the value for the activation
>> of this worker is not actually being updated.
>> 
>> So, it seems that the data must be in the URL (i.e. GET) but
>> something is still not working as I expect.
>> 
>> Can anyone shed some light on what I might be missing?
>> 
>> I can probably change the order of the parameters if that's
>> what's required... I'm using a python dictionary (an unordered
>> name/value hash) to build my request parameters which is
>> automatically converted to URL parameters, but they are
>> unordered. I could put them in order if that is likely to change
>> anything.
> 
> Only GET works currently.

I confirmed that the parameters must be in the URL, but it looks like
using a POST verb works just as well. I've changed my program to use
GET exclusively, since there's no reason to waste bytes with
Content-Length and Content-Type headers if I'm not going to send anything.

> It is easiest to do what you want in the browser GUI and then take
> the request URL including query string from the web server access
> log. And vice versa, does the URL do what you want, if you enter it
> in the browser?

That's what I started with. Well, I didn't bother to produce URLs from
the browser... I just looked at the .

> At first sight, the query string looks good. Value "0" means
> "active". The "from=list" part should not be necessary. It will
> define, which redirect URL will be used in the response (in which
> you are not really interested).

I've removed "from=list"; I still get a  response which,
of course, I ignore.

> In case of problems, you can try the JkLogLevel debug for the
> status worker request. Status worker also logs quite verbosely what
> it does. Any changes done will be logged on info log level,
> problems as errors or warnings.

I can confirm that the status worker receives my new values, as per
the log file.

> Are you using 1.2.40 or an older version? Some older versions had 
> problems with updating data via status worker. It should be in the 
> changelog of the more recent version.

I'm using trunk, so 1.2.41-dev.

> Finally: make sure the status worker is not configured as
> read-only.

It's not. I can change the values from the web UI.

Something is definitely weird, here. What I had been doing was calling
the status worker to set the values and then immediately re-requesting
the status to see if the update had occurred. I was observing some
delay in being able to detect the change, so I introduced a 1/4s delay
between the update and status calls. That seemed to help. At first.

Now, what I'm observing is that if I do something like this:

$ mod_jk.py set activation=DIS (changes status)
$ mod_jk.py status (checks status)
  activation=ACT
$ mod_jk.py status
  activation=DIS
$ mod_jk.py status
  activation=DIS
$ mod_jk.py status
  activation=D

Re: Session Clustering Monitoring

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Peter,

On 1/12/15 4:32 PM, Peter Rifel wrote:
> On 1/12/15, 11:36 AM, "Christopher Schultz"
>  wrote: On 1/12/15 2:28 PM, Peter
> Rifel wrote:
 Chris,
 
 On 1/12/15, 11:08 AM, "Christopher Schultz" 
  wrote:
 
 Peter,
 
 On 1/12/15 12:51 PM, Peter Rifel wrote:
>>> I'm running Tomcat 8.0.15 with Java 1.8.0_25 on Ubuntu
>>> 14.04. We have 5 instances that are all setup with
>>> session clustering as follows:
>>> 
>>> >> className="org.apache.catalina.ha.tcp.SimpleTcpCluster">
>>>
>>> 
>> className="org.apache.catalina.ha.session.DeltaManager"
>>>
>>> 
stateTransferTimeout="5" /> >> className="org.apache.catalina.tribes.group.GroupChannel">
>>>
>>> 
>> className="org.apache.catalina.tribes.membership.McastService"
>>>
>>>
>
>>> 
address="${multicast}" />  
>>> 
>>> -Dmulticast=228.0.0.4
>>> 
>>> To help prevent accidental misconfigurations that have 
>>> occurred in the past, I decided to implement monitoring
>>> on the session replication by checking the JMX mbean 
>>> Catalina/Manager///activeSessions
>>> attribute. Most of the time the values for the 5
>>> instances are all within 1 or 2 of each other. Over the
>>> weekend we consistently had one instance that had more
>>> sessions than the other 4. It began with 102 sessions
>>> where every other instance had 95. Over the next 36
>>> hours as more sessions were expiring over the weekend,
>>> the difference grew to 49 vs 29. Eventually it resynced
>>> and now they all report the same active session count.
>>> My question is, does anyone know why this would happen,
>>> and if this can be expected is there a better way to 
>>> monitor session replication to ensure that there isn't
>>> one instance that isn't being replicated to? I believe
>>> this only happens on weekends when most sessions are
>>> expiring and very few are being created but I may be
>>> wrong.
 
 How is your load-balancer configured to distribute traffic?
 
> Two of the instances are behind one load balancer, and the
> other 3 are behind another.  They each provide a different
> service but are running the same war application and we
> want sessions clustered across both services. Each load
> balancer's initial distribution is based on the least
> number of connections, with persistence based on source
> IP.
> 
> So basically all requests are randomly sent to back-end nodes? Or
> are you using session stickiness or anything like that?
> 
>> Sorry, I should have clarified.  Stickiness is based on the
>> source ip, so requests from the same IP will be routed to the
>> same instance.  With these applications we don't expect sessions
>> to change Ips very often if at all, but if you think it would
>> help I could stick based on the JSESSIONID cookie.

I was wondering, because there is an unfortunately situation with
session stickiness and long-lived clients where fail-over can cause a
large number of clients to switch to a particular server and /stay
there/ even if they have to re-login (when you'd likely prefer that
they get re-balanced to another node if they have to re-login).

If you had a temporary failure of one node, perhaps the clients were
re-assigned to another node and they "stayed there" when the failing
node became available again. Those clients would stay there until
either their newly-assigned node failed, or they closed their browser
(assuming they are using cookies that live for the life of the client,
like JSESSIONIDs typically do).

After the weekend in your scenario, perhaps all your users restarted
their browsers (or computers) and thus were re-balanced.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJUtSySAAoJEBzwKT+lPKRYsy4P/3i4YqxWocydSt/gWjNv+AAG
tiwzXYCd1MsVrnqy05nFjSJqJvdwCd027xPStf6O2m+VSO4M0+siRK11iupGdrFx
aRAR93RQrMViX94dVxn+QSTot+Ma0me9igZ61y/YBceTkxXTjP9WGGi2KWG4zX9/
YMQv1Wsk030jFGETQTAcEiI+LFepWuJfaoPnDtLTGJzYuA2TvMw+MTJfVeiJ+/AG
+R1fQPorfAiP8iS23J8787CZuLsuLggo6MrgRmEZbATEFk4zy3JeK0+s0DSEUZmp
lm5tWXaHgn+IybWOdxLuxv8pGDkc2nRtu/P9PFOVFfLgxpxdbstHk51V4C3UIIg7
rHfYGninpIM1RetzTMva791WEez4V+IHQM5EpcgNn5Yt6ENCQMkslYfupplK9gT+
Ieawrg4p90T8OpIW77Ir67Xv5nQ5vtjX4HdPydOmEUuO6Be0X/m65LEuBUdPMV6R
MEy47b5e0el1krojRWKZvf8/4B2ibHWApktAxww7F7TxLCSiHKuLFKnZikZrFap9
SZHK38tdOFmqYf8LR/qlDmetRhIRxOFH9VEO98EIxI11jp9TtXWGLIuBUOEBX5Pb
D+kZR4anF12vLZmvzf5nvOJuTX7tcnMaf9Btfpfhmo/fib8zrDHVOh2bhrqEbBt/
hQ4T9XbHy4GyD/NFk+z2
=a5Ju
-END PGP SIGNATURE-

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

Re: Memory shortage appears as missing pulse-java.jar file error with Java 7

[André Warnier]

Peter Lavin wrote:


Hi all, I have deployed a simple (Eclipse developed) webservice in a 
Tomcat7 container which is running on Debian, details as follows...


The error is as follows... (abridged, but it is complaining about 
missing a file called pulse-java.jar)


INFO: Deploying web application archive 
/var/lib/tomcat7/webapps/SecureServiceExample.war

Jan 12, 2015 3:03:01 PM org.apache.catalina.startup.TldConfig tldScanJar
WARNING: Failed to process JAR 
[jar:file:/usr/lib/jvm/java-7-openjdk-amd64/jre/lib/ext/pulse-java.jar!/] 
for TLD files
java.io.FileNotFoundException: 
/usr/lib/jvm/java-7-openjdk-amd64/jre/lib/ext/pulse-java.jar (No such 
file or directory)

at java.util.zip.ZipFile.open(Native Method)
at java.util.zip.ZipFile.(ZipFile.java:215)
at java.util.zip.ZipFile.(ZipFile.java:145)


I'm using a Debian GNU Linux 7 VM, running version.sh of Tomcat7 yields...

Using CATALINA_BASE:   /usr/share/tomcat7
Using CATALINA_HOME:   /usr/share/tomcat7
Using CATALINA_TMPDIR: /usr/share/tomcat7/temp
Using JRE_HOME:/usr/lib/jvm/java-7-openjdk-amd64
Using CLASSPATH:   
/usr/share/tomcat7/bin/bootstrap.jar:/usr/share/tomcat7/bin/tomcat-juli.jar

Server version: Apache Tomcat/7.0.28
Server built:   Apr 8 2014 08:47:08
Server number:  7.0.28.0
OS Name:Linux
OS Version: 3.2.0-4-amd64
Architecture:   amd64
JVM Version:1.7.0_65-b32
JVM Vendor: Oracle Corporation

Tomcat7 was installed using apt-get. With the default memory settings 
(around line 271 in catalina.sh) as follows...


CATALINA_OPTS="$CATALINA_OPTS $JPDA_OPTS"

The above error occurs.

When I made the following changes... (below) the error goes away

CATALINA_OPTS="-server $CATALINA_OPTS -Xms512m -Xms2048m 


a typo here ? (2 times -Xms ..)

and, what was in $JPDA_OPTS ?


-XX:MaxPermSize=512m -Dcom.sun.management.jmxremote"

My question... pulse-java.jar does not exist in Java 7 although it did 
in Java 6. In Java 7, it is provided by a different file. It appears 
that the shortage of allocated memory manifests itself as a missing 
file. Has anyone else found anything like this or used a different 
solution to fix it?


regards,
Peter



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





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

Re: Slow HTTP Rquest via Tomcat

[André Warnier]

Christopher Schultz wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Thone,

On 1/12/15 6:03 PM, Thone Soungpanya wrote:
When connecting from Tomcat to third party, we are going through a 
servlet code which is customized by us. We package the code into a 
jar file which sits on the \WEB-INF\lib folder. When connection,
we create a session and connect through the application server IP 
address, jolt port, username and password. The third party system

we connect to is a PeopleSoft ERP system.

When the problem occurs, I would estimate it to be about 200 or so 
active sessions through just that one folder. Now, another thing I 
forgot to mention is, we have multiple web application folders

with the same files but just different PeopleTools version to
support for different clients. These are not slowing up and they
have about maybe 10 - 20 sessions. Just throwing this information
out there in case.

Also to note again, I do not think it is the connection to the
third party. While reviewing the logs, I notice when connecting to
third party, it takes about 10 seconds round-trip. We write logs
when it begin connection to end connection. Something is
bottlenecking in the tomcat server before trying to connect.


The number of uses sessions is largely irrelevant. What is relevant is
the number of simultaneous requests that are being made to your own
web application, and how many are trying to create these outgoing
connections.

(Just curious: what is a "jolt port"?)

If you have a 20-50 second pause, there's enough time to trigger a
thread dump of the application (see the wiki HOWTO section for how to
do that). A thread dump will tell you where the code is hanging. It's
not likely to be in Tomcat itself.



Maybe a DNS lookup issue ?
If the code of the webapp is under control of the OP ("servlet code which is customized by 
us"), then it should be easy to add some logging in there, to figure out where the time 
really goes ?

That may be a bit easier to do at first, than taking thread dumps.



- -chris

-Original Message- From: cjder...@gmail.com 
[mailto:cjder...@gmail.com] On Behalf Of chris derham Sent:

Monday, January 12, 2015 2:43 PM To: Tomcat Users List Subject: Re:
Slow HTTP Rquest via Tomcat

On 13 January 2015 at 11:38, Thone Soungpanya 
 wrote:

Hello,

Can anyone give some advice on what the issue may be? We have a
web application folder in Tomcat that have been slowing the http 
request's connection to another third party system when there

are high traffic. It seems to be halting in the Tomcat server for
about 20 - 50 seconds before attempting to connect to the third
party system. Once it tries to connect to the third party system,
the response time is only about 6 - 10 seconds which is normal.
It does not seem to be an issue at the third party's end as the
response time is quick once we get connected.

Here are the specs that we have and additional information...

1) Apache Tomcat 7.0.56 2) JVM version 1.7 3) Running on Linux
OS Version 2.6.32

Connection Flow: 1) User submits a HTTP request from web 
application to Tomcat 2) Tomcat calls Java's servlet code along 
with HTTP request parameters 3) Java servlet code connects to

third party system via application server and jolt port 4) Third
party system returns requested information

We thought it would be a session issue which we lowered the
session timeout (just for that folder) in WEB-INF folder to 5
minutes from defaulted 30 minutes but it is still doing the same
thing.

Any advice on what it may be? Let me know if you need additional 
information.

How does your code connect to the 3rd party? There are libraries
that do this, please elaborate which you use. I recall using one,
and it had a limit on the number of concurrent connections to a 3rd
party. Perhaps you hit this limit? How many connections are you
talking about when the problem occurs - 10s, 100s, 1000s or more?

Chris


Thank you in advance!

Thone

-




To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org

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


-




To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org

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


-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJUtJPoAAoJEBzwKT+lPKRYeYAQAIElQByMpZ88BGNpwNPNqJ08
n0uw/bsBAhKV39Yz54qNRFiQ/7CBCDtP9IrghdjrWNDgnocFb2DGPCW37dT3IS3P
76nTzcZIby8XU/CtUP2iPBqxYLbhm8FEsRB6yH4YB/0QRgz5E1SRBBFw7f2LVQFz
8xnnGObrIJn2Ah0sYlpwVH3FejokjLe67wra3SBV1ONQsZzwpm3JCGdpHzXEzUqt
MhSElAoXhk+LupA7ofvPC4GLiS6uvS1o9cOP1wbEK5P5DeFe3E78H/QPmSWf/0Vd
iEIZbrlKRQyKjNPn+9NvKZMWcwcMYuntjdbhQNDOyQ0A/GW9DwV4qNjsUuQbyLi6
sF0UBmygw1dmHnDTJ4F04JNkYsGVG+POlWltKvG/Q6H+aywu86OxJKqWp7L4NL5G
T4g9j4pGYLdX1WDjZLWlG71SrxbsugyXa+vxP21Vujo2XikwGOSfOju+DvcFEm1r
+RC/2NBYfJnB2yfkNQJiVFaVg5h

Memory shortage appears as missing pulse-java.jar file error with Java 7

[Peter Lavin]

Hi all, I have deployed a simple (Eclipse developed) webservice in a 
Tomcat7 container which is running on Debian, details as follows...


The error is as follows... (abridged, but it is complaining about 
missing a file called pulse-java.jar)


INFO: Deploying web application archive 
/var/lib/tomcat7/webapps/SecureServiceExample.war
Jan 12, 2015 3:03:01 PM org.apache.catalina.startup.TldConfig 
tldScanJar
WARNING: Failed to process JAR 
[jar:file:/usr/lib/jvm/java-7-openjdk-amd64/jre/lib/ext/pulse-java.jar!/] 
for TLD files
java.io.FileNotFoundException: 
/usr/lib/jvm/java-7-openjdk-amd64/jre/lib/ext/pulse-java.jar (No such 
file or directory)

at java.util.zip.ZipFile.open(Native Method)
at java.util.zip.ZipFile.(ZipFile.java:215)
at java.util.zip.ZipFile.(ZipFile.java:145)


I'm using a Debian GNU Linux 7 VM, running version.sh of Tomcat7 
yields...


Using CATALINA_BASE:   /usr/share/tomcat7
Using CATALINA_HOME:   /usr/share/tomcat7
Using CATALINA_TMPDIR: /usr/share/tomcat7/temp
Using JRE_HOME:/usr/lib/jvm/java-7-openjdk-amd64
Using CLASSPATH:   
/usr/share/tomcat7/bin/bootstrap.jar:/usr/share/tomcat7/bin/tomcat-juli.jar

Server version: Apache Tomcat/7.0.28
Server built:   Apr 8 2014 08:47:08
Server number:  7.0.28.0
OS Name:Linux
OS Version: 3.2.0-4-amd64
Architecture:   amd64
JVM Version:1.7.0_65-b32
JVM Vendor: Oracle Corporation

Tomcat7 was installed using apt-get. With the default memory settings 
(around line 271 in catalina.sh) as follows...


CATALINA_OPTS="$CATALINA_OPTS $JPDA_OPTS"

The above error occurs.

When I made the following changes... (below) the error goes away

CATALINA_OPTS="-server $CATALINA_OPTS -Xms512m -Xms2048m 
-XX:MaxPermSize=512m -Dcom.sun.management.jmxremote"


My question... pulse-java.jar does not exist in Java 7 although it did 
in Java 6. In Java 7, it is provided by a different file. It appears 
that the shortage of allocated memory manifests itself as a missing 
file. Has anyone else found anything like this or used a different 
solution to fix it?


regards,
Peter



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