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
