Re: threading issues - continued
Thanks Eelco, https://issues.apache.org/jira/browse/WICKET-994 Have you had a chance to reproduce it? We tested with a few browsers but all in the same server env, although hard to see what difference that would make. Eelco Hillenius wrote: On 9/20/07, Sam Hough [EMAIL PROTECTED] wrote: Matej, Sorry for the delay. If you unzip the attached file into the root of src dir and point web.xml at TestWicketApplication it should work with 1.3-beta3. We have tested on FF2 and IE6 and breaks. Quickest way it to get focus on the button and hold down return. Please let me know if this is not in an easy format for you. Is slightly different from our real code as I update the whole form as I can't target RepeatingView but wanted to keep the code as slim as possible. http://www.nabble.com/file/p12794149/test.zip test.zip It's probably a good idea to open a JIRA issue for this and attach the zip to that. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/threading-issues---continued-tf4400569.html#a12812623 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: threading issues - continued
Hi, I'm unable to reproduce this with latest trunk. I believe this has been already fixed by delaying the actual form serialization until the previous request finishes. Can you please test this with latest trunk? Unfurtunately, there are no current snapshots available so you'd have to build it from SVN. -Matej On 9/21/07, Sam Hough [EMAIL PROTECTED] wrote: Thanks Eelco, https://issues.apache.org/jira/browse/WICKET-994 Have you had a chance to reproduce it? We tested with a few browsers but all in the same server env, although hard to see what difference that would make. Eelco Hillenius wrote: On 9/20/07, Sam Hough [EMAIL PROTECTED] wrote: Matej, Sorry for the delay. If you unzip the attached file into the root of src dir and point web.xml at TestWicketApplication it should work with 1.3-beta3. We have tested on FF2 and IE6 and breaks. Quickest way it to get focus on the button and hold down return. Please let me know if this is not in an easy format for you. Is slightly different from our real code as I update the whole form as I can't target RepeatingView but wanted to keep the code as slim as possible. http://www.nabble.com/file/p12794149/test.zip test.zip It's probably a good idea to open a JIRA issue for this and attach the zip to that. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/threading-issues---continued-tf4400569.html#a12812623 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: threading issues - continued
Btw., did you clean browser cache after updating wicket? There's
chance that you have old javascript code still in browser cache.
Also part of the fix is in wicket-ajax.js, line 950:
submitForm: function(form, submitButton) {
var body = function() {
var s = Wicket.Form.serialize(form);
if (submitButton != null) {
s += Wicket.Form.encode(submitButton) + =1;
}
return s;
}
return this.request.post(body);
},
So body is not just serialized from content, but it's a method that
returns serialized form content. This method gets evaluated right
before submitting the form, which means the previous ajax request must
have been finished.
-Matej
On 9/21/07, Matej Knopp [EMAIL PROTECTED] wrote:
So you tried it with latest trunk and it still doesn't work for you? I
used FF2/IE7 on Vista.
-Matej
On 9/21/07, Sam Hough [EMAIL PROTECTED] wrote:
Still doesn't work for me. Can you give me a pointer to which change should
fix things?
What browser/OS did you use? Did you let the form get nice and big so it
takes a while to render?
Thanks for looking into it. Hope I'm not raising another red herring.
Matej Knopp-2 wrote:
Hi, I'm unable to reproduce this with latest trunk. I believe this has
been already fixed by delaying the actual form serialization until the
previous request finishes. Can you please test this with latest trunk?
Unfurtunately, there are no current snapshots available so you'd have
to build it from SVN.
-Matej
On 9/21/07, Sam Hough [EMAIL PROTECTED] wrote:
Thanks Eelco,
https://issues.apache.org/jira/browse/WICKET-994
Have you had a chance to reproduce it? We tested with a few browsers but
all
in the same server env, although hard to see what difference that would
make.
Eelco Hillenius wrote:
On 9/20/07, Sam Hough [EMAIL PROTECTED] wrote:
Matej,
Sorry for the delay. If you unzip the attached file into the root of
src
dir
and point web.xml at TestWicketApplication it should work with
1.3-beta3.
We
have tested on FF2 and IE6 and breaks. Quickest way it to get focus on
the
button and hold down return.
Please let me know if this is not in an easy format for you.
Is slightly different from our real code as I update the whole form as
I
can't target RepeatingView but wanted to keep the code as slim as
possible.
http://www.nabble.com/file/p12794149/test.zip test.zip
It's probably a good idea to open a JIRA issue for this and attach the
zip to that.
Eelco
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
View this message in context:
http://www.nabble.com/threading-issues---continued-tf4400569.html#a12812623
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
View this message in context:
http://www.nabble.com/threading-issues---continued-tf4400569.html#a12814523
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: threading issues - continued
Doh. Owe you a pint. My build from trunk didn't work because I had wrong version of logger... So I was running older code that was hanging about. Can't break it now :) Many thanks. If you are in London lots of nice warm English beer waiting for you! -- View this message in context: http://www.nabble.com/threading-issues---continued-tf4400569.html#a12814826 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: threading issues - continued
So you tried it with latest trunk and it still doesn't work for you? I used FF2/IE7 on Vista. -Matej On 9/21/07, Sam Hough [EMAIL PROTECTED] wrote: Still doesn't work for me. Can you give me a pointer to which change should fix things? What browser/OS did you use? Did you let the form get nice and big so it takes a while to render? Thanks for looking into it. Hope I'm not raising another red herring. Matej Knopp-2 wrote: Hi, I'm unable to reproduce this with latest trunk. I believe this has been already fixed by delaying the actual form serialization until the previous request finishes. Can you please test this with latest trunk? Unfurtunately, there are no current snapshots available so you'd have to build it from SVN. -Matej On 9/21/07, Sam Hough [EMAIL PROTECTED] wrote: Thanks Eelco, https://issues.apache.org/jira/browse/WICKET-994 Have you had a chance to reproduce it? We tested with a few browsers but all in the same server env, although hard to see what difference that would make. Eelco Hillenius wrote: On 9/20/07, Sam Hough [EMAIL PROTECTED] wrote: Matej, Sorry for the delay. If you unzip the attached file into the root of src dir and point web.xml at TestWicketApplication it should work with 1.3-beta3. We have tested on FF2 and IE6 and breaks. Quickest way it to get focus on the button and hold down return. Please let me know if this is not in an easy format for you. Is slightly different from our real code as I update the whole form as I can't target RepeatingView but wanted to keep the code as slim as possible. http://www.nabble.com/file/p12794149/test.zip test.zip It's probably a good idea to open a JIRA issue for this and attach the zip to that. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/threading-issues---continued-tf4400569.html#a12812623 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/threading-issues---continued-tf4400569.html#a12814523 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: threading issues - continued
Matej, Sorry for the delay. If you unzip the attached file into the root of src dir and point web.xml at TestWicketApplication it should work with 1.3-beta3. We have tested on FF2 and IE6 and breaks. Quickest way it to get focus on the button and hold down return. Please let me know if this is not in an easy format for you. Is slightly different from our real code as I update the whole form as I can't target RepeatingView but wanted to keep the code as slim as possible. http://www.nabble.com/file/p12794149/test.zip test.zip Thanks Sam Matej Knopp-2 wrote: While the repaint is somewhat asynchronous, this shouldn't affect the actual form serialization. Can you provide a quickstart that can be used to reproduce this problem? -Matej On 9/19/07, Sam Hough [EMAIL PROTECTED] wrote: I'm using 1.3-beta3 I think as far as the wicket js is concerned it has finished (as it has done elmt.innerHTML='something') but the problem is that the browser does the re-rendering in a different thread to the java script engine. So when I click the second time the HTML is only partially finished... Maybe I'll have a look at how selenium waits for the browser to settle. Think this is a common problem for browser based robot testing. Matej Knopp-2 wrote: What exact wicket version are you using? With the current trunk the client side form serialization waits until the previous ajax request finished even if you submit the form during previous request processing. But I'm not really sure that this is your issue. -Matej On 9/19/07, Sam Hough [EMAIL PROTECTED] wrote: Yes. Click A updates part of the form. Click B (very soon after A) also submits that form. So my suspicion is that the browser is still busy parsing the last update and click B sends a form in an intermediate state. Does that sound likely? I've seen it in the past that after innerHTML you have to wait a while to access the DOM. Johan Compagner wrote: do you click fast on a dom portion that is being replaced by the previous request? johan On 9/19/07, Sam Hough [EMAIL PROTECTED] wrote: Bit more information is that the bean property that is causing the problem is being set to null by my html form via a wicket ajax update... Could it be that although wicket is doing everything correctly the DOM in (firefox 2) has not settled after the elmt.innerHTML= ... from the previous ajax response so the next click sends an update that I wouldn't expect? Any options in wicket to block the UI till the DOM has settled? Or shall I point my html monkey at it? Sam Hough wrote: Must be me then. I'll try and pin it down more. Hmmm. Johan Compagner wrote: the nullpointer comes from outside of wicket (criterion class) but you say if you click quickly you only get it? all pages are blocked by a barrier that is build around the pagemap. its in Session.get page method. only 1 request can pass that at the same time. but what is suddenly null that you dont expect to be null? On 9/18/07, Sam Hough [EMAIL PROTECTED] wrote: That is pretty much it. Except that: Caused by: java.lang.NullPointerException at com.namechangedtoprotectguilty.search.Criterion.getHelper( Criterion.java:200) at sun.reflect.GeneratedMethodAccessor41.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke( DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.wicket.util.lang.PropertyResolver$MethodGetAndSet.getValue( PropertyResolver.java:1030) Blows up in our code in a way that really looks like a multithreading issue to me. If I click slowly no problems, if I click quickly on a slow page it reliably blows up. Guess I could put in a sync filter to double check that it is a sync error. We don't create any threads so apart from threading issue I can't see what else it could be... igor.vaynberg wrote: show us the full stack trace -igor On 9/18/07, Sam Hough [EMAIL PROTECTED] wrote: Which bit of code does the blocking on the server? I'm getting what looks very much like a threading issue. I've looked at all the methods below and can't see any obvious sync code... I'm using 1.3-beta3 at org.apache.wicket.util.lang.PropertyResolver$MethodGetAndSet.getValue( PropertyResolver.java:1034) at org.apache.wicket.util.lang.PropertyResolver.getObjectAndGetSetter( PropertyResolver.java:247) at org.apache.wicket.util.lang.PropertyResolver.getValue( PropertyResolver.java:89) at org.apache.wicket.model.AbstractPropertyModel.getObject(
Re: threading issues - continued
On 9/20/07, Sam Hough [EMAIL PROTECTED] wrote: Matej, Sorry for the delay. If you unzip the attached file into the root of src dir and point web.xml at TestWicketApplication it should work with 1.3-beta3. We have tested on FF2 and IE6 and breaks. Quickest way it to get focus on the button and hold down return. Please let me know if this is not in an easy format for you. Is slightly different from our real code as I update the whole form as I can't target RepeatingView but wanted to keep the code as slim as possible. http://www.nabble.com/file/p12794149/test.zip test.zip It's probably a good idea to open a JIRA issue for this and attach the zip to that. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: threading issues - continued
Bit more information is that the bean property that is causing the problem is being set to null by my html form via a wicket ajax update... Could it be that although wicket is doing everything correctly the DOM in (firefox 2) has not settled after the elmt.innerHTML= ... from the previous ajax response so the next click sends an update that I wouldn't expect? Any options in wicket to block the UI till the DOM has settled? Or shall I point my html monkey at it? Sam Hough wrote: Must be me then. I'll try and pin it down more. Hmmm. Johan Compagner wrote: the nullpointer comes from outside of wicket (criterion class) but you say if you click quickly you only get it? all pages are blocked by a barrier that is build around the pagemap. its in Session.get page method. only 1 request can pass that at the same time. but what is suddenly null that you dont expect to be null? On 9/18/07, Sam Hough [EMAIL PROTECTED] wrote: That is pretty much it. Except that: Caused by: java.lang.NullPointerException at com.namechangedtoprotectguilty.search.Criterion.getHelper(Criterion.java:200) at sun.reflect.GeneratedMethodAccessor41.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.wicket.util.lang.PropertyResolver$MethodGetAndSet.getValue(PropertyResolver.java:1030) Blows up in our code in a way that really looks like a multithreading issue to me. If I click slowly no problems, if I click quickly on a slow page it reliably blows up. Guess I could put in a sync filter to double check that it is a sync error. We don't create any threads so apart from threading issue I can't see what else it could be... igor.vaynberg wrote: show us the full stack trace -igor On 9/18/07, Sam Hough [EMAIL PROTECTED] wrote: Which bit of code does the blocking on the server? I'm getting what looks very much like a threading issue. I've looked at all the methods below and can't see any obvious sync code... I'm using 1.3-beta3 at org.apache.wicket.util.lang.PropertyResolver$MethodGetAndSet.getValue( PropertyResolver.java:1034) at org.apache.wicket.util.lang.PropertyResolver.getObjectAndGetSetter( PropertyResolver.java:247) at org.apache.wicket.util.lang.PropertyResolver.getValue( PropertyResolver.java:89) at org.apache.wicket.model.AbstractPropertyModel.getObject( AbstractPropertyModel.java:110) at org.apache.wicket.Component.getModelObject(Component.java:1293) at org.apache.wicket.Component$2.compare(Component.java:540) at org.apache.wicket.Component.setModelObject(Component.java:2522) at org.apache.wicket.markup.html.form.FormComponent.updateModel( FormComponent.java:1002) at org.apache.wicket.markup.html.form.Form$14.validate(Form.java :1642) at org.apache.wicket.markup.html.form.Form$ValidationVisitor.formComponent( Form.java:160) at org.apache.wicket.markup.html.form.FormComponent.visitFormComponentsPostOrderHelper (FormComponent.java:403) at org.apache.wicket.markup.html.form.FormComponent.visitFormComponentsPostOrderHelper (FormComponent.java:390) at org.apache.wicket.markup.html.form.FormComponent.visitFormComponentsPostOrderHelper (FormComponent.java:390) at org.apache.wicket.markup.html.form.FormComponent.visitFormComponentsPostOrderHelper (FormComponent.java:390) at org.apache.wicket.markup.html.form.FormComponent.visitFormComponentsPostOrderHelper (FormComponent.java:390) at org.apache.wicket.markup.html.form.FormComponent.visitFormComponentsPostOrder (FormComponent.java:368) at org.apache.wicket.markup.html.form.Form.visitFormComponentsPostOrder( Form.java:1004) at org.apache.wicket.markup.html.form.Form.updateFormComponentModels( Form.java:1637) at org.apache.wicket.markup.html.form.Form.process(Form.java:834) at org.apache.wicket.markup.html.form.Form.onFormSubmitted( Form.java:783) at org.apache.wicket.ajax.form.AjaxFormSubmitBehavior.onEvent( AjaxFormSubmitBehavior.java:126) at org.apache.wicket.ajax.AjaxEventBehavior.respond(AjaxEventBehavior.java :163) at org.apache.wicket.ajax.AbstractDefaultAjaxBehavior.onRequest( AbstractDefaultAjaxBehavior.java:268) at org.apache.wicket.request.target.component.listener.BehaviorRequestTarget.processEvents (BehaviorRequestTarget.java:100) at org.apache.wicket.request.AbstractRequestCycleProcessor.processEvents( AbstractRequestCycleProcessor.java:90) at org.apache.wicket.RequestCycle.processEventsAndRespond(RequestCycle.java :1032) at org.apache.wicket.RequestCycle.step(RequestCycle.java:1108)
Re: threading issues - continued
but you get null pointers in the serverside. So what should that have to do with busy parsing on the client side That second submit is being done again (with the OLD dom) and that maybe doesn't map correctly any more? The problem is that the ajax request and waiting for the response and updating the dom should be done then completely synchronously Because it could be a problem yes when you click fast on things that will be replaced.. johan On 9/19/07, Sam Hough [EMAIL PROTECTED] wrote: Yes. Click A updates part of the form. Click B (very soon after A) also submits that form. So my suspicion is that the browser is still busy parsing the last update and click B sends a form in an intermediate state. Does that sound likely? I've seen it in the past that after innerHTML you have to wait a while to access the DOM. Johan Compagner wrote: do you click fast on a dom portion that is being replaced by the previous request? johan On 9/19/07, Sam Hough [EMAIL PROTECTED] wrote: Bit more information is that the bean property that is causing the problem is being set to null by my html form via a wicket ajax update... Could it be that although wicket is doing everything correctly the DOM in (firefox 2) has not settled after the elmt.innerHTML= ... from the previous ajax response so the next click sends an update that I wouldn't expect? Any options in wicket to block the UI till the DOM has settled? Or shall I point my html monkey at it? Sam Hough wrote: Must be me then. I'll try and pin it down more. Hmmm. Johan Compagner wrote: the nullpointer comes from outside of wicket (criterion class) but you say if you click quickly you only get it? all pages are blocked by a barrier that is build around the pagemap. its in Session.get page method. only 1 request can pass that at the same time. but what is suddenly null that you dont expect to be null? On 9/18/07, Sam Hough [EMAIL PROTECTED] wrote: That is pretty much it. Except that: Caused by: java.lang.NullPointerException at com.namechangedtoprotectguilty.search.Criterion.getHelper( Criterion.java:200) at sun.reflect.GeneratedMethodAccessor41.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke( DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.wicket.util.lang.PropertyResolver$MethodGetAndSet.getValue( PropertyResolver.java:1030) Blows up in our code in a way that really looks like a multithreading issue to me. If I click slowly no problems, if I click quickly on a slow page it reliably blows up. Guess I could put in a sync filter to double check that it is a sync error. We don't create any threads so apart from threading issue I can't see what else it could be... igor.vaynberg wrote: show us the full stack trace -igor On 9/18/07, Sam Hough [EMAIL PROTECTED] wrote: Which bit of code does the blocking on the server? I'm getting what looks very much like a threading issue. I've looked at all the methods below and can't see any obvious sync code... I'm using 1.3-beta3 at org.apache.wicket.util.lang.PropertyResolver$MethodGetAndSet.getValue( PropertyResolver.java:1034) at org.apache.wicket.util.lang.PropertyResolver.getObjectAndGetSetter( PropertyResolver.java:247) at org.apache.wicket.util.lang.PropertyResolver.getValue( PropertyResolver.java:89) at org.apache.wicket.model.AbstractPropertyModel.getObject( AbstractPropertyModel.java:110) at org.apache.wicket.Component.getModelObject(Component.java:1293) at org.apache.wicket.Component$2.compare(Component.java :540) at org.apache.wicket.Component.setModelObject(Component.java:2522) at org.apache.wicket.markup.html.form.FormComponent.updateModel( FormComponent.java:1002) at org.apache.wicket.markup.html.form.Form$14.validate(Form.java :1642) at org.apache.wicket.markup.html.form.Form$ValidationVisitor.formComponent ( Form.java:160) at org.apache.wicket.markup.html.form.FormComponent.visitFormComponentsPostOrderHelper (FormComponent.java:403) at org.apache.wicket.markup.html.form.FormComponent.visitFormComponentsPostOrderHelper (FormComponent.java:390) at org.apache.wicket.markup.html.form.FormComponent.visitFormComponentsPostOrderHelper (FormComponent.java:390) at org.apache.wicket.markup.html.form.FormComponent.visitFormComponentsPostOrderHelper (FormComponent.java:390) at
Re: threading issues - continued
But shouldn't that be a validation error? -Matej On 9/19/07, Sam Hough [EMAIL PROTECTED] wrote: I'm getting null pointers on the server side because the form _values_ seem not do have been set by the client yet so in the http request someParameter= which would otherwise not be the case. Doesn't seem like something I want to handle on the server... If somebody is hacking, has broken browser I'd rather the server threw an error. Johan Compagner wrote: but you get null pointers in the serverside. So what should that have to do with busy parsing on the client side That second submit is being done again (with the OLD dom) and that maybe doesn't map correctly any more? The problem is that the ajax request and waiting for the response and updating the dom should be done then completely synchronously Because it could be a problem yes when you click fast on things that will be replaced.. johan On 9/19/07, Sam Hough [EMAIL PROTECTED] wrote: Yes. Click A updates part of the form. Click B (very soon after A) also submits that form. So my suspicion is that the browser is still busy parsing the last update and click B sends a form in an intermediate state. Does that sound likely? I've seen it in the past that after innerHTML you have to wait a while to access the DOM. Johan Compagner wrote: do you click fast on a dom portion that is being replaced by the previous request? johan On 9/19/07, Sam Hough [EMAIL PROTECTED] wrote: Bit more information is that the bean property that is causing the problem is being set to null by my html form via a wicket ajax update... Could it be that although wicket is doing everything correctly the DOM in (firefox 2) has not settled after the elmt.innerHTML= ... from the previous ajax response so the next click sends an update that I wouldn't expect? Any options in wicket to block the UI till the DOM has settled? Or shall I point my html monkey at it? Sam Hough wrote: Must be me then. I'll try and pin it down more. Hmmm. Johan Compagner wrote: the nullpointer comes from outside of wicket (criterion class) but you say if you click quickly you only get it? all pages are blocked by a barrier that is build around the pagemap. its in Session.get page method. only 1 request can pass that at the same time. but what is suddenly null that you dont expect to be null? On 9/18/07, Sam Hough [EMAIL PROTECTED] wrote: That is pretty much it. Except that: Caused by: java.lang.NullPointerException at com.namechangedtoprotectguilty.search.Criterion.getHelper( Criterion.java:200) at sun.reflect.GeneratedMethodAccessor41.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke( DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.wicket.util.lang.PropertyResolver$MethodGetAndSet.getValue( PropertyResolver.java:1030) Blows up in our code in a way that really looks like a multithreading issue to me. If I click slowly no problems, if I click quickly on a slow page it reliably blows up. Guess I could put in a sync filter to double check that it is a sync error. We don't create any threads so apart from threading issue I can't see what else it could be... igor.vaynberg wrote: show us the full stack trace -igor On 9/18/07, Sam Hough [EMAIL PROTECTED] wrote: Which bit of code does the blocking on the server? I'm getting what looks very much like a threading issue. I've looked at all the methods below and can't see any obvious sync code... I'm using 1.3-beta3 at org.apache.wicket.util.lang.PropertyResolver$MethodGetAndSet.getValue( PropertyResolver.java:1034) at org.apache.wicket.util.lang.PropertyResolver.getObjectAndGetSetter( PropertyResolver.java:247) at org.apache.wicket.util.lang.PropertyResolver.getValue( PropertyResolver.java:89) at org.apache.wicket.model.AbstractPropertyModel.getObject( AbstractPropertyModel.java:110) at org.apache.wicket.Component.getModelObject(Component.java:1293) at org.apache.wicket.Component$2.compare(Component.java :540) at org.apache.wicket.Component.setModelObject(Component.java:2522) at org.apache.wicket.markup.html.form.FormComponent.updateModel( FormComponent.java:1002) at org.apache.wicket.markup.html.form.Form$14.validate(Form.java :1642) at org.apache.wicket.markup.html.form.Form$ValidationVisitor.formComponent ( Form.java:160) at
Re: threading issues - continued
While the repaint is somewhat asynchronous, this shouldn't affect the actual form serialization. Can you provide a quickstart that can be used to reproduce this problem? -Matej On 9/19/07, Sam Hough [EMAIL PROTECTED] wrote: I'm using 1.3-beta3 I think as far as the wicket js is concerned it has finished (as it has done elmt.innerHTML='something') but the problem is that the browser does the re-rendering in a different thread to the java script engine. So when I click the second time the HTML is only partially finished... Maybe I'll have a look at how selenium waits for the browser to settle. Think this is a common problem for browser based robot testing. Matej Knopp-2 wrote: What exact wicket version are you using? With the current trunk the client side form serialization waits until the previous ajax request finished even if you submit the form during previous request processing. But I'm not really sure that this is your issue. -Matej On 9/19/07, Sam Hough [EMAIL PROTECTED] wrote: Yes. Click A updates part of the form. Click B (very soon after A) also submits that form. So my suspicion is that the browser is still busy parsing the last update and click B sends a form in an intermediate state. Does that sound likely? I've seen it in the past that after innerHTML you have to wait a while to access the DOM. Johan Compagner wrote: do you click fast on a dom portion that is being replaced by the previous request? johan On 9/19/07, Sam Hough [EMAIL PROTECTED] wrote: Bit more information is that the bean property that is causing the problem is being set to null by my html form via a wicket ajax update... Could it be that although wicket is doing everything correctly the DOM in (firefox 2) has not settled after the elmt.innerHTML= ... from the previous ajax response so the next click sends an update that I wouldn't expect? Any options in wicket to block the UI till the DOM has settled? Or shall I point my html monkey at it? Sam Hough wrote: Must be me then. I'll try and pin it down more. Hmmm. Johan Compagner wrote: the nullpointer comes from outside of wicket (criterion class) but you say if you click quickly you only get it? all pages are blocked by a barrier that is build around the pagemap. its in Session.get page method. only 1 request can pass that at the same time. but what is suddenly null that you dont expect to be null? On 9/18/07, Sam Hough [EMAIL PROTECTED] wrote: That is pretty much it. Except that: Caused by: java.lang.NullPointerException at com.namechangedtoprotectguilty.search.Criterion.getHelper( Criterion.java:200) at sun.reflect.GeneratedMethodAccessor41.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke( DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.wicket.util.lang.PropertyResolver$MethodGetAndSet.getValue( PropertyResolver.java:1030) Blows up in our code in a way that really looks like a multithreading issue to me. If I click slowly no problems, if I click quickly on a slow page it reliably blows up. Guess I could put in a sync filter to double check that it is a sync error. We don't create any threads so apart from threading issue I can't see what else it could be... igor.vaynberg wrote: show us the full stack trace -igor On 9/18/07, Sam Hough [EMAIL PROTECTED] wrote: Which bit of code does the blocking on the server? I'm getting what looks very much like a threading issue. I've looked at all the methods below and can't see any obvious sync code... I'm using 1.3-beta3 at org.apache.wicket.util.lang.PropertyResolver$MethodGetAndSet.getValue( PropertyResolver.java:1034) at org.apache.wicket.util.lang.PropertyResolver.getObjectAndGetSetter( PropertyResolver.java:247) at org.apache.wicket.util.lang.PropertyResolver.getValue( PropertyResolver.java:89) at org.apache.wicket.model.AbstractPropertyModel.getObject( AbstractPropertyModel.java:110) at org.apache.wicket.Component.getModelObject(Component.java:1293) at org.apache.wicket.Component$2.compare(Component.java :540) at org.apache.wicket.Component.setModelObject(Component.java:2522) at org.apache.wicket.markup.html.form.FormComponent.updateModel( FormComponent.java:1002) at org.apache.wicket.markup.html.form.Form$14.validate(Form.java :1642) at org.apache.wicket.markup.html.form.Form$ValidationVisitor.formComponent( Form.java:160)
Re: threading issues - continued
I'm getting null pointers on the server side because the form _values_ seem not do have been set by the client yet so in the http request someParameter= which would otherwise not be the case. Doesn't seem like something I want to handle on the server... If somebody is hacking, has broken browser I'd rather the server threw an error. Johan Compagner wrote: but you get null pointers in the serverside. So what should that have to do with busy parsing on the client side That second submit is being done again (with the OLD dom) and that maybe doesn't map correctly any more? The problem is that the ajax request and waiting for the response and updating the dom should be done then completely synchronously Because it could be a problem yes when you click fast on things that will be replaced.. johan On 9/19/07, Sam Hough [EMAIL PROTECTED] wrote: Yes. Click A updates part of the form. Click B (very soon after A) also submits that form. So my suspicion is that the browser is still busy parsing the last update and click B sends a form in an intermediate state. Does that sound likely? I've seen it in the past that after innerHTML you have to wait a while to access the DOM. Johan Compagner wrote: do you click fast on a dom portion that is being replaced by the previous request? johan On 9/19/07, Sam Hough [EMAIL PROTECTED] wrote: Bit more information is that the bean property that is causing the problem is being set to null by my html form via a wicket ajax update... Could it be that although wicket is doing everything correctly the DOM in (firefox 2) has not settled after the elmt.innerHTML= ... from the previous ajax response so the next click sends an update that I wouldn't expect? Any options in wicket to block the UI till the DOM has settled? Or shall I point my html monkey at it? Sam Hough wrote: Must be me then. I'll try and pin it down more. Hmmm. Johan Compagner wrote: the nullpointer comes from outside of wicket (criterion class) but you say if you click quickly you only get it? all pages are blocked by a barrier that is build around the pagemap. its in Session.get page method. only 1 request can pass that at the same time. but what is suddenly null that you dont expect to be null? On 9/18/07, Sam Hough [EMAIL PROTECTED] wrote: That is pretty much it. Except that: Caused by: java.lang.NullPointerException at com.namechangedtoprotectguilty.search.Criterion.getHelper( Criterion.java:200) at sun.reflect.GeneratedMethodAccessor41.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke( DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.wicket.util.lang.PropertyResolver$MethodGetAndSet.getValue( PropertyResolver.java:1030) Blows up in our code in a way that really looks like a multithreading issue to me. If I click slowly no problems, if I click quickly on a slow page it reliably blows up. Guess I could put in a sync filter to double check that it is a sync error. We don't create any threads so apart from threading issue I can't see what else it could be... igor.vaynberg wrote: show us the full stack trace -igor On 9/18/07, Sam Hough [EMAIL PROTECTED] wrote: Which bit of code does the blocking on the server? I'm getting what looks very much like a threading issue. I've looked at all the methods below and can't see any obvious sync code... I'm using 1.3-beta3 at org.apache.wicket.util.lang.PropertyResolver$MethodGetAndSet.getValue( PropertyResolver.java:1034) at org.apache.wicket.util.lang.PropertyResolver.getObjectAndGetSetter( PropertyResolver.java:247) at org.apache.wicket.util.lang.PropertyResolver.getValue( PropertyResolver.java:89) at org.apache.wicket.model.AbstractPropertyModel.getObject( AbstractPropertyModel.java:110) at org.apache.wicket.Component.getModelObject(Component.java:1293) at org.apache.wicket.Component$2.compare(Component.java :540) at org.apache.wicket.Component.setModelObject(Component.java:2522) at org.apache.wicket.markup.html.form.FormComponent.updateModel( FormComponent.java:1002) at org.apache.wicket.markup.html.form.Form$14.validate(Form.java :1642) at org.apache.wicket.markup.html.form.Form$ValidationVisitor.formComponent ( Form.java:160) at org.apache.wicket.markup.html.form.FormComponent.visitFormComponentsPostOrderHelper (FormComponent.java:403) at org.apache.wicket.markup.html.form.FormComponent.visitFormComponentsPostOrderHelper (FormComponent.java:390)
Re: threading issues - continued
So is the form sent using wicket JS from the DOM? Anyway, I'm afraid I need to get the OK from my project manager before spending more time on this :( Sucks that he is happy for you to work for free on our problem but that I'm not even allowed to help you in this effort :( Thanks for your time till then, so I can bother you again. Matej Knopp-2 wrote: While the repaint is somewhat asynchronous, this shouldn't affect the actual form serialization. Can you provide a quickstart that can be used to reproduce this problem? -Matej On 9/19/07, Sam Hough [EMAIL PROTECTED] wrote: I'm using 1.3-beta3 I think as far as the wicket js is concerned it has finished (as it has done elmt.innerHTML='something') but the problem is that the browser does the re-rendering in a different thread to the java script engine. So when I click the second time the HTML is only partially finished... Maybe I'll have a look at how selenium waits for the browser to settle. Think this is a common problem for browser based robot testing. Matej Knopp-2 wrote: What exact wicket version are you using? With the current trunk the client side form serialization waits until the previous ajax request finished even if you submit the form during previous request processing. But I'm not really sure that this is your issue. -Matej On 9/19/07, Sam Hough [EMAIL PROTECTED] wrote: Yes. Click A updates part of the form. Click B (very soon after A) also submits that form. So my suspicion is that the browser is still busy parsing the last update and click B sends a form in an intermediate state. Does that sound likely? I've seen it in the past that after innerHTML you have to wait a while to access the DOM. Johan Compagner wrote: do you click fast on a dom portion that is being replaced by the previous request? johan On 9/19/07, Sam Hough [EMAIL PROTECTED] wrote: Bit more information is that the bean property that is causing the problem is being set to null by my html form via a wicket ajax update... Could it be that although wicket is doing everything correctly the DOM in (firefox 2) has not settled after the elmt.innerHTML= ... from the previous ajax response so the next click sends an update that I wouldn't expect? Any options in wicket to block the UI till the DOM has settled? Or shall I point my html monkey at it? Sam Hough wrote: Must be me then. I'll try and pin it down more. Hmmm. Johan Compagner wrote: the nullpointer comes from outside of wicket (criterion class) but you say if you click quickly you only get it? all pages are blocked by a barrier that is build around the pagemap. its in Session.get page method. only 1 request can pass that at the same time. but what is suddenly null that you dont expect to be null? On 9/18/07, Sam Hough [EMAIL PROTECTED] wrote: That is pretty much it. Except that: Caused by: java.lang.NullPointerException at com.namechangedtoprotectguilty.search.Criterion.getHelper( Criterion.java:200) at sun.reflect.GeneratedMethodAccessor41.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke( DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.wicket.util.lang.PropertyResolver$MethodGetAndSet.getValue( PropertyResolver.java:1030) Blows up in our code in a way that really looks like a multithreading issue to me. If I click slowly no problems, if I click quickly on a slow page it reliably blows up. Guess I could put in a sync filter to double check that it is a sync error. We don't create any threads so apart from threading issue I can't see what else it could be... igor.vaynberg wrote: show us the full stack trace -igor On 9/18/07, Sam Hough [EMAIL PROTECTED] wrote: Which bit of code does the blocking on the server? I'm getting what looks very much like a threading issue. I've looked at all the methods below and can't see any obvious sync code... I'm using 1.3-beta3 at org.apache.wicket.util.lang.PropertyResolver$MethodGetAndSet.getValue( PropertyResolver.java:1034) at org.apache.wicket.util.lang.PropertyResolver.getObjectAndGetSetter( PropertyResolver.java:247) at org.apache.wicket.util.lang.PropertyResolver.getValue( PropertyResolver.java:89) at org.apache.wicket.model.AbstractPropertyModel.getObject( AbstractPropertyModel.java:110) at org.apache.wicket.Component.getModelObject(Component.java:1293) at org.apache.wicket.Component$2.compare(Component.java :540) at
Re: threading issues - continued
show us the full stack trace -igor On 9/18/07, Sam Hough [EMAIL PROTECTED] wrote: Which bit of code does the blocking on the server? I'm getting what looks very much like a threading issue. I've looked at all the methods below and can't see any obvious sync code... I'm using 1.3-beta3 at org.apache.wicket.util.lang.PropertyResolver$MethodGetAndSet.getValue( PropertyResolver.java:1034) at org.apache.wicket.util.lang.PropertyResolver.getObjectAndGetSetter( PropertyResolver.java:247) at org.apache.wicket.util.lang.PropertyResolver.getValue( PropertyResolver.java:89) at org.apache.wicket.model.AbstractPropertyModel.getObject( AbstractPropertyModel.java:110) at org.apache.wicket.Component.getModelObject(Component.java:1293) at org.apache.wicket.Component$2.compare(Component.java:540) at org.apache.wicket.Component.setModelObject(Component.java:2522) at org.apache.wicket.markup.html.form.FormComponent.updateModel( FormComponent.java:1002) at org.apache.wicket.markup.html.form.Form$14.validate(Form.java :1642) at org.apache.wicket.markup.html.form.Form$ValidationVisitor.formComponent( Form.java:160) at org.apache.wicket.markup.html.form.FormComponent.visitFormComponentsPostOrderHelper (FormComponent.java:403) at org.apache.wicket.markup.html.form.FormComponent.visitFormComponentsPostOrderHelper (FormComponent.java:390) at org.apache.wicket.markup.html.form.FormComponent.visitFormComponentsPostOrderHelper (FormComponent.java:390) at org.apache.wicket.markup.html.form.FormComponent.visitFormComponentsPostOrderHelper (FormComponent.java:390) at org.apache.wicket.markup.html.form.FormComponent.visitFormComponentsPostOrderHelper (FormComponent.java:390) at org.apache.wicket.markup.html.form.FormComponent.visitFormComponentsPostOrder (FormComponent.java:368) at org.apache.wicket.markup.html.form.Form.visitFormComponentsPostOrder( Form.java:1004) at org.apache.wicket.markup.html.form.Form.updateFormComponentModels( Form.java:1637) at org.apache.wicket.markup.html.form.Form.process(Form.java:834) at org.apache.wicket.markup.html.form.Form.onFormSubmitted( Form.java:783) at org.apache.wicket.ajax.form.AjaxFormSubmitBehavior.onEvent( AjaxFormSubmitBehavior.java:126) at org.apache.wicket.ajax.AjaxEventBehavior.respond(AjaxEventBehavior.java :163) at org.apache.wicket.ajax.AbstractDefaultAjaxBehavior.onRequest( AbstractDefaultAjaxBehavior.java:268) at org.apache.wicket.request.target.component.listener.BehaviorRequestTarget.processEvents (BehaviorRequestTarget.java:100) at org.apache.wicket.request.AbstractRequestCycleProcessor.processEvents( AbstractRequestCycleProcessor.java:90) at org.apache.wicket.RequestCycle.processEventsAndRespond(RequestCycle.java :1032) at org.apache.wicket.RequestCycle.step(RequestCycle.java:1108) at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1177) at org.apache.wicket.RequestCycle.request(RequestCycle.java:500) at org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:261) at org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java :127) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter( ApplicationFilterChain.java:215) at org.apache.catalina.core.ApplicationFilterChain.doFilter( ApplicationFilterChain.java:188) at org.apache.catalina.core.StandardWrapperValve.invoke( StandardWrapperValve.java:210) at org.apache.catalina.core.StandardContextValve.invoke( StandardContextValve.java:174) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java :127) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java :117) at org.apache.catalina.core.StandardEngineValve.invoke( StandardEngineValve.java:108) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java :151) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:870) at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection (Http11BaseProtocol.java:665) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket( PoolTcpEndpoint.java:528) at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt( LeaderFollowerWorkerThread.java:81) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run( ThreadPool.java:685) at java.lang.Thread.run(Thread.java:595) Matej Knopp-2 wrote: There is no way that ajax requests can be processed without blocking. a) ajax requests are ordered on client into queues b) requests are blocked on target page (not session) on server side -Matej On 9/7/07, Sam
Re: threading issues - continued
Which bit of code does the blocking on the server? I'm getting what looks very much like a threading issue. I've looked at all the methods below and can't see any obvious sync code... I'm using 1.3-beta3 at org.apache.wicket.util.lang.PropertyResolver$MethodGetAndSet.getValue(PropertyResolver.java:1034) at org.apache.wicket.util.lang.PropertyResolver.getObjectAndGetSetter(PropertyResolver.java:247) at org.apache.wicket.util.lang.PropertyResolver.getValue(PropertyResolver.java:89) at org.apache.wicket.model.AbstractPropertyModel.getObject(AbstractPropertyModel.java:110) at org.apache.wicket.Component.getModelObject(Component.java:1293) at org.apache.wicket.Component$2.compare(Component.java:540) at org.apache.wicket.Component.setModelObject(Component.java:2522) at org.apache.wicket.markup.html.form.FormComponent.updateModel(FormComponent.java:1002) at org.apache.wicket.markup.html.form.Form$14.validate(Form.java:1642) at org.apache.wicket.markup.html.form.Form$ValidationVisitor.formComponent(Form.java:160) at org.apache.wicket.markup.html.form.FormComponent.visitFormComponentsPostOrderHelper(FormComponent.java:403) at org.apache.wicket.markup.html.form.FormComponent.visitFormComponentsPostOrderHelper(FormComponent.java:390) at org.apache.wicket.markup.html.form.FormComponent.visitFormComponentsPostOrderHelper(FormComponent.java:390) at org.apache.wicket.markup.html.form.FormComponent.visitFormComponentsPostOrderHelper(FormComponent.java:390) at org.apache.wicket.markup.html.form.FormComponent.visitFormComponentsPostOrderHelper(FormComponent.java:390) at org.apache.wicket.markup.html.form.FormComponent.visitFormComponentsPostOrder(FormComponent.java:368) at org.apache.wicket.markup.html.form.Form.visitFormComponentsPostOrder(Form.java:1004) at org.apache.wicket.markup.html.form.Form.updateFormComponentModels(Form.java:1637) at org.apache.wicket.markup.html.form.Form.process(Form.java:834) at org.apache.wicket.markup.html.form.Form.onFormSubmitted(Form.java:783) at org.apache.wicket.ajax.form.AjaxFormSubmitBehavior.onEvent(AjaxFormSubmitBehavior.java:126) at org.apache.wicket.ajax.AjaxEventBehavior.respond(AjaxEventBehavior.java:163) at org.apache.wicket.ajax.AbstractDefaultAjaxBehavior.onRequest(AbstractDefaultAjaxBehavior.java:268) at org.apache.wicket.request.target.component.listener.BehaviorRequestTarget.processEvents(BehaviorRequestTarget.java:100) at org.apache.wicket.request.AbstractRequestCycleProcessor.processEvents(AbstractRequestCycleProcessor.java:90) at org.apache.wicket.RequestCycle.processEventsAndRespond(RequestCycle.java:1032) at org.apache.wicket.RequestCycle.step(RequestCycle.java:1108) at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1177) at org.apache.wicket.RequestCycle.request(RequestCycle.java:500) at org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:261) at org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:127) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:210) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:174) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:108) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:151) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:870) at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:665) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:528) at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:81) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:685) at java.lang.Thread.run(Thread.java:595) Matej Knopp-2 wrote: There is no way that ajax requests can be processed without blocking. a) ajax requests are ordered on client into queues b) requests are blocked on target page (not session) on server side -Matej On 9/7/07, Sam Hough [EMAIL PROTECTED] wrote: A bit of the application lets you add items to a list using AjaxFallbackButton. All works fine if you click the buttons slowly but if I click quickly I get exceptions that look like my code is running concurrently
Re: threading issues - continued
That is pretty much it. Except that: Caused by: java.lang.NullPointerException at com.namechangedtoprotectguilty.search.Criterion.getHelper(Criterion.java:200) at sun.reflect.GeneratedMethodAccessor41.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.wicket.util.lang.PropertyResolver$MethodGetAndSet.getValue(PropertyResolver.java:1030) Blows up in our code in a way that really looks like a multithreading issue to me. If I click slowly no problems, if I click quickly on a slow page it reliably blows up. Guess I could put in a sync filter to double check that it is a sync error. We don't create any threads so apart from threading issue I can't see what else it could be... igor.vaynberg wrote: show us the full stack trace -igor On 9/18/07, Sam Hough [EMAIL PROTECTED] wrote: Which bit of code does the blocking on the server? I'm getting what looks very much like a threading issue. I've looked at all the methods below and can't see any obvious sync code... I'm using 1.3-beta3 at org.apache.wicket.util.lang.PropertyResolver$MethodGetAndSet.getValue( PropertyResolver.java:1034) at org.apache.wicket.util.lang.PropertyResolver.getObjectAndGetSetter( PropertyResolver.java:247) at org.apache.wicket.util.lang.PropertyResolver.getValue( PropertyResolver.java:89) at org.apache.wicket.model.AbstractPropertyModel.getObject( AbstractPropertyModel.java:110) at org.apache.wicket.Component.getModelObject(Component.java:1293) at org.apache.wicket.Component$2.compare(Component.java:540) at org.apache.wicket.Component.setModelObject(Component.java:2522) at org.apache.wicket.markup.html.form.FormComponent.updateModel( FormComponent.java:1002) at org.apache.wicket.markup.html.form.Form$14.validate(Form.java :1642) at org.apache.wicket.markup.html.form.Form$ValidationVisitor.formComponent( Form.java:160) at org.apache.wicket.markup.html.form.FormComponent.visitFormComponentsPostOrderHelper (FormComponent.java:403) at org.apache.wicket.markup.html.form.FormComponent.visitFormComponentsPostOrderHelper (FormComponent.java:390) at org.apache.wicket.markup.html.form.FormComponent.visitFormComponentsPostOrderHelper (FormComponent.java:390) at org.apache.wicket.markup.html.form.FormComponent.visitFormComponentsPostOrderHelper (FormComponent.java:390) at org.apache.wicket.markup.html.form.FormComponent.visitFormComponentsPostOrderHelper (FormComponent.java:390) at org.apache.wicket.markup.html.form.FormComponent.visitFormComponentsPostOrder (FormComponent.java:368) at org.apache.wicket.markup.html.form.Form.visitFormComponentsPostOrder( Form.java:1004) at org.apache.wicket.markup.html.form.Form.updateFormComponentModels( Form.java:1637) at org.apache.wicket.markup.html.form.Form.process(Form.java:834) at org.apache.wicket.markup.html.form.Form.onFormSubmitted( Form.java:783) at org.apache.wicket.ajax.form.AjaxFormSubmitBehavior.onEvent( AjaxFormSubmitBehavior.java:126) at org.apache.wicket.ajax.AjaxEventBehavior.respond(AjaxEventBehavior.java :163) at org.apache.wicket.ajax.AbstractDefaultAjaxBehavior.onRequest( AbstractDefaultAjaxBehavior.java:268) at org.apache.wicket.request.target.component.listener.BehaviorRequestTarget.processEvents (BehaviorRequestTarget.java:100) at org.apache.wicket.request.AbstractRequestCycleProcessor.processEvents( AbstractRequestCycleProcessor.java:90) at org.apache.wicket.RequestCycle.processEventsAndRespond(RequestCycle.java :1032) at org.apache.wicket.RequestCycle.step(RequestCycle.java:1108) at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1177) at org.apache.wicket.RequestCycle.request(RequestCycle.java:500) at org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:261) at org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java :127) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter( ApplicationFilterChain.java:215) at org.apache.catalina.core.ApplicationFilterChain.doFilter( ApplicationFilterChain.java:188) at org.apache.catalina.core.StandardWrapperValve.invoke( StandardWrapperValve.java:210) at org.apache.catalina.core.StandardContextValve.invoke( StandardContextValve.java:174) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java :127) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java :117) at org.apache.catalina.core.StandardEngineValve.invoke( StandardEngineValve.java:108) at
Re: threading issues - continued
the nullpointer comes from outside of wicket (criterion class) but you say if you click quickly you only get it? all pages are blocked by a barrier that is build around the pagemap. its in Session.get page method. only 1 request can pass that at the same time. but what is suddenly null that you dont expect to be null? On 9/18/07, Sam Hough [EMAIL PROTECTED] wrote: That is pretty much it. Except that: Caused by: java.lang.NullPointerException at com.namechangedtoprotectguilty.search.Criterion.getHelper(Criterion.java:200) at sun.reflect.GeneratedMethodAccessor41.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.wicket.util.lang.PropertyResolver$MethodGetAndSet.getValue(PropertyResolver.java:1030) Blows up in our code in a way that really looks like a multithreading issue to me. If I click slowly no problems, if I click quickly on a slow page it reliably blows up. Guess I could put in a sync filter to double check that it is a sync error. We don't create any threads so apart from threading issue I can't see what else it could be... igor.vaynberg wrote: show us the full stack trace -igor On 9/18/07, Sam Hough [EMAIL PROTECTED] wrote: Which bit of code does the blocking on the server? I'm getting what looks very much like a threading issue. I've looked at all the methods below and can't see any obvious sync code... I'm using 1.3-beta3 at org.apache.wicket.util.lang.PropertyResolver$MethodGetAndSet.getValue( PropertyResolver.java:1034) at org.apache.wicket.util.lang.PropertyResolver.getObjectAndGetSetter( PropertyResolver.java:247) at org.apache.wicket.util.lang.PropertyResolver.getValue( PropertyResolver.java:89) at org.apache.wicket.model.AbstractPropertyModel.getObject( AbstractPropertyModel.java:110) at org.apache.wicket.Component.getModelObject(Component.java:1293) at org.apache.wicket.Component$2.compare(Component.java:540) at org.apache.wicket.Component.setModelObject(Component.java:2522) at org.apache.wicket.markup.html.form.FormComponent.updateModel( FormComponent.java:1002) at org.apache.wicket.markup.html.form.Form$14.validate(Form.java :1642) at org.apache.wicket.markup.html.form.Form$ValidationVisitor.formComponent( Form.java:160) at org.apache.wicket.markup.html.form.FormComponent.visitFormComponentsPostOrderHelper (FormComponent.java:403) at org.apache.wicket.markup.html.form.FormComponent.visitFormComponentsPostOrderHelper (FormComponent.java:390) at org.apache.wicket.markup.html.form.FormComponent.visitFormComponentsPostOrderHelper (FormComponent.java:390) at org.apache.wicket.markup.html.form.FormComponent.visitFormComponentsPostOrderHelper (FormComponent.java:390) at org.apache.wicket.markup.html.form.FormComponent.visitFormComponentsPostOrderHelper (FormComponent.java:390) at org.apache.wicket.markup.html.form.FormComponent.visitFormComponentsPostOrder (FormComponent.java:368) at org.apache.wicket.markup.html.form.Form.visitFormComponentsPostOrder( Form.java:1004) at org.apache.wicket.markup.html.form.Form.updateFormComponentModels( Form.java:1637) at org.apache.wicket.markup.html.form.Form.process(Form.java:834) at org.apache.wicket.markup.html.form.Form.onFormSubmitted( Form.java:783) at org.apache.wicket.ajax.form.AjaxFormSubmitBehavior.onEvent( AjaxFormSubmitBehavior.java:126) at org.apache.wicket.ajax.AjaxEventBehavior.respond(AjaxEventBehavior.java :163) at org.apache.wicket.ajax.AbstractDefaultAjaxBehavior.onRequest( AbstractDefaultAjaxBehavior.java:268) at org.apache.wicket.request.target.component.listener.BehaviorRequestTarget.processEvents (BehaviorRequestTarget.java:100) at org.apache.wicket.request.AbstractRequestCycleProcessor.processEvents( AbstractRequestCycleProcessor.java:90) at org.apache.wicket.RequestCycle.processEventsAndRespond(RequestCycle.java :1032) at org.apache.wicket.RequestCycle.step(RequestCycle.java:1108) at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1177) at org.apache.wicket.RequestCycle.request(RequestCycle.java:500) at org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:261) at org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java :127) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter( ApplicationFilterChain.java:215) at org.apache.catalina.core.ApplicationFilterChain.doFilter( ApplicationFilterChain.java:188) at
Re: threading issues - continued
Must be me then. I'll try and pin it down more. Hmmm. Johan Compagner wrote: the nullpointer comes from outside of wicket (criterion class) but you say if you click quickly you only get it? all pages are blocked by a barrier that is build around the pagemap. its in Session.get page method. only 1 request can pass that at the same time. but what is suddenly null that you dont expect to be null? On 9/18/07, Sam Hough [EMAIL PROTECTED] wrote: That is pretty much it. Except that: Caused by: java.lang.NullPointerException at com.namechangedtoprotectguilty.search.Criterion.getHelper(Criterion.java:200) at sun.reflect.GeneratedMethodAccessor41.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.wicket.util.lang.PropertyResolver$MethodGetAndSet.getValue(PropertyResolver.java:1030) Blows up in our code in a way that really looks like a multithreading issue to me. If I click slowly no problems, if I click quickly on a slow page it reliably blows up. Guess I could put in a sync filter to double check that it is a sync error. We don't create any threads so apart from threading issue I can't see what else it could be... igor.vaynberg wrote: show us the full stack trace -igor On 9/18/07, Sam Hough [EMAIL PROTECTED] wrote: Which bit of code does the blocking on the server? I'm getting what looks very much like a threading issue. I've looked at all the methods below and can't see any obvious sync code... I'm using 1.3-beta3 at org.apache.wicket.util.lang.PropertyResolver$MethodGetAndSet.getValue( PropertyResolver.java:1034) at org.apache.wicket.util.lang.PropertyResolver.getObjectAndGetSetter( PropertyResolver.java:247) at org.apache.wicket.util.lang.PropertyResolver.getValue( PropertyResolver.java:89) at org.apache.wicket.model.AbstractPropertyModel.getObject( AbstractPropertyModel.java:110) at org.apache.wicket.Component.getModelObject(Component.java:1293) at org.apache.wicket.Component$2.compare(Component.java:540) at org.apache.wicket.Component.setModelObject(Component.java:2522) at org.apache.wicket.markup.html.form.FormComponent.updateModel( FormComponent.java:1002) at org.apache.wicket.markup.html.form.Form$14.validate(Form.java :1642) at org.apache.wicket.markup.html.form.Form$ValidationVisitor.formComponent( Form.java:160) at org.apache.wicket.markup.html.form.FormComponent.visitFormComponentsPostOrderHelper (FormComponent.java:403) at org.apache.wicket.markup.html.form.FormComponent.visitFormComponentsPostOrderHelper (FormComponent.java:390) at org.apache.wicket.markup.html.form.FormComponent.visitFormComponentsPostOrderHelper (FormComponent.java:390) at org.apache.wicket.markup.html.form.FormComponent.visitFormComponentsPostOrderHelper (FormComponent.java:390) at org.apache.wicket.markup.html.form.FormComponent.visitFormComponentsPostOrderHelper (FormComponent.java:390) at org.apache.wicket.markup.html.form.FormComponent.visitFormComponentsPostOrder (FormComponent.java:368) at org.apache.wicket.markup.html.form.Form.visitFormComponentsPostOrder( Form.java:1004) at org.apache.wicket.markup.html.form.Form.updateFormComponentModels( Form.java:1637) at org.apache.wicket.markup.html.form.Form.process(Form.java:834) at org.apache.wicket.markup.html.form.Form.onFormSubmitted( Form.java:783) at org.apache.wicket.ajax.form.AjaxFormSubmitBehavior.onEvent( AjaxFormSubmitBehavior.java:126) at org.apache.wicket.ajax.AjaxEventBehavior.respond(AjaxEventBehavior.java :163) at org.apache.wicket.ajax.AbstractDefaultAjaxBehavior.onRequest( AbstractDefaultAjaxBehavior.java:268) at org.apache.wicket.request.target.component.listener.BehaviorRequestTarget.processEvents (BehaviorRequestTarget.java:100) at org.apache.wicket.request.AbstractRequestCycleProcessor.processEvents( AbstractRequestCycleProcessor.java:90) at org.apache.wicket.RequestCycle.processEventsAndRespond(RequestCycle.java :1032) at org.apache.wicket.RequestCycle.step(RequestCycle.java:1108) at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1177) at org.apache.wicket.RequestCycle.request(RequestCycle.java:500) at org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:261) at org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java :127) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter( ApplicationFilterChain.java:215) at
Re: threading issues - continued
Can you be more specific? What kind of concurrency issues? -Matej On 9/7/07, Sam Hough [EMAIL PROTECTED] wrote: oops, I posted on old forum... http://www.nabble.com/threading-question-tf841003.html [all request serialised on Session object] Is this true even for Ajax requests? Is whole life cycle effectively single threaded for a single session? I think I'm seeing a concurrency issue in my website (Wicket 1.3-beta3 and lots of AjaxFallbackButton, I did listen to Igor)... Obviously would be tempting to sync on the Session but might break lot of the usability advantages of Ajax... Anybody got any top tips? -- View this message in context: http://www.nabble.com/threading-issues---continued-tf4400569.html#a12552735 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: threading issues - continued
I must be slowing down or Sun is speeding up. Huge amounts of stuff in 1.5 that I've not played with. From 1.1 to 1.2 it didn't seem that much to keep up with!? Not sure we have really slow tasks (like classic booking ticket) but we are using Alfresco for some calls and that can be slow... Thread per sluggish request is heavy duty maybe would be better with messaging... Even if within same JVM. I'm having one of those isn't Wicket wonderful weeks ;) Somebody hits a problem and I just hunt through JavaDoc to find the correct Component to plugin. Not like struts 2 where I tried to do something simple only, a few hours later, finding something in the docs about yes this sucks but only way to do it. Martijn Dashorst wrote: On 9/7/07, Sam Hough [EMAIL PROTECTED] wrote: Create a thread from within a servlet container...? Tut tut ;) Yeah, not the most elegant way since they are not monitored by the container, but it sure does get the work done. And we have really nice users that would never try to flood our server. :) And of course if you're on Java 5, you can create worker pools really easy to limit the number of concurrent threads. Martijn -- Buy Wicket in Action: http://manning.com/dashorst Apache Wicket 1.3.0-beta3 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0-beta3/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/threading-issues---continued-tf4400569.html#a1239 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: threading issues - continued
On 9/7/07, Sam Hough [EMAIL PROTECTED] wrote: Create a thread from within a servlet container...? Tut tut ;) Yeah, not the most elegant way since they are not monitored by the container, but it sure does get the work done. And we have really nice users that would never try to flood our server. :) And of course if you're on Java 5, you can create worker pools really easy to limit the number of concurrent threads. Martijn -- Buy Wicket in Action: http://manning.com/dashorst Apache Wicket 1.3.0-beta3 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0-beta3/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: threading issues - continued
Create a thread from within a servlet container...? Tut tut ;) I don't think we have any messaging or timing framework at the mo so may come to that. Martijn Dashorst wrote: On 9/7/07, Sam Hough [EMAIL PROTECTED] wrote: OK. Should give me fewer nightmares even if it doesn't explain current problem. Many thanks. It is probably just my dodgy code. What pattern do you use for long running Ajax requests? Create a worker thread in the background. If it really lasts long, craete a feedback mechanism that polls the worker thread and gives a progress indication. Martijn -- Buy Wicket in Action: http://manning.com/dashorst Apache Wicket 1.3.0-beta3 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0-beta3/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/threading-issues---continued-tf4400569.html#a12554945 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: threading issues - continued
In our application, for long running ajax request we block the screen, so the user is unable to click somewhere else. Alex. Sam Hough wrote: OK. Should give me fewer nightmares even if it doesn't explain current problem. Many thanks. It is probably just my dodgy code. What pattern do you use for long running Ajax requests? Matej Knopp-2 wrote: There is no way that ajax requests can be processed without blocking. a) ajax requests are ordered on client into queues b) requests are blocked on target page (not session) on server side -Matej On 9/7/07, Sam Hough [EMAIL PROTECTED] wrote: A bit of the application lets you add items to a list using AjaxFallbackButton. All works fine if you click the buttons slowly but if I click quickly I get exceptions that look like my code is running concurrently (nullpointer where it can't happen if running in a single thread). What behaviour is Wicket aiming to implement for Ajax and threading? Matej Knopp-2 wrote: Can you be more specific? What kind of concurrency issues? -Matej On 9/7/07, Sam Hough [EMAIL PROTECTED] wrote: oops, I posted on old forum... http://www.nabble.com/threading-question-tf841003.html [all request serialised on Session object] Is this true even for Ajax requests? Is whole life cycle effectively single threaded for a single session? I think I'm seeing a concurrency issue in my website (Wicket 1.3-beta3 and lots of AjaxFallbackButton, I did listen to Igor)... Obviously would be tempting to sync on the Session but might break lot of the usability advantages of Ajax... Anybody got any top tips? -- View this message in context: http://www.nabble.com/threading-issues---continued-tf4400569.html#a12552735 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/threading-issues---continued-tf4400569.html#a12553207 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/threading-issues---continued-tf4400569.html#a12553980 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: threading issues - continued
OK. Should give me fewer nightmares even if it doesn't explain current problem. Many thanks. It is probably just my dodgy code. What pattern do you use for long running Ajax requests? Matej Knopp-2 wrote: There is no way that ajax requests can be processed without blocking. a) ajax requests are ordered on client into queues b) requests are blocked on target page (not session) on server side -Matej On 9/7/07, Sam Hough [EMAIL PROTECTED] wrote: A bit of the application lets you add items to a list using AjaxFallbackButton. All works fine if you click the buttons slowly but if I click quickly I get exceptions that look like my code is running concurrently (nullpointer where it can't happen if running in a single thread). What behaviour is Wicket aiming to implement for Ajax and threading? Matej Knopp-2 wrote: Can you be more specific? What kind of concurrency issues? -Matej On 9/7/07, Sam Hough [EMAIL PROTECTED] wrote: oops, I posted on old forum... http://www.nabble.com/threading-question-tf841003.html [all request serialised on Session object] Is this true even for Ajax requests? Is whole life cycle effectively single threaded for a single session? I think I'm seeing a concurrency issue in my website (Wicket 1.3-beta3 and lots of AjaxFallbackButton, I did listen to Igor)... Obviously would be tempting to sync on the Session but might break lot of the usability advantages of Ajax... Anybody got any top tips? -- View this message in context: http://www.nabble.com/threading-issues---continued-tf4400569.html#a12552735 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/threading-issues---continued-tf4400569.html#a12553207 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/threading-issues---continued-tf4400569.html#a12553815 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: threading issues - continued
There is no way that ajax requests can be processed without blocking. a) ajax requests are ordered on client into queues b) requests are blocked on target page (not session) on server side -Matej On 9/7/07, Sam Hough [EMAIL PROTECTED] wrote: A bit of the application lets you add items to a list using AjaxFallbackButton. All works fine if you click the buttons slowly but if I click quickly I get exceptions that look like my code is running concurrently (nullpointer where it can't happen if running in a single thread). What behaviour is Wicket aiming to implement for Ajax and threading? Matej Knopp-2 wrote: Can you be more specific? What kind of concurrency issues? -Matej On 9/7/07, Sam Hough [EMAIL PROTECTED] wrote: oops, I posted on old forum... http://www.nabble.com/threading-question-tf841003.html [all request serialised on Session object] Is this true even for Ajax requests? Is whole life cycle effectively single threaded for a single session? I think I'm seeing a concurrency issue in my website (Wicket 1.3-beta3 and lots of AjaxFallbackButton, I did listen to Igor)... Obviously would be tempting to sync on the Session but might break lot of the usability advantages of Ajax... Anybody got any top tips? -- View this message in context: http://www.nabble.com/threading-issues---continued-tf4400569.html#a12552735 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/threading-issues---continued-tf4400569.html#a12553207 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: threading issues - continued
On 9/7/07, Sam Hough [EMAIL PROTECTED] wrote: OK. Should give me fewer nightmares even if it doesn't explain current problem. Many thanks. It is probably just my dodgy code. What pattern do you use for long running Ajax requests? Create a worker thread in the background. If it really lasts long, craete a feedback mechanism that polls the worker thread and gives a progress indication. Martijn -- Buy Wicket in Action: http://manning.com/dashorst Apache Wicket 1.3.0-beta3 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0-beta3/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
