//
I think if you have vendor-locked app in vendor-locked environment (am I
right?)
//
Yes indeed.
//
As I said above, there is an options for JVM:
-XX:-HeapDumpOnOutOfMemoryError - it will make heapdump on OOM.
-XX:HeapDumpPath=./java_pid.hprof - give it an reasonable path to file.
Set this o
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Baron,
On 3/20/15 4:27 PM, Baron Fujimoto wrote:
> I hope someone may be able to provide some insight or a solution to
> a problem we encountered after I upgraded from Tomcat 6 to 8. We're
> using Tomcat as the servlet container for our Shibboleth I
2015-03-20 22:29 GMT+02:00 Eric Robinson :
>> Very good information. I much prefer finding the actual root causes of
>> things rather than just bumping the memory, but I'm not sure how much that
>> would help because the best I can do is report the issue to the vendor.
>> Changing the code is of
//
Mostly leaner - a 32-bit JVM uses 32-bit pointers, so object references consume
less heap and stack space. Whether or not the code runs faster or slower
depends on what you're doing, since the tradeoff is fewer registers available
in 32-bit mode, which can lead to more register spills and re
//
You can look for biggest objects in heap (using MAT, Leak Suspects report,
Dominators Tree report).
This way you can try to find what was the exact reason of OOM instead of just
thinking "eh, I need to give instances more memory".
MAT does things good. I've already found using MAT+JVVM the rea
I hope someone may be able to provide some insight or a solution to a
problem we encountered after I upgraded from Tomcat 6 to 8. We're using
Tomcat as the servlet container for our Shibboleth IdP SSO, which we use
to authenticate to Google Apps. Google allows you to configure a URL used
for logout
> From: Eric Robinson [mailto:eric.robin...@psmnv.com]
> Subject: RE: Java Heap Space / Thread Dump Numbers
> > If you have the option, you might want to run a 32-bit JVM; it will
> > probably run leaner
> > and faster than a 64-bit JVM will.
> What do you mean my faster and leaner?
Mostly le
2015-03-20 22:09 GMT+02:00 Eric Robinson :
>> I've posted above some howtos, have you looked at them?
> No, I'm not sure how useful I would find them. I think the heap summary is
> probably all I need, but I may be wrong. Would the heap dump provide more
> actionable intel as far as tuning my me
> From: Eric Robinson [mailto:eric.robin...@psmnv.com]
> Subject: RE: Java Heap Space / Thread Dump Numbers
> Would the heap dump provide more actionable intel as far as tuning my memory
> parameters?
It would provide information about what types of objects are consuming the heap
space. From
//
Recent 64-bit JVMs will automatically use "-XX:+UseCompressedOops".
I'm not sure about your version, specifically. If you have the option, you
might want to run a 32-bit JVM; it will probably run leaner and faster than a
64-bit JVM will.
//
Interesting. What do you mean my faster and leaner?
//
Yeah, heapdumps.
I've posted above some howtos, have you looked at them?
//
No, I'm not sure how useful I would find them. I think the heap summary is
probably all I need, but I may be wrong. Would the heap dump provide more
actionable intel as far as tuning my memory parameters?
--Eric
2015-03-20 1:15 GMT+02:00 Eric Robinson :
> Heap dumps?
> What we do is called a thread dump, as far as I know. We use kill -3 on
> Linux, which dumps the thread activity. The memory data shows up at the
> bottom of that. See:
> http://producthelp.sdl.com/WorldServer/10.2/en/GUID-4F09CD10-BC4F-4
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
James,
On 3/20/15 12:12 PM, James Nord wrote:
> We have a webapp that when run with tomcat (7.0.52) on a certain
> host after a period of time has issues with chunking.
>
> The issue is that the terminating Zero length chunk is not sent by
> tomca
Hello Chris,
As of today I figured out that the jasper.jar in Tomcat's \lib takes care
of the task out of the box. I've tweaked my pom a few times, but I started
fresh today and realized it. So no pom updates were necessary. Still I'm
getting this exception I mentioned in the earlier e-mail:
Caus
Hi all,
We have a webapp that when run with tomcat (7.0.52) on a certain host
after a period of time has issues with chunking.
The issue is that the terminating Zero length chunk is not sent by
tomcat even though looking at the last chunk the data is complete.
Whilst at first glance this wo
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Neill,
On 3/20/15 4:58 AM, Neill Lima wrote:
> I have a existing WebApp that I'm planning to upgrade to Tomcat8
> (version 8.0.20 as of today). It is running stable in Tomcat7
> already for ages.
Great.
> Tomcat8 does not embed the JasperListener
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Eric,
On 3/19/15 7:15 PM, Eric Robinson wrote:
> Christopher Shultz wrote: // Time to upgrade. Tomcat is hideously
> out of date (probably because you are using RedHat's Tomcat
> package), at least by version number. I'm not sure what RedHat
> doe
Hello list,
I'm not sure if this the right place to ask, but here it goes...
I have a existing WebApp that I'm planning to upgrade to Tomcat8 (version
8.0.20 as of today). It is running stable in Tomcat7 already for ages.
Tomcat8 does not embed the JasperListener so I added it manually to my
pom
Hi,
>
> Hi Chris,
>
> Thanks a lot for the quick response. Please find inline answers.
>
> On 3/18/15 5:39 AM, Thusitha Thilina Dayaratne wrote:
> >> I'm in the process of migrating embedded tomcat 7.0.59 application
> >> to Tomcat 8.0.20. Tomcat is been bundle as a OSGI bundle. First I
> >> get a
19 matches
Mail list logo
