Automatic renew does not work as expected

[meverett]

Hi, thanks for the super useful library. Mostly it's been working great for me, but I decided to test out the autorenew feature and I could not get it to work.

The autorenew was not working for me and when I began to investigate I realized that the timer callback was aborting. It would run once, maybe twice, and then stop silently. It appears there was an inner exception somewhere in all of the nested tasks occurring and the top-level timer callback is not resilient to inner exceptions maybe? Anyways it was very hard to get much out of break points and no exceptions, but I was able to piece most of it together.

I learned that the autorenew only works for MappingLifetime.Session type of mapping. No where in the docs or anything said this! It would be amazing if you could make just a quick mention somewhere of just a few key points of how the autorenew feature is designed and operates.

I figured it worked when I specified a lifetime manually as well, because honestly it's not any really different as the "session" is just a forced 10 minute lifetime anyways. Most people would use a specified timeout or session as a precaution in case of a crash or unclean shutdown of the application. It is possible that some people would want to start an application, then open a temporary timeout of a specified size, use it for that time, and then stop, and let it just timeout on its own... maybe. But this seems like the less likely default behavior. What do you think?

Well I did eventually figure out this is why my manual lifetimes were not autorenewing. I disabled the code that rejects manual lifetimes, and instead it treats them just like a session. When I tested this, it worked in that while my application ran, it stayed perpetually renewed. But when I closed the application and expected it to timeout, it never did. Sessions of int.MaxValue are long to test at 10 mintues, although I am testing it now. But I expect the same behavior as the code is more or less identical and just differs by time intervals (forced 10 minutes vs. user supplied).

Basically it's as if once my router has multiple temporary mappings created, it somehow turns it into a permanent one (as far as I can tell, I've never let it run super long, but it appears to be permanent). I'm running Tomato 1.28 if that's of any use. I understand this behavior could be the router, but curious why you think that might be?

My suggestions after lots of time lost on this issue:

1. It would be useful to offer a little more specificity around the feature somewhere in the README or on the WIKI. That it only works for sessions, explain they are 10 minute, autorenewing mapping types, and that manual lifetimes will not autorenew (or change the default behavior).
2. Also in the README would be nice if there was a super brief mention of debugging/tracing and how to get output out of the library if necessary. Even if an exception is ultimately not the libraries fault, when it's routines hold them hostage and let them die silently, it can deadend debugging. Is there a good way to extract exceptions from all of the nested tasks used by the library, if so shedding just a little bit of light on it would be a huge grace to people finding themselves needing to be able to debug into the project a bit.

Thanks 👍

[meverett]

Seems like the session based lifetime (int.MaxValue) worked! A little bit more testing need to verify. So I guess that puts things back on my router then with things becoming permanent. Strange that with shorter lifetimes, many in a row, and it I guess it just decides, "stop spamming me, you just get a permanent session!"

[jespertheend]

Thanks for this! Took me a while to get this to work, but await device.CreatePortMapAsync(new Mapping(protocol, port, port, int.MaxValue, description)) worked.