Re: [Wicket-user] Upload Progress bar
yes you are right. There are a things that go outside the session sync for images like the last modified time but handling the resource is also inside the synch block.Maybe it would be nice to not have that, because that looks also for the performance part of a website better. That you can serve out more then one
image at one time.johanOn 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.
johan On 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 liketo see some statuses.Figured out with Igor how to go aboutinjecting a CountingInputStream into the process for FileUpload, but have run into a roadblock!
What ends up happening, is the page runs a _javascript_, to showanother page that meta refreshes and shows a status grabbed from thesession.And at the same time submits the form to start the upload. Only problem is, it seems to block on the form submissionuploading
the file, and never shows the status page until after its doneprocessing 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 updatesthe Session.Whew!That was long.Ideas and thoughts?Thanks! ---
This SF.Net email is sponsored by the JBoss Inc.Get Certified TodayRegister for a JBoss Training Course.Free Certification Examfor All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628alloc_id=16845op=click___Wicket-user mailing list
Wicket-user@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Upload Progress bar
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 levelbecause 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; } xx
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 differentthis:// Attach thread local resources for request
threadAttach();// Response is beginninginternalOnBeginRequest();onBeginRequest();doesn't care if it isn't synched.But this part:
catch (RuntimeException e) {// Handle any runtime exceptioninternalOnRuntimeException(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.
johan On 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 liketo see some statuses.Figured out with Igor how to go aboutinjecting a CountingInputStream into the
Re: [Wicket-user] Upload Progress bar
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 pseudoboolean 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 levelbecause 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; } xx
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 differentthis:// Attach thread local resources for request
threadAttach();// Response is beginninginternalOnBeginRequest();onBeginRequest();doesn't care if it isn't synched.But this part:
catch (RuntimeException e) {// Handle any runtime exceptioninternalOnRuntimeException(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
Re: [Wicket-user] Upload Progress bar
you are right. My quick prototyping was not completely valid.we should just invert it yes first check for isResource() || isStatic()and if that returns false then do something elseThe problem is that in the end we do this:
else { int rtn = doParseRequest(); if (rtn == PARSE_REQUEST_RETURNING_PAGE) {return true;
} xx
where do we do that now? I haven't used it yet but that is i think user parsed request.Where does that belong?johanOn 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 pseudoboolean 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 levelbecause 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; } xx
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 differentthis:// Attach thread local resources for request
threadAttach();// Response is beginninginternalOnBeginRequest();onBeginRequest();doesn't care if it isn't synched.But this part:
catch (RuntimeException e) {// Handle any runtime exceptioninternalOnRuntimeException(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(); }
Re: [Wicket-user] Upload Progress bar
i havent used that either so im not sure. but that probably needs to be inside the synchronized block. its in the else block so its safe to check for resource before that check runs.
im off to bed now, 1am here :)-IgorOn 11/24/05, Johan Compagner [EMAIL PROTECTED] wrote:
you are right. My quick prototyping was not completely valid.we should just invert it yes first check for isResource() || isStatic()
and if that returns false then do something elseThe problem is that in the end we do this:
else { int rtn = doParseRequest(); if (rtn == PARSE_REQUEST_RETURNING_PAGE) {return true;
} xx
where do we do that now? I haven't used it yet but that is i think user parsed request.Where does that belong?
johanOn 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 pseudoboolean 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 levelbecause 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; } xx
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 differentthis:// Attach thread local resources for request
threadAttach();// Response is beginninginternalOnBeginRequest();onBeginRequest();doesn't care if it isn't synched.But this part:
catch (RuntimeException e) {// Handle any runtime exceptioninternalOnRuntimeException(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) {
Re: [Wicket-user] Upload Progress bar
ok changed the code over here, this is RequestCycle.request:public final void request() throws ServletException { // Serialize renderings on the session object so that only one page // can be rendered at a time for a given session.
try { // Attach thread local resources for request threadAttach(); // Response is beginning internalOnBeginRequest(); onBeginRequest();
// If request is parsed successfully if(!parseResource()) {synchronized (session){ try {
if (parseRequest()) { // respond with a page respond(); } }
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); } }} }
} catch (RuntimeException e) { // Handle any runtime exception internalOnRuntimeException(null, e); } finally { // Response is ending
try {internalOnEndRequest(); } catch (RuntimeException e) {log.error(Exception occurred during internalOnEndRequest, e);
} try {onEndRequest(); } catch (RuntimeException e) {log.error(Exception occurred during onEndRequest, e);
} // Release thread local resources threadDetach(); } }And then one extra method in WebRequestCycle:protected final boolean parseResource()
{ // If it's not a resource reference or static content if (resourceReference() || staticContent()) { // Don't update the cluster, not returning a page setUpdateCluster(false);
setResponsePage((Page)null); return true; } return false; }that is the behaviour that was in parseRequest() for resources and static content.Now the only question is is it save for these 2 methods to be not synced:
// Response is beginning
internalOnBeginRequest();
onBeginRequest();
What can a user do there in onBeginRequest() (i think openen sessions for hibernate and those things but that is not problem because those are for the current thread)we do ourselfs Session.updateSession() where we loop and order pages(sets) and set those in the session if they wheren't already and so on.
I think that we don't have to do that when it is a Resource lookup but i am not sure.I am also not sure if Session.updateSession() can run twice at the same time or at the same time if a page map would be updated by another thread that is in
callComponentListener area... A bit tricky..johanOn 11/24/05, Igor Vaynberg [EMAIL PROTECTED]
wrote:i havent used that either so im not sure. but that probably needs to be inside the synchronized block. its in the else block so its safe to check for resource before that check runs.
im off to bed now, 1am here :)-IgorOn 11/24/05, Johan Compagner
[EMAIL PROTECTED] wrote:
you are right. My quick prototyping was not completely valid.we should just invert it yes first check for isResource() || isStatic()
and if that returns false then do something elseThe problem is that in the end we do this:
else { int rtn = doParseRequest(); if (rtn == PARSE_REQUEST_RETURNING_PAGE) {return true;
} xx
where do we do that now? I haven't used it yet but that is i think user parsed request.Where does that belong?
johanOn 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 pseudoboolean 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 levelbecause 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; } xx
and then in RequestCycle.request() have something like this:boolean parsed =
Re: [Wicket-user] Upload Progress bar
I kind of missed this discussion as I was working on the request cycle handling refactoring. After a short offline discussion with Johan, I took this as part of the refactoring too. The new way of handling (still has to be discussed with the other devs after I'm further with it, but I think it is look much, much better now) has synchronization depending on what I now call the 'request target' which could be anything from a page - which should be synchronized on the session - to shared resources or external resources (like images from your web app directory) - which shouldn't be synchronized at all. The Session.updateSession thingy is planned for step 2 of the refactoring. Ultimately, I'd like to end up with something that would allow for 'sessionless' applications. For instance, while working with bookmarkable pages that do not hold any components that implement IRequestListener, there is really no need to even put them in the session. In that case, or if you would have a home page like that, I would like to be able to at least defer creating a session object until it is actually needed. Not sure how difficult this will be, but it is probably doable. The refactoring encompasses quite a lot; it touches most important internals on Wicket, so I'd like to take a few days to sort it out and keep really focussed and have offline dicussions with core developers based on the commits first. So... Johan, Juergen, Igor, Martijn, ... you know where to find me :) Eelco --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_idv37alloc_id865op=click ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
[Wicket-user] Upload Progress bar
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=7628alloc_id=16845op=click ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Upload Progress bar
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.johan On 11/23/05, Andrew Lombardi [EMAIL PROTECTED] wrote: I've got a need to show an Upload progress bar in a Wicket app thatI've built.We're uploading some fairly large files and would liketo see some statuses.Figured out with Igor how to go aboutinjecting a CountingInputStream into the process for FileUpload, but have run into a roadblock!What ends up happening, is the page runs a _javascript_, to showanother page that meta refreshes and shows a status grabbed from thesession.And at the same time submits the form to start the upload. Only problem is, it seems to block on the form submissionuploadingthe file, and never shows the status page until after its doneprocessing 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 thisthat 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 thatwraps the InputStream in a CountingInputStream, that in turn updatesthe Session.Whew!That was long.Ideas and thoughts?Thanks! ---This SF.Net email is sponsored by the JBoss Inc.Get Certified TodayRegister for a JBoss Training Course.Free Certification Examfor All Training Attendees Through End of 2005. For more info visit: http://ads.osdn.com/?ad_id=7628alloc_id=16845op=click___Wicket-user mailing list Wicket-user@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Upload Progress bar
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.johan On 11/23/05, Andrew Lombardi [EMAIL PROTECTED] wrote: I've got a need to show an Upload progress bar in a Wicket app thatI've built. We're uploading some fairly large files and would liketo see some statuses. Figured out with Igor how to go aboutinjecting a CountingInputStream into the process for FileUpload, but have run into a roadblock!What ends up happening, is the page runs a _javascript_, to showanother page that meta refreshes and shows a status grabbed from thesession. And at the same time submits the form to start the upload. Only problem is, it seems to block on the form submission uploadingthe file, and never shows the status page until after its doneprocessing 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 thisthat 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 thatwraps the InputStream in a CountingInputStream, that in turn updatesthe Session. Whew! That was long.Ideas and thoughts?Thanks! ---This SF.Net email is sponsored by the JBoss Inc. Get Certified TodayRegister for a JBoss Training Course. Free Certification Examfor All Training Attendees Through End of 2005. For more info visit: http://ads.osdn.com/?ad_id=7628alloc_id=16845op=click___Wicket-user mailing list Wicket-user@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Upload Progress bar
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.
johan On 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 liketo see some statuses.Figured out with Igor how to go aboutinjecting a CountingInputStream into the process for FileUpload, but have run into a roadblock!
What ends up happening, is the page runs a _javascript_, to showanother page that meta refreshes and shows a status grabbed from thesession.And at the same time submits the form to start the upload. Only problem is, it seems to block on the form submissionuploading
the file, and never shows the status page until after its doneprocessing 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 updatesthe Session.Whew!That was long.Ideas and thoughts?Thanks! ---
This SF.Net email is sponsored by the JBoss Inc.Get Certified TodayRegister for a JBoss Training Course.Free Certification Examfor All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628alloc_id=16845op=click___Wicket-user mailing list
Wicket-user@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Upload Progress bar
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.
johan On 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 liketo see some statuses.Figured out with Igor how to go aboutinjecting a CountingInputStream into the process for FileUpload, but have run into a roadblock!
What ends up happening, is the page runs a _javascript_, to showanother page that meta refreshes and shows a status grabbed from thesession.And at the same time submits the form to start the upload. Only problem is, it seems to block on the form submissionuploading
the file, and never shows the status page until after its doneprocessing 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 updatesthe Session.Whew!That was long.Ideas and thoughts?Thanks! ---
This SF.Net email is sponsored by the JBoss Inc.Get Certified TodayRegister for a JBoss Training Course.Free Certification Examfor All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628alloc_id=16845op=click___Wicket-user mailing list
Wicket-user@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/wicket-user
