How to do a JNDI look up in a different thread
Hi , Thanks for your prompt reply. But the below suggestion "Set the thread context class loader to the web application class loader." will not work in our case as we have our own custom class loader to load the hibernate resources like e.g. hbm files , Entity classes and all. Below is the code snippet : Configuration cfg = new Configuration(); cfg.addInputStream(inputStrm); // This is the input stream of the .hbm file which is in our database and Entity class in this xml to be loaded by our custom class loader only as our Entity classes in the database. cfg.buildMappings(); cfg.buildSessionFactory(); // It fails in JNDI look up if I dont set the web application class loader as context class loader. so ideally if I set my custom class loader as context class loader I am able to load my .hbm files and corresponding Entity classes. If I set the context class loader to wep application class loader my JNDI look-up works but I get class not found exception for my Entity classes referred in the .hbm files. Any idea to solve this? RegardsDinesh From: Mark Thomas Sent: 29-07-2016 16:19 To: Tomcat Users List Subject: Re: How to do a JNDI look up in a different thread On 29/07/2016 11:41, Khandelwal, Dinesh wrote: > > Hi, > > As part of my project , we maintain multiple Hibernate session factoriesand > as building these session factories take lot of time which causes server > totake more time in start-up , we are creating these session factories > indifferent threads Each thread creating one factory but when > theconfiguration.buildsessionFactory() [Hibernate internally does JNDI look > upwhich 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 > namecombinations 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
Re: Tomcat 8.5.x missing javax.servlet.forward.* attributes in an included jsp?
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?
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
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
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
+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
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
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
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 java.util.concurrent.locks.AbstractQueuedSynchronizer$Condit
Tomee process status "Running" but application processing no order - Hung Threads?
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 org.apache.tomcat.util.threads.TaskQueue.take(
Re: How to do a JNDI look up in a different thread
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
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.
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.
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 : ... ... ...