Re: EOF / multithreading app design question
Re: EOF / multithreading app design question
- Subject: Re: EOF / multithreading app design question
- From: Kieran Kelleher <email@hidden>
- Date: Tue, 01 Dec 2009 23:40:48 -0500
hundreds per second, thousands of EOs ..... sounds like a light
load ;-) .... just max out the memory of the app using -Xmx launch
args. for java 1.5 32bit, use 1.5GB. For java 1.6 64bit give the app
8GB if the machine has 10GB ..... max it out. Make the machine scream
at 100% total CPU and using the available memory.
BTW, if you are not actually editing (saving) much EOs, then maybe one
OSC can be shared across threads or maybe a ERXOSC pool.
Also, garbage collection might not be as expeditious as you need it to
be so make a "garbageCollectIfNEcessary" utility that checks for
memory at 95% at the start of each task and forces GC if out of memory
risk exists.
On Dec 1, 2009, at 11:28 PM, Ken Anderson wrote:
We're already processing hundreds of messages per second, leveraging
thousands of EOs... so not really.
On Dec 1, 2009, at 9:48 PM, Andrew Lindesay wrote:
Hi Ken;
I do this sort of thing; feeding in workload via messaging queues
and process it.
If you had a number of instances consuming from the queue rather
than focussing on threading within one instance, I wonder if you
really need to do anything special around EOF concurrency within a
single JVM? In my applications, the batch processing occurs on a
different EOObjectStoreCoordinator to the regular user-processing
and so there is no contention between the two. This seems to work
well for me.
...a single context for all this stuff takes up a few hundred
megabytes already.
Can you not break down the workload (presumably by message) and
create a new EC each time you have to do some work?
cheers.
___
Andrew Lindesay
www.lindesay.co.nz
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden