we should just invert it yes first check for isResource() || isStatic()
and if that returns false then do something else
The problem is that in the end we do this:
else
{
int rtn = doParseRequest();
if (rtn == PARSE_REQUEST_RETURNING_PAGE)
{
return true;
}
xxxxxx
where do we do that now? I haven't used it yet but that is i think user parsed request.
Where does that belong?
johan
On 11/24/05,
Igor Vaynberg <[EMAIL PROTECTED]> wrote:
boolean parsed = false;
synchronize()
should be
boolean parsed = false;
synchronized(session)
right?
then we are back to the same problem. it will wait for session to be come available until it can parse the request.
we need to somehow check if the url being requested is a resource before we sync on session
something like this in pseudo
boolean requestForResource=isRequsetForResource(url);
if (requestForResource) {
handle resource
} else {
synchronize(session) { parse(); respond(); }
}
this can also open a can of worms for dynamic resources that use the session because that access will need to be made threadsafe by the user.
-Igor
On 11/24/05, Johan Compagner <[EMAIL PROTECTED] > wrote:I don't see it as a bug, but more not the best behaviour..
The problem is getting rid of that sync block at that level
because parseRequest() and response have to be in one synch block because in parseRequest the callComponentListener is called..
if (parseRequest())
{
// respond with a page
respond();
}
but in parseRequest() we do the resourceReference() and the staticContent()
I think we have remove those.things from there so this part:
else if (resourceReference() || staticContent())
{
// if it is, we don't need to update the cluster, etc, and return
// false
}
else
{
int rtn = doParseRequest();
if (rtn == PARSE_REQUEST_RETURNING_PAGE)
{
return true;
}
xxxxxx
and then in RequestCycle.request() have something like this:
boolean parsed = false;
synchronize()
{
parsed = parseRequest()
if (parsed)
{
// respond with a page
respond();
}
}
if(!parsed)
{
callResourceHandlingPartPreviouslyinParseRquest()
}
then we only have to look if the try/catch/finally block in RequestCycle() must be different
this:
// Attach thread local resources for request
threadAttach();
// Response is beginning
internalOnBeginRequest();
onBeginRequest();
doesn't care if it isn't synched.
But this part:
catch (RuntimeException e)
{
// Handle any runtime exception
internalOnRuntimeException(null, e);
}
finally
{
// make sure the invokerPage is ended correctly.
try
{
if (invokePage != null)
{
invokePage.internalEndRequest();
}
}
catch (RuntimeException e)
{
log.error("Exception occurred during invokerPage.internalEndRequest", e);
}
should be in the synch block.
the rest (threadDetach() doesn't have to be)
johan
On 11/24/05, Igor Vaynberg < [EMAIL PROTECTED]> wrote:thats the whole point. the request to retrieve the status would come from another request thread, maybe an iframe with a meta refresh tag or something. why wouldnt this be advisable? http is a multithreaded protocol, as long as the operation of retrieving a resource does not touch any objects in an unthreadsafe manner it should be fine. like retrieving a package resource, why should threads like that block? for pages we need to synchronize on the session because we save the users a lot of headaches by allowing them not to worry about thread safety.
resources are a different matter. imagine a page with a component that renders twenty package resources that are images. we dont want the browser to only be able to retrieve them one by one, its a performance bottleneck which will lead to much longer page loading times. and no, resource caching is not a solution that will fix performance.
however, seems like that is exactly what is happening currently. wicketservlet.doget() calls requestcycle.request() and the first thing that does is synchronize on the session before it knows if the request is for a resource or for a page. to me this looks like a major bug. what do others think?
-IgorOn 11/23/05, Nick Heudecker < [EMAIL PROTECTED]> wrote:I don't see how the upload wouldn't block the request thread. You'd need to have another thread running to return the status to the user, and I'm not sure that possible, or even advisable.On 11/24/05, Andrew Lombardi <[EMAIL PROTECTED]> wrote:johan,ok, i've attempted that, and ran into the same blocking-type behaviour. I've added the following to the init() of my Application:DynamicByteArrayResource dbar = new DynamicByteArrayResource() {protected byte[] getData() {if(RequestCycle.get()!=null) {ProgressSession sess = (ProgressSession) RequestCycle.get().getSession();if(sess!=null) {int count = sess.getCount();String countStatus = "count: "+count;return countStatus.getBytes();}}return "".getBytes();}public String getContentType() {return "text/html";}};Application.get().getSharedResources().add("statusResource", dbar);ProgressSession being a Session implementation holding property count.And then in a Page component, I've grabbed a ResourceReference and printed out the accessor url with this:ResourceReference ref = new ResourceReference( "statusResource");String url = "">System.out.println("url:"+url);And the resource gets pulled up fine without the upload occuring at the same time. but once the upload occurs, it seems to exhibit a blocking behaviour.any ideas? it shouldn't behave this way right? i'm using 1.1 final.-kinOn Nov 23, 2005, at 3:02 PM, Johan Compagner wrote:just an idea.
The progress bar thread could be a SharedResource request.
Those request are not synchonized.
And you can give back the progress number everytime the Resource is requested.
johanOn 11/23/05, Andrew Lombardi < [EMAIL PROTECTED]> wrote:I've got a need to show an Upload progress bar in a Wicket app that
I've built. We're uploading some fairly large files and would like
to see some statuses. Figured out with Igor how to go about
injecting a CountingInputStream into the process for FileUpload, but
have run into a roadblock!
What ends up happening, is the page runs a _javascript_, to show
another page that meta refreshes and shows a status grabbed from the
session. And at the same time submits the form to start the upload.
Only problem is, it seems to block on the form submission uploading
the file, and never shows the status page until after its done
processing the form. Obviously too late.
Igor mentioned that this was probably because Wicket synchronizes
with the session. And we both think there must be a way around this
that is missing.
the code I have overrides:
protected WebRequest newWebRequest(HttpServletRequest servletRequest)
and then subclasses ServletWebRequest offering a wrapped
MultipartServletWebRequest which passes back a custom FileItem that
wraps the InputStream in a CountingInputStream, that in turn updates
the Session. Whew! That was long.
Ideas and thoughts?
Thanks!
-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc. Get Certified Today
Register for a JBoss Training Course. Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
_______________________________________________
Wicket-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-user
- Re: [Wicket-user] Upload Progress bar Johan Compagner
- Re: [Wicket-user] Upload Progress bar Igor Vaynberg
- Re: [Wicket-user] Upload Progress bar Johan Compagner
- Re: [Wicket-user] Upload Progress bar Igor Vaynberg
- Re: [Wicket-user] Upload Progress bar Johan Compagner
- Re: [Wicket-user] Upload Progress ba... Eelco Hillenius
