Re: JDBC Realm & exceptions

[Felix Schumacher]

Am 5. Februar 2015 22:21:38 MEZ, schrieb Leonid Rozenblyum 
:
>Hello Felix!
>Thanks for the detail answer! Good suggestion about  DataSourceRealm!
>(I thought about this possibility but then I discovered that we have
>extended JDBCRealm to support some complex DB structure so maybe this
>switch to another Realm is not SO easy as it should be).

It would be a good idea to share what complex structure you need to support. 
Maybe it would be worth to extend the standard realms to support them as well.

On the other hand the code of JDBCRealm and DataSourceRealm are quit similar, 
so it should be easy for you to port your code. 

>
>Is it a good idea to suggest reducing logging level inside the
>JDBCRealm if this is not an issue to worry about? E.g. not SEVERE but
>DEBUG or TRACE?
I fixed the error, it should be in tomcat 8.0.19.

Felix
>
>
>On Thu, Feb 5, 2015 at 10:14 PM, Felix Schumacher
> wrote:
>> Hi Leonid,
>>
>> Am 05.02.2015 um 16:28 schrieb Leonid Rozenblyum:
>>>
>>> Hello!
>>>
>>> After upgrading from Tomcat7 to Tomcat8 we started facing
>exceptions:
>>>
>>> rg.apache.catalina.realm.JDBCRealm getPassword
>>> SEVERE: Exception performing authentication
>>> org.postgresql.util.PSQLException: This statement has been closed.
>>>
>>> They look like not giving any harm (?).
>>
>> JDBCRealm will try again after it reports the error, so no real harm
>for
>> you.
>>
>> The exception gets thrown, because the PreparedStatement is used with
>a
>> try-with block, which closes the instance variable, which is reused
>later
>> (then obviously closed :( ).
>>>
>>> Could we do anything to avoid this? Is it some kind of
>>> misconfiguration at our side or some issue in Tomcat?
>>
>> Use DataSourceRealm :)
>>
>> Regards
>>  Felix
>>>
>>>
>>> I've googled and found
>>>
>>>
>http://stackoverflow.com/questions/24534286/strange-jdbcream-exception-occurs-on-tomcat
>>>
>>> but without any suggestions what to do.
>>>
>>> Thanks for any help.
>>>
>>>
>-
>>> 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
>>
>
>-
>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: Tomcat 7.0.55 System Down

[Caldarale, Charles R]

> From: 토로치 [mailto:http7...@gmail.com] 
> Subject: Re: Tomcat 7.0.55 System Down

> > That is a very old JVM. You should also try updating that to the latest
> > 7.0.x release and see if the bug reoccurs.

> This solution is extremely dependent on JAVA version.

Then your solution is seriously broken.

> Support Policy for Java: Java 7 Update 03 is a Validated Platform.

It is certainly validated to have some very, very serious bugs; check the JRE 
changelog.  Running a JVM version that old with so many security issues is 
irresponsible.

> It is almost impossible to upgrade JAVA.

Then your processes are fatally flawed; your installation is a hacker's 
playground.

> In addition, I don't quit get 'HTTP BIO vs HTTP APR/native'.

Read the documentation for the  element:
http://tomcat.apache.org/tomcat-7.0-doc/config/http.html

Use the protocol attribute to select the desired handler.

 - Chuck


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

Re: Tomcat 7.0.55 System Down

[토로치]

Hi Mark Thomas.

Firstry thanks for your reply.

> If you think you have hit a JVM bug, why are you posting here?

I wanted to get solutions in variety of ways.

> That is a very old JVM. You should also try updating that to the latest
7.0.x release and see if the bug reoccurs.

This solution is extremely dependent on JAVA version.

Support Policy for Java: Java 7 Update 03 is a Validated Platform.

It is almost impossible to upgrade JAVA.

In addition, I don't quit get 'HTTP BIO vs HTTP APR/native'.

Duseong.


2015-02-05 18:29 GMT+09:00 Mark Thomas :

> On 05/02/2015 09:11, 토로치 wrote:
> > Hello.
> >
> >
> > I am a PLM system developers.
> >
> > We PLM system operates by JAVA.
> >
> > We are using the Tomcat version 7.0.55.
> >
> > The system Down occurs when we are using a PLM system.
> >
> > The hs-err_pid5684.mdmp file over 20GB is created in the Tomcat root
> folder.
> >
> > When the contents of the hs_err_pid5512.log file shown that a JVM bug.
>
> If you think you have hit a JVM bug, why are you posting here?
>
> 
>
> > Current thread (0x384c9800):  JavaThread "http-apr-9500-exec-226"
> > daemon [_thread_in_native, id=18668,
> > stack(0x5a63,0x5a73)]
>
> That tells me you are using the APR/native connector. It is possible
> that that connector is casing the problem but the stack trace isn't what
> I'd expect to see in that case.
>
> I recommend switching to the BIO HTTP connector and seeing if the crash
> still occurs.
>
> 
>
> > JAVA_HOME=C:\Java\x64\jdk1.7.0_03
>
> That is a very old JVM. You should also try updating that to the latest
> 7.0.x release and see if the bug reoccurs.
>
> On a related topic, make sure you are using the latest native component
> for the APR/native connector (1.1.32 as I type this). An upgrade to the
> latest Tomcat 7.0.x release wouldn't hurt either.
>
> In short:
> - get everything up to date
> - test HTTP BIO vs HTTP APR/native
>
> Mark
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

RE: Sporadic HTTP 403 returned by Tomcat when this should not happen ever. How to find out why this happens?

[Brian]

Hello David,

Not, it is not the case. No exceptions whatsoever. And about 1/100 (or less) of 
the requests return a 403 to the users, and all those requests are doing the 
same thing.
Thanks a lot for your help!


> -Original Message-
> From: David Bullock [mailto:david.bull...@machaira.com.au]
> Sent: jueves, 05 de febrero de 2015 06:04 p.m.
> To: Tomcat Users List
> Subject: Re: Sporadic HTTP 403 returned by Tomcat when this should not
> happen ever. How to find out why this happens?
> 
> On 6 February 2015 at 02:42, Brian  wrote:
> 
> > Hi,
> >
> > I have a Restful service that receives a huge amount of HTTP requests per
> > day. In some of these requests, Tomcat returns an HTTP 403 error status.
> >
> 
> Your servlet does something which throws a java.lang.Security exception
> (which is a runtime exception), and Tomcat is translating it into a 403 for
> you?  (I didn't test it, but it might be a reasonable thing for a
> servlet-container to do).


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

Re: Sporadic HTTP 403 returned by Tomcat when this should not happen ever. How to find out why this happens?

[David Bullock]

On 6 February 2015 at 02:42, Brian  wrote:

> Hi,
>
> I have a Restful service that receives a huge amount of HTTP requests per
> day. In some of these requests, Tomcat returns an HTTP 403 error status.
>

Your servlet does something which throws a java.lang.Security exception
(which is a runtime exception), and Tomcat is translating it into a 403 for
you?  (I didn't test it, but it might be a reasonable thing for a
servlet-container to do).

Re: JDBC Realm & exceptions

[Leonid Rozenblyum]

Hello Felix!
Thanks for the detail answer! Good suggestion about  DataSourceRealm!
(I thought about this possibility but then I discovered that we have
extended JDBCRealm to support some complex DB structure so maybe this
switch to another Realm is not SO easy as it should be).

Is it a good idea to suggest reducing logging level inside the
JDBCRealm if this is not an issue to worry about? E.g. not SEVERE but
DEBUG or TRACE?


On Thu, Feb 5, 2015 at 10:14 PM, Felix Schumacher
 wrote:
> Hi Leonid,
>
> Am 05.02.2015 um 16:28 schrieb Leonid Rozenblyum:
>>
>> Hello!
>>
>> After upgrading from Tomcat7 to Tomcat8 we started facing exceptions:
>>
>> rg.apache.catalina.realm.JDBCRealm getPassword
>> SEVERE: Exception performing authentication
>> org.postgresql.util.PSQLException: This statement has been closed.
>>
>> They look like not giving any harm (?).
>
> JDBCRealm will try again after it reports the error, so no real harm for
> you.
>
> The exception gets thrown, because the PreparedStatement is used with a
> try-with block, which closes the instance variable, which is reused later
> (then obviously closed :( ).
>>
>> Could we do anything to avoid this? Is it some kind of
>> misconfiguration at our side or some issue in Tomcat?
>
> Use DataSourceRealm :)
>
> Regards
>  Felix
>>
>>
>> I've googled and found
>>
>> http://stackoverflow.com/questions/24534286/strange-jdbcream-exception-occurs-on-tomcat
>>
>> but without any suggestions what to do.
>>
>> Thanks for any help.
>>
>> -
>> 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
>

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

Re: JDBC Realm & exceptions

[Felix Schumacher]

Hi Leonid,

Am 05.02.2015 um 16:28 schrieb Leonid Rozenblyum:

Hello!

After upgrading from Tomcat7 to Tomcat8 we started facing exceptions:

rg.apache.catalina.realm.JDBCRealm getPassword
SEVERE: Exception performing authentication
org.postgresql.util.PSQLException: This statement has been closed.

They look like not giving any harm (?).
JDBCRealm will try again after it reports the error, so no real harm for 
you.


The exception gets thrown, because the PreparedStatement is used with a 
try-with block, which closes the instance variable, which is reused 
later (then obviously closed :( ).

Could we do anything to avoid this? Is it some kind of
misconfiguration at our side or some issue in Tomcat?

Use DataSourceRealm :)

Regards
 Felix


I've googled and found
http://stackoverflow.com/questions/24534286/strange-jdbcream-exception-occurs-on-tomcat

but without any suggestions what to do.

Thanks for any help.

-
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: Apparent Bug Introduced between 8.0.15 & 8.0.17

[Mark Thomas]

On 05/02/2015 18:51, Jerry Malcolm wrote:
> There is an apparent bug or functional change dealing with the sax
> package getting loaded that was introduced in 8.0.17.
> 
> Background: I have been in the process of migrating three independent
> servers to new hardware.  As part of the migration, I decided to upgrade
> all of them to the latest Tomcat 8.  The first one worked fine.  I
> repeated the install process on the 2nd one.  I kept getting an error on
> my pages, though, on the 2nd server install.  I decide to continue on to
> the third server while trying to figure out the problem.  The third
> server had the identical error.  The error message I received was:
> 
> --- javax.el.ELException: The package [org.saxpath] could not be found
> 
> I'm using JSTL, and the stack trace showed that it was occurring on a
> JSTL tag in a JSP.  Also, all three servers are Win Server 2008-R2.
> 
> I tried for several hours to figure out why a jar was apparently missing
> and/or what might be different from server #1.  I then noticed that I
> had downloaded Tomcat 8.0.15 for the first server and 8.0.17 for the
> other two servers.  Definitely a total long shot. But I uninstalled
> 8.0.17 from the 2nd server and downloaded/installed 8.0.15 from the
> Tomcat archive.  Voila it works.  Did the same thing on the third
> server, and it fixed the problem there as well.
> 
> If this error message was the result of a bug that was introduced in
> 8.0.17 that has been or will be corrected, then no problem. However, if
> this is a result of incompatibilities between my code and all future
> Tomcat releases, I want to figure it out now and get it resolved.  I
> definitely don't want to have to readdress this again when I decide to
> move up to Tomcat 9.x, etc.
> 
> Can anyone explain what changed?  BTW I'm using Apache Taglib 1.2.1
> jars, which as far I have been able to find, are the latest. Nothing
> else unique in what I'm doing in this area of the code as far as I can
> tell.
> 
> Thanks for any info you can provide.

Can you try again with 8.0.18? I think you may have hit a regression
that has since been fixed.

If you still see the error, open a BZ issue and provide the simplest
steps to reproduce you can (e.g. a JSP to add to Tomcat's examples app).

Cheers,

Mark


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

Re: HttpSessionBindingListener details

[Igor Urisman]

Right, makes sense. Thank you.

On Thu, Feb 5, 2015 at 10:21 AM, Konstantin Kolinko 
wrote:

> 2015-02-05 21:07 GMT+03:00 Igor Urisman :
> > Hello, folks.
> >
> > I can't seem to find a good solution for the following problem.  I have
> an
> > object that is added to the HTTP session via the setAttribute() method.
> The
> > object implements the HttpSessionBindingListener interface and its
> > valueUnbound() method is dutifully called by the contained at the time
> the
> > session is destroyed. Now, in my use case the session is destroyed via
> the
> > HttpSession.invalidate() call, so (presumably) the container creates the
> > new session concurrently with destroying the current session.
>
> No.  invalidate() only destroys the current session. It does not
> create any new sessions.
>
> A new session can be created by a HttpServletRequest.getSession() /
> getSession(true) call.
>
> Best regards,
> Konstantin Kolinko
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Apparent Bug Introduced between 8.0.15 & 8.0.17

[Jerry Malcolm]

There is an apparent bug or functional change dealing with the sax 
package getting loaded that was introduced in 8.0.17.


Background: I have been in the process of migrating three independent 
servers to new hardware.  As part of the migration, I decided to upgrade 
all of them to the latest Tomcat 8.  The first one worked fine.  I 
repeated the install process on the 2nd one.  I kept getting an error on 
my pages, though, on the 2nd server install.  I decide to continue on to 
the third server while trying to figure out the problem.  The third 
server had the identical error.  The error message I received was:


--- javax.el.ELException: The package [org.saxpath] could not be found

I'm using JSTL, and the stack trace showed that it was occurring on a 
JSTL tag in a JSP.  Also, all three servers are Win Server 2008-R2.


I tried for several hours to figure out why a jar was apparently missing 
and/or what might be different from server #1.  I then noticed that I 
had downloaded Tomcat 8.0.15 for the first server and 8.0.17 for the 
other two servers.  Definitely a total long shot. But I uninstalled 
8.0.17 from the 2nd server and downloaded/installed 8.0.15 from the 
Tomcat archive.  Voila it works.  Did the same thing on the third 
server, and it fixed the problem there as well.


If this error message was the result of a bug that was introduced in 
8.0.17 that has been or will be corrected, then no problem. However, if 
this is a result of incompatibilities between my code and all future 
Tomcat releases, I want to figure it out now and get it resolved.  I 
definitely don't want to have to readdress this again when I decide to 
move up to Tomcat 9.x, etc.


Can anyone explain what changed?  BTW I'm using Apache Taglib 1.2.1 
jars, which as far I have been able to find, are the latest. Nothing 
else unique in what I'm doing in this area of the code as far as I can tell.


Thanks for any info you can provide.

Jerry

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

Re: HttpSessionBindingListener details

[Konstantin Kolinko]

2015-02-05 21:07 GMT+03:00 Igor Urisman :
> Hello, folks.
>
> I can't seem to find a good solution for the following problem.  I have an
> object that is added to the HTTP session via the setAttribute() method. The
> object implements the HttpSessionBindingListener interface and its
> valueUnbound() method is dutifully called by the contained at the time the
> session is destroyed. Now, in my use case the session is destroyed via the
> HttpSession.invalidate() call, so (presumably) the container creates the
> new session concurrently with destroying the current session.

No.  invalidate() only destroys the current session. It does not
create any new sessions.

A new session can be created by a HttpServletRequest.getSession() /
getSession(true) call.

Best regards,
Konstantin Kolinko

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

HttpSessionBindingListener details

[Igor Urisman]

Hello, folks.

I can't seem to find a good solution for the following problem.  I have an
object that is added to the HTTP session via the setAttribute() method. The
object implements the HttpSessionBindingListener interface and its
valueUnbound() method is dutifully called by the contained at the time the
session is destroyed. Now, in my use case the session is destroyed via the
HttpSession.invalidate() call, so (presumably) the container creates the
new session concurrently with destroying the current session. What I need
is preserve the object across the session destruction event. In other
words,  I want it to be rebound to the new session.  Is there a way to do
that from inside the valueUnbound() call?  All I get there is the the
HttpSessionBindingEvent object, passed passed as an argument, but its
getSession() method returns the old session that is in the final stages of
being destroyed.  I wonder if this isn't a bug and if it wasn't meant to
return the new session, for what's the point giving me the old session —
it's easy for me to get to it anyway, and its state is already invalid.

Many thanks in advance,
-Igor.

Sporadic HTTP 403 returned by Tomcat when this should not happen ever. How to find out why this happens?

[Brian]

Hi,

 

I have a Restful service that receives a huge amount of HTTP requests per
day. In some of these requests, Tomcat returns an HTTP 403 error status.
This should never happen as far as I can tell because the resource is open,
and is very sporadic but yet very critical because it makes my service
unreliable. When this happens, it does for the same resource that would
otherwise return a succesful response. 

I'm sure this is happening, because my users have reported me the issue, and
because I can clearly see that in our Tomcat log, as follows:

 

localhost - - [04/Feb/2015:01:11:06 -0500] "GET
/location/v1.7/locateip?key=abc123&ip=182.68.243.178&format=JSON HTTP/1.0"
403 - "-" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML,
like Gecko) Chrome/40.0.2214.94 Safari/537.36"

localhost - - [04/Feb/2015:01:12:24 -0500] "GET
/location/v1.8/locateip?key=abc123&ip=local-ip&format=json&capacity=6X
HTTP/1.0" 403 - "-" "Mozilla/5.0 (Windows NT 5.1) AppleWebKit/537.36 (KHTML,
like Gecko) Chrome/40.0.2214.94 Safari/537.36"

localhost - - [04/Feb/2015:01:18:06 -0500] "GET
/location/v1.8/locateip?key=abc123&ip=local-ip&format=json&capacity=6X
HTTP/1.0" 403 - "-" "Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML,
like Gecko) Chrome/40.0.2214.94 Safari/537.36"

 

Is there a way to show in the log why the 403s took place? How do I debug
these events?

 

I'm using Tomcat 7.0.50.

 

By the way: I don't know if this is relevant, but this is the complete stack
of software between the user and my Java App:

 

- The request first goes through a Amazon AWS load balancer

- Then it enters my Linux instance (Ubuntu 12.04.3)

- Then it arrives to Nginx (v1.4.7), that runs a module that deals with
abuses (when there are too many requests)

- Then it hits Tomcat (7.0.50)

- Then it finally hits my java servlet.

 

Thanks in advance,

 

Brian

 

 

 

JDBC Realm & exceptions

[Leonid Rozenblyum]

Hello!

After upgrading from Tomcat7 to Tomcat8 we started facing exceptions:

rg.apache.catalina.realm.JDBCRealm getPassword
SEVERE: Exception performing authentication
org.postgresql.util.PSQLException: This statement has been closed.

They look like not giving any harm (?).

Could we do anything to avoid this? Is it some kind of
misconfiguration at our side or some issue in Tomcat?

I've googled and found
http://stackoverflow.com/questions/24534286/strange-jdbcream-exception-occurs-on-tomcat

but without any suggestions what to do.

Thanks for any help.

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

Re: [OT] Tomcat 7.0.55 System Down

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Mark,

On 2/5/15 4:29 AM, Mark Thomas wrote:
> On 05/02/2015 09:11, 토로치 wrote:
>> Hello.
>> 
>> 
>> I am a PLM system developers.
>> 
>> We PLM system operates by JAVA.
>> 
>> We are using the Tomcat version 7.0.55.
>> 
>> The system Down occurs when we are using a PLM system.
>> 
>> The hs-err_pid5684.mdmp file over 20GB is created in the Tomcat
>> root folder.
>> 
>> When the contents of the hs_err_pid5512.log file shown that a JVM
>> bug.
> 
> If you think you have hit a JVM bug, why are you posting here?
> 
> 
> 
>> Current thread (0x384c9800):  JavaThread
>> "http-apr-9500-exec-226" daemon [_thread_in_native, id=18668, 
>> stack(0x5a63,0x5a73)]
> 
> That tells me you are using the APR/native connector. It is
> possible that that connector is casing the problem but the stack
> trace isn't what I'd expect to see in that case.
> 
> *I recommend switching to the BIO HTTP connector* and seeing if the
> crash still occurs.

(Emphasis mine)

See? S!?

(Just sayin')

> That is a very old JVM. You should also try updating that to the
> latest 7.0.x release and see if the bug reoccurs.

+1

> On a related topic, make sure you are using the latest native
> component for the APR/native connector (1.1.32 as I type this). An
> upgrade to the latest Tomcat 7.0.x release wouldn't hurt either.
> 
> In short: - get everything up to date - test HTTP BIO vs HTTP
> APR/native

+1

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

iQIcBAEBCAAGBQJU03xaAAoJEBzwKT+lPKRYTRMP/0zS2jE90pGbgI6CIDwR6HAE
tRFbqHQhWq/dNdcgJBV6o6jaCtDMWt/IwiupqS0vvnfhZLlSxU9E2cuUp6xPuXFW
U06cCq7aGWYPof6g7m3W1bUdECKMkv1nk92X4fSqJqEQk3rQ/yNXPAYpGoLzUwdt
KDw4xlTX0RmBu1untGivSZHoubrMwL9ZCZgVWgZc3DCW21UGjvKoTpDeRQBZMDN1
DiLwJCWQJq+RIfIwueHGlpHAkfqEGHdy8/ckGCdE2/DR4yyuRM8JwKR5AD9bX0Vh
vM4NjvhjZj0OrDA7PyM4jIgZzb2nqBCSaSwWIu6ug4Lj7m6YJh46alHEbxAhh5gB
GISjI5LW4nUESgi6TCIjW8Oyox0YMPOwLkxuGGjl539IR7nr0YOPOVJ9er7WQHh7
zTD+8RuMcFiUum4MenrUBpOgExC/AImZIeRbk7UYVR9n8hG7evxfOyyYDNtSJd+h
c5yjqdolS4O5hklvH72MVJLJGdTSUSgTj2mAArthH1asS/Fqk68x2/TzpOsvLvDA
WDQoAU0stZiFSbV66PxFZjUwnZ27b5ZI6Zo4wmRSEnuPxsRDNBxxVcbn1iGbr81x
BNbrXgcxNMT5NDmqIeGFRCeT8Z85sqyI6fGEjGBFsh7ZMZlOvhsa0IcUM6N6kFFw
IiXzB+oulAqnQJBS5owe
=mzIx
-END PGP SIGNATURE-

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

Re: JDBC authentication problem

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Luc,

On 2/5/15 5:25 AM, Luc DALLEMANE wrote:
> The keep alive on postgres was already setup, but was not working.
> However, I finally found a workaround.
> 
> I'm using the tomcat connexion pool, but For the authentication,
> Tomcat is creating its own connexion and does not use the pool (and
> seems to use the same connexion all along the session).
> 
> So I think that's was why it was dropped by the firewall after a
> while, and when we restarted tomcat, the connexion was recreated
> and it worked again.
> 
> To resolve this problem, we override Tomcat's authenticate method.
> We made our own open function which uses the postgres driver and is
> called in the authenticate. We do not use the getPassword and
> getRoles function, because they used the Tomcat's "global"
> connexion.
> 
> With this, we are now able to connect to the site even after a long
> period of inactivity.
> 
> Thank you for your help, and maybe this could help someone else.

None of that should be necessary /at all/. Did you switch-over to
using the DataSourceRealm or not?

JDBCRealm is pretty stupid.

- -chris

>  De : Felix Schumacher
>  Envoyé : mercredi 4 février
> 2015 20:11 À : Tomcat Users List Objet : Re: JDBC authentication
> problem
> 
> Am 04.02.2015 um 14:21 schrieb Luc DALLEMANE:
>> Hi,
>> 
>> I'm back again with the problem :)
>> 
>> Firstly, I add the validationQuery and it works and I can see it
>> in postgres logs.
>> 
>> But still not able to login after a while of inactivity
>> 
>> Now, after 15 min of waiting, I'm getting a socket connexion
>> timeout, but seems logic after such a long period of trying to
>> connect.
>> 
>> Thank you again for your ideas and haven't found a solution.
> You might try to enable keepalive on your postgresql connection. 
> Connection porperties can be specified with the attribute 
> "connectionProperties" (at least according to 
> http://commons.apache.org/proper/commons-dbcp/configuration.html)
> or in the jdbc url jdbc://...?tcpKeepAlive=true. You can even
> specify the timeout for connnecting to your database.
> 
> Regards Felix
>> 
>> Regards, Luc.  De :
>> Konstantin Kolinko  Envoyé : mardi 3
>> février 2015 12:33 À : Tomcat Users List Objet : Re: JDBC
>> authentication problem
>> 
>> 2015-02-03 14:29 GMT+03:00 Luc DALLEMANE
>> :
>>> Hi,
>>> 
>>> Thanks for the reply, I tried to add the options you told me
>>> about (testWhileIdle, timeBetweenEvictionRunsMillis, and
>>> maxConnLifetimeMillis), but I'm still unable to log after un
>>> hour ...
>> Do you have validationQuery configured?  testOnBorrow,
>> testWhileIdle do not work without it.
>> 
>> 
>> Best regards, Konstantin Kolinko
>> 
>> -
>>
>> 
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
>> 
> 
> 
> -
>
> 
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

iQIcBAEBCAAGBQJU03ulAAoJEBzwKT+lPKRYUPoQAKUx68eqWORIYbvUJr9i2G01
cd7xbemgBy0tWP2DmCG6D1MAEqfzphXXTCuOqvf1sg3aU+XbQtAexezJA826XXVb
5KrgQu3wYWG0Bc3D2tCNrzLzz8yqUE33+R+H13CGXPBX5vO48DvfjUZuMQ65/SQ+
G05t1LuljBTVulqwzK3l4lt48CS02xTlEu7KtMQ0WagmoeTnjBPZRjxuMNdtXeW6
DIW4MT++yOgptlOyyHbY1rjtlobP9vSpKK97cuwbG1W9DN+9FQ2HqDe+7V9QnNVg
9vr3eyj6wkOYAdzwatT8yusugxFJhl3reMavGdeYZzyv1leC6oLlBEZ4SEG5mftu
yT7L9pwNWPChJVhpq8VXDWsz63M8WGCDYyvjjRKCkca0eUSRv2dnWTsjsDfRTLT7
JORaDs1KF5x57Wb0yy7sLcsPty9U+FAxhFykYQdGUKjB8O9ZEZ+NFv0XrIqn0M+R
6+8r5ndr1uG+vqETeTnK4Eq+l2aZ0OaYbBhf0mpDvhCcqGlbD19AglUUsWN5Gevw
FLPhi0FSokLnV6uthypeKIixEtB66BrHsnXb+yl/q42GfExeSPEwSzLS48spPxDf
AppY8vCGdhtkEwhJqsbpdgeEwOakMhs1e8TuJ2tXIiDMoCLrcEmH0Lur0twWt0NW
CGqDrWy22blnCxqcneTj
=iDbk
-END PGP SIGNATURE-

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

Re: Issues with log4j.core.async.AsyncLoggerContextSelector when upgrading from 8.0.15 to 8.0.18

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

To whom it may concern,

On 2/4/15 12:15 PM, Evil Bit wrote:
> setenv.sh does have an extra "\r" but the same file worked for me
> on 8.0.15 - I only copied it from the older tomcat.

How did you copy it? Was 8.0.15 running on Windows or *NIX?

> I removed it and now it works on 8.0.18 too. thank you.
> 
>  On Wed, 04 Feb 2015 08:52:24 -0800
> Caldarale wrote 
> 
> > From: Evil Bit [mailto:evil...@zoho.com] > Subject: Issues
> with log4j.core.async.AsyncLoggerContextSelector when upgrading
> from 8.0.15 to 8.0.18
> 
> > When running tomcat with >
> -DLog4jContextSelector=org.apache.logging.log4j.core.async.AsyncLoggerContextSelector
>  > (defined in setenv.sh) to enable log4j2's async logging, I
> now get a ClassNotFoundException > (see below). What could be
> the problem?
> 
> > ERROR StatusLogger Unable to create context
> org.apache.logging.log4j.core.async.AsyncLoggerContextSelector^M
> 
> Note the ^M at the end of the class name; this makes me suspicious
> that your setenv.sh file has been edited on Windows and then used
> on Linux/UNIX/OSX/? (been there, done that).

Good catch. I saw the ^M too but assumed it was a copy/paste mailing
list thing or some other unrelated issue.

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

iQIcBAEBCAAGBQJU03h3AAoJEBzwKT+lPKRYyq0QAK1yjTVxUx+p6paL2M5C6gJz
0NKClLDL1vtnKYhiquw970NVYKn6vp1tJaZpEnfIv1/CV4aadyzAqJ6x7f/61a5/
ah/nX+e0Dtw5EAJSidx8qXBcU8gz35Yda3TRDmfRa/zZ45hfOjDspf6YV4Fh7glN
lbdVYUQapJO0htTzbReaUd0NODHulu67x1TZyeIboVHlSaNcS5TCGiSlZJBvleUT
/nrtdaUkhkAdrQRiFZR7SO9lqRD9TKFeWu35mgNGWG/W9mMDa4NXabCbKS0nFE/b
kqcWUSa5F4XLpZ+w7H5rkoxUApuPmTXiywlYBks/+hZ/6tnPRRSvSo7CJTkdDYDT
uEoJUqnYLWkJVv4Qhmf6fiflatx6UcmwbO8cYFlDt3XuSU762Tw/MaLQ4qUUqHnf
1SYBBzWrWbrjJZPSvFDMYTxlIiCapAlJUAeVYGJT4sVCblquUVZKuQXDnL/yq4Hv
rxU3WKlZFi/wsi75IvoUmTumI0mHGr5Kf6gOApZaMyfwuM2whMnz5X9bO55+2hm9
s1lvpG732X0o1gQxTSzSi/G7McrbMEvxDbbkjLThE0U2IN/RyQRXQFl2QpDEjzQA
9V4WIyi0Bdwr0GLorkibQnd8RHfO+ns0PZy6Fh94N1Vq48tgpEEkaaAZsi0Wp3H3
zt5MO1Zz1Yf4V6uAxBhI
=y/iW
-END PGP SIGNATURE-

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

Re: Tomcat 7.0.55 System Down

[토로치]

Hi André Warnier.

Thank you for your reply.

I am in charge of customize the Dassault Systèmes PLM solution, ENOVIA.

PLM(Product lifecycle management) is the process of managing the entire
lifecycle of a product from inception, through engineering design and
manufacture, to service and disposal of manufactured products.

ENOVIA provides a framework for collaboration for Company's PLM software.

It is a JAVA-based online environment.

Thank you.

Duseong.



2015-02-05 18:25 GMT+09:00 André Warnier :

> Hi.
> As per the error information which you copied below, this seems to be a
> Java or Windows problem, not a Tomcat problem.
> The right place to report that problem is to the vendor that makes the
> Java which you are using (Oracle), or the vendor of the OS which you are
> using (Microsoft).
> Or maybe even the vendor of the Java application which you are using
> (which may be Dassault Systèmes).
>
> The error message below contains this :
>
> > # If you would like to submit a bug report, please visit:
> > #   http://bugreport.sun.com/bugreport/crash.jsp
> > # The crash happened outside the Java Virtual Machine in native code.
> > # See problematic frame for where to report the bug.
> > #
>
> Also, for the benefit of the naive ones among us, what is "PLM" ?
>
> 토로치 wrote:
>
>> Hello.
>>
>>
>> I am a PLM system developers.
>>
>>
>> We PLM system operates by JAVA.
>>
>>
>> We are using the Tomcat version 7.0.55.
>>
>>
>> The system Down occurs when we are using a PLM system.
>>
>>
>> The hs-err_pid5684.mdmp file over 20GB is created in the Tomcat root
>> folder..
>>
>>
>>
>> When the contents of the hs_err_pid5512.log file shown that a JVM bug.
>>
>>
>> There are logs that appear whenever an error occurs in common.
>>
>> ==ERROR=
>> 
>>
>> com.dassault_systemes.platform.ipmodeling.jni.
>> EnoviaKernel.statelessDispatch
>> com/dassault_systemes/platform/ipmodeling/jni/EnoviaSessionWrapper;Ljava/
>> lang/String;Ljava/lang/String
>>
>> 
>> ==
>>
>>
>> How ho we fix this?
>>
>>
>> Below is the full text of hs_err_pid5512.log.
>>
>>
>> ---  SYSTEM  ---
>>
>> OS: Windows NT 6.1 , 64 bit Build 7601 Service Pack 1
>>
>> CPU : total 12 (6 cores per cpu, 2 threads per core) family 6 model 44
>> stepping 2, cmov, cx8, fxsr, mmx, sse, sse2, sse3, ssse3, sse4.1, sse4.2,
>> popcnt, ht
>>
>> Memory: 4k page, physical 50318424k(17358476k free), swap
>> 100634984k(73454820k free)
>>
>> vm_info: Java HotSpot(TM) 64-Bit Server VM (22.1-b02) for windows-amd64
>> JRE
>> (1.7.0_03-b05), built on Feb  3 2012 20:43:56 by "java_re" with unknown MS
>> VC++:1600
>>
>> time: Wed Feb 04 13:39:01 2015
>> elapsed time: 407758 seconds
>>
>>
>> ==  hs_err_pid5512.log
>>  =
>>
>> #
>> # A fatal error has been detected by the Java Runtime Environment:
>> #
>> #  EXCEPTION_ACCESS_VIOLATION (0xc005) at pc=0x7737e4e4,
>> pid=5512, tid=18668
>> #
>> # JRE version: 7.0_03-b05
>> # Java VM: Java HotSpot(TM) 64-Bit Server VM (22.1-b02 mixed mode
>> windows-amd64 )
>> # Problematic frame:
>> # C  [ntdll.dll+0x4e4e4]
>> #
>> # Core dump written. Default location:
>> D:\apache-tomcat-7.0.55\hs_err_pid5512.mdmp
>> #
>> # If you would like to submit a bug report, please visit:
>> #   http://bugreport.sun.com/bugreport/crash.jsp
>> # The crash happened outside the Java Virtual Machine in native code.
>> # See problematic frame for where to report the bug.
>> #
>>
>> ---  T H R E A D  ---
>>
>> Current thread (0x384c9800):  JavaThread "http-apr-9500-exec-226"
>> daemon [_thread_in_native, id=18668,
>> stack(0x5a63,0x5a73)]
>>
>> siginfo: ExceptionCode=0xc005, writing address 0x0024
>>
>> Registers:
>> RAX=0x, RBX=0x796d5ed8, RCX=0xfffc,
>> RDX=0x00015fe0
>> RSP=0x5a724b80, RBP=0x, RSI=0x00015fe0,
>> RDI=0x
>> R8 =0x5a724b38, R9 =0x0004, R10=0x,
>> R11=0x0246
>> R12=0x, R13=0x, R14=0x07efe000,
>> R15=0x
>> RIP=0x7737e4e4, EFLAGS=0x00010213
>>
>> Top of Stack: (sp=0x5a724b80)
>> 0x5a724b80:   5063b620 00015fe0
>> 0x5a724b90:   3bf60080 3bf60190
>> 0x5a724ba0:   5063b620 3c15
>> 0x5a724bb0:   fffe 
>> 0x5a724bc0:   3c15b3a0 00399c13
>> 0x5a724bd0:   3b1fcb20 0050
>> 0x5a724be0:    001f
>> 0x5a724bf0:   0218 46edc360

Re: FIPS Mode enabling on Tomcat 7.00.057

[Geett Chanddra Singha]

Thanks Chris!

I am able to resolve the issue.

On Fri, Jan 30, 2015 at 10:09 PM, Christopher Schultz <
ch...@christopherschultz.net> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Geet,
>
> On 1/30/15 1:22 AM, Geett Chanddra Singha wrote:
> > Steps followed to build FIPS
> >
> > tar zxf openssl-1.0.1l.tar.gz
> >
> > cd openssl-1.0.1l
> >
> > ./config --prefix=/usr/local
> > --with-fipsdir=/usr/local/ssl/fips-2.0
> >
> > make
> >
> > make install
> >
> > Note: I have installed the FIPS module in /usr/local/ssl/fips-2.0
>
> You have to do "./config fips --with--fipsdir=[...]". You are missing
> the "fips" argument to "config".
>
> After I did the "config", it told me that I needed to first "make
> depend". Then I did a regular "make" and got a FIPS-capable module (as
> tested by doing:
>
> $ cd test
> $ sh ./testfipsssl
>
> (Note that this test fails part way through because it's missing some
> kind of fake certificate... it looks like a problem with the test itself).
>
> I ran the test without building with FIPS and it died right away, so
> I'm confident I ended up with a FIPS-capable module:
>
> $ sh ./testfipsssl
> WARNING: can't open config file: /usr/local/ssl/openssl.cnf
> test ssl3 is forbidden in FIPS mode
> *** IN FIPS MODE ***
> Available compression methods:
>   NONE
> 140652183557800:error:140A9129:SSL routines:SSL_CTX_new:only tls
> allowed in fips mode:ssl_lib.c:1715:
> 140652183557800:error:140A9129:SSL routines:SSL_CTX_new:only tls
> allowed in fips mode:ssl_lib.c:1715:
> test ssl2 is forbidden in FIPS mode
> *** IN FIPS MODE ***
> Available compression methods:
>   NONE
> 139882949523112:error:140A9129:SSL routines:SSL_CTX_new:only tls
> allowed in fips mode:ssl_lib.c:1715:
> 139882949523112:error:140A9129:SSL routines:SSL_CTX_new:only tls
> allowed in fips mode:ssl_lib.c:1715:
> test tls1
> *** IN FIPS MODE ***
> Available compression methods:
>   NONE
> TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
> 1 handshakes of 256 bytes done
> test tls1 with server authentication
> *** IN FIPS MODE ***
> Available compression methods:
>   NONE
> server authentication
> depth=0 error=20 /C=UK/O=OpenSSL Group/OU=FOR TESTING PURPOSES
> ONLY/CN=Test Server Cert
> Error string: unable to get local issuer certificate
> ERROR in CLIENT
> 140515612989096:error:14090086:SSL
> routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify
> failed:s3_clnt.c:1162:
> TLSv1, cipher (NONE) (NONE)
> 1 handshakes of 256 bytes done
>
> $ cd ..
> $ ./apps/openssl version
> WARNING: can't open config file: /usr/local/ssl/openssl.cnf
> OpenSSL 1.0.1l-fips 15 Jan 2015
>
> (Man... OpenSSL really is a big ball of crap: you have to be in the
> exact right directory for everything to work. It's amazing that these
> guys don't fix stuff like that. I like scripting everything, and
> having to do a "cd" in a script usually means that it's going to be
> hard to do things properly.)
>
> - -chris
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1
> Comment: GPGTools - http://gpgtools.org
>
> iQIcBAEBCAAGBQJUy7PaAAoJEBzwKT+lPKRYAqcQAI+So5gWQYfh166f1V30jrR4
> IqWHGvwxUYjIRPeuwu6V0tTVgAkwcspRiMapLWOIpSojrr+9jysj2N85EOVSpg+r
> yIkc7dJmDgvaQ025u6bhnCby8YwupVmoyQKuiR4CzQb+ZjZIaDgp0l4XEyP/DxTy
> UDD/CnXvJE/Fgp6lwnOcLygOYuPwGq0cDMcJEW5RT9TMfp8T0yLgOoC8NOuYp4q5
> Buywt9adAjNYZR1xREIKgRzEXEalFuI2dA4XyIV55Pye00dsAufsBj/uLhv4xAva
> XU3qbHnHSnycfiipGjW60ZM0zJqLtszx3Q26luElCbv9QqOAyf68+QV4cYVhI2rY
> 6SefnQZ2mCQKDs15+aYyB093zveQxKLkVIHyYsbHLpe0oPBUp0f8cy5UVRZnmtE+
> H8IXxG3jaz6mG15DYF6IXyg/GVlHMS+RQdoD2c0sNN+WtY0g+7kbcNLcrjwvsei0
> nKm6lnWXDUT4u8ggp5h+XDSbf1RzyxMyl6B9EwFW39rgmOnTtYIJjW7N8TxvcxvI
> 5LBEUJUcVSi2kb3tiWNHdcEeT5cnk8Woy3Tyoi+OrdcDoawz7x8o8sroXHgXogxN
> Zm5k6gAB+4xCv8LUVnkRV2qu+MBk6hmX5vEOp8NYf0xKzEuOhYGyxSL4b/5U+6c2
> bbYfRCbqLI/ySkifw55o
> =o/7E
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>


-- 
Thanks & Regards
Geett Chanddra Singha

RE: JDBC authentication problem

[Felix Schumacher]

Am 5. Februar 2015 11:25:13 MEZ, schrieb Luc DALLEMANE :
>Hi,
>
>The keep alive on postgres was already setup, but was not working.
>However, I finally found a workaround.
>
>I'm using the tomcat connexion pool, but For the authentication, Tomcat
>is creating its own connexion and does not use the pool (and seems to
>use the same connexion all along the session).

Which realm do you use? 

Felix
>
>So I think that's was why it was dropped by the firewall after a while,
>and when we restarted tomcat, the connexion was recreated and it worked
>again.
>
>To resolve this problem, we override Tomcat's authenticate method. We
>made our own open function which uses the postgres driver and is called
>in the authenticate.
>We do not use the getPassword and getRoles function, because they used
>the Tomcat's "global" connexion.
>
>With this, we are now able to connect to the site even after a long
>period of inactivity.
>
>Thank you for your help, and maybe this could help someone else.
>
>Regards, Luc.
>
>De : Felix Schumacher 
>Envoyé : mercredi 4 février 2015 20:11
>À : Tomcat Users List
>Objet : Re: JDBC authentication problem
>
>Am 04.02.2015 um 14:21 schrieb Luc DALLEMANE:
>> Hi,
>>
>> I'm back again with the problem :)
>>
>> Firstly, I add the validationQuery and it works and I can see it in
>postgres logs.
>>
>> But still not able to login after a while of inactivity
>>
>> Now, after 15 min of waiting, I'm getting a socket connexion timeout,
>but seems logic after such a long period of trying to connect.
>>
>> Thank you again for your ideas and haven't found a solution.
>You might try to enable keepalive on your postgresql connection.
>Connection porperties can be specified with the attribute
>"connectionProperties" (at least according to
>http://commons.apache.org/proper/commons-dbcp/configuration.html) or in
>the jdbc url jdbc://...?tcpKeepAlive=true. You can even specify the
>timeout for connnecting to your database.
>
>Regards
>  Felix
>>
>> Regards, Luc.
>> 
>> De : Konstantin Kolinko 
>> Envoyé : mardi 3 février 2015 12:33
>> À : Tomcat Users List
>> Objet : Re: JDBC authentication problem
>>
>> 2015-02-03 14:29 GMT+03:00 Luc DALLEMANE :
>>> Hi,
>>>
>>> Thanks for the reply, I tried to add the options you told me about
>(testWhileIdle, timeBetweenEvictionRunsMillis, and
>maxConnLifetimeMillis), but I'm still unable to log after un hour ...
>> Do you have validationQuery configured?  testOnBorrow, testWhileIdle
>> do not work without it.
>>
>>
>> Best regards,
>> Konstantin Kolinko
>>
>> -
>> 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
>>
>
>
>-
>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


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

RE: JDBC authentication problem

[Luc DALLEMANE]

Hi,

The keep alive on postgres was already setup, but was not working. However, I 
finally found a workaround.

I'm using the tomcat connexion pool, but For the authentication, Tomcat is 
creating its own connexion and does not use the pool (and seems to use the same 
connexion all along the session).

So I think that's was why it was dropped by the firewall after a while, and 
when we restarted tomcat, the connexion was recreated and it worked again.

To resolve this problem, we override Tomcat's authenticate method. We made our 
own open function which uses the postgres driver and is called in the 
authenticate.
We do not use the getPassword and getRoles function, because they used the 
Tomcat's "global" connexion.

With this, we are now able to connect to the site even after a long period of 
inactivity.

Thank you for your help, and maybe this could help someone else.

Regards, Luc.

De : Felix Schumacher 
Envoyé : mercredi 4 février 2015 20:11
À : Tomcat Users List
Objet : Re: JDBC authentication problem

Am 04.02.2015 um 14:21 schrieb Luc DALLEMANE:
> Hi,
>
> I'm back again with the problem :)
>
> Firstly, I add the validationQuery and it works and I can see it in postgres 
> logs.
>
> But still not able to login after a while of inactivity
>
> Now, after 15 min of waiting, I'm getting a socket connexion timeout, but 
> seems logic after such a long period of trying to connect.
>
> Thank you again for your ideas and haven't found a solution.
You might try to enable keepalive on your postgresql connection.
Connection porperties can be specified with the attribute
"connectionProperties" (at least according to
http://commons.apache.org/proper/commons-dbcp/configuration.html) or in
the jdbc url jdbc://...?tcpKeepAlive=true. You can even specify the
timeout for connnecting to your database.

Regards
  Felix
>
> Regards, Luc.
> 
> De : Konstantin Kolinko 
> Envoyé : mardi 3 février 2015 12:33
> À : Tomcat Users List
> Objet : Re: JDBC authentication problem
>
> 2015-02-03 14:29 GMT+03:00 Luc DALLEMANE :
>> Hi,
>>
>> Thanks for the reply, I tried to add the options you told me about 
>> (testWhileIdle, timeBetweenEvictionRunsMillis, and maxConnLifetimeMillis), 
>> but I'm still unable to log after un hour ...
> Do you have validationQuery configured?  testOnBorrow, testWhileIdle
> do not work without it.
>
>
> Best regards,
> Konstantin Kolinko
>
> -
> 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
>


-
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: Tomcat 7.0.55 System Down

[Mark Thomas]

On 05/02/2015 09:11, 토로치 wrote:
> Hello.
> 
> 
> I am a PLM system developers.
> 
> We PLM system operates by JAVA.
> 
> We are using the Tomcat version 7.0.55.
> 
> The system Down occurs when we are using a PLM system.
> 
> The hs-err_pid5684.mdmp file over 20GB is created in the Tomcat root folder.
> 
> When the contents of the hs_err_pid5512.log file shown that a JVM bug.

If you think you have hit a JVM bug, why are you posting here?



> Current thread (0x384c9800):  JavaThread "http-apr-9500-exec-226"
> daemon [_thread_in_native, id=18668,
> stack(0x5a63,0x5a73)]

That tells me you are using the APR/native connector. It is possible
that that connector is casing the problem but the stack trace isn't what
I'd expect to see in that case.

I recommend switching to the BIO HTTP connector and seeing if the crash
still occurs.



> JAVA_HOME=C:\Java\x64\jdk1.7.0_03

That is a very old JVM. You should also try updating that to the latest
7.0.x release and see if the bug reoccurs.

On a related topic, make sure you are using the latest native component
for the APR/native connector (1.1.32 as I type this). An upgrade to the
latest Tomcat 7.0.x release wouldn't hurt either.

In short:
- get everything up to date
- test HTTP BIO vs HTTP APR/native

Mark

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

Re: Tomcat 7.0.55 System Down

[André Warnier]

Hi.
As per the error information which you copied below, this seems to be a Java or Windows 
problem, not a Tomcat problem.
The right place to report that problem is to the vendor that makes the Java which you are 
using (Oracle), or the vendor of the OS which you are using (Microsoft).
Or maybe even the vendor of the Java application which you are using (which may be 
Dassault Systèmes).


The error message below contains this :

> # If you would like to submit a bug report, please visit:
> #   http://bugreport.sun.com/bugreport/crash.jsp
> # The crash happened outside the Java Virtual Machine in native code.
> # See problematic frame for where to report the bug.
> #

Also, for the benefit of the naive ones among us, what is "PLM" ?

토로치 wrote:

Hello.


I am a PLM system developers.


We PLM system operates by JAVA.


We are using the Tomcat version 7.0.55.


The system Down occurs when we are using a PLM system.


The hs-err_pid5684.mdmp file over 20GB is created in the Tomcat root folder..


When the contents of the hs_err_pid5512.log file shown that a JVM bug.


There are logs that appear whenever an error occurs in common.

==ERROR=

com.dassault_systemes.platform.ipmodeling.jni.EnoviaKernel.statelessDispatch
com/dassault_systemes/platform/ipmodeling/jni/EnoviaSessionWrapper;Ljava/lang/String;Ljava/lang/String

==


How ho we fix this?


Below is the full text of hs_err_pid5512.log.


---  SYSTEM  ---

OS: Windows NT 6.1 , 64 bit Build 7601 Service Pack 1

CPU : total 12 (6 cores per cpu, 2 threads per core) family 6 model 44
stepping 2, cmov, cx8, fxsr, mmx, sse, sse2, sse3, ssse3, sse4.1, sse4.2,
popcnt, ht

Memory: 4k page, physical 50318424k(17358476k free), swap
100634984k(73454820k free)

vm_info: Java HotSpot(TM) 64-Bit Server VM (22.1-b02) for windows-amd64 JRE
(1.7.0_03-b05), built on Feb  3 2012 20:43:56 by "java_re" with unknown MS
VC++:1600

time: Wed Feb 04 13:39:01 2015
elapsed time: 407758 seconds


==  hs_err_pid5512.log
 =

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  EXCEPTION_ACCESS_VIOLATION (0xc005) at pc=0x7737e4e4,
pid=5512, tid=18668
#
# JRE version: 7.0_03-b05
# Java VM: Java HotSpot(TM) 64-Bit Server VM (22.1-b02 mixed mode
windows-amd64 )
# Problematic frame:
# C  [ntdll.dll+0x4e4e4]
#
# Core dump written. Default location:
D:\apache-tomcat-7.0.55\hs_err_pid5512.mdmp
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.sun.com/bugreport/crash.jsp
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#

---  T H R E A D  ---

Current thread (0x384c9800):  JavaThread "http-apr-9500-exec-226"
daemon [_thread_in_native, id=18668,
stack(0x5a63,0x5a73)]

siginfo: ExceptionCode=0xc005, writing address 0x0024

Registers:
RAX=0x, RBX=0x796d5ed8, RCX=0xfffc,
RDX=0x00015fe0
RSP=0x5a724b80, RBP=0x, RSI=0x00015fe0,
RDI=0x
R8 =0x5a724b38, R9 =0x0004, R10=0x,
R11=0x0246
R12=0x, R13=0x, R14=0x07efe000,
R15=0x
RIP=0x7737e4e4, EFLAGS=0x00010213

Top of Stack: (sp=0x5a724b80)
0x5a724b80:   5063b620 00015fe0
0x5a724b90:   3bf60080 3bf60190
0x5a724ba0:   5063b620 3c15
0x5a724bb0:   fffe 
0x5a724bc0:   3c15b3a0 00399c13
0x5a724bd0:   3b1fcb20 0050
0x5a724be0:    001f
0x5a724bf0:   0218 46edc360
0x5a724c00:   5a727b20 
0x5a724c10:   0004 0001
0x5a724c20:   ff00 7737e40b
0x5a724c30:    001f
0x5a724c40:    796d5ed8
0x5a724c50:   796d5ed0 00399c13
0x5a724c60:   80017660 
0x5a724c70:   48ec 001f

Instructions: (pc=0x7737e4e4)
0x7737e4c4:   0f b1 4b 08 0f 85 9b 47 fd ff 48 8b 03 4c 89 ac
0x7737e4d4:   24 c0 00 00 00 33 ed 45 33 ed 48 83 f8 ff 74 03
0x7737e4e4:   ff 40 24 ba 22 17 00 00 48 8d 3d 9d 8f 0e 00 80
0x7737e4f4:   3c 25 82 03 fe 7f 00 0f 85 b3 bd 01 00 48 83 fe


Register to memory mapping:

RAX=0x is an unknown value
RBX=0x00

Tomcat 7.0.55 System Down

[토로치]

Hello.


I am a PLM system developers.


We PLM system operates by JAVA.


We are using the Tomcat version 7.0.55.


The system Down occurs when we are using a PLM system.


The hs-err_pid5684.mdmp file over 20GB is created in the Tomcat root folder.


When the contents of the hs_err_pid5512.log file shown that a JVM bug.


There are logs that appear whenever an error occurs in common.

==ERROR=

com.dassault_systemes.platform.ipmodeling.jni.EnoviaKernel.statelessDispatch
com/dassault_systemes/platform/ipmodeling/jni/EnoviaSessionWrapper;Ljava/lang/String;Ljava/lang/String

==


How ho we fix this?


Below is the full text of hs_err_pid5512.log.


---  SYSTEM  ---

OS: Windows NT 6.1 , 64 bit Build 7601 Service Pack 1

CPU : total 12 (6 cores per cpu, 2 threads per core) family 6 model 44
stepping 2, cmov, cx8, fxsr, mmx, sse, sse2, sse3, ssse3, sse4.1, sse4.2,
popcnt, ht

Memory: 4k page, physical 50318424k(17358476k free), swap
100634984k(73454820k free)

vm_info: Java HotSpot(TM) 64-Bit Server VM (22.1-b02) for windows-amd64 JRE
(1.7.0_03-b05), built on Feb  3 2012 20:43:56 by "java_re" with unknown MS
VC++:1600

time: Wed Feb 04 13:39:01 2015
elapsed time: 407758 seconds


==  hs_err_pid5512.log
 =

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  EXCEPTION_ACCESS_VIOLATION (0xc005) at pc=0x7737e4e4,
pid=5512, tid=18668
#
# JRE version: 7.0_03-b05
# Java VM: Java HotSpot(TM) 64-Bit Server VM (22.1-b02 mixed mode
windows-amd64 )
# Problematic frame:
# C  [ntdll.dll+0x4e4e4]
#
# Core dump written. Default location:
D:\apache-tomcat-7.0.55\hs_err_pid5512.mdmp
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.sun.com/bugreport/crash.jsp
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#

---  T H R E A D  ---

Current thread (0x384c9800):  JavaThread "http-apr-9500-exec-226"
daemon [_thread_in_native, id=18668,
stack(0x5a63,0x5a73)]

siginfo: ExceptionCode=0xc005, writing address 0x0024

Registers:
RAX=0x, RBX=0x796d5ed8, RCX=0xfffc,
RDX=0x00015fe0
RSP=0x5a724b80, RBP=0x, RSI=0x00015fe0,
RDI=0x
R8 =0x5a724b38, R9 =0x0004, R10=0x,
R11=0x0246
R12=0x, R13=0x, R14=0x07efe000,
R15=0x
RIP=0x7737e4e4, EFLAGS=0x00010213

Top of Stack: (sp=0x5a724b80)
0x5a724b80:   5063b620 00015fe0
0x5a724b90:   3bf60080 3bf60190
0x5a724ba0:   5063b620 3c15
0x5a724bb0:   fffe 
0x5a724bc0:   3c15b3a0 00399c13
0x5a724bd0:   3b1fcb20 0050
0x5a724be0:    001f
0x5a724bf0:   0218 46edc360
0x5a724c00:   5a727b20 
0x5a724c10:   0004 0001
0x5a724c20:   ff00 7737e40b
0x5a724c30:    001f
0x5a724c40:    796d5ed8
0x5a724c50:   796d5ed0 00399c13
0x5a724c60:   80017660 
0x5a724c70:   48ec 001f

Instructions: (pc=0x7737e4e4)
0x7737e4c4:   0f b1 4b 08 0f 85 9b 47 fd ff 48 8b 03 4c 89 ac
0x7737e4d4:   24 c0 00 00 00 33 ed 45 33 ed 48 83 f8 ff 74 03
0x7737e4e4:   ff 40 24 ba 22 17 00 00 48 8d 3d 9d 8f 0e 00 80
0x7737e4f4:   3c 25 82 03 fe 7f 00 0f 85 b3 bd 01 00 48 83 fe


Register to memory mapping:

RAX=0x is an unknown value
RBX=0x796d5ed8 is an unknown value
RCX=0xfffc is an unknown value
RDX=0x00015fe0 is an unknown value
RSP=0x5a724b80 is pointing into the stack for thread:
0x384c9800
RBP=0x is an unknown value
RSI=0x00015fe0 is an unknown value
RDI=0x is an unknown value
R8 =0x5a724b38 is pointing into the stack for thread:
0x384c9800
R9 =0x0004 is an unknown value
R10=0x is an unknown value
R11=0x0246 is an unknown value
R12=0x is an unknown value
R13=0x is an unknown value
R14=0x07efe000 is an unknown value
R15=0x is an unknown value


Stack:
[0x5a63,0x5a73],