<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">The DXSQL fix is for those Storeable
crashes, particularly on 10Ghz beacons (for a very few people).<br>
<br>
I am really struggling to understand what is going wrong for you
(and AFAIK nobody else) generating those user_asc files. As it's
now Tuesday, it would be interesting to see how big your users.v3
is right now and then look again on Wednesday morning. <br>
<br>
The underlying mechanism is pretty straightforward and does not do
anything remotely unorthodox, it just reads from the first record
in the file to the last - and while that is going on everything
else is locked out - all other node activity is stopped for the
10-15 seconds that it takes. But the underlying storage mechanism
is DB_File a.k.a Berkeley DB which is known for being _very_
finicky about things like multiple writers and closing programs
without first properly closing database file handles. But that
can't happen in this case (or even after "normal" Storable
crashes). Having said that, if you do have a Storable crash (and
continue to do so after the dxqsl fix is in) then it is
nonetheless prudent to restore the two DB_File backed files (using
create_qsl.pl and perl user_asc) as well as removing the dupefile.
<br>
<br>
Dirk G1TLH<br>
<br>
On 17/09/2019 05:34, Michael Carper, Ph.D. wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAKJep-DNrEHZk2E6_11LWoPYbVz-fv2JFezyuFoMj2PDgH+R0A@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div class="gmail_default"
style="font-family:arial,helvetica,sans-serif">Understood,
Dirk. But they're not held for more than a week. I think that
something happens when these user_asc file versions are
created. It makes no sense. They're all the same size... very
small... compared to the V3 file.</div>
<div class="gmail_default"
style="font-family:arial,helvetica,sans-serif"><br>
</div>
<div class="gmail_default"
style="font-family:arial,helvetica,sans-serif">I'm not aware
of the DXQSL fix. If it will resolve this issue, I'll take a
look.</div>
<div class="gmail_default"
style="font-family:arial,helvetica,sans-serif"><br>
</div>
<div class="gmail_default"
style="font-family:arial,helvetica,sans-serif">Mike,
VK4/WA9PIE</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Mon, Sep 16, 2019 at 12:38
PM Dirk Koopman via Dxspider-support <<a
href="mailto:dxspider-support@tobit.co.uk"
moz-do-not-send="true">dxspider-support@tobit.co.uk</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF">
<div class="gmail-m_2929153283902345777moz-cite-prefix">On
16/09/2019 13:33, dd5xx--- via Dxspider-support wrote:<br>
</div>
<blockquote type="cite">
<div>Hi Mike,</div>
<div> </div>
<div>sorry to hear about the still existing issues.</div>
<div> </div>
<div>The bad news are: I cannot tell you what's happening
on your cluster node</div>
<div>The good news are: your cluster node is working 100%
fine at this moment (16/Sep/2019 12:20UTC), I just did
some tests</div>
</blockquote>
<tt><font size="+1"><snip><br>
I just did a straight telnet test as well and my details
now seem to be persistent as well..<br>
<br>
???<br>
<br>
Dirk G1TLH<br>
</font></tt> </div>
_______________________________________________<br>
Dxspider-support mailing list<br>
<a href="mailto:Dxspider-support@tobit.co.uk" target="_blank"
moz-do-not-send="true">Dxspider-support@tobit.co.uk</a><br>
<a
href="https://mailman.tobit.co.uk/mailman/listinfo/dxspider-support"
rel="noreferrer" target="_blank" moz-do-not-send="true">https://mailman.tobit.co.uk/mailman/listinfo/dxspider-support</a><br>
</blockquote>
</div>
</blockquote>
<br>
</body>
</html>