You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Sam Hough <sa...@redspr.com> on 2007/09/07 12:25:46 UTC
threading issues - continued
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: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: threading issues - continued
Posted by Sam Hough <sa...@redspr.com>.
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 <sa...@redspr.com> 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: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
>
--
View this message in context: http://www.nabble.com/threading-issues---continued-tf4400569.html#a12555539
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: threading issues - continued
Posted by Martijn Dashorst <ma...@gmail.com>.
On 9/7/07, Sam Hough <sa...@redspr.com> 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: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: threading issues - continued
Posted by Sam Hough <sa...@redspr.com>.
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 <sa...@redspr.com> 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: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
>
--
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: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: threading issues - continued
Posted by Martijn Dashorst <ma...@gmail.com>.
On 9/7/07, Sam Hough <sa...@redspr.com> 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: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: threading issues - continued
Posted by Alex Objelean <al...@isdc.ro>.
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 <sa...@redspr.com> 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 <sa...@redspr.com> 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: users-unsubscribe@wicket.apache.org
>>> >> For additional commands, e-mail: users-help@wicket.apache.org
>>> >>
>>> >>
>>> >
>>> > ---------------------------------------------------------------------
>>> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> > For additional commands, e-mail: users-help@wicket.apache.org
>>> >
>>> >
>>> >
>>>
>>> --
>>> 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: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>>
>
>
--
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: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: threading issues - continued
Posted by Sam Hough <sa...@redspr.com>.
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 <sa...@redspr.com> 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 <sa...@redspr.com> 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: users-unsubscribe@wicket.apache.org
>> >> For additional commands, e-mail: users-help@wicket.apache.org
>> >>
>> >>
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> > For additional commands, e-mail: users-help@wicket.apache.org
>> >
>> >
>> >
>>
>> --
>> 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: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
>
--
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: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: threading issues - continued
Posted by Matej Knopp <ma...@gmail.com>.
com.namechangedtoprotectguilty.search.Criterion.getHelper(Criterion.java:200)
This doesn't look like wicket...
-Matej
On 9/18/07, Sam Hough <sa...@redspr.com> 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 <sa...@redspr.com> 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 <sa...@redspr.com> 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 <sa...@redspr.com> 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: users-unsubscribe@wicket.apache.org
> >> >> >> For additional commands, e-mail: users-help@wicket.apache.org
> >> >> >>
> >> >> >>
> >> >> >
> >> >> >
> >> ---------------------------------------------------------------------
> >> >> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> >> > For additional commands, e-mail: users-help@wicket.apache.org
> >> >> >
> >> >> >
> >> >> >
> >> >>
> >> >> --
> >> >> 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: users-unsubscribe@wicket.apache.org
> >> >> For additional commands, e-mail: users-help@wicket.apache.org
> >> >>
> >> >>
> >> >
> >> > ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> > For additional commands, e-mail: users-help@wicket.apache.org
> >> >
> >> >
> >> >
> >>
> >> --
> >> 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: users-unsubscribe@wicket.apache.org
> >> For additional commands, e-mail: users-help@wicket.apache.org
> >>
> >>
> >
> >
>
> --
> 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: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: threading issues - continued
Posted by Matej Knopp <ma...@gmail.com>.
But shouldn't that be a validation error?
-Matej
On 9/19/07, Sam Hough <sa...@redspr.com> 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 <sa...@redspr.com> 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 <sa...@redspr.com> 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 <sa...@redspr.com> 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 <sa...@redspr.com> 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 <sa...@redspr.com> 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 <sa...@redspr.com> 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:
> >> users-unsubscribe@wicket.apache.org
> >> >> >>> >> >> >> For additional commands, e-mail:
> >> >> users-help@wicket.apache.org
> >> >> >>> >> >> >>
> >> >> >>> >> >> >>
> >> >> >>> >> >> >
> >> >> >>> >> >> >
> >> >> >>> >>
> >> >> ---------------------------------------------------------------------
> >> >> >>> >> >> > To unsubscribe, e-mail:
> >> users-unsubscribe@wicket.apache.org
> >> >> >>> >> >> > For additional commands, e-mail:
> >> users-help@wicket.apache.org
> >> >> >>> >> >> >
> >> >> >>> >> >> >
> >> >> >>> >> >> >
> >> >> >>> >> >>
> >> >> >>> >> >> --
> >> >> >>> >> >> 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: users-unsubscribe@wicket.apache.org
> >> >> >>> >> >> For additional commands, e-mail:
> >> users-help@wicket.apache.org
> >> >> >>> >> >>
> >> >> >>> >> >>
> >> >> >>> >> >
> >> >> >>> >> >
> >> >> >>>
> >> ---------------------------------------------------------------------
> >> >> >>> >> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> >> >>> >> > For additional commands, e-mail: users-help@wicket.apache.org
> >> >> >>> >> >
> >> >> >>> >> >
> >> >> >>> >> >
> >> >> >>> >>
> >> >> >>> >> --
> >> >> >>> >> 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: users-unsubscribe@wicket.apache.org
> >> >> >>> >> For additional commands, e-mail: users-help@wicket.apache.org
> >> >> >>> >>
> >> >> >>> >>
> >> >> >>> >
> >> >> >>> >
> >> >> >>>
> >> >> >>> --
> >> >> >>> 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: users-unsubscribe@wicket.apache.org
> >> >> >>> For additional commands, e-mail: users-help@wicket.apache.org
> >> >> >>>
> >> >> >>>
> >> >> >>
> >> >> >>
> >> >> >
> >> >> >
> >> >>
> >> >> --
> >> >> 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: users-unsubscribe@wicket.apache.org
> >> >> For additional commands, e-mail: users-help@wicket.apache.org
> >> >>
> >> >>
> >> >
> >> >
> >>
> >> --
> >> View this message in context:
> >> http://www.nabble.com/threading-issues---continued-tf4400569.html#a12774734
> >> Sent from the Wicket - User mailing list archive at Nabble.com.
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> For additional commands, e-mail: users-help@wicket.apache.org
> >>
> >>
> >
> >
>
> --
> View this message in context: http://www.nabble.com/threading-issues---continued-tf4400569.html#a12774961
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: threading issues - continued
Posted by Sam Hough <sa...@redspr.com>.
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 <sa...@redspr.com> 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 <sa...@redspr.com> 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 <sa...@redspr.com> 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 <sa...@redspr.com> 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 <sa...@redspr.com> 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 <sa...@redspr.com> 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:
>> users-unsubscribe@wicket.apache.org
>> >> >>> >> >> >> For additional commands, e-mail:
>> >> users-help@wicket.apache.org
>> >> >>> >> >> >>
>> >> >>> >> >> >>
>> >> >>> >> >> >
>> >> >>> >> >> >
>> >> >>> >>
>> >> ---------------------------------------------------------------------
>> >> >>> >> >> > To unsubscribe, e-mail:
>> users-unsubscribe@wicket.apache.org
>> >> >>> >> >> > For additional commands, e-mail:
>> users-help@wicket.apache.org
>> >> >>> >> >> >
>> >> >>> >> >> >
>> >> >>> >> >> >
>> >> >>> >> >>
>> >> >>> >> >> --
>> >> >>> >> >> 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: users-unsubscribe@wicket.apache.org
>> >> >>> >> >> For additional commands, e-mail:
>> users-help@wicket.apache.org
>> >> >>> >> >>
>> >> >>> >> >>
>> >> >>> >> >
>> >> >>> >> >
>> >> >>>
>> ---------------------------------------------------------------------
>> >> >>> >> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >> >>> >> > For additional commands, e-mail: users-help@wicket.apache.org
>> >> >>> >> >
>> >> >>> >> >
>> >> >>> >> >
>> >> >>> >>
>> >> >>> >> --
>> >> >>> >> 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: users-unsubscribe@wicket.apache.org
>> >> >>> >> For additional commands, e-mail: users-help@wicket.apache.org
>> >> >>> >>
>> >> >>> >>
>> >> >>> >
>> >> >>> >
>> >> >>>
>> >> >>> --
>> >> >>> 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: users-unsubscribe@wicket.apache.org
>> >> >>> For additional commands, e-mail: users-help@wicket.apache.org
>> >> >>>
>> >> >>>
>> >> >>
>> >> >>
>> >> >
>> >> >
>> >>
>> >> --
>> >> 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: users-unsubscribe@wicket.apache.org
>> >> For additional commands, e-mail: users-help@wicket.apache.org
>> >>
>> >>
>> >
>> >
>>
>> --
>> View this message in context:
>> http://www.nabble.com/threading-issues---continued-tf4400569.html#a12774734
>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
>
--
View this message in context: http://www.nabble.com/threading-issues---continued-tf4400569.html#a12774961
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: threading issues - continued
Posted by Johan Compagner <jc...@gmail.com>.
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 <sa...@redspr.com> 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 <sa...@redspr.com> 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 <sa...@redspr.com> 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 <sa...@redspr.com> 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 <sa...@redspr.com> 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 <sa...@redspr.com> 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:
> users-unsubscribe@wicket.apache.org
> >> >>> >> >> >> For additional commands, e-mail:
> >> users-help@wicket.apache.org
> >> >>> >> >> >>
> >> >>> >> >> >>
> >> >>> >> >> >
> >> >>> >> >> >
> >> >>> >>
> >> ---------------------------------------------------------------------
> >> >>> >> >> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> >>> >> >> > For additional commands, e-mail:
> users-help@wicket.apache.org
> >> >>> >> >> >
> >> >>> >> >> >
> >> >>> >> >> >
> >> >>> >> >>
> >> >>> >> >> --
> >> >>> >> >> 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: users-unsubscribe@wicket.apache.org
> >> >>> >> >> For additional commands, e-mail: users-help@wicket.apache.org
> >> >>> >> >>
> >> >>> >> >>
> >> >>> >> >
> >> >>> >> >
> >> >>>
> ---------------------------------------------------------------------
> >> >>> >> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> >>> >> > For additional commands, e-mail: users-help@wicket.apache.org
> >> >>> >> >
> >> >>> >> >
> >> >>> >> >
> >> >>> >>
> >> >>> >> --
> >> >>> >> 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: users-unsubscribe@wicket.apache.org
> >> >>> >> For additional commands, e-mail: users-help@wicket.apache.org
> >> >>> >>
> >> >>> >>
> >> >>> >
> >> >>> >
> >> >>>
> >> >>> --
> >> >>> 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: users-unsubscribe@wicket.apache.org
> >> >>> For additional commands, e-mail: users-help@wicket.apache.org
> >> >>>
> >> >>>
> >> >>
> >> >>
> >> >
> >> >
> >>
> >> --
> >> 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: users-unsubscribe@wicket.apache.org
> >> For additional commands, e-mail: users-help@wicket.apache.org
> >>
> >>
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/threading-issues---continued-tf4400569.html#a12774734
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: threading issues - continued
Posted by Matej Knopp <ma...@gmail.com>.
warm beer? eew :)
-Matej
On 9/21/07, Sam Hough <sa...@redspr.com> wrote:
>
> 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: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: threading issues - continued
Posted by Sam Hough <sa...@redspr.com>.
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: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: threading issues - continued
Posted by Matej Knopp <ma...@gmail.com>.
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 <ma...@gmail.com> 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 <sa...@redspr.com> 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 <sa...@redspr.com> 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 <sa...@redspr.com> 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: users-unsubscribe@wicket.apache.org
> > >> > For additional commands, e-mail: users-help@wicket.apache.org
> > >> >
> > >> >
> > >> >
> > >>
> > >> --
> > >> 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: users-unsubscribe@wicket.apache.org
> > >> For additional commands, e-mail: users-help@wicket.apache.org
> > >>
> > >>
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > > For additional commands, e-mail: users-help@wicket.apache.org
> > >
> > >
> > >
> >
> > --
> > 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: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: threading issues - continued
Posted by Matej Knopp <ma...@gmail.com>.
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 <sa...@redspr.com> 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 <sa...@redspr.com> 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 <sa...@redspr.com> 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: users-unsubscribe@wicket.apache.org
> >> > For additional commands, e-mail: users-help@wicket.apache.org
> >> >
> >> >
> >> >
> >>
> >> --
> >> 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: users-unsubscribe@wicket.apache.org
> >> For additional commands, e-mail: users-help@wicket.apache.org
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
> >
>
> --
> 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: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: threading issues - continued
Posted by Sam Hough <sa...@redspr.com>.
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 <sa...@redspr.com> 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 <sa...@redspr.com> 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: users-unsubscribe@wicket.apache.org
>> > For additional commands, e-mail: users-help@wicket.apache.org
>> >
>> >
>> >
>>
>> --
>> 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: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
>
--
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: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: threading issues - continued
Posted by Matej Knopp <ma...@gmail.com>.
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 <sa...@redspr.com> 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 <sa...@redspr.com> 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: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
> >
>
> --
> 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: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: threading issues - continued
Posted by Sam Hough <sa...@redspr.com>.
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 <sa...@redspr.com> 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: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
>
--
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: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: threading issues - continued
Posted by Eelco Hillenius <ee...@gmail.com>.
On 9/20/07, Sam Hough <sa...@redspr.com> 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: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: threading issues - continued
Posted by Sam Hough <sa...@redspr.com>.
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 <sa...@redspr.com> 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 <sa...@redspr.com> 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 <sa...@redspr.com> 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 <sa...@redspr.com> 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 <sa...@redspr.com> 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 <sa...@redspr.com> 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 <sa...@redspr.com> 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:
>> >> users-unsubscribe@wicket.apache.org
>> >> >> >>> >> >> >> For additional commands, e-mail:
>> >> >> users-help@wicket.apache.org
>> >> >> >>> >> >> >>
>> >> >> >>> >> >> >>
>> >> >> >>> >> >> >
>> >> >> >>> >> >> >
>> >> >> >>> >>
>> >> >>
>> ---------------------------------------------------------------------
>> >> >> >>> >> >> > To unsubscribe, e-mail:
>> >> users-unsubscribe@wicket.apache.org
>> >> >> >>> >> >> > For additional commands, e-mail:
>> >> users-help@wicket.apache.org
>> >> >> >>> >> >> >
>> >> >> >>> >> >> >
>> >> >> >>> >> >> >
>> >> >> >>> >> >>
>> >> >> >>> >> >> --
>> >> >> >>> >> >> 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:
>> users-unsubscribe@wicket.apache.org
>> >> >> >>> >> >> For additional commands, e-mail:
>> >> users-help@wicket.apache.org
>> >> >> >>> >> >>
>> >> >> >>> >> >>
>> >> >> >>> >> >
>> >> >> >>> >> >
>> >> >> >>>
>> >> ---------------------------------------------------------------------
>> >> >> >>> >> > To unsubscribe, e-mail:
>> users-unsubscribe@wicket.apache.org
>> >> >> >>> >> > For additional commands, e-mail:
>> users-help@wicket.apache.org
>> >> >> >>> >> >
>> >> >> >>> >> >
>> >> >> >>> >> >
>> >> >> >>> >>
>> >> >> >>> >> --
>> >> >> >>> >> 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: users-unsubscribe@wicket.apache.org
>> >> >> >>> >> For additional commands, e-mail:
>> users-help@wicket.apache.org
>> >> >> >>> >>
>> >> >> >>> >>
>> >> >> >>> >
>> >> >> >>> >
>> >> >> >>>
>> >> >> >>> --
>> >> >> >>> 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: users-unsubscribe@wicket.apache.org
>> >> >> >>> For additional commands, e-mail: users-help@wicket.apache.org
>> >> >> >>>
>> >> >> >>>
>> >> >> >>
>> >> >> >>
>> >> >> >
>> >> >> >
>> >> >>
>> >> >> --
>> >> >> 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: users-unsubscribe@wicket.apache.org
>> >> >> For additional commands, e-mail: users-help@wicket.apache.org
>> >> >>
>> >> >>
>> >> >
>> >> >
>> >>
>> >> --
>> >> View this message in context:
>> >>
>> http://www.nabble.com/threading-issues---continued-tf4400569.html#a12774734
>> >> Sent from the Wicket - User mailing list archive at Nabble.com.
>> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >> For additional commands, e-mail: users-help@wicket.apache.org
>> >>
>> >>
>> >
>> >
>>
>> --
>> View this message in context:
>> http://www.nabble.com/threading-issues---continued-tf4400569.html#a12774963
>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
>
--
View this message in context: http://www.nabble.com/threading-issues---continued-tf4400569.html#a12794149
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: threading issues - continued
Posted by Sam Hough <sa...@redspr.com>.
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 <sa...@redspr.com> 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 <sa...@redspr.com> 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 <sa...@redspr.com> 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 <sa...@redspr.com> 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 <sa...@redspr.com> 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 <sa...@redspr.com> 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 <sa...@redspr.com> 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:
>> >> users-unsubscribe@wicket.apache.org
>> >> >> >>> >> >> >> For additional commands, e-mail:
>> >> >> users-help@wicket.apache.org
>> >> >> >>> >> >> >>
>> >> >> >>> >> >> >>
>> >> >> >>> >> >> >
>> >> >> >>> >> >> >
>> >> >> >>> >>
>> >> >>
>> ---------------------------------------------------------------------
>> >> >> >>> >> >> > To unsubscribe, e-mail:
>> >> users-unsubscribe@wicket.apache.org
>> >> >> >>> >> >> > For additional commands, e-mail:
>> >> users-help@wicket.apache.org
>> >> >> >>> >> >> >
>> >> >> >>> >> >> >
>> >> >> >>> >> >> >
>> >> >> >>> >> >>
>> >> >> >>> >> >> --
>> >> >> >>> >> >> 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:
>> users-unsubscribe@wicket.apache.org
>> >> >> >>> >> >> For additional commands, e-mail:
>> >> users-help@wicket.apache.org
>> >> >> >>> >> >>
>> >> >> >>> >> >>
>> >> >> >>> >> >
>> >> >> >>> >> >
>> >> >> >>>
>> >> ---------------------------------------------------------------------
>> >> >> >>> >> > To unsubscribe, e-mail:
>> users-unsubscribe@wicket.apache.org
>> >> >> >>> >> > For additional commands, e-mail:
>> users-help@wicket.apache.org
>> >> >> >>> >> >
>> >> >> >>> >> >
>> >> >> >>> >> >
>> >> >> >>> >>
>> >> >> >>> >> --
>> >> >> >>> >> 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: users-unsubscribe@wicket.apache.org
>> >> >> >>> >> For additional commands, e-mail:
>> users-help@wicket.apache.org
>> >> >> >>> >>
>> >> >> >>> >>
>> >> >> >>> >
>> >> >> >>> >
>> >> >> >>>
>> >> >> >>> --
>> >> >> >>> 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: users-unsubscribe@wicket.apache.org
>> >> >> >>> For additional commands, e-mail: users-help@wicket.apache.org
>> >> >> >>>
>> >> >> >>>
>> >> >> >>
>> >> >> >>
>> >> >> >
>> >> >> >
>> >> >>
>> >> >> --
>> >> >> 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: users-unsubscribe@wicket.apache.org
>> >> >> For additional commands, e-mail: users-help@wicket.apache.org
>> >> >>
>> >> >>
>> >> >
>> >> >
>> >>
>> >> --
>> >> View this message in context:
>> >>
>> http://www.nabble.com/threading-issues---continued-tf4400569.html#a12774734
>> >> Sent from the Wicket - User mailing list archive at Nabble.com.
>> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >> For additional commands, e-mail: users-help@wicket.apache.org
>> >>
>> >>
>> >
>> >
>>
>> --
>> View this message in context:
>> http://www.nabble.com/threading-issues---continued-tf4400569.html#a12774963
>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
>
--
View this message in context: http://www.nabble.com/threading-issues---continued-tf4400569.html#a12778151
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: threading issues - continued
Posted by Matej Knopp <ma...@gmail.com>.
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 <sa...@redspr.com> 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 <sa...@redspr.com> 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 <sa...@redspr.com> 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 <sa...@redspr.com> 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 <sa...@redspr.com> 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 <sa...@redspr.com> 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 <sa...@redspr.com> 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:
> >> users-unsubscribe@wicket.apache.org
> >> >> >>> >> >> >> For additional commands, e-mail:
> >> >> users-help@wicket.apache.org
> >> >> >>> >> >> >>
> >> >> >>> >> >> >>
> >> >> >>> >> >> >
> >> >> >>> >> >> >
> >> >> >>> >>
> >> >> ---------------------------------------------------------------------
> >> >> >>> >> >> > To unsubscribe, e-mail:
> >> users-unsubscribe@wicket.apache.org
> >> >> >>> >> >> > For additional commands, e-mail:
> >> users-help@wicket.apache.org
> >> >> >>> >> >> >
> >> >> >>> >> >> >
> >> >> >>> >> >> >
> >> >> >>> >> >>
> >> >> >>> >> >> --
> >> >> >>> >> >> 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: users-unsubscribe@wicket.apache.org
> >> >> >>> >> >> For additional commands, e-mail:
> >> users-help@wicket.apache.org
> >> >> >>> >> >>
> >> >> >>> >> >>
> >> >> >>> >> >
> >> >> >>> >> >
> >> >> >>>
> >> ---------------------------------------------------------------------
> >> >> >>> >> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> >> >>> >> > For additional commands, e-mail: users-help@wicket.apache.org
> >> >> >>> >> >
> >> >> >>> >> >
> >> >> >>> >> >
> >> >> >>> >>
> >> >> >>> >> --
> >> >> >>> >> 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: users-unsubscribe@wicket.apache.org
> >> >> >>> >> For additional commands, e-mail: users-help@wicket.apache.org
> >> >> >>> >>
> >> >> >>> >>
> >> >> >>> >
> >> >> >>> >
> >> >> >>>
> >> >> >>> --
> >> >> >>> 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: users-unsubscribe@wicket.apache.org
> >> >> >>> For additional commands, e-mail: users-help@wicket.apache.org
> >> >> >>>
> >> >> >>>
> >> >> >>
> >> >> >>
> >> >> >
> >> >> >
> >> >>
> >> >> --
> >> >> 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: users-unsubscribe@wicket.apache.org
> >> >> For additional commands, e-mail: users-help@wicket.apache.org
> >> >>
> >> >>
> >> >
> >> >
> >>
> >> --
> >> View this message in context:
> >> http://www.nabble.com/threading-issues---continued-tf4400569.html#a12774734
> >> Sent from the Wicket - User mailing list archive at Nabble.com.
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> For additional commands, e-mail: users-help@wicket.apache.org
> >>
> >>
> >
> >
>
> --
> View this message in context: http://www.nabble.com/threading-issues---continued-tf4400569.html#a12774963
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: threading issues - continued
Posted by Sam Hough <sa...@redspr.com>.
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 <sa...@redspr.com> 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 <sa...@redspr.com> 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 <sa...@redspr.com> 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 <sa...@redspr.com> 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 <sa...@redspr.com> 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 <sa...@redspr.com> 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:
>> users-unsubscribe@wicket.apache.org
>> >> >>> >> >> >> For additional commands, e-mail:
>> >> users-help@wicket.apache.org
>> >> >>> >> >> >>
>> >> >>> >> >> >>
>> >> >>> >> >> >
>> >> >>> >> >> >
>> >> >>> >>
>> >> ---------------------------------------------------------------------
>> >> >>> >> >> > To unsubscribe, e-mail:
>> users-unsubscribe@wicket.apache.org
>> >> >>> >> >> > For additional commands, e-mail:
>> users-help@wicket.apache.org
>> >> >>> >> >> >
>> >> >>> >> >> >
>> >> >>> >> >> >
>> >> >>> >> >>
>> >> >>> >> >> --
>> >> >>> >> >> 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: users-unsubscribe@wicket.apache.org
>> >> >>> >> >> For additional commands, e-mail:
>> users-help@wicket.apache.org
>> >> >>> >> >>
>> >> >>> >> >>
>> >> >>> >> >
>> >> >>> >> >
>> >> >>>
>> ---------------------------------------------------------------------
>> >> >>> >> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >> >>> >> > For additional commands, e-mail: users-help@wicket.apache.org
>> >> >>> >> >
>> >> >>> >> >
>> >> >>> >> >
>> >> >>> >>
>> >> >>> >> --
>> >> >>> >> 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: users-unsubscribe@wicket.apache.org
>> >> >>> >> For additional commands, e-mail: users-help@wicket.apache.org
>> >> >>> >>
>> >> >>> >>
>> >> >>> >
>> >> >>> >
>> >> >>>
>> >> >>> --
>> >> >>> 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: users-unsubscribe@wicket.apache.org
>> >> >>> For additional commands, e-mail: users-help@wicket.apache.org
>> >> >>>
>> >> >>>
>> >> >>
>> >> >>
>> >> >
>> >> >
>> >>
>> >> --
>> >> 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: users-unsubscribe@wicket.apache.org
>> >> For additional commands, e-mail: users-help@wicket.apache.org
>> >>
>> >>
>> >
>> >
>>
>> --
>> View this message in context:
>> http://www.nabble.com/threading-issues---continued-tf4400569.html#a12774734
>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
>
--
View this message in context: http://www.nabble.com/threading-issues---continued-tf4400569.html#a12774963
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: threading issues - continued
Posted by Matej Knopp <ma...@gmail.com>.
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 <sa...@redspr.com> 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 <sa...@redspr.com> 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 <sa...@redspr.com> 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 <sa...@redspr.com> 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 <sa...@redspr.com> 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 <sa...@redspr.com> 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: users-unsubscribe@wicket.apache.org
> >> >>> >> >> >> For additional commands, e-mail:
> >> users-help@wicket.apache.org
> >> >>> >> >> >>
> >> >>> >> >> >>
> >> >>> >> >> >
> >> >>> >> >> >
> >> >>> >>
> >> ---------------------------------------------------------------------
> >> >>> >> >> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> >>> >> >> > For additional commands, e-mail: users-help@wicket.apache.org
> >> >>> >> >> >
> >> >>> >> >> >
> >> >>> >> >> >
> >> >>> >> >>
> >> >>> >> >> --
> >> >>> >> >> 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: users-unsubscribe@wicket.apache.org
> >> >>> >> >> For additional commands, e-mail: users-help@wicket.apache.org
> >> >>> >> >>
> >> >>> >> >>
> >> >>> >> >
> >> >>> >> >
> >> >>> ---------------------------------------------------------------------
> >> >>> >> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> >>> >> > For additional commands, e-mail: users-help@wicket.apache.org
> >> >>> >> >
> >> >>> >> >
> >> >>> >> >
> >> >>> >>
> >> >>> >> --
> >> >>> >> 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: users-unsubscribe@wicket.apache.org
> >> >>> >> For additional commands, e-mail: users-help@wicket.apache.org
> >> >>> >>
> >> >>> >>
> >> >>> >
> >> >>> >
> >> >>>
> >> >>> --
> >> >>> 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: users-unsubscribe@wicket.apache.org
> >> >>> For additional commands, e-mail: users-help@wicket.apache.org
> >> >>>
> >> >>>
> >> >>
> >> >>
> >> >
> >> >
> >>
> >> --
> >> 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: users-unsubscribe@wicket.apache.org
> >> For additional commands, e-mail: users-help@wicket.apache.org
> >>
> >>
> >
> >
>
> --
> View this message in context: http://www.nabble.com/threading-issues---continued-tf4400569.html#a12774734
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: threading issues - continued
Posted by Sam Hough <sa...@redspr.com>.
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 <sa...@redspr.com> 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 <sa...@redspr.com> 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 <sa...@redspr.com> 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 <sa...@redspr.com> 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 <sa...@redspr.com> 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: users-unsubscribe@wicket.apache.org
>> >>> >> >> >> For additional commands, e-mail:
>> users-help@wicket.apache.org
>> >>> >> >> >>
>> >>> >> >> >>
>> >>> >> >> >
>> >>> >> >> >
>> >>> >>
>> ---------------------------------------------------------------------
>> >>> >> >> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >>> >> >> > For additional commands, e-mail: users-help@wicket.apache.org
>> >>> >> >> >
>> >>> >> >> >
>> >>> >> >> >
>> >>> >> >>
>> >>> >> >> --
>> >>> >> >> 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: users-unsubscribe@wicket.apache.org
>> >>> >> >> For additional commands, e-mail: users-help@wicket.apache.org
>> >>> >> >>
>> >>> >> >>
>> >>> >> >
>> >>> >> >
>> >>> ---------------------------------------------------------------------
>> >>> >> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >>> >> > For additional commands, e-mail: users-help@wicket.apache.org
>> >>> >> >
>> >>> >> >
>> >>> >> >
>> >>> >>
>> >>> >> --
>> >>> >> 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: users-unsubscribe@wicket.apache.org
>> >>> >> For additional commands, e-mail: users-help@wicket.apache.org
>> >>> >>
>> >>> >>
>> >>> >
>> >>> >
>> >>>
>> >>> --
>> >>> 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: users-unsubscribe@wicket.apache.org
>> >>> For additional commands, e-mail: users-help@wicket.apache.org
>> >>>
>> >>>
>> >>
>> >>
>> >
>> >
>>
>> --
>> 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: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
>
--
View this message in context: http://www.nabble.com/threading-issues---continued-tf4400569.html#a12774734
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: threading issues - continued
Posted by Johan Compagner <jc...@gmail.com>.
do you click fast on a dom portion that is being replaced by the previous
request?
johan
On 9/19/07, Sam Hough <sa...@redspr.com> 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 <sa...@redspr.com> 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 <sa...@redspr.com> 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 <sa...@redspr.com> 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 <sa...@redspr.com> 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: users-unsubscribe@wicket.apache.org
> >>> >> >> >> For additional commands, e-mail: users-help@wicket.apache.org
> >>> >> >> >>
> >>> >> >> >>
> >>> >> >> >
> >>> >> >> >
> >>> >>
> ---------------------------------------------------------------------
> >>> >> >> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >>> >> >> > For additional commands, e-mail: users-help@wicket.apache.org
> >>> >> >> >
> >>> >> >> >
> >>> >> >> >
> >>> >> >>
> >>> >> >> --
> >>> >> >> 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: users-unsubscribe@wicket.apache.org
> >>> >> >> For additional commands, e-mail: users-help@wicket.apache.org
> >>> >> >>
> >>> >> >>
> >>> >> >
> >>> >> >
> >>> ---------------------------------------------------------------------
> >>> >> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >>> >> > For additional commands, e-mail: users-help@wicket.apache.org
> >>> >> >
> >>> >> >
> >>> >> >
> >>> >>
> >>> >> --
> >>> >> 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: users-unsubscribe@wicket.apache.org
> >>> >> For additional commands, e-mail: users-help@wicket.apache.org
> >>> >>
> >>> >>
> >>> >
> >>> >
> >>>
> >>> --
> >>> 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: users-unsubscribe@wicket.apache.org
> >>> For additional commands, e-mail: users-help@wicket.apache.org
> >>>
> >>>
> >>
> >>
> >
> >
>
> --
> 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: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: threading issues - continued
Posted by Sam Hough <sa...@redspr.com>.
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 <sa...@redspr.com> 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 <sa...@redspr.com> 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 <sa...@redspr.com> 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 <sa...@redspr.com> 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: users-unsubscribe@wicket.apache.org
>>> >> >> >> For additional commands, e-mail: users-help@wicket.apache.org
>>> >> >> >>
>>> >> >> >>
>>> >> >> >
>>> >> >> >
>>> >> ---------------------------------------------------------------------
>>> >> >> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> >> >> > For additional commands, e-mail: users-help@wicket.apache.org
>>> >> >> >
>>> >> >> >
>>> >> >> >
>>> >> >>
>>> >> >> --
>>> >> >> 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: users-unsubscribe@wicket.apache.org
>>> >> >> For additional commands, e-mail: users-help@wicket.apache.org
>>> >> >>
>>> >> >>
>>> >> >
>>> >> >
>>> ---------------------------------------------------------------------
>>> >> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> >> > For additional commands, e-mail: users-help@wicket.apache.org
>>> >> >
>>> >> >
>>> >> >
>>> >>
>>> >> --
>>> >> 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: users-unsubscribe@wicket.apache.org
>>> >> For additional commands, e-mail: users-help@wicket.apache.org
>>> >>
>>> >>
>>> >
>>> >
>>>
>>> --
>>> 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: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>
>>
>
>
--
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: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: threading issues - continued
Posted by Sam Hough <sa...@redspr.com>.
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 <sa...@redspr.com> 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 <sa...@redspr.com> 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 <sa...@redspr.com> 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 <sa...@redspr.com> 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: users-unsubscribe@wicket.apache.org
>> >> >> >> For additional commands, e-mail: users-help@wicket.apache.org
>> >> >> >>
>> >> >> >>
>> >> >> >
>> >> >> >
>> >> ---------------------------------------------------------------------
>> >> >> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >> >> > For additional commands, e-mail: users-help@wicket.apache.org
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >>
>> >> >> --
>> >> >> 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: users-unsubscribe@wicket.apache.org
>> >> >> For additional commands, e-mail: users-help@wicket.apache.org
>> >> >>
>> >> >>
>> >> >
>> >> >
>> ---------------------------------------------------------------------
>> >> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >> > For additional commands, e-mail: users-help@wicket.apache.org
>> >> >
>> >> >
>> >> >
>> >>
>> >> --
>> >> 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: users-unsubscribe@wicket.apache.org
>> >> For additional commands, e-mail: users-help@wicket.apache.org
>> >>
>> >>
>> >
>> >
>>
>> --
>> 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: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
>
--
View this message in context: http://www.nabble.com/threading-issues---continued-tf4400569.html#a12763016
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: threading issues - continued
Posted by Johan Compagner <jc...@gmail.com>.
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 <sa...@redspr.com> 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 <sa...@redspr.com> 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 <sa...@redspr.com> 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 <sa...@redspr.com> 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: users-unsubscribe@wicket.apache.org
> >> >> >> For additional commands, e-mail: users-help@wicket.apache.org
> >> >> >>
> >> >> >>
> >> >> >
> >> >> >
> >> ---------------------------------------------------------------------
> >> >> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> >> > For additional commands, e-mail: users-help@wicket.apache.org
> >> >> >
> >> >> >
> >> >> >
> >> >>
> >> >> --
> >> >> 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: users-unsubscribe@wicket.apache.org
> >> >> For additional commands, e-mail: users-help@wicket.apache.org
> >> >>
> >> >>
> >> >
> >> > ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> > For additional commands, e-mail: users-help@wicket.apache.org
> >> >
> >> >
> >> >
> >>
> >> --
> >> 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: users-unsubscribe@wicket.apache.org
> >> For additional commands, e-mail: users-help@wicket.apache.org
> >>
> >>
> >
> >
>
> --
> 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: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: threading issues - continued
Posted by Sam Hough <sa...@redspr.com>.
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 <sa...@redspr.com> 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 <sa...@redspr.com> 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 <sa...@redspr.com> 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: users-unsubscribe@wicket.apache.org
>> >> >> For additional commands, e-mail: users-help@wicket.apache.org
>> >> >>
>> >> >>
>> >> >
>> >> >
>> ---------------------------------------------------------------------
>> >> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >> > For additional commands, e-mail: users-help@wicket.apache.org
>> >> >
>> >> >
>> >> >
>> >>
>> >> --
>> >> 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: users-unsubscribe@wicket.apache.org
>> >> For additional commands, e-mail: users-help@wicket.apache.org
>> >>
>> >>
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> > For additional commands, e-mail: users-help@wicket.apache.org
>> >
>> >
>> >
>>
>> --
>> 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: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
>
--
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: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: threading issues - continued
Posted by Igor Vaynberg <ig...@gmail.com>.
show us the full stack trace
-igor
On 9/18/07, Sam Hough <sa...@redspr.com> 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 <sa...@redspr.com> 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 <sa...@redspr.com> 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: users-unsubscribe@wicket.apache.org
> >> >> For additional commands, e-mail: users-help@wicket.apache.org
> >> >>
> >> >>
> >> >
> >> > ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> > For additional commands, e-mail: users-help@wicket.apache.org
> >> >
> >> >
> >> >
> >>
> >> --
> >> 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: users-unsubscribe@wicket.apache.org
> >> For additional commands, e-mail: users-help@wicket.apache.org
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
> >
>
> --
> 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: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: threading issues - continued
Posted by Sam Hough <sa...@redspr.com>.
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 <sa...@redspr.com> 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 <sa...@redspr.com> 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: users-unsubscribe@wicket.apache.org
>> >> For additional commands, e-mail: users-help@wicket.apache.org
>> >>
>> >>
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> > For additional commands, e-mail: users-help@wicket.apache.org
>> >
>> >
>> >
>>
>> --
>> 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: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
>
--
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: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: threading issues - continued
Posted by Matej Knopp <ma...@gmail.com>.
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 <sa...@redspr.com> 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 <sa...@redspr.com> 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: users-unsubscribe@wicket.apache.org
> >> For additional commands, e-mail: users-help@wicket.apache.org
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
> >
>
> --
> 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: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: threading issues - continued
Posted by Sam Hough <sa...@redspr.com>.
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 <sa...@redspr.com> 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: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
>
--
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: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: threading issues - continued
Posted by Matej Knopp <ma...@gmail.com>.
Can you be more specific? What kind of concurrency issues?
-Matej
On 9/7/07, Sam Hough <sa...@redspr.com> 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: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org