Re: "Choosing" the WOWorkerThread that executes the request...
Re: "Choosing" the WOWorkerThread that executes the request...
- Subject: Re: "Choosing" the WOWorkerThread that executes the request...
- From: Chuck Hill <email@hidden>
- Date: Wed, 17 Aug 2005 10:14:41 -0700
Hi,
On Aug 16, 2005, at 1:27 AM, Fabrice Pipart wrote:
or to notify that you want to check that the current one is not
actually used by another request?
I think you are misinterpreting what you are seeing. Worker
threads are not reused until they fully complete processing a
request.
Hummmmm... Strange.
When I use Eclipse in Debug mode, I can see a "pool" of threads
ready to handle requests. In my case I have 16 of those.
OK, those are the WOWorkerThreads.
As I explained previously I have two jobs running at the same time
when I start an upload :
two jobs == two requests?
- one that actually does the upload (the response to the request
is only sent when the upload is finished : it is necessary to keep
the InputStream opened)
- one that reloads the page that monitors the progress of the
upload (communication between the two processes is done through the
Session since I did not find any better way).
That is going to block, see below.
That request-response loop is "short" since it only has to update
the progress value.
When I use Firefox as the client browser (the behavior is slightly
different with Safari though I cannot explain why), here is what
happens if I do 1 upload :
- the upload uses one WorkerThread
- the page reloading request-response uses another
- you can still navigate in the app (it uses either a third thread
or the same as the page reloading which does not "block" as the
upload does)
The thread doing the page reloading is only active / in use during
the very short RR loop. It is unlikely that the page reloading will
consistently use the same thread.
Here is what happens if I upload 2 files at the same time
- Upload 1 blocks a WorkerThread during the upload
- Upload 2 blocks another one
- the page reloading of the two upload tries to execute in the
same thread as the second upload.
I very much doubt that this is correct. Try logging the thread name
in Application's dispatchRequest.
I can see this easily since as soon as the second upload is
finished, the page reloading is "unblocked" and occurs 4 times in
that thread (this has been verified by putting breakpoints)
That is not worker thread blocking, that is session blocking. Only
one thread at a time can check a session out from the session store.
The session remains checked out for the entire RR loop. Other
requests that need that session will block and queue until the
session is checked in.
Here is what happens if I do several uploads
- the 3rd or 4th upload is blocked because it tries to do the
upload in a WorkerThread that is already used by the 1st or 2nd
upload...
- the page reloading is also blocked
So, did I miss something to notify clearly that I am using the
WorkerThread for the upload and that no other request should be
sent to that WorkerThread?
You are blocking on session checkout. A WOWorkerThread _never_
services more than one request at a time.
Is there a way to put a page reloading in a seperate thread?
I'm not sure what you mean here.
I mean I would like to use a seperate thread to handle the upload
request, not a WorkerThread.
Not possible. If you can get the page reload to work without
referencing a session that will solve your problem. Or get the
upload to work without referencing a session.
Quick description of why I ask such a question:
when you want to upload a file in my application, two portions of
code begin to run concurrently :
- one to manage the upload itself
- an other to refresh the progress bar
Is this from Jonathan Rochkind's code on www.wocode.com?
I tried that one and I based a part of my code on his. But it is
totally new and simpler code. His solution blocked the user, he
could not navigate in the app while uploading and therefore could
not do several uploads at the same time. I was not satisfied with
this.
I think you may be trying to do the impossible.
But currently I have a nasty problem : the refreshing of the
progress page uses the same WorkerThread as the upload... though
many other thread are "free"
Not seeing the code, I'm not sure what you are seeing here. They
should not be using the same worker thread. If both are referring
to the session then WO will block on the second request to check
out the session. If both are referring to the same editing
context, your code will also block there.
In fact, my code is not yet used when it blocks. It seems that the
request is sent to the used WorkerThread and executed as soon as it
is freed.
Actually, it is dispatched and then blocks when the request handler
attempts to checkout the session.
So I guess I am not puting any lock on the session or the editing
context since it is not executing "my" code.
You aren't, but the WO framework is.
The page reloading is simply a WOLongResponse page with nothing
else but Thread.sleep() in its performAction and a lastStatus
method that gets the progress from the user session. The
performAction is executed in a seperate thread (not a WorkerThread)
and if I put a breakpoint at the first line of lastStatus, it is
only hit when the WorkerThread is freed.
Do you want me to post the code somewhere?
No, I am rather busy at the moment.
Chuck
Does that get you any closer to understanding what is going wrong?
Unfortunately, not really :(
The only difference I see is the way the request is initiated.
Here is the workflow (everything has a reason to be like this) :
- the user is in the main page
- he clicks a button to start an upload -> a popup is opened with
two frames : one with the upload form (choose file...) and one
dedicated to the progress bar
- when he submits the upload form, that frame is blocked by the
upload (normal submit) and the progress bar reloading starts
(Javascript to do this in the other frame)
- he can still navigate in the main page
Does that give you an idea of anything I do wrong?
Thanks a lot !
Fabrice
Chuck
--
Practical WebObjects - a book for intermediate WebObjects
developers who want to increase their overall knowledge of
WebObjects, or those who are trying to solve specific application
development problems.
http://www.global-village.net/products/practical_webobjects
www.icconsulting.mc
International Corporate Consulting
25, Boulevard de Belgique
MC - 98000 Monaco
T. +377 97982104 (direct)
F. +377 97708807
--
Practical WebObjects - a book for intermediate WebObjects developers
who want to increase their overall knowledge of WebObjects, or those
who are trying to solve specific application development problems.
http://www.global-village.net/products/practical_webobjects
_______________________________________________
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