Re: [wro4j] Memory leak

[Alex Objelean]

I'll open an issue and will try to fix it for the next release. It would help if you could provide as many details as possible to make it easier to reproduce the problem.

Btw, the latest version is 1.7.7.

Thanks,
Alex

On 9 Nov 2014 15:57, "Itamar Cohen" <itc...@gmail.com> wrote:

Hi,

We are using Wro4j v1.7.5 on our tomcat web server.

After running long webload job (100 requests per minute) and examine the heap dump,

we have found that the CONTEXT_MAP hash map in ro.isdc.wro.config.Context

is getting bigger and bigger and after a week it became 2.5GB! 

I attached 3 screenshots of the heap dump size (taken with "mat").

The first screen is after 2 hours load - the size is 16MB

The second screen is after 12 hours- size is 225MB.

The third screen is after a week load - size is 2.5GB.

Have anyone raise this issue before?

Any help will gratefully received.

Regards,

Itamar Cohen

Some additional details:

We have implemented CacheKeyFactory & WroModelFactory interfaces

{Server details: tomcat 7.0.53, Spring 3.2, struts}

--
You received this message because you are subscribed to the Google Groups "wro4j" group.
To unsubscribe from this group and stop receiving emails from it, send an email to wro4j+un...@googlegroups.com.
To post to this group, send email to wr...@googlegroups.com.
Visit this group at http://groups.google.com/group/wro4j.
For more options, visit https://groups.google.com/d/optout.

[Itamar Cohen]

Additional Details:

We implemented WroModelFactory, to achieve dynamic model.

I attached relevant files to this post.

I attached the impl classes to the msg.

This is our wro.properties content:

cacheUpdatePeriod=0

modelUpdatePeriod=0

debug=true

disableCache=false

gzipResources=false

ignoreMissingResources=true

ignoreFailingProcessor=true

jmxEnabled=false

managerFactoryClassName=com.exlibris.primo.customWro.PrimoWroManagerFactory

#Custom defined in PrimoWroManagerFactory

#preProcessors=cssImport,semicolonAppender,cssMin

[Alex Objelean]

Hi, 

thanks for providing the attachment. 

Normally, there should be no leak of the Context object, which is cleaned up in 'finally' block in the filter. Unfortunately I cannot see the entire flow of your customized configuration. I would suggest trying to count the number of times the context is created and the number of time it is being unset. If the unset is called less than set, then there is something weird which is probably related to your custom implementation. I wasn't able to reproduce the leak using standard approach (when WroFilter is used as it is documented in getting started). 

If you have any updates regarding your investigation, please let me know.

Thanks,

Alex

[Itamar Cohen]

Hi Alex,

After lot of investigations we managed to determined that the leak origin is not the Wro4j component.

I appreciate your help in this issue.

And thank again for this great tool!

Itamar

[Alex Objelean]

You are welcome.

I'm glad you have figured it out.

Cheers,

Alex

[cvetelin...@gmail.com]

Hi there,

-M

I'm experiencing the same problem. After couple of hours working the CONTEXT_MAP becomes 1 gb and contains about 1 million entries. What could be the cause for this?

@Itamar Cohen  What was your problem caused by?

Thanks!

[Itamar Cohen]

Hi,

We haven't figure out what was the root cause, we just manage to bypass it.

This was part of our Tomcat filter-mapping.xml file:

<filter-mapping>

<filter-name>WroContextFilter</filter-name>

<url-pattern>/*</url-pattern>

</filter-mapping>

<filter-mapping>

<filter-name>WebResourceOptimizer</filter-name>

<url-pattern>/wro/*</url-pattern>

</filter-mapping>

We removed the WroContextFilter filter, which we found unnecessary, and the problem disappeared.

PS

Sorry for the late response (the guy who actually handled it is just back from vacation).

[Cvetelin Andreev]

Hi Itamar,

Thanks for the answer.

Actually the WroContextFilter also makes a call to Context.set() which fills the CONTEXT_MAP hashmap so removing it could solve the problem. I think I have a siilar problem. Still investigating. The current workaround i made was simple call Context.destroy() when the user logs out. The method empties the hashmap and frees the memory.

Cvetelin Andreev
+359 889 651 656

http://blog.flowerlin.net