Re: ERR_SPDY_COMPRESSION_ERROR (http2)

[Durga Srinivasu Karuturi]

Mark,

Thanks for the fix!

We will use 8.5.10 once it is available.

Thanks,
Durga Srinivasu

On Sat, Dec 24, 2016 at 11:33 PM, Mark Thomas  wrote:

> On 24/12/2016 14:51, Durga Srinivasu Karuturi wrote:
> > Mark,
> >
> > Thanks for the update!
>
> Fixed for 9.0.0.M16 onwards and 8.5.10 onwards. Releases of these are
> likely in the first few weeks of 2017.
>
> The root cause was Tomact agreeing the new HTTP/2 setting but not
> updating the HPACK encoder so the encoder carried on using the old value.
>
> Mark
>
>
> >
> > Thanks,
> > Durga Srinivasu
> >
> > On Sat, Dec 24, 2016 at 6:47 PM, Mark Thomas  wrote:
> >
> >> On 22/12/2016 12:58, Mark Thomas wrote:
> >>> On 22 December 2016 10:16:18 GMT+00:00, Durga Srinivasu Karuturi <
> >> durgasriniv...@gmail.com> wrote:
>  Hi,
> 
>  Shall i raise a defect?
> >>>
> >>> Patience. Give the community a chance to look at it first. Given the
> >> time of year, that might take longer than usual.
> >>
> >> I can confirm I can repeat the problem you are describing.
> >>
> >> Tomcat not sending an HPACK dynamic table size update is certainly a
> >> possibility.
> >>
> >> I'll look into the root cause next.
> >>
> >> Mark
> >>
> >>
> >>>
> >>> Mark
> >>>
> >>>
> 
>  Thanks,
>  Durga Srinivasu
> 
>  On Wed, Dec 21, 2016 at 2:56 PM, Durga Srinivasu Karuturi <
>  durgasriniv...@gmail.com> wrote:
> 
> > Hi,
> >
> > We are stuck with this issue.
> >
> > Is this locally reproducible with sample web-app?
> >
> > Thanks,
> > Durga Srinvasu
> >
> >
> > On Tue, Dec 20, 2016 at 11:26 AM, Durga Srinivasu Karuturi <
> > durgasriniv...@gmail.com> wrote:
> >
> >> Its ~5MB file (ROOT app tar bundle).
> >>
> >> I hope the information, which i have shared so far is useful enough
>  to
> >> reproduce the problem locally.
> >>
> >> Please let me know if i missed any other information.
> >>
> >> Thanks,
> >> Durga Srinivasu
> >>
> >>
> >> On Tue, Dec 20, 2016 at 7:42 AM, Sreeraj V P 
>  wrote:
> >>
> >>> yes.. started download.. hadnt waited to complete.
> >>>
> >>> Sent from BlueMail ​
> >>>
> >>> On 19 Dec 2016, 3:27 p.m., at 3:27 p.m., Durga Srinivasu Karuturi <
> >>> durgasriniv...@gmail.com> wrote:
>  Mark,
> 
>  Looks like tar/zip attachments are getting removed.
> 
>  Uploaded same in google drive now.
> 
>  Please let me know if you can access the same or not.
> 
>  https://drive.google.com/open?id=0B1OzquDqWi6bVUN0MDk2RDFENG8
> 
>  Thanks,
>  Durga Srinivasu
> 
> 
>  On Mon, Dec 19, 2016 at 3:21 PM, Durga Srinivasu Karuturi <
>  durgasriniv...@gmail.com> wrote:
> 
> > Mark,
> >
> > Attaching the modified ROOT web-app from tomcat 8.5.9 bundle.
>  Just
>  changed
> > index.jsp and added lib [mostly DOJO] folder content to
>  reproduce.
> >
> > If we deploy this in latest 8.5.9 with http2 enabled in chrome
>  we are
> > seeing the SPDY compression errors
> >
> > Please let me know if this helps.
> >
> > Thanks,
> > Durga Srinivasu
> >
> >
> >
> > On Mon, Dec 19, 2016 at 2:31 PM, Mark Thomas 
>  wrote:
> >
> >> On 17/12/2016 06:35, Durga Srinivasu Karuturi wrote:
> >>> Do i need to post in any other forum?
> >>
> >> No, you are in the right place.
> >>
> >> You mentioned the issue was reproducible with the Dojo
>  libraries. If
>  you
> >> can provide the simplest possible set of steps to recreate this
>  issue
> >> from a clean Tomcat 8.5.9 install that would be a big help.
> >>
> >> Mark
> >>
> >>>
> >>> Thanks,
> >>> Durga Srinivasu
> >>>
> >>> On Thu, Dec 15, 2016 at 6:41 PM, Durga Srinivasu Karuturi
> >>> >
>  wrote:
> >>>
> >>> Hi,
> >>>
> >>> Any pointers please?
> >>>
> >>> Thanks,
> >>> Durga Srinivasu
> >>>
> >>> On Wed, Dec 14, 2016 at 10:15 PM, Durga Srinivasu
>  Karuturi
> >>>   >
>  wrote:
> >>>
> >>> Hi,
> >>>
> >>> Recent chrome  [Mac - Sierra : Version  55.0.2883.87
>  (64-bit) ]
> >> we are seeing issues in http2 sites.
> >>>
> >>>
> >>> Initially we have seen problem with http2 table
>  header
>  size
> >> limit error 

Re: Maintaining Session with Apache RewriteRule

[Rainer Jung]

Am 24.12.2016 um 19:58 schrieb Jerry Malcolm:

Mark,

Thanks, but what can I do to correct it?



On 12/24/2016 11:09 AM, Mark Thomas wrote:

On 24/12/2016 16:08, Jerry Malcolm wrote:

I have an app that runs in a single WAR file deployment (single webapp
context).  I added some Apache RewriteRule statements to hide the actual
URLs for pages in the webapp.  All of the rules still resolve to the
single WAR file context.  But the problem is now I get a different
session on each page.  I need to pass a session variable from page to
page.  Everything worked with a single session until I moved to the
RewriteRule statements.  Am I missing some flag in the RewriteRule or a
Tomcat config option that will allow me to keep one session even with
RewriteRules in effect?

Here's one of the Apache statements:

  RewriteRule ^/precheckout$
/order/jsp/user/termsandconditions.jsp[PT]

What am I missing?

You are missing that the session cookie has a path and your rewrite
rules are changing the path and therefore preventing the client from
returning cookie.


http://httpd.apache.org/docs/2.4/en/mod/mod_proxy.html#proxypassreversecookiepath

Regards,

Rainer


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

Re: Maintaining Session with Apache RewriteRule

[Jerry Malcolm]

Mark,

Thanks, but what can I do to correct it?


On 12/24/2016 11:09 AM, Mark Thomas wrote:

On 24/12/2016 16:08, Jerry Malcolm wrote:

I have an app that runs in a single WAR file deployment (single webapp
context).  I added some Apache RewriteRule statements to hide the actual
URLs for pages in the webapp.  All of the rules still resolve to the
single WAR file context.  But the problem is now I get a different
session on each page.  I need to pass a session variable from page to
page.  Everything worked with a single session until I moved to the
RewriteRule statements.  Am I missing some flag in the RewriteRule or a
Tomcat config option that will allow me to keep one session even with
RewriteRules in effect?

Here's one of the Apache statements:

  RewriteRule ^/precheckout$
/order/jsp/user/termsandconditions.jsp[PT]

What am I missing?

You are missing that the session cookie has a path and your rewrite
rules are changing the path and therefore preventing the client from
returning cookie.

Mark


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



-
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2016.0.7924 / Virus Database: 4739/13644 - Release Date: 12/23/16



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

Re: Upgrade to 8.5.8/9

[Mark Thomas]

On 24/12/2016 13:33, Greg Huber wrote:
> We use spring for startup only,  struts2 and hibernate for persistance.

Thanks. I was expecting to see some pool size settings there but I
didn't. In which the the default will be used which is unchanged from 8.

Looking at the thread dump, you have a few threads at:
java.lang.Thread.State: RUNNABLE
 at org.events.ui.core.filters.IPBanFilter.doFilter(IPBanFilter.java:36)
 etc.

and the rest stuck at:
java.lang.Thread.State: WAITING (on object monitor)
 at java.lang.Object.wait(Native Method)
 at java.lang.Object.wait(Object.java:502)
 at
org.apache.commons.pool.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:1104)
- locked <0xf1f541b8> (a
org.apache.commons.pool.impl.GenericObjectPool$Latch)
 at
org.apache.commons.dbcp.PoolingDataSource.getConnection(PoolingDataSource.java:106)

Note that is Commons DBCP 1.x.

That looks like a connection leak to me.

The standard debug approach would be to enable abandoned connection logging.

Mark



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

Re: ERR_SPDY_COMPRESSION_ERROR (http2)

[Mark Thomas]

On 24/12/2016 14:51, Durga Srinivasu Karuturi wrote:
> Mark,
> 
> Thanks for the update!

Fixed for 9.0.0.M16 onwards and 8.5.10 onwards. Releases of these are
likely in the first few weeks of 2017.

The root cause was Tomact agreeing the new HTTP/2 setting but not
updating the HPACK encoder so the encoder carried on using the old value.

Mark


> 
> Thanks,
> Durga Srinivasu
> 
> On Sat, Dec 24, 2016 at 6:47 PM, Mark Thomas  wrote:
> 
>> On 22/12/2016 12:58, Mark Thomas wrote:
>>> On 22 December 2016 10:16:18 GMT+00:00, Durga Srinivasu Karuturi <
>> durgasriniv...@gmail.com> wrote:
 Hi,

 Shall i raise a defect?
>>>
>>> Patience. Give the community a chance to look at it first. Given the
>> time of year, that might take longer than usual.
>>
>> I can confirm I can repeat the problem you are describing.
>>
>> Tomcat not sending an HPACK dynamic table size update is certainly a
>> possibility.
>>
>> I'll look into the root cause next.
>>
>> Mark
>>
>>
>>>
>>> Mark
>>>
>>>

 Thanks,
 Durga Srinivasu

 On Wed, Dec 21, 2016 at 2:56 PM, Durga Srinivasu Karuturi <
 durgasriniv...@gmail.com> wrote:

> Hi,
>
> We are stuck with this issue.
>
> Is this locally reproducible with sample web-app?
>
> Thanks,
> Durga Srinvasu
>
>
> On Tue, Dec 20, 2016 at 11:26 AM, Durga Srinivasu Karuturi <
> durgasriniv...@gmail.com> wrote:
>
>> Its ~5MB file (ROOT app tar bundle).
>>
>> I hope the information, which i have shared so far is useful enough
 to
>> reproduce the problem locally.
>>
>> Please let me know if i missed any other information.
>>
>> Thanks,
>> Durga Srinivasu
>>
>>
>> On Tue, Dec 20, 2016 at 7:42 AM, Sreeraj V P 
 wrote:
>>
>>> yes.. started download.. hadnt waited to complete.
>>>
>>> Sent from BlueMail ​
>>>
>>> On 19 Dec 2016, 3:27 p.m., at 3:27 p.m., Durga Srinivasu Karuturi <
>>> durgasriniv...@gmail.com> wrote:
 Mark,

 Looks like tar/zip attachments are getting removed.

 Uploaded same in google drive now.

 Please let me know if you can access the same or not.

 https://drive.google.com/open?id=0B1OzquDqWi6bVUN0MDk2RDFENG8

 Thanks,
 Durga Srinivasu


 On Mon, Dec 19, 2016 at 3:21 PM, Durga Srinivasu Karuturi <
 durgasriniv...@gmail.com> wrote:

> Mark,
>
> Attaching the modified ROOT web-app from tomcat 8.5.9 bundle.
 Just
 changed
> index.jsp and added lib [mostly DOJO] folder content to
 reproduce.
>
> If we deploy this in latest 8.5.9 with http2 enabled in chrome
 we are
> seeing the SPDY compression errors
>
> Please let me know if this helps.
>
> Thanks,
> Durga Srinivasu
>
>
>
> On Mon, Dec 19, 2016 at 2:31 PM, Mark Thomas 
 wrote:
>
>> On 17/12/2016 06:35, Durga Srinivasu Karuturi wrote:
>>> Do i need to post in any other forum?
>>
>> No, you are in the right place.
>>
>> You mentioned the issue was reproducible with the Dojo
 libraries. If
 you
>> can provide the simplest possible set of steps to recreate this
 issue
>> from a clean Tomcat 8.5.9 install that would be a big help.
>>
>> Mark
>>
>>>
>>> Thanks,
>>> Durga Srinivasu
>>>
>>> On Thu, Dec 15, 2016 at 6:41 PM, Durga Srinivasu Karuturi
>>> >
 wrote:
>>>
>>> Hi,
>>>
>>> Any pointers please?
>>>
>>> Thanks,
>>> Durga Srinivasu
>>>
>>> On Wed, Dec 14, 2016 at 10:15 PM, Durga Srinivasu
 Karuturi
>>> >
 wrote:
>>>
>>> Hi,
>>>
>>> Recent chrome  [Mac - Sierra : Version  55.0.2883.87
 (64-bit) ]
>> we are seeing issues in http2 sites.
>>>
>>>
>>> Initially we have seen problem with http2 table
 header
 size
>> limit error and to fix this, we have upgraded tomcat 8.5.4 to
 8.5.9
 where
>> tomcat has increased the header limit from 16K to 64K.
>>>
>>>
>>> Now with latest tomcat 8.5.9 we are seeing
>> ERR_SPDY_COMPRESSION_ERROR while loading dojo libraries.
>>>
>>> Tried couple of steps (flush SPDY sokets etc) based
 on
 google
>> search on this issue but nothing worked..
>>>
>>>
>>>  

Re: Maintaining Session with Apache RewriteRule

[Mark Thomas]

On 24/12/2016 16:08, Jerry Malcolm wrote:
> I have an app that runs in a single WAR file deployment (single webapp
> context).  I added some Apache RewriteRule statements to hide the actual
> URLs for pages in the webapp.  All of the rules still resolve to the
> single WAR file context.  But the problem is now I get a different
> session on each page.  I need to pass a session variable from page to
> page.  Everything worked with a single session until I moved to the
> RewriteRule statements.  Am I missing some flag in the RewriteRule or a
> Tomcat config option that will allow me to keep one session even with
> RewriteRules in effect?
> 
> Here's one of the Apache statements:
> 
>  RewriteRule ^/precheckout$
> /order/jsp/user/termsandconditions.jsp[PT]
> 
> What am I missing?

You are missing that the session cookie has a path and your rewrite
rules are changing the path and therefore preventing the client from
returning cookie.

Mark


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

Maintaining Session with Apache RewriteRule

[Jerry Malcolm]

I have an app that runs in a single WAR file deployment (single webapp 
context).  I added some Apache RewriteRule statements to hide the actual 
URLs for pages in the webapp.  All of the rules still resolve to the 
single WAR file context.  But the problem is now I get a different 
session on each page.  I need to pass a session variable from page to 
page.  Everything worked with a single session until I moved to the 
RewriteRule statements.  Am I missing some flag in the RewriteRule or a 
Tomcat config option that will allow me to keep one session even with 
RewriteRules in effect?


Here's one of the Apache statements:

 RewriteRule ^/precheckout$ 
/order/jsp/user/termsandconditions.jsp[PT]


What am I missing?


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

Re: ERR_SPDY_COMPRESSION_ERROR (http2)

[Durga Srinivasu Karuturi]

Mark,

Thanks for the update!

Thanks,
Durga Srinivasu

On Sat, Dec 24, 2016 at 6:47 PM, Mark Thomas  wrote:

> On 22/12/2016 12:58, Mark Thomas wrote:
> > On 22 December 2016 10:16:18 GMT+00:00, Durga Srinivasu Karuturi <
> durgasriniv...@gmail.com> wrote:
> >> Hi,
> >>
> >> Shall i raise a defect?
> >
> > Patience. Give the community a chance to look at it first. Given the
> time of year, that might take longer than usual.
>
> I can confirm I can repeat the problem you are describing.
>
> Tomcat not sending an HPACK dynamic table size update is certainly a
> possibility.
>
> I'll look into the root cause next.
>
> Mark
>
>
> >
> > Mark
> >
> >
> >>
> >> Thanks,
> >> Durga Srinivasu
> >>
> >> On Wed, Dec 21, 2016 at 2:56 PM, Durga Srinivasu Karuturi <
> >> durgasriniv...@gmail.com> wrote:
> >>
> >>> Hi,
> >>>
> >>> We are stuck with this issue.
> >>>
> >>> Is this locally reproducible with sample web-app?
> >>>
> >>> Thanks,
> >>> Durga Srinvasu
> >>>
> >>>
> >>> On Tue, Dec 20, 2016 at 11:26 AM, Durga Srinivasu Karuturi <
> >>> durgasriniv...@gmail.com> wrote:
> >>>
>  Its ~5MB file (ROOT app tar bundle).
> 
>  I hope the information, which i have shared so far is useful enough
> >> to
>  reproduce the problem locally.
> 
>  Please let me know if i missed any other information.
> 
>  Thanks,
>  Durga Srinivasu
> 
> 
>  On Tue, Dec 20, 2016 at 7:42 AM, Sreeraj V P 
> >> wrote:
> 
> > yes.. started download.. hadnt waited to complete.
> >
> > Sent from BlueMail ​
> >
> > On 19 Dec 2016, 3:27 p.m., at 3:27 p.m., Durga Srinivasu Karuturi <
> > durgasriniv...@gmail.com> wrote:
> >> Mark,
> >>
> >> Looks like tar/zip attachments are getting removed.
> >>
> >> Uploaded same in google drive now.
> >>
> >> Please let me know if you can access the same or not.
> >>
> >> https://drive.google.com/open?id=0B1OzquDqWi6bVUN0MDk2RDFENG8
> >>
> >> Thanks,
> >> Durga Srinivasu
> >>
> >>
> >> On Mon, Dec 19, 2016 at 3:21 PM, Durga Srinivasu Karuturi <
> >> durgasriniv...@gmail.com> wrote:
> >>
> >>> Mark,
> >>>
> >>> Attaching the modified ROOT web-app from tomcat 8.5.9 bundle.
> >> Just
> >> changed
> >>> index.jsp and added lib [mostly DOJO] folder content to
> >> reproduce.
> >>>
> >>> If we deploy this in latest 8.5.9 with http2 enabled in chrome
> >> we are
> >>> seeing the SPDY compression errors
> >>>
> >>> Please let me know if this helps.
> >>>
> >>> Thanks,
> >>> Durga Srinivasu
> >>>
> >>>
> >>>
> >>> On Mon, Dec 19, 2016 at 2:31 PM, Mark Thomas 
> >> wrote:
> >>>
>  On 17/12/2016 06:35, Durga Srinivasu Karuturi wrote:
> > Do i need to post in any other forum?
> 
>  No, you are in the right place.
> 
>  You mentioned the issue was reproducible with the Dojo
> >> libraries. If
> >> you
>  can provide the simplest possible set of steps to recreate this
> >> issue
>  from a clean Tomcat 8.5.9 install that would be a big help.
> 
>  Mark
> 
> >
> > Thanks,
> > Durga Srinivasu
> >
> > On Thu, Dec 15, 2016 at 6:41 PM, Durga Srinivasu Karuturi
> > >
> >> wrote:
> >
> > Hi,
> >
> > Any pointers please?
> >
> > Thanks,
> > Durga Srinivasu
> >
> > On Wed, Dec 14, 2016 at 10:15 PM, Durga Srinivasu
> >> Karuturi
> >  >> >
> >> wrote:
> >
> > Hi,
> >
> > Recent chrome  [Mac - Sierra : Version  55.0.2883.87
> >> (64-bit) ]
>  we are seeing issues in http2 sites.
> >
> >
> > Initially we have seen problem with http2 table
> >> header
> >> size
>  limit error and to fix this, we have upgraded tomcat 8.5.4 to
> >> 8.5.9
> >> where
>  tomcat has increased the header limit from 16K to 64K.
> >
> >
> > Now with latest tomcat 8.5.9 we are seeing
>  ERR_SPDY_COMPRESSION_ERROR while loading dojo libraries.
> >
> > Tried couple of steps (flush SPDY sokets etc) based
> >> on
> >> google
>  search on this issue but nothing worked..
> >
> >
> > Inline image 1
> >
> > t=10513 [st= 1] -HTTP_TRANSACTION_SEND_REQUEST
> >
> > t=10513 [st= 1] +HTTP_TRANSACTION_READ_HEADERS
> >> [dt=36]
> >
> > t=10549 [st=37]HTTP2_STREAM_ERROR
> >
> >--> 

Re: Upgrade to 8.5.8/9

[Greg Huber]

We use spring for startup only,  struts2 and hibernate for persistance.

jdbc.properties

jdbc.driverClassName=org.mariadb.jdbc.Driver
jdbc.url=jdbc:mysql://localhost:3306/eventsdb?autoReconnect=trueuseUnicode=truecharacterEncoding=utf-8mysqlEncoding=utf8
hibernate.dialect=org.hibernate.dialect.MySQL5Dialect
jndi.value=java:comp/env/jdbc/eventsdbxa

hibernate.cfg



org.events.business.hibernate.ThreadLocalSessionContextNoAutoClose
false
true
false
 org.hibernate.transaction.JDBCTransactionFactory
true
org.hibernate.cache.EhCacheProvider
org.hibernate.cache.ehcache.EhCacheRegionFactory
false
false
true




hibernate.properties

file is empty


spring.cfg





${jdbc.driverClassName}


${jdbc.url}


${jdbc.username}


${jdbc.password}




${jdbc.driverClassName}


${quartz.jdbc.url}


${jdbc.username}


${jdbc.password}








${hibernate.dialect}











org.events.pojos







classpath:hibernate.cfg.xml



















On 24 December 2016 at 12:07, Mark Thomas  wrote:

> On 24/12/2016 08:49, Greg Huber wrote:
> > ...Well its not hibernate, will look at switching to commons-dbcp2 if
> > possible.
>
> Again, please post your resource config.
>
> Mark
>
>
> >
> > Cheers
> >
> > On 22 December 2016 at 20:26, Mark Thomas  wrote:
> >
> >> On 22/12/2016 17:50, Greg Huber wrote:
> >>> Chris,
> >>>
> >>> Thanks, I have been running this setup for ages, 8 plus years and
> various
> >>> tomcat versions.  It has never failed on  <= 8.0.x  I had to
> stop/start a
> >>> couple of times to get it to fail and had to run a parallel maven build
> >> to
> >>> slow things down.
> >>>
> >>> Do not read much on dumps, but what would this -locked be?
> >>
> >> It is perfectly normal.
> >>
> >> Your problem is with the connection pool.
> >>
> >> Note that when Tomcat switched form DBCP1 to DBCP2, some of the names of
> >> the attributes changed. You might not be using the settings you think
> >> you are using. Please post your resource config.
> >>
> >> Mark
> >>
> >>>
> >>> at
> >>> org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.
> >> doRun(NioEndpoint.java:1437)
> >>> at
> >>> org.apache.tomcat.util.net.SocketProcessorBase.run(
> >> SocketProcessorBase.java:49)
> >>> - locked <0xf1c54ed8> (a
> >>> org.apache.tomcat.util.net.NioEndpoint$NioSocketWrapper)
> >>> at
> >>> java.util.concurrent.ThreadPoolExecutor.runWorker(
> >> ThreadPoolExecutor.java:1142)
> >>> 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)
> >>>
> >>> Cheers Greg
> >>>
> >>>
> >>> On 22 December 2016 at 16:24, Christopher Schultz <
> >>> ch...@christopherschultz.net> wrote:
> >>>
> >>> Greg,
> >>>
> >>> On 12/22/16 5:18 AM, Greg Huber wrote:
> >> Here is the first dump and I cannot send all three.  Its my prod
> >> server which is locked up at the moment.  I need to get it back on
> >> line so is this enough info?  I can emile the whole file which has
> >> the three dumps if needed.
> >>
> >> [snip]
> >>
> >> Full thread dump Java HotSpot(TM) 64-Bit Server VM (25.40-b25 mixed
> >> mode):
> >>
> >> "ajp-nio-8009-exec-26" #61 daemon prio=5 os_prio=0
> >> tid=0x0cb1 nid=0x1960 in Object.wait()
> >> [0x2ba658a4b000] java.lang.Thread.State: WAITING (on object
> >> monitor) at java.lang.Object.wait(Native Method) at
> >> java.lang.Object.wait(Object.java:502) at
> >> org.apache.commons.pool.impl.GenericObjectPool.
> >> borrowObject(GenericObj
> >>> ectPool.java:1104)
> >>
> >>
> >>> - locked <0xf2879c10> (a
> >> org.apache.commons.pool.impl.GenericObjectPool$Latch)
> >>>
> >>> Waiting on a database connection.
> >>>
> >>>
> >> "ajp-nio-8009-exec-25" #60 daemon prio=5 os_prio=0
> >> tid=0x0c74f800 nid=0x195d in Object.wait()
> >> [0x2ba658a0a000] 

Re: ERR_SPDY_COMPRESSION_ERROR (http2)

[Mark Thomas]

On 22/12/2016 12:58, Mark Thomas wrote:
> On 22 December 2016 10:16:18 GMT+00:00, Durga Srinivasu Karuturi 
>  wrote:
>> Hi,
>>
>> Shall i raise a defect?
> 
> Patience. Give the community a chance to look at it first. Given the time of 
> year, that might take longer than usual.

I can confirm I can repeat the problem you are describing.

Tomcat not sending an HPACK dynamic table size update is certainly a
possibility.

I'll look into the root cause next.

Mark


> 
> Mark
> 
> 
>>
>> Thanks,
>> Durga Srinivasu
>>
>> On Wed, Dec 21, 2016 at 2:56 PM, Durga Srinivasu Karuturi <
>> durgasriniv...@gmail.com> wrote:
>>
>>> Hi,
>>>
>>> We are stuck with this issue.
>>>
>>> Is this locally reproducible with sample web-app?
>>>
>>> Thanks,
>>> Durga Srinvasu
>>>
>>>
>>> On Tue, Dec 20, 2016 at 11:26 AM, Durga Srinivasu Karuturi <
>>> durgasriniv...@gmail.com> wrote:
>>>
 Its ~5MB file (ROOT app tar bundle).

 I hope the information, which i have shared so far is useful enough
>> to
 reproduce the problem locally.

 Please let me know if i missed any other information.

 Thanks,
 Durga Srinivasu


 On Tue, Dec 20, 2016 at 7:42 AM, Sreeraj V P 
>> wrote:

> yes.. started download.. hadnt waited to complete.
>
> Sent from BlueMail ​
>
> On 19 Dec 2016, 3:27 p.m., at 3:27 p.m., Durga Srinivasu Karuturi <
> durgasriniv...@gmail.com> wrote:
>> Mark,
>>
>> Looks like tar/zip attachments are getting removed.
>>
>> Uploaded same in google drive now.
>>
>> Please let me know if you can access the same or not.
>>
>> https://drive.google.com/open?id=0B1OzquDqWi6bVUN0MDk2RDFENG8
>>
>> Thanks,
>> Durga Srinivasu
>>
>>
>> On Mon, Dec 19, 2016 at 3:21 PM, Durga Srinivasu Karuturi <
>> durgasriniv...@gmail.com> wrote:
>>
>>> Mark,
>>>
>>> Attaching the modified ROOT web-app from tomcat 8.5.9 bundle.
>> Just
>> changed
>>> index.jsp and added lib [mostly DOJO] folder content to
>> reproduce.
>>>
>>> If we deploy this in latest 8.5.9 with http2 enabled in chrome
>> we are
>>> seeing the SPDY compression errors
>>>
>>> Please let me know if this helps.
>>>
>>> Thanks,
>>> Durga Srinivasu
>>>
>>>
>>>
>>> On Mon, Dec 19, 2016 at 2:31 PM, Mark Thomas 
>> wrote:
>>>
 On 17/12/2016 06:35, Durga Srinivasu Karuturi wrote:
> Do i need to post in any other forum?

 No, you are in the right place.

 You mentioned the issue was reproducible with the Dojo
>> libraries. If
>> you
 can provide the simplest possible set of steps to recreate this
>> issue
 from a clean Tomcat 8.5.9 install that would be a big help.

 Mark

>
> Thanks,
> Durga Srinivasu
>
> On Thu, Dec 15, 2016 at 6:41 PM, Durga Srinivasu Karuturi
> >
>> wrote:
>
> Hi,
>
> Any pointers please?
>
> Thanks,
> Durga Srinivasu
>
> On Wed, Dec 14, 2016 at 10:15 PM, Durga Srinivasu
>> Karuturi
> > >
>> wrote:
>
> Hi,
>
> Recent chrome  [Mac - Sierra : Version  55.0.2883.87
>> (64-bit) ]
 we are seeing issues in http2 sites.
>
>
> Initially we have seen problem with http2 table
>> header
>> size
 limit error and to fix this, we have upgraded tomcat 8.5.4 to
>> 8.5.9
>> where
 tomcat has increased the header limit from 16K to 64K.
>
>
> Now with latest tomcat 8.5.9 we are seeing
 ERR_SPDY_COMPRESSION_ERROR while loading dojo libraries.
>
> Tried couple of steps (flush SPDY sokets etc) based
>> on
>> google
 search on this issue but nothing worked..
>
>
> Inline image 1
>
> t=10513 [st= 1] -HTTP_TRANSACTION_SEND_REQUEST
>
> t=10513 [st= 1] +HTTP_TRANSACTION_READ_HEADERS
>> [dt=36]
>
> t=10549 [st=37]HTTP2_STREAM_ERROR
>
>--> description = "ABANDONED
> (stream_id=139):
> https://10.104.118.174/webacs/lib/dijit/form/_ToggleB
 uttonMixin.js.map
>
>> "
>
>--> status = -363
>
>--> stream_id = 139
>
> t=10549 [st=37] 

Re: Upgrade to 8.5.8/9

[Mark Thomas]

On 24/12/2016 08:49, Greg Huber wrote:
> ...Well its not hibernate, will look at switching to commons-dbcp2 if
> possible.

Again, please post your resource config.

Mark


> 
> Cheers
> 
> On 22 December 2016 at 20:26, Mark Thomas  wrote:
> 
>> On 22/12/2016 17:50, Greg Huber wrote:
>>> Chris,
>>>
>>> Thanks, I have been running this setup for ages, 8 plus years and various
>>> tomcat versions.  It has never failed on  <= 8.0.x  I had to stop/start a
>>> couple of times to get it to fail and had to run a parallel maven build
>> to
>>> slow things down.
>>>
>>> Do not read much on dumps, but what would this -locked be?
>>
>> It is perfectly normal.
>>
>> Your problem is with the connection pool.
>>
>> Note that when Tomcat switched form DBCP1 to DBCP2, some of the names of
>> the attributes changed. You might not be using the settings you think
>> you are using. Please post your resource config.
>>
>> Mark
>>
>>>
>>> at
>>> org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.
>> doRun(NioEndpoint.java:1437)
>>> at
>>> org.apache.tomcat.util.net.SocketProcessorBase.run(
>> SocketProcessorBase.java:49)
>>> - locked <0xf1c54ed8> (a
>>> org.apache.tomcat.util.net.NioEndpoint$NioSocketWrapper)
>>> at
>>> java.util.concurrent.ThreadPoolExecutor.runWorker(
>> ThreadPoolExecutor.java:1142)
>>> 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)
>>>
>>> Cheers Greg
>>>
>>>
>>> On 22 December 2016 at 16:24, Christopher Schultz <
>>> ch...@christopherschultz.net> wrote:
>>>
>>> Greg,
>>>
>>> On 12/22/16 5:18 AM, Greg Huber wrote:
>> Here is the first dump and I cannot send all three.  Its my prod
>> server which is locked up at the moment.  I need to get it back on
>> line so is this enough info?  I can emile the whole file which has
>> the three dumps if needed.
>>
>> [snip]
>>
>> Full thread dump Java HotSpot(TM) 64-Bit Server VM (25.40-b25 mixed
>> mode):
>>
>> "ajp-nio-8009-exec-26" #61 daemon prio=5 os_prio=0
>> tid=0x0cb1 nid=0x1960 in Object.wait()
>> [0x2ba658a4b000] java.lang.Thread.State: WAITING (on object
>> monitor) at java.lang.Object.wait(Native Method) at
>> java.lang.Object.wait(Object.java:502) at
>> org.apache.commons.pool.impl.GenericObjectPool.
>> borrowObject(GenericObj
>>> ectPool.java:1104)
>>
>>
>>> - locked <0xf2879c10> (a
>> org.apache.commons.pool.impl.GenericObjectPool$Latch)
>>>
>>> Waiting on a database connection.
>>>
>>>
>> "ajp-nio-8009-exec-25" #60 daemon prio=5 os_prio=0
>> tid=0x0c74f800 nid=0x195d in Object.wait()
>> [0x2ba658a0a000] java.lang.Thread.State: WAITING (on object
>> monitor) at java.lang.Object.wait(Native Method) at
>> java.lang.Object.wait(Object.java:502) at
>> org.apache.commons.pool.impl.GenericObjectPool.
>> borrowObject(GenericObj
>>> ectPool.java:1104)
>>
>>
>>> - locked <0xf2852128> (a
>> org.apache.commons.pool.impl.GenericObjectPool$Latch)
>>>
>>> Another thread waiting for a db connection.
>>>
>> "ajp-nio-8009-exec-24" #59 daemon prio=5 os_prio=0
>> tid=0x0dd3b000 nid=0x1959 in Object.wait()
>> [0x2ba6589c9000] java.lang.Thread.State: WAITING (on object
>> monitor) at java.lang.Object.wait(Native Method) at
>> java.lang.Object.wait(Object.java:502) at
>> org.apache.commons.pool.impl.GenericObjectPool.
>> borrowObject(GenericObj
>>> ectPool.java:1104)
>>
>>
>>> - locked <0xf282a818> (a
>> org.apache.commons.pool.impl.GenericObjectPool$Latch)
>>>
>>> I'm starting to see a pattern, here.
>>>
>> "ajp-nio-8009-exec-23" #58 daemon prio=5 os_prio=0
>> tid=0x0cbe6000 nid=0x1953 in Object.wait()
>> [0x2ba658988000] java.lang.Thread.State: WAITING (on object
>> monitor) at java.lang.Object.wait(Native Method) at
>> java.lang.Object.wait(Object.java:502) at
>> org.apache.commons.pool.impl.GenericObjectPool.
>> borrowObject(GenericObj
>>> ectPool.java:1104)
>>
>>
>>> - locked <0xf28030f8> (a
>> org.apache.commons.pool.impl.GenericObjectPool$Latch)
>>>
>>> Hmm. Could it be...
>>>
>> "ajp-nio-8009-exec-22" #57 daemon prio=5 os_prio=0
>> tid=0x0e797800 nid=0x194f in Object.wait()
>> [0x2ba659472000] java.lang.Thread.State: WAITING (on object
>> monitor) at java.lang.Object.wait(Native Method) at
>> java.lang.Object.wait(Object.java:502) at
>> org.apache.commons.pool.impl.GenericObjectPool.
>> borrowObject(GenericObj
>>> ectPool.java:1104)
>>
>>
>>> - locked <0xf27daf28> (a
>> org.apache.commons.pool.impl.GenericObjectPool$Latch)
>>>
>>> ... just possibly ...
>>>
>> "ajp-nio-8009-exec-21" #56 daemon prio=5 os_prio=0

Re: Upgrade to 8.5.8/9

[Greg Huber]

This is a dump of it working:

for

ajp-nio-8009-exec,  I do not see any

- locked <0xf0a3f6b8> (a
org.apache.tomcat.util.net.NioEndpoint$NioSocketWrapper)

from the not working dump. possibly a result of stuff higher up in the
chain?

Cheers Greg

Full thread dump Java HotSpot(TM) 64-Bit Server VM (25.40-b25 mixed mode):

"pool-4-thread-5" #54 prio=5 os_prio=0 tid=0x0a6e5800 nid=0x2dfc
waiting on condition [0x2aef09792000]
   java.lang.Thread.State: TIMED_WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for  <0xd233fca8> (a
java.util.concurrent.SynchronousQueue$TransferStack)
at
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
at
java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:460)
at
java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:362)
at java.util.concurrent.SynchronousQueue.poll(SynchronousQueue.java:941)
at
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1066)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)

"pool-4-thread-4" #53 prio=5 os_prio=0 tid=0x0a834000 nid=0x2dc5
waiting on condition [0x2aef09814000]
   java.lang.Thread.State: TIMED_WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for  <0xd233fca8> (a
java.util.concurrent.SynchronousQueue$TransferStack)
at
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
at
java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:460)
at
java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:362)
at java.util.concurrent.SynchronousQueue.poll(SynchronousQueue.java:941)
at
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1066)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)

"QuartzScheduler_scheduler-NON_CLUSTERED_MisfireHandler" #52 prio=5
os_prio=0 tid=0x0a692800 nid=0x2d67 waiting on condition
[0x2aef0a1ed000]
   java.lang.Thread.State: TIMED_WAITING (sleeping)
at java.lang.Thread.sleep(Native Method)
at
org.quartz.impl.jdbcjobstore.JobStoreSupport$MisfireHandler.run(JobStoreSupport.java:3992)

"pool-3-thread-1" #51 prio=5 os_prio=0 tid=0x0a49a000 nid=0x2d66
waiting on condition [0x2aef09855000]
   java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for  <0xd21d62c8> (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
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 java.lang.Thread.run(Thread.java:745)

"ajp-nio-8009-exec-10" #45 daemon prio=5 os_prio=0 tid=0x0b45c800
nid=0x2d40 waiting on condition [0x2aef09ea8000]
   java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for  <0xd2cdb7a8> (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:103)
at org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:31)
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-nio-8009-exec-9" #44 daemon prio=5 os_prio=0 tid=0x0b45c000
nid=0x2d3f waiting on condition [0x2aef09e67000]
   java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for  <0xd2cdb7a8> (a

Re: Upgrade to 8.5.8/9

[Greg Huber]

Mark/Chris,

Upgraded to dbcp2 with no luck, and get this in the dumps, repeating
pattern.


"ajp-nio-8009-exec-28" #60 daemon prio=5 os_prio=0 tid=0x2b28245c3800
nid=0x2a02 waiting on condition [0x2b28316aa000]
   java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for  <0xd1026878> (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
org.apache.commons.pool2.impl.LinkedBlockingDeque.takeFirst(LinkedBlockingDeque.java:583)
at
org.apache.commons.pool2.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:442)
at
org.apache.commons.pool2.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:363)
at
org.apache.commons.dbcp2.PoolingDataSource.getConnection(PoolingDataSource.java:134)
at
org.apache.commons.dbcp2.BasicDataSource.getConnection(BasicDataSource.java:1533)
at
org.hibernate.engine.jdbc.connections.internal.DatasourceConnectionProviderImpl.getConnection(DatasourceConnectionProviderImpl.java:122)
at
org.hibernate.internal.NonContextualJdbcConnectionAccess.obtainConnection(NonContextualJdbcConnectionAccess.java:35)
at
org.hibernate.resource.jdbc.internal.LogicalConnectionManagedImpl.acquireConnectionIfNeeded(LogicalConnectionManagedImpl.java:99)
at
org.hibernate.resource.jdbc.internal.LogicalConnectionManagedImpl.getPhysicalConnection(LogicalConnectionManagedImpl.java:129)
at
org.hibernate.resource.jdbc.internal.LogicalConnectionManagedImpl.getConnectionForTransactionManagement(LogicalConnectionManagedImpl.java:247)
at
org.hibernate.resource.jdbc.internal.LogicalConnectionManagedImpl.begin(LogicalConnectionManagedImpl.java:254)
at
org.hibernate.resource.transaction.backend.jdbc.internal.JdbcResourceLocalTransactionCoordinatorImpl$TransactionDriverControlImpl.begin(JdbcResourceLocalTransactionCoordinatorImpl.java:203)
at
org.hibernate.engine.transaction.internal.TransactionImpl.begin(TransactionImpl.java:56)
at
org.hibernate.internal.AbstractSharedSessionContract.beginTransaction(AbstractSharedSessionContract.java:401)
at sun.reflect.GeneratedMethodAccessor83.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at
org.hibernate.context.internal.ThreadLocalSessionContext$TransactionProtectionWrapper.invoke(ThreadLocalSessionContext.java:355)
at com.sun.proxy.$Proxy65.beginTransaction(Unknown Source)
at
org.events.business.hibernate.HibernatePersistenceStrategy.getSession(HibernatePersistenceStrategy.java:99)
at
org.events.business.hibernate.HibernateWebsiteManagerImpl.getWebsiteDetailByHandle(HibernateWebsiteManagerImpl.java:319)
at
org.events.business.WebsiteManagerImpl.getWebsiteByHandle(WebsiteManagerImpl.java:252)
at
org.events.business.WebsiteManagerImpl.checkWebsiteByHandle(WebsiteManagerImpl.java:170)
at
org.events.ui.rendering.WebsiteRequestMapper.isWebsite(WebsiteRequestMapper.java:389)
at
org.events.ui.rendering.WebsiteRequestMapper.handleRequest(WebsiteRequestMapper.java:118)
at
org.events.ui.rendering.filters.RequestMappingFilter.doFilter(RequestMappingFilter.java:107)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:192)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:165)
at
org.events.ui.rendering.filters.DeviceResolverRequestFilter.doFilterInternal(DeviceResolverRequestFilter.java:62)
at
org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:192)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:165)
at org.events.ui.core.filters.InitFilter.doFilter(InitFilter.java:57)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:192)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:165)
at
org.events.ui.core.filters.PersistenceSessionFilter.doFilter(PersistenceSessionFilter.java:36)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:192)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:165)
at
org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:317)
at
org.springframework.security.web.access.intercept.FilterSecurityInterceptor.invoke(FilterSecurityInterceptor.java:127)
at

Re: Upgrade to 8.5.8/9

[Greg Huber]

...Well its not hibernate, will look at switching to commons-dbcp2 if
possible.

Cheers

On 22 December 2016 at 20:26, Mark Thomas  wrote:

> On 22/12/2016 17:50, Greg Huber wrote:
> > Chris,
> >
> > Thanks, I have been running this setup for ages, 8 plus years and various
> > tomcat versions.  It has never failed on  <= 8.0.x  I had to stop/start a
> > couple of times to get it to fail and had to run a parallel maven build
> to
> > slow things down.
> >
> > Do not read much on dumps, but what would this -locked be?
>
> It is perfectly normal.
>
> Your problem is with the connection pool.
>
> Note that when Tomcat switched form DBCP1 to DBCP2, some of the names of
> the attributes changed. You might not be using the settings you think
> you are using. Please post your resource config.
>
> Mark
>
> >
> > at
> > org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.
> doRun(NioEndpoint.java:1437)
> > at
> > org.apache.tomcat.util.net.SocketProcessorBase.run(
> SocketProcessorBase.java:49)
> > - locked <0xf1c54ed8> (a
> > org.apache.tomcat.util.net.NioEndpoint$NioSocketWrapper)
> > at
> > java.util.concurrent.ThreadPoolExecutor.runWorker(
> ThreadPoolExecutor.java:1142)
> > 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)
> >
> > Cheers Greg
> >
> >
> > On 22 December 2016 at 16:24, Christopher Schultz <
> > ch...@christopherschultz.net> wrote:
> >
> > Greg,
> >
> > On 12/22/16 5:18 AM, Greg Huber wrote:
>  Here is the first dump and I cannot send all three.  Its my prod
>  server which is locked up at the moment.  I need to get it back on
>  line so is this enough info?  I can emile the whole file which has
>  the three dumps if needed.
> 
>  [snip]
> 
>  Full thread dump Java HotSpot(TM) 64-Bit Server VM (25.40-b25 mixed
>  mode):
> 
>  "ajp-nio-8009-exec-26" #61 daemon prio=5 os_prio=0
>  tid=0x0cb1 nid=0x1960 in Object.wait()
>  [0x2ba658a4b000] java.lang.Thread.State: WAITING (on object
>  monitor) at java.lang.Object.wait(Native Method) at
>  java.lang.Object.wait(Object.java:502) at
>  org.apache.commons.pool.impl.GenericObjectPool.
> borrowObject(GenericObj
> > ectPool.java:1104)
> 
> 
> > - locked <0xf2879c10> (a
>  org.apache.commons.pool.impl.GenericObjectPool$Latch)
> >
> > Waiting on a database connection.
> >
> >
>  "ajp-nio-8009-exec-25" #60 daemon prio=5 os_prio=0
>  tid=0x0c74f800 nid=0x195d in Object.wait()
>  [0x2ba658a0a000] java.lang.Thread.State: WAITING (on object
>  monitor) at java.lang.Object.wait(Native Method) at
>  java.lang.Object.wait(Object.java:502) at
>  org.apache.commons.pool.impl.GenericObjectPool.
> borrowObject(GenericObj
> > ectPool.java:1104)
> 
> 
> > - locked <0xf2852128> (a
>  org.apache.commons.pool.impl.GenericObjectPool$Latch)
> >
> > Another thread waiting for a db connection.
> >
>  "ajp-nio-8009-exec-24" #59 daemon prio=5 os_prio=0
>  tid=0x0dd3b000 nid=0x1959 in Object.wait()
>  [0x2ba6589c9000] java.lang.Thread.State: WAITING (on object
>  monitor) at java.lang.Object.wait(Native Method) at
>  java.lang.Object.wait(Object.java:502) at
>  org.apache.commons.pool.impl.GenericObjectPool.
> borrowObject(GenericObj
> > ectPool.java:1104)
> 
> 
> > - locked <0xf282a818> (a
>  org.apache.commons.pool.impl.GenericObjectPool$Latch)
> >
> > I'm starting to see a pattern, here.
> >
>  "ajp-nio-8009-exec-23" #58 daemon prio=5 os_prio=0
>  tid=0x0cbe6000 nid=0x1953 in Object.wait()
>  [0x2ba658988000] java.lang.Thread.State: WAITING (on object
>  monitor) at java.lang.Object.wait(Native Method) at
>  java.lang.Object.wait(Object.java:502) at
>  org.apache.commons.pool.impl.GenericObjectPool.
> borrowObject(GenericObj
> > ectPool.java:1104)
> 
> 
> > - locked <0xf28030f8> (a
>  org.apache.commons.pool.impl.GenericObjectPool$Latch)
> >
> > Hmm. Could it be...
> >
>  "ajp-nio-8009-exec-22" #57 daemon prio=5 os_prio=0
>  tid=0x0e797800 nid=0x194f in Object.wait()
>  [0x2ba659472000] java.lang.Thread.State: WAITING (on object
>  monitor) at java.lang.Object.wait(Native Method) at
>  java.lang.Object.wait(Object.java:502) at
>  org.apache.commons.pool.impl.GenericObjectPool.
> borrowObject(GenericObj
> > ectPool.java:1104)
> 
> 
> > - locked <0xf27daf28> (a
>  org.apache.commons.pool.impl.GenericObjectPool$Latch)
> >
> > ... just possibly ...
> >
>  "ajp-nio-8009-exec-21" #56 daemon prio=5 os_prio=0
>  tid=0x0e874000 nid=0x194d in Object.wait()
>  [0x2ba656c67000] java.lang.Thread.State: WAITING (on