As an experimentation, I started Tomcat with
“-Dorg.apache.tomcat.util.net.NioSelectorShared=false”, and
“selectorPool.maxSelectors” set to 1000, the same as the number of threads.
This problem didn’t happen with that setting. Even with
“selectorPool.maxSelectors” set to 1, it was noticeably sl
> On 31 Aug 2017, at 17:55, Christopher Schultz
> wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Andrea,
>
> On 8/30/17 4:13 PM, Ing. Andrea Vettori wrote:
>>> On 30 Aug 2017, at 00:16, Christopher Schultz
>>> wrote: RMI is known for flagrantly
>>> wasting permgen/metaspace
Hi Chris,
Thanks for the quick response.
Yes, the clients were being throttled. These throttled requests were slow to
start with and there was no noticeable difference in the download speed when
the problem occurred. The smaller download started out OK. But after 10-15
successful serial reques
Hi,
A change in 7.0.81/7.0.80 changed the File resolution in VirtualDirContext.
In 7.0.79 and before it was possible to use paths with /../ or any other
non-canonical path. This was particularly useful when using placeholders
that are being replaced at compile time like
extraResourcePaths="/
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Andrea,
On 8/30/17 4:13 PM, Ing. Andrea Vettori wrote:
>> On 30 Aug 2017, at 00:16, Christopher Schultz
>> wrote: RMI is known for flagrantly
>> wasting permgen/metaspace because of all the Proxy objects and
>> special throw-away Class objects it u
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Thuc,
On 8/31/17 11:25 AM, Thuc Nguyen wrote:
> We run JFrog Artifactory which is fronted by Tomcat 8.0.32. We
> recently upgraded from Tomcat 7.0.56. Since the upgrade,
> Artifactory occasionally slows to a crawl.
Any chance of using the latest To
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Mark,
On 8/30/17 5:03 PM, Mark Thomas wrote:
> On 30/08/17 21:46, Dan Rabe wrote:
>> I’m using Tomcat 8.5.20, trying to use the rewrite valve to
>> rewrite a root-level URL (/foo) to a URL in my webapp
>> (/mywebapp/bar).
>>
>> I added the rewrite
Hi,
We run JFrog Artifactory which is fronted by Tomcat 8.0.32. We recently
upgraded from Tomcat 7.0.56. Since the upgrade, Artifactory occasionally slows
to a crawl.
We could reproduce this problem by downloading a large (1GB) file concurrently
from 500 different machines. However, to avoid e
> On 29 Aug 2017, at 14:24, Mark Thomas wrote:
>
> On 29/08/17 13:09, Ing. Andrea Vettori wrote:
>>> On 29 Aug 2017, at 12:29, Suvendu Sekhar Mondal wrote:
>>>
>>> On Tue, Aug 29, 2017 at 2:54 PM, Ing. Andrea Vettori
>>> wrote:
- with a fresh started tomcat instance, the time it takes is
> On 31 Aug 2017, at 15:24, Suvendu Sekhar Mondal wrote:
>
> I will suggest that if you have some budget, please get a decent APM
> like AppDynamics, New Relic, Dynatrace to monitor your prod system
> 24x7x365. Trust me, you will be able to identify and solve this type
> of sporadic slowness issu
Andrea,
>> Sometimes Full GC were able to clean up some space from Metaspace but
>> only as part of a final last ditch collection effort:
>>
>> 43618.504: [Full GC (Last ditch collection) 1386M->250M(20G), 1.6455823
>> secs]
>> [Eden: 0.0B(6408.0M)->0.0B(6408.0M) Survivors: 0.0B->0.0B Heap:
>>
11 matches
Mail list logo
