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.
