[jira] [Commented] (WICKET-6861) Possible race condition in clearing and triggering of Wicket timers

2021-01-21 Thread Emond Papegaaij (Jira)


[ 
https://issues.apache.org/jira/browse/WICKET-6861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17269967#comment-17269967
 ] 

Emond Papegaaij commented on WICKET-6861:
-

We've hit the same error again, with our patched version of 
{{wicket-ajax-jquery.js}}, so the proposed change does not help. However, we've 
also added a lot of logging (also to {{wicket-ajax-jquery.js}}) and captured 
the console logs from the browser. I think I now know what is happening:

* The page is rendered with the timer activated
* The timer triggers and sends its Ajax request. Wicket Timers only trigger 
once, so at this point the timer is cleared in the browser.
* The test clicks the Ajax link
* The click handler tries to clear the timer, but it is inactive, so nothing 
happens.
* The Ajax request is queued on the channel.
* The response from the timer comes in and it sets the new timeout for the next 
timer trigger.
* The queued Ajax request for the click is now executed.
* Lots of processing happens at the server
* The timer triggers again, even though it was supposed not to.

This sequence of events makes sense, but I'm not sure how to actually fix it. 
The fact that these timers are triggered in the browser but managed on the 
server makes it very hard to cover these race conditions.

> Possible race condition in clearing and triggering of Wicket timers
> ---
>
> Key: WICKET-6861
> URL: https://issues.apache.org/jira/browse/WICKET-6861
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket-core
>Affects Versions: 9.2.0
>Reporter: Emond Papegaaij
>Priority: Minor
>
> In our test suite we see some intermittent failures related to 
> {{AbstractAjaxTimerBehavior}}. At a few places in our application, we use a 
> background poller at a 1 sec interval that checks for an out-of-band 
> submission of the form data. So the user either has to fill the form via the 
> web interface or via some other route. Either route can complete the form, 
> but as soon as one of the two is triggered, the other must stop. The race 
> condition lies in the {{AbstractAjaxTimerBehavior}} triggering while the user 
> has already submitted the form manually.
> The naive implementation would stop {{AbstractAjaxTimerBehavior}} via 
> {{Wicket.Timer.clear('timer0')}} in the Ajax response of the form submit. 
> However, this results in a very large gap between the moment of submission 
> and the actual moment the timer is stopped. To fix this, we've added the 
> following code to the {{AjaxSubmitLink}}:
> {code:java}
> @Override
> public void renderHead(IHeaderResponse response) {
> super.renderHead(response);
> response.render(OnDomReadyHeaderItem.forScript(
> "Wicket.Event.add('" + getMarkupId() + "', 'click', " +
> "function() {Wicket.Timer.clear('" + getTimerId() + "');})"));
> }
> {code}
> This puts the call to {{Wicket.Timer.clear}} before the actual Ajax submit 
> and should therefore prevent the timer from triggering after the Ajax submit 
> is done. However, in very rare occurrences we still see the timer triggering. 
> When it happens, the timer is always directly after the Ajax submit (often 
> within 10ms). This makes us believe the current implementation has a race 
> condition in the following way:
> * The user clicks the Ajax submit link
> * The execution of the event handlers is started in the browser
> * At this moment the {{setTimeout}} triggers, but it is suspended because JS 
> is single threaded and the browser is already execution JS in response to UI 
> interaction
> * The first event handler now clears the timer
> * The second event handler performs the Ajax call
> * Now the JS executor is freed and the timer function is executed
> Although I'm not entirely at home in the execution model of JS in a browser, 
> this is the only explanation I could come up with. There is no way to 
> reproduce it, other than run a complex test suite 1000ths of times. My 
> proposed fix is to replace the timeout function in {{wicket-ajax-jquery.js}} 
> in {{Wicket.Timer.set}} with this:
> {code:javascript}
> Wicket.TimerHandles[timerId] = setTimeout(function() {
> if (timerId in Wicket.TimerHandles) {
> Wicket.Timer.clear(timerId);
> f();
> }
> }, delay);
> {code}
> This should prevent the function {{f()}} to be executed after the timer has 
> been cleared (Wicket.Timer.clear deletes the {{timerId}} from 
> {{Wicket.TimerHandles}}.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Resolved] (WICKET-6862) Add @Autowired annotation to SpringInjector

2021-01-21 Thread Sven Meier (Jira)


 [ 
https://issues.apache.org/jira/browse/WICKET-6862?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sven Meier resolved WICKET-6862.

Resolution: Won't Fix

As powwowed, Wicket can/will not reproduce the functionality of Spring.

> Add @Autowired annotation to SpringInjector
> ---
>
> Key: WICKET-6862
> URL: https://issues.apache.org/jira/browse/WICKET-6862
> Project: Wicket
>  Issue Type: Improvement
>  Components: wicket-spring
>Reporter: Bas Huisman
>Priority: Minor
>  Labels: pull-request-available
>
> Besides @Inject and @SpringBean I would like to add support for @Autowired 
> injection to the SpringInjector.  [~svenmeier] advised to discus it here.
> The rationale is for consistency mainly. In normal spring beans one can 
> (obviously) not use wickets @SpringBean. The other option @Inject is not the 
> spring defacto standard, I think (new) wicket users (who know spring) will 
> find it intuitive (o even expect) to be able to use @Autowired.
> The PR is: [https://github.com/apache/wicket/pull/461] 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Comment Edited] (WICKET-6862) Add @Autowired annotation to SpringInjector

2021-01-21 Thread Bas Huisman (Jira)


[ 
https://issues.apache.org/jira/browse/WICKET-6862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17269340#comment-17269340
 ] 

Bas Huisman edited comment on WICKET-6862 at 1/21/21, 2:31 PM:
---

please close, conform the discussion here: 
[https://github.com/apache/wicket/pull/461]


was (Author: bhuism):
closing, please see the discussion here: 
https://github.com/apache/wicket/pull/461

> Add @Autowired annotation to SpringInjector
> ---
>
> Key: WICKET-6862
> URL: https://issues.apache.org/jira/browse/WICKET-6862
> Project: Wicket
>  Issue Type: Improvement
>  Components: wicket-spring
>Reporter: Bas Huisman
>Priority: Minor
>  Labels: pull-request-available
>
> Besides @Inject and @SpringBean I would like to add support for @Autowired 
> injection to the SpringInjector.  [~svenmeier] advised to discus it here.
> The rationale is for consistency mainly. In normal spring beans one can 
> (obviously) not use wickets @SpringBean. The other option @Inject is not the 
> spring defacto standard, I think (new) wicket users (who know spring) will 
> find it intuitive (o even expect) to be able to use @Autowired.
> The PR is: [https://github.com/apache/wicket/pull/461] 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (WICKET-6862) Add @Autowired annotation to SpringInjector

2021-01-21 Thread Bas Huisman (Jira)


[ 
https://issues.apache.org/jira/browse/WICKET-6862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17269340#comment-17269340
 ] 

Bas Huisman commented on WICKET-6862:
-

closing, please see the discussion here: 
https://github.com/apache/wicket/pull/461

> Add @Autowired annotation to SpringInjector
> ---
>
> Key: WICKET-6862
> URL: https://issues.apache.org/jira/browse/WICKET-6862
> Project: Wicket
>  Issue Type: Improvement
>  Components: wicket-spring
>Reporter: Bas Huisman
>Priority: Minor
>  Labels: pull-request-available
>
> Besides @Inject and @SpringBean I would like to add support for @Autowired 
> injection to the SpringInjector.  [~svenmeier] advised to discus it here.
> The rationale is for consistency mainly. In normal spring beans one can 
> (obviously) not use wickets @SpringBean. The other option @Inject is not the 
> spring defacto standard, I think (new) wicket users (who know spring) will 
> find it intuitive (o even expect) to be able to use @Autowired.
> The PR is: [https://github.com/apache/wicket/pull/461] 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (WICKET-6862) Add @Autowired annotation to SpringInjector

2021-01-21 Thread Bas Huisman (Jira)


 [ 
https://issues.apache.org/jira/browse/WICKET-6862?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bas Huisman updated WICKET-6862:

Description: 
Besides @Inject and @SpringBean I would like to add support for @Autowired 
injection to the SpringInjector.  [~svenmeier] advised to discus it here.

The rationale is for consistency mainly. In normal spring beans one can 
(obviously) not use wickets @SpringBean. The other option @Inject is not the 
spring defacto standard, I think (new) wicket users (who know spring) will find 
it intuitive (o even expect) to be able to use @Autowired.

The PR is: [https://github.com/apache/wicket/pull/461] 

  was:
Besides @Inject and @SpringBean I would like to add support for @Autowired 
injection to the SpringInjector.  [~svenmeier] advised to discus is here.

The rationale is for consistency mainly. In normal spring beans one can 
(obviously) not use wickets @SpringBean. The other option @Inject is not the 
spring defacto standard, I think (new) wicket users (who know spring) will find 
it intuitive (o even expect) to be able to use @Autowired.

The PR is: [https://github.com/apache/wicket/pull/461] 


> Add @Autowired annotation to SpringInjector
> ---
>
> Key: WICKET-6862
> URL: https://issues.apache.org/jira/browse/WICKET-6862
> Project: Wicket
>  Issue Type: Improvement
>  Components: wicket-spring
>Reporter: Bas Huisman
>Priority: Minor
>  Labels: pull-request-available
>
> Besides @Inject and @SpringBean I would like to add support for @Autowired 
> injection to the SpringInjector.  [~svenmeier] advised to discus it here.
> The rationale is for consistency mainly. In normal spring beans one can 
> (obviously) not use wickets @SpringBean. The other option @Inject is not the 
> spring defacto standard, I think (new) wicket users (who know spring) will 
> find it intuitive (o even expect) to be able to use @Autowired.
> The PR is: [https://github.com/apache/wicket/pull/461] 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Created] (WICKET-6862) Add @Autowired annotation to SpringInjector

2021-01-21 Thread Bas Huisman (Jira)
Bas Huisman created WICKET-6862:
---

 Summary: Add @Autowired annotation to SpringInjector
 Key: WICKET-6862
 URL: https://issues.apache.org/jira/browse/WICKET-6862
 Project: Wicket
  Issue Type: Improvement
  Components: wicket-spring
Reporter: Bas Huisman


Besides @Inject and @SpringBean I would like to add support for @Autowired 
injection to the SpringInjector.  [~svenmeier] advised to discus is here.

The rationale is for consistency mainly. In normal spring beans one can 
(obviously) not use wickets @SpringBean. The other option @Inject is not the 
spring defacto standard, I think (new) wicket users (who know spring) will find 
it intuitive (o even expect) to be able to use @Autowired.

The PR is: [https://github.com/apache/wicket/pull/461] 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)