[RFC] [Plugin] Fixes 100% cpu load

[Andrew Su]

Hi,

----- "Deepak Bhole" <dbhole at redhat.com> wrote:

> From: "Deepak Bhole" <dbhole at redhat.com>
> To: "Andrew Su" <asu at redhat.com>
> Cc: distro-pkg-dev at openjdk.java.net
> Sent: Thursday, September 30, 2010 7:15:55 PM GMT -05:00 US/Canada Eastern
> Subject: Re: [RFC] [Plugin] Fixes 100% cpu load
>
> * Deepak Bhole <dbhole at redhat.com> [2010-09-30 18:55]:
> > * Andrew Su <asu at redhat.com> [2010-09-30 17:57]:
> > > 
> > > ----- "Deepak Bhole" <dbhole at redhat.com> wrote:
> > > 
> > > > From: "Deepak Bhole" <dbhole at redhat.com>
> > > > To: "Andrew Su" <asu at redhat.com>
> > > > Cc: distro-pkg-dev at openjdk.java.net
> > > > Sent: Thursday, September 30, 2010 5:01:44 PM GMT -05:00
> US/Canada Eastern
> > > > Subject: Re: [RFC] [Plugin] Fixes 100% cpu load
--SNIP--

> 
> Doh! So close. Just remembered why it needs to add them to the back
> of
> the queue. It is so that priority messages can be processed while the
> others wait.
> 
> Easy fix though. We would just have to scan the queue to see if there
> are any priority messages, and if so, move them to the front and
> retry
> processing.

Using Deepak's suggestion works out well, since now we can avoid synchronization.
How the message consumer used to work:
1. READ and REMOVE first message in queue.
2. Try and get a free worker to handle message.
 2a. If no free worker, place message at back of queue, then repeat from step 1.
 2b. If there is free worker, proceed.
3. Handle message.
4. Repeat from step 1.

After patch:
1. Scan for priority message.
 1a. If no priority message, READ first message in queue.
 1b. If priority message found, READ the priority message at that index of queue.
2. Try and get a free worker to process the message.
 2a. If there is no free worker, repeat from step 1
 2b. If there is free worker, proceed.
3. Remove the message from which index we got it from. (This is okay, because the queue is not shrinking so the index will not change)
4. Handle message.
5. Repeat from step 1.


Attached is the patch for keeping the messages in order. 
This fixes the issues I brought up about destroy messages taking up the threads by waiting for initialization to finish.

> 
> Deepak
>  
> > This does no solve the problem of the applets 'hanging around in a
> > separate window' until destroy is processed, but I don't imagine
> too
> > many regular users see that case. And even if they do, the applet
> is
> > always guaranteed to be destroyed eventually, ensuring a consistent
> > state.
I was considering, since we are going through the messages, shouldn't we sort it into the following order: Priority, Destroy, Init, Other (are there other?).
That way, we can have the message handler set it to inactive then not process the init we get later.

> > 
> > Cheers,
> > Deepak
Cheers,
--Andrew
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 20101004_keep_message_order.patch
Type: text/x-patch
Size: 1720 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20101004/6b0098f8/20101004_keep_message_order.patch