I want results to stick around until I explicitly tell them to go away (not: "unknown/expired handle") #577

New Issue

zooko · 2009-01-12T18:43:08Z

zooko commented

2009-01-12 18:43:08 +00:00

I ran a deep-verify operation, and when I hit "reload" to find out how it was going, I got:

unknown/expired handle 'xejkkdqay2ygimef2huncyxyci'

Fortunately in this case the operation I was performing was side-effect free, so this only costs my time. But what if it had been a side-effecting operation such as a deep repair? Then it would be impossible for me to find out what happened.

I know that I originally agreed to this time-out mechanism, but now I'm dissatisfied with it. What about adding a button to the form which says "Free up these results" and then storing the results until that button is pressed or the node is restarted?

I ran a deep-verify operation, and when I hit "reload" to find out how it was going, I got: ``` unknown/expired handle 'xejkkdqay2ygimef2huncyxyci' ``` Fortunately in this case the operation I was performing was side-effect free, so this only costs my time. But what if it had been a side-effecting operation such as a deep repair? Then it would be impossible for me to find out what happened. I know that I originally agreed to this time-out mechanism, but now I'm dissatisfied with it. What about adding a button to the form which says "Free up these results" and then storing the results until that button is pressed or the node is restarted?

zooko added the

labels 2009-01-12 18:43:08 +00:00

zooko added this to the undecided milestone 2009-01-12 18:43:08 +00:00

zooko commented

2009-01-12 20:19:14 +00:00

Making the Subject of this ticket a bit more specific -- I'm about to open another ticket with a different aspect of this problem.

zooko changed title from ~~unknown/expired handle~~ to I want results to stick around until I explicitly tell them to go away (not: "unknown/expired handle"P

2009-01-12 20:19:14 +00:00

zooko commented

2009-01-12 20:26:15 +00:00

As an interim measure -- even if we don't go to a "keep this until I tell you to let go of it" design -- could we please set the timeouts to approximately one hundred times as long as they currently are? Maybe 100 hours for uncollected results and 1000 minutes for collected results?

tahoe-lafs changed title from ~~I want results to stick around until I explicitly tell them to go away (not: "unknown/expired handle"P~~ to I want results to stick around until I explicitly tell them to go away (not: "unknown/expired handle")

2010-01-15 02:36:41 +00:00

davidsarah commented

2010-02-14 23:47:02 +00:00

#949 was a duplicate:

I just ran an important deep-check-and-repair, and when I came back to see what had happened I got "unknown/expired handle". This information is gone for good -- since the repair part repaired the files now there is now way for me to tell what their state was before the repair, which was information that I very much wanted to know.

I propose that operation handles be infinite duration by default, and people who want to save a few KB of virtual memory at the cost of risking losing information can configure their node to expire operation handles.

#949 was a duplicate: > I just ran an important deep-check-and-repair, and when I came back to see what had happened I got "unknown/expired handle". This information is gone for good -- since the repair part repaired the files now there is now way for me to tell what their state was before the repair, which was information that I very much wanted to know. > I propose that operation handles be infinite duration by default, and people who want to save a few KB of virtual memory at the cost of risking losing information can configure their node to expire operation handles.

tahoe-lafs modified the milestone from undecided to 1.7.0

2010-02-14 23:47:02 +00:00

davidsarah commented

2010-02-15 19:55:38 +00:00

Increasing the timeout would be very easy.

tahoe-lafs modified the milestone from 1.7.0 to 1.6.1

2010-02-15 19:55:38 +00:00

kevan commented

2010-02-20 21:27:53 +00:00

I can take care of this.

kevan commented

2010-02-20 22:17:12 +00:00

I'm attaching four patches that fix this.

577behavior.darcspatch.txt is the easy fix to the problem identified in this ticket.
577docs.darcspatch.txt updates [webapi.txt]source:docs/frontends/webapi.txt to use the new expiration values.
577testmodifications.darcspatch.txt modifies the [OphandleTable]source:src/allmydata/web/operations.py class to use a provided twisted.internet.task.Clock for callLater calls instead of the reactor, if such a clock is provided. It also changes some code in other classes to relay the provided clock to the OphandleTable. To effectively test this fix, I needed a deterministic way to simulate the passage of large periods of time (since it is very probably unacceptable to have the test suite take 100 hours to run), and I gather that using twisted.internet.task.Clock is the way to do that. That said, I'm by no means a twisted expert, so if there's an easier way of doing that that I missed, please let me know.
577tests.darcspatch.txt adds tests for my changes.

I'm happy with where these are, so I'll add the review-needed keyword.

I'm attaching four patches that fix this. * 577behavior.darcspatch.txt is the easy fix to the problem identified in this ticket. * 577docs.darcspatch.txt updates [webapi.txt]source:docs/frontends/webapi.txt to use the new expiration values. * 577testmodifications.darcspatch.txt modifies the [OphandleTable]source:src/allmydata/web/operations.py class to use a provided `twisted.internet.task.Clock` for `callLater` calls instead of the reactor, if such a clock is provided. It also changes some code in other classes to relay the provided clock to the [OphandleTable](wiki/OphandleTable). To effectively test this fix, I needed a deterministic way to simulate the passage of large periods of time (since it is very probably unacceptable to have the test suite take 100 hours to run), and I gather that using `twisted.internet.task.Clock` is the way to do that. That said, I'm by no means a twisted expert, so if there's an easier way of doing that that I missed, please let me know. * 577tests.darcspatch.txt adds tests for my changes. I'm happy with where these are, so I'll add the review-needed keyword.

kevan commented

2010-02-20 22:18:08 +00:00

Attachment 577testmodifications.darcspatch.txt (8581 bytes) added

**Attachment** 577testmodifications.darcspatch.txt (8581 bytes) added

577testmodifications.darcspatch.txt

8.4 KiB

davidsarah commented

2010-02-21 00:28:02 +00:00

100 hours and 1000 minutes require some mental arithmetic to grasp how long they are. How about 4 days and 1 day respectively (96 hours and 1440 minutes)?

In webapi.txt: "operations which have finished" -> "operations that have finished".

Nitpick: single blank line between test methods.

100 hours and 1000 minutes require some mental arithmetic to grasp how long they are. How about 4 days and 1 day respectively (96 hours and 1440 minutes)? In webapi.txt: "operations which have finished" -> "operations that have finished". Nitpick: single blank line between test methods.

kevan commented

2010-02-21 01:44:50 +00:00

Replying to davidsarah:

100 hours and 1000 minutes require some mental arithmetic to grasp how long they are. How about 4 days and 1 day respectively (96 hours and 1440 minutes)?

That's much nicer to think about (and read). I updated my patches to use those.

In webapi.txt: "operations which have finished" -> "operations that have finished".

Fixed.

Nitpick: single blank line between test methods.

Fixed.

Thanks for the feedback.

Replying to [davidsarah](/tahoe-lafs/trac-2024-07-25/issues/577#issuecomment-68929): > 100 hours and 1000 minutes require some mental arithmetic to grasp how long they are. How about 4 days and 1 day respectively (96 hours and 1440 minutes)? That's much nicer to think about (and read). I updated my patches to use those. > In webapi.txt: "operations which have finished" -> "operations that have finished". Fixed. > Nitpick: single blank line between test methods. Fixed. Thanks for the feedback.

kevan commented

2010-02-21 01:46:41 +00:00

Attachment 577behavior.darcspatch.txt (2561 bytes) added

**Attachment** 577behavior.darcspatch.txt (2561 bytes) added

577behavior.darcspatch.txt

2.5 KiB

kevan commented

2010-02-21 01:46:59 +00:00

Attachment 577docs.darcspatch.txt (3265 bytes) added

**Attachment** 577docs.darcspatch.txt (3265 bytes) added

577docs.darcspatch.txt

3.2 KiB

kevan commented

2010-02-21 01:47:11 +00:00

Attachment 577tests.darcspatch.txt (6811 bytes) added

**Attachment** 577tests.darcspatch.txt (6811 bytes) added

577tests.darcspatch.txt

6.7 KiB

zooko commented

2010-02-22 05:05:49 +00:00

What's the status of this ticket? I think it is review-needed and that David-Sarah or someone should look at the latest versions of Kevan's patches.

What's the status of this ticket? I think it is `review-needed` and that David-Sarah or someone should look at the latest versions of Kevan's patches.

davidsarah commented

2010-02-23 06:32:43 +00:00

Reviewed and fixed in changeset:e9b59a4949d3237a, changeset:09177a6e19af6e8f, changeset:bcdc78bd446f28e2, changeset:81ad52d6ebf05f4f.

tahoe-lafs added the

fixed

label 2010-02-23 06:32:43 +00:00

tahoe-lafs closed this issue

2010-02-23 06:32:43 +00:00

Sign in to join this conversation.