Also for XFire Clients (as of latest release) it will be able handle up to 6
concurrent connections to the SAME web service, no more. Check that out
because it will prevent you from reaching maximum throughput (although, this
is deffinetly NOT the cause of the CPU hog). You can change that value if
required through configuration.
On 11/29/06, Paul Brown <[EMAIL PROTECTED]> wrote:
> So I am implementing a search service that needs to be highly scaleable
> behind an xfireservlet. The search service is a number of threads
pulling
> queries off of a queue, searching an index and passing the results back
to a
> hash for the webservice that called the search to access and return to
the
> client.
The issue lies in the way that you're polling those queues. Is
"queue" a java.util.concurrent queue? A JMS queue? In the j.u.c
context, if you do something like this:
while (true) {
Object foo = queue.poll();
if (foo != null) process(foo);
}
You will absolutely peg the CPU. You need to introduce some delays
into your polling passes, e.g.:
queue.poll(50L, TimeUnit.MILLISECONDS)
And that should take the load off of the CPU.
-- Paul
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
