high cpu utilization problems

[Rajendra Upa]

currently , we are using older version of Ofbiz( 2 year old) . we have been facing high cpu utilization production servers atleast twice in the month. When we took the system thread dump to find out which thread is consuming more of cpu (more than 90%) , following is the thread dump of thread :
"http-0.0.0.0-8080-Processor12" daemon prio=1 tid=0x37110468 nid=0x7761 waiting for monitor entry [0x36cf6000..0x36cf6f30]
        at org.ofbiz.entity.GenericEntity.setFields(GenericEntity.java)
        - waiting to lock <0x5f3c32e0> (a org.ofbiz.entity.GenericValue)
       
In most of the high cpu utilization incidents , we used to get above thread with similar trace. We have verified in our application code base logic if any infinite loop or anything else could be responsible for high cpu usage but did not found anything.
We found that setFields() method of GenericEntity.java is synchronized . setFields() method internally invokes set() which again synchronized one. But in the upgraded version of ofbiz , synchronized modifier has been removed from setField() method .
I have following queries :
(a) is high cpu utilization problem because of back to back synchronized method (setFields() and set()) ?
(b) what is/are the reason(s) removing synchronized modifier from setField() method in GenericEntity.java ?
(c) is there ant one having similar issue or came across ?

waiting for reply.

[David E Jones]

The synchronized was removed because of redundancy, so it wasn't necessary, and because of that redundancy there was a
greater chance of deadlock. I couldn't say based on this info if it is the cause of the deadlock you are seeing. BTW,
using Fisheye or just an SVN client you can look at the revision history and find comments about these sorts of code
changes.

Sometimes deadlocks can cause your CPU to get really busy, and will certainly eat up memory and threads and are
generally things that need to be fixed.

Are you using the release4.0 branch? If so then it might be good to report a bug for that. If not, you should consider
either sticking to the trunk to get bug fixes, or participate in the release branch to use the more stabilized (but less
  feature rich) code base.

-David


Rajendra Upa wrote:

> currently , we are using older version of Ofbiz( 2 year old) . we have been
> facing high cpu utilization production servers atleast twice in the month.
> When we took the system thread dump to find out which thread is consuming
> more of cpu (more than 90%) , following is the thread dump of thread :
> "http-0.0.0.0-8080-Processor12" daemon prio=1 tid=0x37110468 nid=0x7761
> waiting for monitor entry [0x36cf6000..0x36cf6f30]
> at org.ofbiz.entity.GenericEntity.setFields(GenericEntity.java)
> - waiting to lock <0x5f3c32e0> (a org.ofbiz.entity.GenericValue)
>
> In most of the high cpu utilization incidents , we used to get above thread
> with similar trace. We have verified in our application code base logic if
> any infinite loop or anything else could be responsible for high cpu usage
> but did not found anything.
> We found that setFields() method of GenericEntity.java is synchronized .
> setFields() method internally invokes set() which again synchronized one.
> But in the upgraded version of ofbiz , synchronized modifier has been
> removed from setField() method .
> I have following queries :
> (a) is high cpu utilization problem because of back to back synchronized
> method (setFields() and set()) ?
> (b) what is/are the reason(s) removing synchronized modifier from setField()
> method in GenericEntity.java ?
> (c) is there ant one having similar issue or came across ?
>
> waiting for reply.
>