Weblogic performance issue ?

classic Classic list List threaded Threaded
3 messages Options
omerlin omerlin
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Weblogic performance issue ?

Hello,
I'm wondering if we not having an issue with jolokia 1.3.3 on Weblogic.
We have a python client that get important counters (Jdbc, JMS, threading, work manager) on all the managed every 30 minutes. These counters are sent to a graphite TSDB.
The counters are got with single JSON request using the nice batching capabilities of Jolokia.

But without activity we observes a strange statistics on the Weblogic Applications Monitoring tab of Weblogic.
We have more than 100K sessions in the "Current Sessions" and 7721 in the "Maximum Sessions on Any Servers" statistics ....
What is causing me trouble is the statistic "Current Sessions" ... i have done some  stack trace and regularly i see the Jolokia in action:

"[ACTIVE] ExecuteThread: '30' for queue: 'weblogic.kernel.Default (self-tuning)'" daemon prio=3 tid=0x000000010793e000 nid=0x1aa runnable [0xffffffff0e2fb000]
   java.lang.Thread.State: RUNNABLE
        at java.util.Hashtable.putAll(Hashtable.java:586)
        - locked <0x000000077a8236f0> (a java.util.Hashtable)
        at java.util.Hashtable.<init>(Hashtable.java:297)
        at javax.management.ObjectName.getKeyPropertyList(ObjectName.java:1624)
        at com.sun.jmx.mbeanserver.Repository$ObjectNamePattern.matchKeys(Repository.java:177)
        at com.sun.jmx.mbeanserver.Repository.addAllMatching(Repository.java:233)
        - locked <0x0000000414a20558> (a java.util.HashMap)
        at com.sun.jmx.mbeanserver.Repository.query(Repository.java:569)
        at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.queryNamesImpl(DefaultMBeanServerInterceptor.java:562)
        at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.queryNames(DefaultMBeanServerInterceptor.java:554)
        at com.sun.jmx.mbeanserver.JmxMBeanServer.queryNames(JmxMBeanServer.java:619)
        at weblogic.management.jmx.mbeanserver.WLSMBeanServerInterceptorBase$9.run(WLSMBeanServerInterceptorBase.java:273)
        at java.security.AccessController.doPrivileged(Native Method)
        at weblogic.management.jmx.mbeanserver.WLSMBeanServerInterceptorBase.queryNames(WLSMBeanServerInterceptorBase.java:271)
        at weblogic.management.jmx.mbeanserver.WLSMBeanServerInterceptorBase$9.run(WLSMBeanServerInterceptorBase.java:273)
        at java.security.AccessController.doPrivileged(Native Method)
        at weblogic.management.jmx.mbeanserver.WLSMBeanServerInterceptorBase.queryNames(WLSMBeanServerInterceptorBase.java:271)
        at weblogic.management.jmx.mbeanserver.WLSMBeanServer.queryNames(WLSMBeanServer.java:247)
        at org.jolokia.backend.executor.AbstractMBeanServerExecutor.queryNames(AbstractMBeanServerExecutor.java:113)
        at org.jolokia.handler.ReadHandler.searchMBeans(ReadHandler.java:158)
        at org.jolokia.handler.ReadHandler.fetchAttributesForMBeanPattern(ReadHandler.java:126)
        at org.jolokia.handler.ReadHandler.doHandleRequest(ReadHandler.java:116)
        at org.jolokia.handler.ReadHandler.doHandleRequest(ReadHandler.java:37)
        at org.jolokia.handler.JsonRequestHandler.handleRequest(JsonRequestHandler.java:161)
        at org.jolokia.backend.MBeanServerHandler.dispatchRequest(MBeanServerHandler.java:154)
        at org.jolokia.backend.LocalRequestDispatcher.dispatchRequest(LocalRequestDispatcher.java:99)
        at org.jolokia.backend.BackendManager.callRequestDispatcher(BackendManager.java:413)
        at org.jolokia.backend.BackendManager.handleRequest(BackendManager.java:158)
        at org.jolokia.http.HttpRequestHandler.executeRequest(HttpRequestHandler.java:197)
        at org.jolokia.http.HttpRequestHandler.handlePostRequest(HttpRequestHandler.java:131)
        at org.jolokia.http.AgentServlet$3.handleRequest(AgentServlet.java:401)
        at org.jolokia.http.AgentServlet.handleSecurely(AgentServlet.java:290)
        at org.jolokia.http.AgentServlet.handle(AgentServlet.java:261)
        at org.jolokia.http.AgentServlet.doPost(AgentServlet.java:228)



Is it really an issue ? i have a concern of a sort of leakage issue ...
Could it be more a statistics issue or a way jolokia is registerd with Weblogic ?

If anyone has a jolokia deployed on Weblogic could have a look on is envitronement and see if he has a similar behavior ... it would be interesting.
Meanwhile i will see to put a weblogic work manager on the jolokia.war to be sure to have a controlled resources ...

Any help is welcome
cheers,
Olivier


omerlin omerlin
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Weblogic performance issue ?

Hello,

Sorry, i don't mean every 30minutes but every 30 seconds.

cheers,
Olivier
roland roland
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Weblogic performance issue ?

In reply to this post by omerlin
That you will see Jolokia in the stacktrace from time to time is expected when you query every 30seconds. However with Weblogic you should be careful with wildcard queries as it can be quite expensive due to the large amount of data available for Weblogic.

w.r.t to the session count: This should be for sure 0 since Jolokia doesn't use any session at all (its completely stateless w.r.t to client state). So the number you should see should be always 0. Unfortunately the only way an application can indicate that it doesnt use a session is by not requesting one. An application server can still allocate a session for a webapp. Its an app server dependent configuration how to disable this for a particular app. Unfortunately I dont know weblogic well enough to tell you where to can tune this in the server configuration. But it shouldnt be hard to find.
... roland
Loading...