Re: Tomcat 8.5.x missing javax.servlet.forward.* attributes in an included jsp?

2016-07-29 Thread Wang, Andy 
On Sat, 2016-07-30 at 02:07 +, Wang, Andy wrote:
> I did a quick read of the spec just now, and I can't find a good
> explanation of which is correct.  Would this be considered a
> regression in 8.5.x? 

Another quick re-read:
9.4.2 Forwarded Request Parameters
states this:
These attributes are accessible from the forwarded servlet via the
getAttribute
method on the request object. Note that these attributes must always
reflect the
information in the original request even under the situation that
multiple forwards
and subsequent includes are called.

Based on that, I believe this is a regression.  I'll go ahead and file
a bug on this.

Tomcat 8.5.x missing javax.servlet.forward.* attributes in an included jsp?

2016-07-29 Thread Wang, Andy 
I have a really simply example (courtesy of the developer that discovered this 
issue) at:
https://dl.dropboxusercontent.com/u/24563006/TestApp.war

It contains a test.jsp that does:

<%
   String href= "/WEB-INF/jsp/test/test1.jsp";
   RequestDispatcher rd = request.getRequestDispatcher(href);
   rd.forward(request, response);
%>

test1.jsp simply dumps out all the attributes and then:


and test2.jsp dumps out attributes again.

In tomcat 8.0.36 the output of
http://server/TestApp/test.jsp is:

You are in test1.jsp 

test1 inRequest org.apache.catalina.core.ApplicationHttpRequest@22f9afc4
test1 inRequest.getServletPath() /WEB-INF/jsp/test/test1.jsp
javax.servlet.forward.request_uri :: /TestApp/test.jsp
javax.servlet.forward.context_path :: /TestApp
javax.servlet.forward.servlet_path :: /test.jsp



You are in test2.jsp 

test2 inRequest org.apache.catalina.core.ApplicationHttpRequest@21695eed
test2 inRequest.getServletPath() /WEB-INF/jsp/test/test1.jsp
javax.servlet.include.request_uri :: /TestApp/WEB-INF/jsp/test/test2.jsp
javax.servlet.include.context_path :: /TestApp
javax.servlet.include.servlet_path :: /WEB-INF/jsp/test/test2.jsp
javax.servlet.forward.request_uri :: /TestApp/test.jsp
javax.servlet.forward.context_path :: /TestApp
javax.servlet.forward.servlet_path :: /test.jsp

Note that the "You are in test2.jsp" block contains javax.servlet.forward.*

In tomcat 8.5.4 (and 8.5.3 too)
It looks like:
You are in test1.jsp 

test1 inRequest org.apache.catalina.core.ApplicationHttpRequest@31d80a34
test1 inRequest.getServletPath() /WEB-INF/jsp/test/test1.jsp
javax.servlet.forward.request_uri :: /TestApp/test.jsp
javax.servlet.forward.context_path :: /TestApp
javax.servlet.forward.servlet_path :: /test.jsp
javax.servlet.forward.mapping :: 
org.apache.catalina.core.ApplicationMapping$MappingImpl@6a64c5b8



You are in test2.jsp 

test2 inRequest org.apache.catalina.core.ApplicationHttpRequest@1130eccf
test2 inRequest.getServletPath() /WEB-INF/jsp/test/test1.jsp
javax.servlet.include.request_uri :: /TestApp/WEB-INF/jsp/test/test2.jsp
javax.servlet.include.context_path :: /TestApp
javax.servlet.include.servlet_path :: /WEB-INF/jsp/test/test2.jsp
javax.servlet.include.mapping :: 
org.apache.catalina.core.ApplicationMapping$MappingImpl@7e9a01d5

I did a quick read of the spec just now, and I can't find a good explanation of 
which is correct.  Would this be considered a regression in 8.5.x? 

Thanks,
Andy

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

Realm SSHA Code

2016-07-29 Thread George Sexton 
I was looking at the source code for org.apache.catalina.realm.RealmBase 
and see that it can handle salted SHA for passwords. Does anyone have 
some example code that demonstrates generating the SSHA value: 
generating the salt, doing the digest, and outputting the value so that 
I could put it in my Tomcat-Users.xml file? I'm using Tomcat 7, so it 
looks like the CredentialHandler which provides a mutate() method 
wouldn't be available.



--
George Sexton
*MH Software, Inc.*
Voice: 303 438 9585
http://www.connectdaily.com

Re: Huge Time Tomcat Manager

2016-07-29 Thread Mohit Chawla 
I see this on my system as well for all requests, except for the
manager/status request, which shows the correct time.

On Fri, Jul 29, 2016 at 5:06 PM, George Sexton 
wrote:

>
> On 7/21/2016 9:58 AM, Christopher Schultz wrote:
>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA256
>>
>> Teresa,
>>
>> On 7/21/16 5:33 AM, Teresa Fasano wrote:
>>
>>> I notice on my tomcat manager the huge and wrong values for the
>>> thread times. For example: 1469093029135 ms
>>>
>>> This is the information: Server version: Apache Tomcat/7.0.56
>>> (Debian) Server built:   Feb 3 2015 06:16:51 Server number:
>>> 7.0.56.0 OS Name:Linux OS Version: 3.2.0-4-amd64
>>> Architecture:   amd64 JVM Version:1.6.0_35-b35 JVM Vendor:
>>> Sun Microsystems Inc.
>>>
>>> Why? It is a bug?
>>>
>> Since it's unlikely that your application has been running for 46
>> years straight, something is obviously wrong.
>>
>
> I consistently see this on my mod_jk connector for the "Time" value.
>
>
>
>> Exactly which timing value are you looking at in the manager application
>> ?
>>
>> - -chris
>> -BEGIN PGP SIGNATURE-
>> Comment: GPGTools - http://gpgtools.org
>> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>>
>> iQIcBAEBCAAGBQJXkPE5AAoJEBzwKT+lPKRYlmgP/i9OYYa1eRt36e0kNKXVcvWj
>> 4bET69/zh9UxJR5H3JdJDwmPY2RxhIzKQrDXC+bgEI0s2vor3T/C9MTAkFKFfUuV
>> 0fE5YLCityUOR4M2dy++nOhoHKedZvIXzJWVAil/z+yRLfUepNOoHfb+b2y6uWU5
>> pIqa4/604UaSj+MQgJVi2N2nNuAxTLhi0Te1wxhjTu9foZJGU9fLaYSmGP7XMWIq
>> ztsH5JOSPHpGiqOZK4UoKXo7w8glSvTGX8834EsnTkJ8N13anl8nFo11qk66JRWi
>> f/vlydnIc9vRON6NXy3OJsMky7bkfEgFuLIngzA1VhXKfCdquzbwyAH2ISOJ1DPw
>> r8wAUNWWFZnOa0UJr61L5Xp/vRq+k4oX1kijKLXfmPd5RySJLYaw2OD6w8b21R/9
>> Y36RxHAW9K7OgNSfr12L6nT9ZLPzLa+qbradicJcV8sppR2fTqq8Gq48P0NQhg9t
>> Q3ZCGa5JX7nxEnloN9dW+MVZr6gmDmhcgg9hF4RRof3tLj14iwiVhKk8mTqnNmLZ
>> 4rehbEs7loHze87D+YwdB956AGK0lEFJGSnWN2g6/ZstQs+7mhwPyxr5MSscHv95
>> zhyvp3j7EqQZPr1vuEkjda9NOA3MxzcwKpVcld0nkNnj8UadLdNZkOYTCAm9FG8u
>> hVD1Z/EN9G3aBezCzgSz
>> =SWSD
>> -END PGP SIGNATURE-
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>
>>
> --
> George Sexton
> *MH Software, Inc.*
> Voice: 303 438 9585
> http://www.connectdaily.com
>

Re: Incorrect request processing times in server status

2016-07-29 Thread Mohit Chawla 
+1, the clock on my system is also correct and in sync.

On Fri, Jul 29, 2016 at 5:04 PM, George Sexton 
wrote:

>
>
> On 6/23/2016 5:12 AM, Mark Thomas wrote:
>
>> On 23/06/2016 12:11, Mohit Chawla wrote:
>>
>>> Hi,
>>>
>>> Can someone suggest if this should be opened as a bug instead ?
>>>
>> Not a bug. Probably just an unstable system clock.
>>
>
> I consistently see this on my server for the mod_jk connector. In my case,
> the connections between the Apache front end and tomcat seem to be
> persistent. I'm using NTP to synch the clock, so I don't think that's an
> issue.
>
>
>
>
>> Mark
>>
>>
>> Thanks,
>>> Mohit
>>>
>>> On Tue, Jun 21, 2016 at 11:06 AM, Mohit Chawla <
>>> mohit.chawla.bin...@gmail.com> wrote:
>>>
>>> Hello list,

 On a new tomcat installation I am noticing extremely high values for
 request processing times being reported by the server status page. Even
 if
 I restart tomcat and start sending requests again, the request
 processing
 time again shows extremely high values for a few requests. I have tested
 this with tomcat 7.0.26 and 7.0.52 on Ubuntu 14.04.

 For example,

 K  1466499689496 ms  ?  ?  10.128.3.236  10.128.3.236  ?  ?

 In reality that request came into the system only a few milliseconds
 ago.

 Can someone suggest what could be done here ?

 Thanks,

 Mohit


>> -
>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>
>>
> --
> George Sexton
> *MH Software, Inc.*
> Voice: 303 438 9585
> http://www.connectdaily.com
>

Re: Huge Time Tomcat Manager

2016-07-29 Thread George Sexton 


On 7/21/2016 9:58 AM, Christopher Schultz wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Teresa,

On 7/21/16 5:33 AM, Teresa Fasano wrote:

I notice on my tomcat manager the huge and wrong values for the
thread times. For example: 1469093029135 ms

This is the information: Server version: Apache Tomcat/7.0.56
(Debian) Server built:   Feb 3 2015 06:16:51 Server number:
7.0.56.0 OS Name:Linux OS Version: 3.2.0-4-amd64
Architecture:   amd64 JVM Version:1.6.0_35-b35 JVM Vendor:
Sun Microsystems Inc.

Why? It is a bug?

Since it's unlikely that your application has been running for 46
years straight, something is obviously wrong.


I consistently see this on my mod_jk connector for the "Time" value.



Exactly which timing value are you looking at in the manager application
?

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJXkPE5AAoJEBzwKT+lPKRYlmgP/i9OYYa1eRt36e0kNKXVcvWj
4bET69/zh9UxJR5H3JdJDwmPY2RxhIzKQrDXC+bgEI0s2vor3T/C9MTAkFKFfUuV
0fE5YLCityUOR4M2dy++nOhoHKedZvIXzJWVAil/z+yRLfUepNOoHfb+b2y6uWU5
pIqa4/604UaSj+MQgJVi2N2nNuAxTLhi0Te1wxhjTu9foZJGU9fLaYSmGP7XMWIq
ztsH5JOSPHpGiqOZK4UoKXo7w8glSvTGX8834EsnTkJ8N13anl8nFo11qk66JRWi
f/vlydnIc9vRON6NXy3OJsMky7bkfEgFuLIngzA1VhXKfCdquzbwyAH2ISOJ1DPw
r8wAUNWWFZnOa0UJr61L5Xp/vRq+k4oX1kijKLXfmPd5RySJLYaw2OD6w8b21R/9
Y36RxHAW9K7OgNSfr12L6nT9ZLPzLa+qbradicJcV8sppR2fTqq8Gq48P0NQhg9t
Q3ZCGa5JX7nxEnloN9dW+MVZr6gmDmhcgg9hF4RRof3tLj14iwiVhKk8mTqnNmLZ
4rehbEs7loHze87D+YwdB956AGK0lEFJGSnWN2g6/ZstQs+7mhwPyxr5MSscHv95
zhyvp3j7EqQZPr1vuEkjda9NOA3MxzcwKpVcld0nkNnj8UadLdNZkOYTCAm9FG8u
hVD1Z/EN9G3aBezCzgSz
=SWSD
-END PGP SIGNATURE-

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



--
George Sexton
*MH Software, Inc.*
Voice: 303 438 9585
http://www.connectdaily.com

Re: Incorrect request processing times in server status

2016-07-29 Thread George Sexton 



On 6/23/2016 5:12 AM, Mark Thomas wrote:

On 23/06/2016 12:11, Mohit Chawla wrote:

Hi,

Can someone suggest if this should be opened as a bug instead ?

Not a bug. Probably just an unstable system clock.


I consistently see this on my server for the mod_jk connector. In my 
case, the connections between the Apache front end and tomcat seem to be 
persistent. I'm using NTP to synch the clock, so I don't think that's an 
issue.





Mark



Thanks,
Mohit

On Tue, Jun 21, 2016 at 11:06 AM, Mohit Chawla <
mohit.chawla.bin...@gmail.com> wrote:


Hello list,

On a new tomcat installation I am noticing extremely high values for
request processing times being reported by the server status page. Even if
I restart tomcat and start sending requests again, the request processing
time again shows extremely high values for a few requests. I have tested
this with tomcat 7.0.26 and 7.0.52 on Ubuntu 14.04.

For example,

K  1466499689496 ms  ?  ?  10.128.3.236  10.128.3.236  ?  ?

In reality that request came into the system only a few milliseconds ago.

Can someone suggest what could be done here ?

Thanks,

Mohit



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



--
George Sexton
*MH Software, Inc.*
Voice: 303 438 9585
http://www.connectdaily.com

Hanging threads in tomee 1.7.4

2016-07-29 Thread Kuldeep Sagoo 
Hi all,


 
I was really hoping you could help – I’m currently workingin application 
support and one of our key applications as started behavingabnormally when 
upgrading from Tomee version 1.68 to 1.7.4 (Apache Tomcat(TomEE)/7.0.68 
(1.7.4)) .


 
JDK

java version "1.8.0_77"

Java(TM) SE Runtime Environment (build 1.8.0_77-b03)

Java HotSpot(TM) 64-Bit Server VM (build 25.77-b03, mixedmode)


 
OS

Red Hat Enterprise Linux Server release 6.7 (Santiago)

Oracle Linux Server release 6.7


 
The issue occurs intermittently.  The Tomee processwhen its status is checked 
reports to be in ‘Running’ state. But from adatabase and application 
perspective all created orders remain in “New State”and remain in a Wait state 
to be processed.


 
I have taken a thread dump at the point when this occurs andwas hoping you that 
someone could give me some pointers.


 
Thanks for your help in advance and have a great weekend


 




Thread Dump 



2016-07-29 14:07:24Full thread dump Java HotSpot(TM) 64-Bit Server VM 
(25.77-b03 mixed mode):
"ajp-bio-8009-exec-10" #724 daemon prio=5 os_prio=0 tid=0x7f8e78b16800 
nid=0x36d9 waiting on condition [0x7f8e183de000]   java.lang.Thread.State: 
WAITING (parking)        at sun.misc.Unsafe.park(Native Method)        - 
parking to wait for  <0x0006c1746568> (a 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)        
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)        at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
        at 
java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)     
   at org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:104)        
at org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:32)        at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)   
     at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) 
       at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) 
       at 
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
        at java.lang.Thread.run(Thread.java:745)
"ajp-bio-8009-exec-9" #723 daemon prio=5 os_prio=0 tid=0x7f8e78b14800 
nid=0x36c2 waiting on condition [0x7f8e184df000]   java.lang.Thread.State: 
WAITING (parking)        at sun.misc.Unsafe.park(Native Method)        - 
parking to wait for  <0x0006c1746568> (a 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)        
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)        at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
        at 
java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)     
   at org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:104)        
at org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:32)        at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)   
     at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) 
       at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) 
       at 
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
        at java.lang.Thread.run(Thread.java:745)
"ajp-bio-8009-exec-8" #722 daemon prio=5 os_prio=0 tid=0x7f8e78b12800 
nid=0x36c0 waiting on condition [0x7f8e185e]   java.lang.Thread.State: 
WAITING (parking)        at sun.misc.Unsafe.park(Native Method)        - 
parking to wait for  <0x0006c1746568> (a 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)        
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)        at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
        at 
java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)     
   at org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:104)        
at org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:32)        at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)   
     at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) 
       at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) 
       at 
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
        at java.lang.Thread.run(Thread.java:745)
"ajp-bio-8009-exec-7" #721 daemon prio=5 os_prio=0 tid=0x7f8e78b11000 
nid=0x36bc waiting on condition [0x7f8e186e1000]   java.lang.Thread.State: 
WAITING (parking)        at sun.misc.Unsafe.park(Native Method)        - 
parking to wait for  <0x0006c1746568> (a

Tomee process status "Running" but application processing no order - Hung Threads?

2016-07-29 Thread Kuldeep Sagoo (C) 
Hi all,

I was really hoping you could help - I'm currently working in application 
support and one of our key applications as started behaving abnormally when 
upgrading from Tomee version 1.68 to 1.7.4 (Apache Tomcat (TomEE)/7.0.68 
(1.7.4)) .

JDK
java version "1.8.0_77"
Java(TM) SE Runtime Environment (build 1.8.0_77-b03)
Java HotSpot(TM) 64-Bit Server VM (build 25.77-b03, mixed mode)

OS
Red Hat Enterprise Linux Server release 6.7 (Santiago)
Oracle Linux Server release 6.7

The issue occurs intermittently.  The Tomee process when its status is checked 
reports to be in 'Running' state. But from a database and application 
perspective all created orders remain in "New State" and remain in a Wait state 
to be processed.

I have taken a thread dump at the point when this occurs and was hoping you 
that someone could give me some pointers.

Thanks for your help in advance and have a great weekend


Kind Regards,

Kuldeep Sagoo



This email is only intended for the person to whom it is addressed and may 
contain confidential information. If you have received this email in error, 
please notify the sender and delete this email which must not be copied, 
distributed or disclosed to any other person.

Unless stated otherwise, the contents of this email are personal to the writer 
and do not represent the official view of Ordnance Survey. Nor can any contract 
be formed on Ordnance Survey's behalf via email. We reserve the right to 
monitor emails and attachments without prior notice.

Thank you for your cooperation.

Ordnance Survey Limited (Company Registration number 09121572)
Registered Office: Explorer House
Adanac Drive
Southampton SO16 0AS
Tel: 03456 050505
http://www.os.uk
2016-07-29 11:52:07
Full thread dump Java HotSpot(TM) 64-Bit Server VM (25.77-b03 mixed mode):

"ajp-bio-8009-exec-10" #2612 daemon prio=5 os_prio=0 tid=0x7f6608d05000 
nid=0x3e5f waiting on condition [0x7f65a9f87000]
   java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for  <0x0006c17c0d40> (a 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
at 
java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
at org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:104)
at org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:32)
at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at 
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.lang.Thread.run(Thread.java:745)

"ajp-bio-8009-exec-9" #2611 daemon prio=5 os_prio=0 tid=0x7f6608d03000 
nid=0x3e4f waiting on condition [0x7f65aa088000]
   java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for  <0x0006c17c0d40> (a 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
at 
java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
at org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:104)
at org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:32)
at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at 
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.lang.Thread.run(Thread.java:745)

"ajp-bio-8009-exec-8" #2610 daemon prio=5 os_prio=0 tid=0x7f66081b3800 
nid=0x3e4d waiting on condition [0x7f65aa189000]
   java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for  <0x0006c17c0d40> (a 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
at 
java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
at org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:104)
at

Re: How to do a JNDI look up in a different thread

2016-07-29 Thread Mark Thomas 
On 29/07/2016 11:41, Khandelwal, Dinesh wrote:
> 
> Hi,
> 
> As part of my project , we maintain multiple Hibernate session factories and 
> as building these session factories take lot of time which causes server to 
> take more time in start-up , we are creating these session factories in 
> different threads Each thread creating one factory but when the 
> configuration.buildsessionFactory() [Hibernate internally does JNDI look up 
> which fails]API is called it throws Unable to lookup JNDI name 
> [java:/comp/env/BFDS].
> 
> Please note that I am using Tomcat 7 and I have tried multiple JNDI name 
> combinations e.g. java: /BFDS , java:global/BFDS , BFDS etc. but nothing 
> works. Same code works in JBOSS 7 and Websphere.
> 
> Please suggest something.

Set the thread context class loader to the web application class loader.

Mark

> 
> 
> Tomcat  Version   apache-tomcat-7.0.59
> JDK 1.7
> Hibernate  4.3.11.Final
> 
> -Dinesh
> "Misys" is the trade name of the Misys group of companies. This email and any 
> attachments have been scanned for known viruses using multiple scanners. This 
> email message is intended for the named recipient only. It may be privileged 
> and/or confidential. If you are not the named recipient of this email please 
> notify us immediately and do not copy it or use it for any purpose, nor 
> disclose its contents to any other person. This email does not constitute the 
> commencement of legal relations between you and Misys. Please refer to the 
> executed contract between you and the relevant member of the Misys group for 
> the identity of the contracting party with which you are dealing.
> 


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

How to do a JNDI look up in a different thread

2016-07-29 Thread Khandelwal, Dinesh 

Hi,

As part of my project , we maintain multiple Hibernate session factories and as 
building these session factories take lot of time which causes server to take 
more time in start-up , we are creating these session factories in different 
threads Each thread creating one factory but when the 
configuration.buildsessionFactory() [Hibernate internally does JNDI look up 
which fails]API is called it throws Unable to lookup JNDI name 
[java:/comp/env/BFDS].

Please note that I am using Tomcat 7 and I have tried multiple JNDI name 
combinations e.g. java: /BFDS , java:global/BFDS , BFDS etc. but nothing works. 
Same code works in JBOSS 7 and Websphere.

Please suggest something.


Tomcat  Version   apache-tomcat-7.0.59
JDK 1.7
Hibernate  4.3.11.Final

-Dinesh
"Misys" is the trade name of the Misys group of companies. This email and any 
attachments have been scanned for known viruses using multiple scanners. This 
email message is intended for the named recipient only. It may be privileged 
and/or confidential. If you are not the named recipient of this email please 
notify us immediately and do not copy it or use it for any purpose, nor 
disclose its contents to any other person. This email does not constitute the 
commencement of legal relations between you and Misys. Please refer to the 
executed contract between you and the relevant member of the Misys group for 
the identity of the contracting party with which you are dealing.

Problem with Cluster after upgrade to Tomcat 8.0.36.

2016-07-29 Thread Andrey Kocherga 
Hi all.

Tomcat-8.0.36; JDK 1.8.0_102; CentOS 6.8. After upgrade from 8.0.28 to 8.0.36 I 
have problem with my cluster. I use static membership cluster with two nodes 
with BackupManager. After update I have errors in default.log: "WARN  
org.apache.catalina.tribes.tipis.AbstractReplicatedMap - Notified member is not 
registered in the membership", but all works fine (packets exchanging between 
two nodes on tcp/4000). This message gone only if set default 
channelStartOptions (enable multicast), but not channelStartOptions="3". I try 
to downgrade version of Tomcat and this problem are not present in tomcat < 
8.0.30.

My config works a few years w/out problems.

server.xml:

...



...











...

Problem with Cluster after upgrade to Tomcat >8.0.30.

2016-07-29 Thread Andrey Kocherga 
 Hi all.

Tomcat-8.0.36; JDK 1.8.0_102; CentOS 6.8. After upgrade from 8.0.28 to 8.0.36 I 
have problem with my cluster. I use static membership cluster with two nodes 
with BackupManager. After update I have errors in default.log: "WARN  
org.apache.catalina.tribes.tipis.AbstractReplicatedMap - Notified member is not 
registered in the membership", but all works fine (packets exchanging between 
two nodes on tcp/4000). This message gone only if set default 
channelStartOptions (enable multicast), but not channelStartOptions="3". I try 
to downgrade version of Tomcat and this problem are not present in tomcat < 
8.0.30.

My config works a few years w/out problems.

server.xml : 

...


    
...


    
    
    
    
    

    
    
    
...