Thanks for looking further into this, Mark,
We are running:
java version "1.7.0_65"
OpenJDK Runtime Environment (IcedTea 2.5.1)
(7u65-2.5.1-4ubuntu1~0.12.04.2)
OpenJDK 64-Bit Server VM (build 24.65-b04, mixed mode)
Linux 3.11.0-15-generic #25~precise1-Ubuntu SMP Thu Jan 30 17:39:31 UTC
2
On 10/11/2014 09:57, Lars Engholm Johansen wrote:
> Hi Mark,
>
> I looked into our javax.websocket.Endpoint implementation and found the
> following suspicious code:
>
> When we need to close the WebSocket session already in .onOpen() method
> (rejecting a connection), we are calling session.clos
Hi Mark,
I looked into our javax.websocket.Endpoint implementation and found the
following suspicious code:
When we need to close the WebSocket session already in .onOpen() method
(rejecting a connection), we are calling session.close() asynchronously
after 1 second via a java.util.Timer task.
Th
On 06/10/2014 10:11, Lars Engholm Johansen wrote:
> Hi all,
>
> I have good news as I have identified the reason for the devastating
> NioEndpoint.Poller thread death:
>
> In rare circumstances a ConcurrentModification can occur in the Poller's
> connection timeout handling called from OUTSIDE th
Hi all,
I have good news as I have identified the reason for the devastating
NioEndpoint.Poller thread death:
In rare circumstances a ConcurrentModification can occur in the Poller's
connection timeout handling called from OUTSIDE the try-catch(Throwable) of
Poller.run()
java.util.ConcurrentModi
Thanks Lars, if you are indeed experiencing a non caught error, let us know
what it is.
On Thu, Sep 18, 2014 at 2:30 AM, Lars Engholm Johansen
wrote:
> Thanks guys for all the feedback.
>
> I have tried the following suggested tasks:
>
>- Upgrading Tomcat to the newest 7.0.55 on all our serv
Thanks guys for all the feedback.
I have tried the following suggested tasks:
- Upgrading Tomcat to the newest 7.0.55 on all our servers -> Problem
still persists
- Force a System.gc() when connection count is on the loose ->
Connection count is not dropping
- Lowering the log leve
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Filip,
On 6/27/14, 11:36 AM, Filip Hanik wrote:
> Are there any log entries that would indicate that the poller
> thread has died? This/these thread/s start when Tomcat starts. and
> a stack over flow on a processing thread should never affect the
>
Are there any log entries that would indicate that the poller thread has
died?
This/these thread/s start when Tomcat starts. and a stack over flow on a
processing thread should never affect the poller thread.
Filip
On Thu, Jun 26, 2014 at 4:01 PM, Christopher Schultz <
ch...@christopherschultz.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
André,
On 6/26/14, 11:09 AM, André Warnier wrote:
> Lars Engholm Johansen wrote:
>> Thanks for all the replies guys.
>>
>> Have you observed a performance increase by setting
>>> acceptorThreadCount to 4 instead of a lower number? I'm just
>>> curi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Lars,
On 6/26/14, 9:56 AM, Lars Engholm Johansen wrote:
> Thanks for all the replies guys.
>
> Have you observed a performance increase by setting
>> acceptorThreadCount to 4 instead of a lower number? I'm just
>> curious.
>
>
> No, but this was
Lars Engholm Johansen wrote:
Thanks for all the replies guys.
Have you observed a performance increase by setting
acceptorThreadCount to 4 instead of a lower number? I'm just curious.
No, but this was the consensus after elongated discussions in my team. We
have 12 cpu cores - better save th
Thanks for all the replies guys.
Have you observed a performance increase by setting
> acceptorThreadCount to 4 instead of a lower number? I'm just curious.
No, but this was the consensus after elongated discussions in my team. We
have 12 cpu cores - better save than sorry. I know that the offic
"Our sites still functions normally with no cpu spikes during this build up
until around 60,000 connections, but then the server refuses further
connections and a manual Tomcat restart is required."
yes, the connection limit is a 16 bit short count minus some reserved
addresses. So your system sho
Konstantin Kolinko wrote:
2014-06-19 17:10 GMT+04:00 Lars Engholm Johansen :
I will try to force a GC next time I am at the console about to restart a
Tomcat where one of the http-nio-80-ClientPoller-x threads have died and
connection count is exploding.
But I do not see this as a solution - ca
2014-06-19 17:10 GMT+04:00 Lars Engholm Johansen :
> I will try to force a GC next time I am at the console about to restart a
> Tomcat where one of the http-nio-80-ClientPoller-x threads have died and
> connection count is exploding.
>
> But I do not see this as a solution - can you somehow deduct
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Lars,
On 6/16/14, 5:40 AM, Lars Engholm Johansen wrote:
> Our sites can run for days without problems, but once in a while
> the tomcat connection count suddenly starts growing abnormally
> fast. See this graph: http://imgur.com/s4fOUte netstat sho
I will try to force a GC next time I am at the console about to restart a
Tomcat where one of the http-nio-80-ClientPoller-x threads have died and
connection count is exploding.
But I do not see this as a solution - can you somehow deduct why this
thread died from the outcome from a GC?
And could
Lars Engholm Johansen wrote:
Our company are running several Tomcat 7.0.52 high volume Ubuntu 12.04
production servers.
We are using Tomcat WebSockets (JSR356 implementation) heavily with 100M
text messages (100GiB) per day.
We monitor webserver health by measuring several key parameters every
m
Our company are running several Tomcat 7.0.52 high volume Ubuntu 12.04
production servers.
We are using Tomcat WebSockets (JSR356 implementation) heavily with 100M
text messages (100GiB) per day.
We monitor webserver health by measuring several key parameters every
minute, including tomcat connect
20 matches
Mail list logo
