Re: multiple AjaxFileDropBehaviour on single page
I would simply lock other drag and drop upload components, while upload is in progress. You can also have a look at my experiments with custom drag and drop upload fields here https://github.com/andruhon/WicketDragAndDropFileAjaxUpload I have similar implementation in my app and it does allow you to drop files into multiple drag and drop area, however, files are uploaded sequentially, one by one. On 2019/08/13 06:19:08, Korbinian Bachl wrote: > Hi, > > wicket 8 has this neat AjaxFileDropBehaviour and it works like charm. > However, if I have multiple components on one page with a > AjaxFileDropBehaviour each and the upload of 1 drop is running, i cant upload > a 2nd one at the same time; Any idea how to solve this? > > E.g.: File 1 with 100MB gets dropped onto component A, File B wiht 50MB gets > dropped onto Component B about 10 secs later - upload of a is not working and > page somehow goes stale. It might be noteworthy that during the upload an > IAjaxIndicatorAware spinner is shown on Component A (and expected on B); > > Best, > > KB > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: multiple AjaxFileDropBehaviour on single page
Hi Sven, so to get this right: all wicket ajax is basically a queue where only 1 instance is worked on at a time and nothing is possible in parallel? (but browsers and ajax in parallel is working since at least 2011? e.g.: jQuery.when() ) You mention the upload to a resource - how would this change it in that in could be parallel and could you point me an example? Best & Thanks for the answer so far, KB - Ursprüngliche Mail - > Von: "Sven Meier" > An: "users" > Gesendet: Dienstag, 13. August 2019 09:03:49 > Betreff: Re: multiple AjaxFileDropBehaviour on single page > Hi, > > all Ajax behaviors' requests are queued in the browser. Even if you > disable this (see AjaxRequestAttributes#channel), all access to the page > is synchronized on the server anyway. > > You could to upload to a resource instead, AjaxFileDropBehaviour doesn't > support this though. > > Have fun > Sven > > > On 13.08.19 08:19, Korbinian Bachl wrote: >> Hi, >> >> wicket 8 has this neat AjaxFileDropBehaviour and it works like charm. >> However, >> if I have multiple components on one page with a AjaxFileDropBehaviour each >> and >> the upload of 1 drop is running, i cant upload a 2nd one at the same time; >> Any >> idea how to solve this? >> >> E.g.: File 1 with 100MB gets dropped onto component A, File B wiht 50MB gets >> dropped onto Component B about 10 secs later - upload of a is not working and >> page somehow goes stale. It might be noteworthy that during the upload an >> IAjaxIndicatorAware spinner is shown on Component A (and expected on B); >> >> Best, >> >> KB >> >> - >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >> For additional commands, e-mail: users-h...@wicket.apache.org >> > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: getPageClass locks the page
Hi, Some time ago, we faced a similar issue. A custom component accessed pages after they were unlocked, causing stale locks. Back then I filed an issue (WICKET-6558), but haven't had time to implement the fix. Locking pages after commitRequest should be blocked. Best regards, Emond On Tue, Aug 13, 2019 at 8:57 AM Sven Meier wrote: > > Hi, > > PageAccessSynchronizer#detach() unlocks all pages. > > Is your request logger running after that? > > Have fun > Sven > > > On 13.08.19 07:46, Martin Grigorov wrote: > > Hi, > > > > If the page is not unlocked then it is a bug. > > But it is strange that no one faced it before. This code is in use since > > Wicket 1.5.0. > > > > On Tue, Aug 13, 2019 at 7:38 AM Andrew Kondratev > > wrote: > > > >> Hi! > >> > >> My colleague noticed some dodgy behavior, which I think could be a bug. > >> Just asking here if it's known, befor I try to create a quickstart or PR. > >> > >> * page is rendered > >> * user interacts with a page causing ajax request (clicking checkbox) > >> * the wicket PageAccessSynchronizer locks, renders and unlocks the page > >> with that id > >> * after that, custom request logger asks for the className of the current > >> page > >> * the PageProvider doesn't have it on hand, so has to ask for the page from > >> DefaultMapperContext#getPageInstance > >> * that in turn locks the page again -- without unlocking it > >> * so subsequent interaction with the same component blows up after a minute > >> of not being able to get the lock for the page > >> > >> Wicket 8.5.0 > >> > >> The stack trace > >> org.apache.wicket.page.CouldNotLockPageException: Could not lock page 86. > >> Attempt lasted 1 minute > >> at > >> org.apache.wicket.page > >> .PageAccessSynchronizer.lockPage(PageAccessSynchronizer.java:168) > >> at > >> org.apache.wicket.page > >> .PageAccessSynchronizer$2.getPage(PageAccessSynchronizer.java:246) > >> at > >> > >> org.apache.wicket.DefaultMapperContext.getPageInstance(DefaultMapperContext.java:101) > >> at > >> > >> org.apache.wicket.core.request.handler.PageProvider$Provision.resolve(PageProvider.java:412) > >> at > >> > >> org.apache.wicket.core.request.handler.PageProvider.getProvision(PageProvider.java:163) > >> at > >> > >> org.apache.wicket.core.request.handler.PageProvider.getPageInstance(PageProvider.java:171) > >> at > >> > >> org.apache.wicket.core.request.handler.PageProvider.getPageClass(PageProvider.java:257) > >> at > >> > >> org.apache.wicket.core.request.handler.ListenerRequestHandler.getPageClass(ListenerRequestHandler.java:108) > >> at > >> > >> org.apache.wicket.protocol.https.HttpsMapper.getDesiredSchemeFor(HttpsMapper.java:199) > >> at > >> > >> org.apache.wicket.protocol.https.HttpsMapper.mapRequest(HttpsMapper.java:103) > >> at > >> > >> org.apache.wicket.request.mapper.CompoundRequestMapper.mapRequest(CompoundRequestMapper.java:147) > >> at > >> > >> org.apache.wicket.request.cycle.RequestCycle.resolveRequestHandler(RequestCycle.java:193) > >> at > >> > >> org.apache.wicket.request.cycle.RequestCycle.processRequest(RequestCycle.java:243) > >> at > >> > >> com.mycompany.core.web.framework.MyRequestCycle.processRequest(MyRequestCycle.java:129) > >> at > >> > >> org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(RequestCycle.java:221) > >> at > >> > >> org.apache.wicket.protocol.http.WicketFilter.processRequestCycle(WicketFilter.java:275) > >> at > >> > >> org.apache.wicket.protocol.http.WicketFilter.processRequest(WicketFilter.java:206) > >> at > >> > >> org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:299) > >> at > >> > >> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193) > >> at > >> > >> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166) > >> at > >> > >> com.mycompany.core.web.filter.ResponseHeadersFilter.doFilter(ResponseHeadersFilter.java:31) > >> at > >> > >> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193) > >> at > >> > >> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166) > >> at > >> > >> com.mycompany.core.web.filter.MDCEnhancingFilter.lambda$doFilterInternal$0(MDCEnhancingFilter.java:29) > >> at > >> > >> com.mycompany.common.logging.LoggingContextUtil$VoidCallable.call(LoggingContextUtil.java:168) > >> at > >> > >> com.mycompany.common.logging.LoggingContextUtil$VoidCallable.call(LoggingContextUtil.java:163) > >> at > >> > >> com.mycompany.common.logging.LoggingContextUtil.runWithLoggingContext(LoggingContextUtil.java:65) > >> at > >> > >> com.mycompany.common.logging.LoggingContextUtil.runWithLoggingContext(LoggingContextUtil.java:34) > >> at > >> > >> com.mycompany.core.web.filter.MDCEnhancingFilter.doFilterInternal(MDCEnhancingFilter.java:29) > >> at > >> > >> org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107) > >> at > >> > >> org.apache.catalina
Re: multiple AjaxFileDropBehaviour on single page
Hi, all Ajax behaviors' requests are queued in the browser. Even if you disable this (see AjaxRequestAttributes#channel), all access to the page is synchronized on the server anyway. You could to upload to a resource instead, AjaxFileDropBehaviour doesn't support this though. Have fun Sven On 13.08.19 08:19, Korbinian Bachl wrote: Hi, wicket 8 has this neat AjaxFileDropBehaviour and it works like charm. However, if I have multiple components on one page with a AjaxFileDropBehaviour each and the upload of 1 drop is running, i cant upload a 2nd one at the same time; Any idea how to solve this? E.g.: File 1 with 100MB gets dropped onto component A, File B wiht 50MB gets dropped onto Component B about 10 secs later - upload of a is not working and page somehow goes stale. It might be noteworthy that during the upload an IAjaxIndicatorAware spinner is shown on Component A (and expected on B); Best, KB - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
