[Building Sakai] high cpu with a Image Animator thread

[Matthew Jones]

No, there was no jira, nobody ever found a cause.

The only two tools in Sakai that use java.awt.* are Sitestats and Profile2.
The only thing that this stack tells us are that it involves gif images and
it's ends up inside a Native Method, which means it's outside java and into
an operating system call. So it could be a lot of possible things wrong,
possibly not even involving any code in Sakai, since I've never seen it
anywhere else.

Chuck Hedrick did mention it on the list back in 2011 (As Zhen mentioned)
but that was about it.
http://collab.sakaiproject.org/pipermail/sakai-dev/2011-April/011890.html

Not sure the similarties there? It could even be in a library like POI
(which are often upgraded release to release), but you'd still have
expected someone else to see this in production?

You're on the latest JDK 7 right? It looks like there were some changes to
better image handling in this library in JDK7
http://hg.openjdk.java.net/jdk7u/jdk7u/jdk/log/828c4fedd29f/src/share/native/sun/awt/image/awt_parseImage.c

And further changes coming up for JDK8
http://hg.openjdk.java.net/jdk8/jdk8/jdk/log/687fd7c7986d/src/share/native/sun/awt/image/awt_parseImage.c

Which might improve, or make this go away, at least from what it was in
2011.


On Thu, Sep 4, 2014 at 5:43 PM, Steve Swinsburg <steve.swinsburg at gmail.com>
wrote:

> Hi Zhen,
>
> Where was it reported, is there a Jira?
>
> cheers
> Steve
>
>
> On Fri, Sep 5, 2014 at 5:50 AM, Zhen Qian <zqian at umich.edu> wrote:
>
>> Hi, all:
>>
>> One of our prod server shows high CPU and we traced down to an Image
>> Animator thread. Here is one stack trace:
>>
>> 2014-09-01 17:51:02
>> Full thread dump Java HotSpot(TM) 64-Bit Server VM (24.65-b04 mixed mode):
>> ...
>>
>> "Image Animator 3" daemon prio=10 tid=0x00007fd728174000 nid=0x2328
>> runnable [0x00007fd6f9528000]
>>    java.lang.Thread.State: RUNNABLE
>> at sun.awt.image.GifImageDecoder.parseImage(Native Method)
>> at sun.awt.image.GifImageDecoder.readImage(GifImageDecoder.java:596)
>>  at sun.awt.image.GifImageDecoder.produceImage(GifImageDecoder.java:212)
>> at sun.awt.image
>> .InputStreamImageSource.doFetch(InputStreamImageSource.java:269)
>>  at sun.awt.image.ImageFetcher.fetchloop(ImageFetcher.java:205)
>> at sun.awt.image.ImageFetcher.run(ImageFetcher.java:169)
>>
>> Meanwhile, there is no impact on database usage or end-user response
>> time.
>>
>> This problem has been originally reported by Rutgers in Sakai back in
>> 2011. It still occurs with our current system based on 2.9.2. Anyone else
>> ever seen this?
>>
>> Thanks,
>> - Zhen
>>
>>
>> _______________________________________________
>> sakai-dev mailing list
>> sakai-dev at collab.sakaiproject.org
>> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>>
>> TO UNSUBSCRIBE: send email to
>> sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of
>> "unsubscribe"
>>
>
>
> _______________________________________________
> sakai-dev mailing list
> sakai-dev at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>
> TO UNSUBSCRIBE: send email to
> sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of
> "unsubscribe"
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20140904/35f56db6/attachment.html