L.S., Could you provide us with a thread dump taken at the moment where things have almost stalled down? I would expect the ESB to slow down a bit for pure lock contention, but it stalls compeletely that sounds more like there's some kind of underlying locking problem (like a deadlock or a lock that's being kept far too long).
Regards, Gert Vanthienen ------------------------ Open Source SOA: http://fusesource.com Blog: http://gertvanthienen.blogspot.com/ On 26 February 2010 07:00, Eighty8 <[email protected]> wrote: > > Thanks for all of your feedback. When I did this, simply more thread > contention was revealed. > I could really use some estimate of throughput estimate/sizing estimate for > a ESB-cluster. I'm finding that under increasing load there is an > increasing and then catastrophic amount of waiting on the huge number of > synchronize API calls that make up packages like eip ( we use for content > enriching ). > > I know sizing is an art as well as a science and is application dependent. > For the most part we were hoping to process roughly 5,000 request an hour > with 3 ESB's. Seem that under my load evaluations, this won't happen, as > using Yourkit profiling, we see dramatic amount of threads blocked on > synchronized calls and the throughput of requests decreases as threads stall > and the it all stops. > Sorry for going on and on, any sizing estimates would be welcomed. > > > Claus Ibsen-2 wrote: >> >> On Thu, Feb 25, 2010 at 9:14 PM, Guillaume Nodet <[email protected]> wrote: >>> No, nobody cares what the UID is as long as it is unique. >>> Feel free to raise a JIRA and attach a patch. >>> Also some simple performance metrics would be good to make sure >>> the new generator is not awfully slow ;-) >>> >> >> Look at the UID generated in Camel as we recently adjusted it to >> accommodate running in GAE. >> AFAIR its also using the UUID from JDK now. >> >> Its located in the util package in Camel. >> >> >>> On Thu, Feb 25, 2010 at 18:28, Eighty8 <[email protected]> wrote: >>>> >>>> If I replace the IdGenerator class with a version that has the >>>> GenerateId >>>> method NOT synchronized ( and the implementation just calling >>>> java.util.UUID >>>> instead of using a sequence, will the runtime calls all start failing >>>> because the whole application wasn't compiled against that class? >>>> >>>> I wasn't sure if the 'synchronized' was just a runtime execution >>>> modifier or >>>> a compile-time modifier. >>>> Any thoughts? >>>> >>>> I'm thinking to do this because I'm seeing eip block/deadlocking on >>>> GenerateId call when high numbers of threads are active. >>>> -- >>>> View this message in context: >>>> http://old.nabble.com/Replacing-IdGenerator-class-tp27714487p27714487.html >>>> Sent from the ServiceMix - User mailing list archive at Nabble.com. >>>> >>>> >>> >>> >>> >>> -- >>> Cheers, >>> Guillaume Nodet >>> ------------------------ >>> Blog: http://gnodet.blogspot.com/ >>> ------------------------ >>> Open Source SOA >>> http://fusesource.com >>> >> >> >> >> -- >> Claus Ibsen >> Apache Camel Committer >> >> Author of Camel in Action: http://www.manning.com/ibsen/ >> Open Source Integration: http://fusesource.com >> Blog: http://davsclaus.blogspot.com/ >> Twitter: http://twitter.com/davsclaus >> >> > > -- > View this message in context: > http://old.nabble.com/Replacing-IdGenerator-class-tp27714487p27714858.html > Sent from the ServiceMix - User mailing list archive at Nabble.com. > >
