DelayQueue is not Serializable?
aleksey.shipilev at gmail.com
Wed Sep 21 04:06:31 PDT 2011
On Wed, Sep 21, 2011 at 3:00 PM, Doug Lea <dl at cs.oswego.edu> wrote:
> On 09/21/11 05:17, Aleksey Shipilev wrote:
>> On Wed, Sep 21, 2011 at 1:12 PM, Aleksey Shipilev
>> <aleksey.shipilev at gmail.com> wrote:
>>> On Tue, Sep 20, 2011 at 10:34 PM, Doug Lea<dl at cs.oswego.edu> wrote:
>>> From the code perspective, it appears to be point change.
>> I take that assertion back. I understand the Delayed elements which
>> are using constant delays need to be carefully recalibrated after
>> deserialization, which will probably require storing advanced metainfo
>> (i.e. "absolute time-to-fire") in serialized form.
> Yes, this is what I was getting at. We try to avoid in j.u.c
> any invisible conversions between relative and absolute time,
> because they are filled with potential surprises; including
> inconsistent clocks across machines, ntp adjustments,
> resets of system clocks, and the difference in precision
> between nanoTime and currentTimeMillis. And further, because
> the "Delayed" elements in the queue are opaque to us, we cannot
> automate any such conversions or adjustments anyway.
> If we had an AbsoluteDelayQueue, it would be a good candidate
> for being serializable.
> But as it stands, anyone needing to transport delayed tasks across
> machines can do so by iterating over the queue, and dealing
> one-by-one with their own Delayed elements wrt the above issues.
That's one good explanation, thanks Doug!
More information about the core-libs-dev