Re: Handling futures
Did you already take a look at wicketstuff-progressbar? Regards Hans Am 23.07.11 17:02 schrieb Bertrand Guay-Paquet unter ber...@step.polymtl.ca: I haven't actually done it yet, but the 3 steps you list are what I have in mind. After these, I plan to use a javascript timer that polls the status of the request and updates a label (or icon). That ajax behavior would be the one polling the Future. What I can't wrap my head around is this: the ajax behavior can't directly hold a reference to the Future because it can be serialized with the page. On the other hand, if I store the Future in a map somewhere and keep a serializable handle in the behavior, there is a possibility that the user will navigate to another page before get() is called on the Future. To avoid running out of memory, this means that I would need to have a daemon that periodically nulls stale Futures from the map so they can be garbage collected. This kind of operation (submit + polling asynchronous result) seems rather common so I'm sure there's some (easy) way to handle it... On 23/07/2011 9:14 AM, Scott Swank wrote: What does your workflow look like? 1. submit form (or ajax event) 2. create Future 3. return response page (or ajax response) Now who checks the Future and what sort of UI result occurs? Scott On Fri, Jul 22, 2011 at 8:55 PM, Bertrand Guay-Paquet ber...@step.polymtl.ca wrote: Hello, I can't find the correct way to handle java.util.concurrent.Future instances returned from asynchronous methods in Wicket. This interface does not extend Serializable so its instances can't be stored in components or pages. So what do you do with them? Do you store them in a map in the application and keep a handle (e.g. an int) in the Wicket component? I saw code on a github repository that implemented an ajax timer behavior that keeps a reference to a Future in a transient field to update a status. However, I can't understand how that would work. Wouldn't the transient field be nulled out if the behavior is serialized with the page and then deserialized? Essentially, my question is: what is the standard way to handle Futures in Wicket that run longer than the page rendering? (like processing an order or sending emails) I hope I'm not missing something obvious, but that might be the case... Regards, Bertrand - 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 - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Handling futures
Hans: I hadn't looked at that project, thanks for mentioning it. Thank you all for your input. It seems the only viable solution is to keep track of Futures in another scope than the relevant components so I'll go with that. On 24/07/2011 1:21 AM, Rodolfo Hansen wrote: Have you thought about keeping your future in another scope? a conversation scope for example, or delegating it to the application / session ? On Sat, Jul 23, 2011 at 10:31 PM, Bertrand Guay-Paquet ber...@step.polymtl.ca wrote: Thanks for your answers Scott. I thought Wicket could essentially serialize a page any time it sees fit. Is that the case? If so, that would mean that even if the page containing the Future reference is still open in the browser window, the Future could be thrown away. Wouldn't that be a definite possibility if a user has multiple browser windows open in the same session and keeps browsing the site in another window while the pending result window is still open? On 23/07/2011 11:10 AM, Scott Swank wrote: Perhaps a transient Future would work for you after all. If the user navigates away the Page is serialized and the Future is thrown away. If you do put futures in a Map, perhaps in the Session, I'd wrap that in an AbstractReadonlyModelFuture. Then you could use have a MapInteger, SoftReferenceFuture (assuming your key is an Integer) if you're still concerned about memory usage getting out of hand. Scott On Sat, Jul 23, 2011 at 8:02 AM, Bertrand Guay-Paquet ber...@step.polymtl.ca wrote: I haven't actually done it yet, but the 3 steps you list are what I have in mind. After these, I plan to use a javascript timer that polls the status of the request and updates a label (or icon). That ajax behavior would be the one polling the Future. What I can't wrap my head around is this: the ajax behavior can't directly hold a reference to the Future because it can be serialized with the page. On the other hand, if I store the Future in a map somewhere and keep a serializable handle in the behavior, there is a possibility that the user will navigate to another page before get() is called on the Future. To avoid running out of memory, this means that I would need to have a daemon that periodically nulls stale Futures from the map so they can be garbage collected. This kind of operation (submit + polling asynchronous result) seems rather common so I'm sure there's some (easy) way to handle it... On 23/07/2011 9:14 AM, Scott Swank wrote: What does your workflow look like? 1. submit form (or ajax event) 2. create Future 3. return response page (or ajax response) Now who checks the Future and what sort of UI result occurs? Scott On Fri, Jul 22, 2011 at 8:55 PM, Bertrand Guay-Paquet ber...@step.polymtl.ca wrote: Hello, I can't find the correct way to handle java.util.concurrent.Future instances returned from asynchronous methods in Wicket. This interface does not extend Serializable so its instances can't be stored in components or pages. So what do you do with them? Do you store them in a map in the application and keep a handle (e.g. an int) in the Wicket component? I saw code on a github repository that implemented an ajax timer behavior that keeps a reference to a Future in a transient field to update a status. However, I can't understand how that would work. Wouldn't the transient field be nulled out if the behavior is serialized with the page and then deserialized? Essentially, my question is: what is the standard way to handle Futures in Wicket that run longer than the page rendering? (like processing an order or sending emails) I hope I'm not missing something obvious, but that might be the case... Regards, Bertrand --**--** - To unsubscribe, e-mail: users-unsubscribe@wicket.**apache.orgusers-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org --**--** - To unsubscribe, e-mail: users-unsubscribe@wicket.**apache.orgusers-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org --**--** - To unsubscribe, e-mail: users-unsubscribe@wicket.**apache.orgusers-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org --**--** - To unsubscribe, e-mail: users-unsubscribe@wicket.**apache.orgusers-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org --**--**- To unsubscribe, e-mail: users-unsubscribe@wicket.**apache.orgusers-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe,
Re: Handling futures
What does your workflow look like? 1. submit form (or ajax event) 2. create Future 3. return response page (or ajax response) Now who checks the Future and what sort of UI result occurs? Scott On Fri, Jul 22, 2011 at 8:55 PM, Bertrand Guay-Paquet ber...@step.polymtl.ca wrote: Hello, I can't find the correct way to handle java.util.concurrent.Future instances returned from asynchronous methods in Wicket. This interface does not extend Serializable so its instances can't be stored in components or pages. So what do you do with them? Do you store them in a map in the application and keep a handle (e.g. an int) in the Wicket component? I saw code on a github repository that implemented an ajax timer behavior that keeps a reference to a Future in a transient field to update a status. However, I can't understand how that would work. Wouldn't the transient field be nulled out if the behavior is serialized with the page and then deserialized? Essentially, my question is: what is the standard way to handle Futures in Wicket that run longer than the page rendering? (like processing an order or sending emails) I hope I'm not missing something obvious, but that might be the case... Regards, Bertrand - 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: Handling futures
I haven't actually done it yet, but the 3 steps you list are what I have in mind. After these, I plan to use a javascript timer that polls the status of the request and updates a label (or icon). That ajax behavior would be the one polling the Future. What I can't wrap my head around is this: the ajax behavior can't directly hold a reference to the Future because it can be serialized with the page. On the other hand, if I store the Future in a map somewhere and keep a serializable handle in the behavior, there is a possibility that the user will navigate to another page before get() is called on the Future. To avoid running out of memory, this means that I would need to have a daemon that periodically nulls stale Futures from the map so they can be garbage collected. This kind of operation (submit + polling asynchronous result) seems rather common so I'm sure there's some (easy) way to handle it... On 23/07/2011 9:14 AM, Scott Swank wrote: What does your workflow look like? 1. submit form (or ajax event) 2. create Future 3. return response page (or ajax response) Now who checks the Future and what sort of UI result occurs? Scott On Fri, Jul 22, 2011 at 8:55 PM, Bertrand Guay-Paquet ber...@step.polymtl.ca wrote: Hello, I can't find the correct way to handle java.util.concurrent.Future instances returned from asynchronous methods in Wicket. This interface does not extend Serializable so its instances can't be stored in components or pages. So what do you do with them? Do you store them in a map in the application and keep a handle (e.g. an int) in the Wicket component? I saw code on a github repository that implemented an ajax timer behavior that keeps a reference to a Future in a transient field to update a status. However, I can't understand how that would work. Wouldn't the transient field be nulled out if the behavior is serialized with the page and then deserialized? Essentially, my question is: what is the standard way to handle Futures in Wicket that run longer than the page rendering? (like processing an order or sending emails) I hope I'm not missing something obvious, but that might be the case... Regards, Bertrand - 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: Handling futures
Perhaps a transient Future would work for you after all. If the user navigates away the Page is serialized and the Future is thrown away. If you do put futures in a Map, perhaps in the Session, I'd wrap that in an AbstractReadonlyModelFuture. Then you could use have a MapInteger, SoftReferenceFuture (assuming your key is an Integer) if you're still concerned about memory usage getting out of hand. Scott On Sat, Jul 23, 2011 at 8:02 AM, Bertrand Guay-Paquet ber...@step.polymtl.ca wrote: I haven't actually done it yet, but the 3 steps you list are what I have in mind. After these, I plan to use a javascript timer that polls the status of the request and updates a label (or icon). That ajax behavior would be the one polling the Future. What I can't wrap my head around is this: the ajax behavior can't directly hold a reference to the Future because it can be serialized with the page. On the other hand, if I store the Future in a map somewhere and keep a serializable handle in the behavior, there is a possibility that the user will navigate to another page before get() is called on the Future. To avoid running out of memory, this means that I would need to have a daemon that periodically nulls stale Futures from the map so they can be garbage collected. This kind of operation (submit + polling asynchronous result) seems rather common so I'm sure there's some (easy) way to handle it... On 23/07/2011 9:14 AM, Scott Swank wrote: What does your workflow look like? 1. submit form (or ajax event) 2. create Future 3. return response page (or ajax response) Now who checks the Future and what sort of UI result occurs? Scott On Fri, Jul 22, 2011 at 8:55 PM, Bertrand Guay-Paquet ber...@step.polymtl.ca wrote: Hello, I can't find the correct way to handle java.util.concurrent.Future instances returned from asynchronous methods in Wicket. This interface does not extend Serializable so its instances can't be stored in components or pages. So what do you do with them? Do you store them in a map in the application and keep a handle (e.g. an int) in the Wicket component? I saw code on a github repository that implemented an ajax timer behavior that keeps a reference to a Future in a transient field to update a status. However, I can't understand how that would work. Wouldn't the transient field be nulled out if the behavior is serialized with the page and then deserialized? Essentially, my question is: what is the standard way to handle Futures in Wicket that run longer than the page rendering? (like processing an order or sending emails) I hope I'm not missing something obvious, but that might be the case... Regards, Bertrand - 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 - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Handling futures
Thanks for your answers Scott. I thought Wicket could essentially serialize a page any time it sees fit. Is that the case? If so, that would mean that even if the page containing the Future reference is still open in the browser window, the Future could be thrown away. Wouldn't that be a definite possibility if a user has multiple browser windows open in the same session and keeps browsing the site in another window while the pending result window is still open? On 23/07/2011 11:10 AM, Scott Swank wrote: Perhaps a transient Future would work for you after all. If the user navigates away the Page is serialized and the Future is thrown away. If you do put futures in a Map, perhaps in the Session, I'd wrap that in an AbstractReadonlyModelFuture. Then you could use have a MapInteger, SoftReferenceFuture (assuming your key is an Integer) if you're still concerned about memory usage getting out of hand. Scott On Sat, Jul 23, 2011 at 8:02 AM, Bertrand Guay-Paquet ber...@step.polymtl.ca wrote: I haven't actually done it yet, but the 3 steps you list are what I have in mind. After these, I plan to use a javascript timer that polls the status of the request and updates a label (or icon). That ajax behavior would be the one polling the Future. What I can't wrap my head around is this: the ajax behavior can't directly hold a reference to the Future because it can be serialized with the page. On the other hand, if I store the Future in a map somewhere and keep a serializable handle in the behavior, there is a possibility that the user will navigate to another page before get() is called on the Future. To avoid running out of memory, this means that I would need to have a daemon that periodically nulls stale Futures from the map so they can be garbage collected. This kind of operation (submit + polling asynchronous result) seems rather common so I'm sure there's some (easy) way to handle it... On 23/07/2011 9:14 AM, Scott Swank wrote: What does your workflow look like? 1. submit form (or ajax event) 2. create Future 3. return response page (or ajax response) Now who checks the Future and what sort of UI result occurs? Scott On Fri, Jul 22, 2011 at 8:55 PM, Bertrand Guay-Paquet ber...@step.polymtl.cawrote: Hello, I can't find the correct way to handle java.util.concurrent.Future instances returned from asynchronous methods in Wicket. This interface does not extend Serializable so its instances can't be stored in components or pages. So what do you do with them? Do you store them in a map in the application and keep a handle (e.g. an int) in the Wicket component? I saw code on a github repository that implemented an ajax timer behavior that keeps a reference to a Future in a transient field to update a status. However, I can't understand how that would work. Wouldn't the transient field be nulled out if the behavior is serialized with the page and then deserialized? Essentially, my question is: what is the standard way to handle Futures in Wicket that run longer than the page rendering? (like processing an order or sending emails) I hope I'm not missing something obvious, but that might be the case... Regards, Bertrand - 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 - 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: Handling futures
Have you thought about keeping your future in another scope? a conversation scope for example, or delegating it to the application / session ? On Sat, Jul 23, 2011 at 10:31 PM, Bertrand Guay-Paquet ber...@step.polymtl.ca wrote: Thanks for your answers Scott. I thought Wicket could essentially serialize a page any time it sees fit. Is that the case? If so, that would mean that even if the page containing the Future reference is still open in the browser window, the Future could be thrown away. Wouldn't that be a definite possibility if a user has multiple browser windows open in the same session and keeps browsing the site in another window while the pending result window is still open? On 23/07/2011 11:10 AM, Scott Swank wrote: Perhaps a transient Future would work for you after all. If the user navigates away the Page is serialized and the Future is thrown away. If you do put futures in a Map, perhaps in the Session, I'd wrap that in an AbstractReadonlyModelFuture. Then you could use have a MapInteger, SoftReferenceFuture (assuming your key is an Integer) if you're still concerned about memory usage getting out of hand. Scott On Sat, Jul 23, 2011 at 8:02 AM, Bertrand Guay-Paquet ber...@step.polymtl.ca wrote: I haven't actually done it yet, but the 3 steps you list are what I have in mind. After these, I plan to use a javascript timer that polls the status of the request and updates a label (or icon). That ajax behavior would be the one polling the Future. What I can't wrap my head around is this: the ajax behavior can't directly hold a reference to the Future because it can be serialized with the page. On the other hand, if I store the Future in a map somewhere and keep a serializable handle in the behavior, there is a possibility that the user will navigate to another page before get() is called on the Future. To avoid running out of memory, this means that I would need to have a daemon that periodically nulls stale Futures from the map so they can be garbage collected. This kind of operation (submit + polling asynchronous result) seems rather common so I'm sure there's some (easy) way to handle it... On 23/07/2011 9:14 AM, Scott Swank wrote: What does your workflow look like? 1. submit form (or ajax event) 2. create Future 3. return response page (or ajax response) Now who checks the Future and what sort of UI result occurs? Scott On Fri, Jul 22, 2011 at 8:55 PM, Bertrand Guay-Paquet ber...@step.polymtl.cawrote: Hello, I can't find the correct way to handle java.util.concurrent.Future instances returned from asynchronous methods in Wicket. This interface does not extend Serializable so its instances can't be stored in components or pages. So what do you do with them? Do you store them in a map in the application and keep a handle (e.g. an int) in the Wicket component? I saw code on a github repository that implemented an ajax timer behavior that keeps a reference to a Future in a transient field to update a status. However, I can't understand how that would work. Wouldn't the transient field be nulled out if the behavior is serialized with the page and then deserialized? Essentially, my question is: what is the standard way to handle Futures in Wicket that run longer than the page rendering? (like processing an order or sending emails) I hope I'm not missing something obvious, but that might be the case... Regards, Bertrand --**--** - To unsubscribe, e-mail: users-unsubscribe@wicket.**apache.orgusers-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org --**--** - To unsubscribe, e-mail: users-unsubscribe@wicket.**apache.orgusers-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org --**--** - To unsubscribe, e-mail: users-unsubscribe@wicket.**apache.orgusers-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org --**--** - To unsubscribe, e-mail: users-unsubscribe@wicket.**apache.orgusers-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org --**--**- To unsubscribe, e-mail: users-unsubscribe@wicket.**apache.orgusers-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- Rodolfo Hansen CTO, KindleIT Software Development Email: rhan...@kitsd.com Mobile: +1 (809) 860-6669
