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 AbstractReadonlyModel<Future>. Then you could use have a
Map<Integer, SoftReference<Future>> (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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
