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)
>>> >>         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 (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#a12759130
>>> >> Sent from the Wicket - User mailing list archive at Nabble.com.
>>> >>
>>> >>
>>> >> ---------------------------------------------------------------------
>>> >> 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#a12759515
>>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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#a12772965
Sent from the Wicket - User mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to