<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
Hi John,<br>
<br>
Yes, that sounds entirely sensible. Clearly something I addressed in
some version between 6.05 and 6.13. I might have even mentioned it
in the ChangeLog somewhere... :-)<br>
<br>
Cheers,<br>
Jules.<br>
<br>
<br>
<div class="moz-cite-prefix">On 13/11/2024 8:30 pm, John Thurston
via ZendTo wrote:<br>
</div>
<blockquote type="cite"
cite="mid:WM!1c38cf6bfa9517c401e3ea859585cd3678b49ce7c3cf84e62651397105d18265770803d663bfb5f11bd10def7335ca4d!@mx.jul.es">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<p>A little more information. I've lifted the cover and peeked at
the data tables in the sqlite database.</p>
<p>It looks like I have several 'requests' with "Expiry" values of
4080127620 and 4083327900. If my epoch calculations are correct,
those are <span
title="Fri Apr 17 2099 08:47:00 GMT-0800 (Alaska Daylight Time)">April
17, 2099 and </span><span
title="Sun May 24 2099 09:45:00 GMT-0800 (Alaska Daylight Time)">May 24,
2099 So I suppose it is little wonder that the reaping
process hasn't cleaned them out. It is interesting that they
all have the same "SrcEmail", and were created at 1713286033
and 1716486355 (</span><span
title="Tue Apr 16 2024 08:47:13 GMT-0800 (Alaska Daylight Time)">April
16, 2024 and </span><span
title="Thu May 23 2024 09:45:55 GMT-0800 (Alaska Daylight Time)">May 23,
2024). It kind of looks like they were assigned a 75-year
lifetime.</span></p>
<p><span
title="Thu May 23 2024 09:45:55 GMT-0800 (Alaska Daylight Time)">And it
looks like that is just an editable number in the 6.05 web
interface. "Drop-off must occur between XXX and YYY", and the
fields are user-editable with no limits. Where the 6.13
interface has a nice little calendar control, managed by the
new 'maxRequestEndDays' setting. So my user in April was
tricky, and simply changed the '2024' in that text box to
'2099', giving me entries in my 'reqtable' which the reaper
will never act on.</span></p>
<p><span
title="Thu May 23 2024 09:45:55 GMT-0800 (Alaska Daylight Time)">It
looks like in 6.13, 'Requests' can be deleted from the "Global
Drop-off List" in the same way that 'Dropoffs' can be deleted
in 6.05. <br>
</span></p>
<p><span
title="Thu May 23 2024 09:45:55 GMT-0800 (Alaska Daylight Time)">So my
hunch is, I can proceed with my 6.05 --> 6.13 update. And
when it is done, I can use the "Global Drop-off List" to
select and delete those long-lived 'requests'.<br>
</span></p>
<pre class="moz-signature" cols="72">--
Do things because you should, not just because you can.
John Thurston 907-465-8591
<a class="moz-txt-link-abbreviated moz-txt-link-freetext"
href="mailto:John.Thurston@alaska.gov" moz-do-not-send="true">John.Thurston@alaska.gov</a>
Department of Administration
State of Alaska</pre>
<div class="moz-cite-prefix">On 11/13/2024 7:44 AM, John Thurston
via ZendTo wrote:<br>
</div>
<blockquote type="cite"
cite="mid:WM!f1759e43ce88534e41404afbac0cecfefd1ce8833281cf7c3750a872930caa453eaf5620b0136a513a382a5dcaa3d730!@mx.jul.es">
<div>
<p>I can see what you mean when I look at my new-to-me 6.13
test-installation. Thank you for the guidance.<br>
</p>
<p>On that system, after I make a 'request', the "Global
Drop-off List" has similar looking numeric "Claim ID" (e.g.
"828 320 622") and the word "Request" in the "Size" column.
Interestingly, the 'requests' are shown with yellow
backgrounds in the table cells.<br>
</p>
<p>On the system I updated from 6.05 --> 6.13, the numeric
entries appeared with "0" (zero) in the "Size" column
(rather than the word "Request"). And they appeared in the
same table color-scheme as all of the drop-offs.</p>
<p>On that system, the entries carried dates ranging from
20240416 --> 20241112 (our requests should expire after 7
days). They all appeared with numeric "Claim ID", "0" in the
"Size", and with no distinctive background. So my concerns
here are:</p>
<ul>
<li>Some parts of the code recognize them as Requests, other
parts seem not to</li>
<li>New Requests must be stored differently than old
instances, as they are displayed differently in the Global
List</li>
</ul>
<ol>
<li>Will these Old Requests (which display differently),
behave as expected?</li>
<li>Will the ancient Requests now be caught by the reaper?</li>
</ol>
<p>I can live with yes or no for either question. I'd like to
know what to tell my customers to expect.<br>
</p>
<pre class="moz-signature" cols="72">--
Do things because you should, not just because you can.
John Thurston 907-465-8591
<a class="moz-txt-link-abbreviated moz-txt-link-freetext"
href="mailto:John.Thurston@alaska.gov" moz-do-not-send="true">John.Thurston@alaska.gov</a>
Department of Administration
State of Alaska</pre>
<div class="moz-cite-prefix">On 11/13/2024 6:51 AM, <a
class="moz-txt-link-abbreviated moz-txt-link-freetext"
href="mailto:jules@zend.to" moz-do-not-send="true">
jules@zend.to</a> wrote:<br>
</div>
<blockquote type="cite"
cite="mid:WM!dcc975368e601bcf716a84e0f80a930173d1d2837150d8be0497b41758551b463c6799bd7e5baaf5d3df95c11b91875a!@mx.jul.es">
<div>The ones with the numeric values should be labelled as
"requests" in one of the other columns. They are
requests-for-dropoffs, not dropoffs themselves. They
should get cleared up like they have been in the past,
it's just now they show in that table.<br>
<br>
Cheers,<br>
Jules.<br>
<br>
<br>
<div class="moz-cite-prefix">On 13/11/2024 3:25 pm, John
Thurston via ZendTo wrote:<br>
</div>
<blockquote type="cite"
cite="mid:WM!b31340de06823061d684645fb87396d055473ff22d4910e54a3b3ffeaa64dc53f4e1d809f9cf482bad6334b743bddd3b!@mx.jul.es">
<p>Updating our test-system seemed to work perfectly.
Not so for production.</p>
<p>After updating from 6.05-4 to 6.13-3, I have some
strange behavior (and have reverted to the old, by way
of a VMWare snapshot).</p>
<p>New drop-off and pickup seems to work as expected.
Picking up recent drop-offs seemed to work as
expected. But the "Show All Drop-offs" now contains
some entries with numeric values (e.g. "235 637 597")
in place of the expected strings (e.g.
"22iUmVdjs9WxszxD"). I exported all of the drop-offs
to a CVS. All of the numeric clamIDs show a zero size.
And most of them are well past their expiration date.
Most are only a little old, but some are more than
6-months old.</p>
<p>So I <i>suspect</i> there are some old entries in
the database which weren't cleaned up in the normal
course of operations. The new code in 6.13 is finding
them, interpreting them, and adding them to the list
of available downloads. I also <i>suspect</i> that
the next reaping through the database by the new code
would clean them out.</p>
<p>But I couldn't be sure, so I've reverted to 6.05
while I try to figure out what it is doing and if it
is safe.</p>
<p>I know that 6.13 is now a couple of years old, so
others probably performed their update in the distant
past. But does anyone have any insight or advice?</p>
<br>
</blockquote>
</div>
</blockquote>
</div>
<br>
<fieldset class="moz-mime-attachment-header"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
ZendTo mailing list
<a class="moz-txt-link-abbreviated moz-txt-link-freetext"
href="mailto:ZendTo@zend.to" moz-do-not-send="true">ZendTo@zend.to</a>
<a class="moz-txt-link-freetext"
href="http://jul.es/mailman/listinfo/zendto"
moz-do-not-send="true">http://jul.es/mailman/listinfo/zendto</a>
</pre>
</blockquote>
<br>
<fieldset class="moz-mime-attachment-header"></fieldset>
<pre wrap="" class="moz-quote-pre">_______________________________________________
ZendTo mailing list
<a class="moz-txt-link-abbreviated" href="mailto:ZendTo@zend.to">ZendTo@zend.to</a>
<a class="moz-txt-link-freetext" href="http://jul.es/mailman/listinfo/zendto">http://jul.es/mailman/listinfo/zendto</a>
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">Jules
--
Julian Field MEng CEng CITP MBCS MIEEE MACM
'We have an asset out of containment.'
- Jurassic World
<a class="moz-txt-link-abbreviated" href="http://www.Zend.To">www.Zend.To</a>
Twitter: @JulesFM
</pre>
</body>
</html>