Hi John,
Thanks for your message, and for your analysis of a problem in WSPR-X.
You have no doubt noticed that WSPR-X has been neglected of late -- most
of us have been busy with other programs in the WSJT group. So I'm
delighted that you have spent some time with it!
As for what to do with your changes: if you expect to have continuing
interest in these things, we'd be happy to have you as a "official"
member of the WSJT Development Group, with svn commit privileges. If
you would prefer to just send a patch, or a "diff", I'll be happy to
commit your code.
-- 73, Joe, K1JT
On 3/18/2015 3:55 PM, John C. Peterson wrote:
>
> Hello WSPR-X users, developers:
>
> I have been running WSPR-X 24/7 since late Nov 2014 (built from svn).
>
> I noticed that WSPR-X would sometimes get into a state where spots were
> being successfully decoded, but would never show up at the wsprnet.org
> site. This happened maybe once a month for quite awhile. I payed little
> attention as stopping and restarting WSPR-X would "fix" the problem.
>
> A few weeks ago, this started to happen much more frequently, say
> every couple days or so. Then it happened after only two hours! So I
> decided to do some detective work of my own.
>
> After uncommenting and adding some debug statements, and several
> long runs of the code, it became clear that the problem was that the
> WSPRNet::networkReply() sometimes never got called (handler for the
> finished signal).
>
> The next time spots were decoded, the m_uploading boolean was still
> true and MainWindow::uploadSpots() would just return without even trying
> to upload the newly decoded spots. I'm not sure if it was an overloaded
> wsprnet.org server or broken network routes, but sometimes a spot request
> just never finished, which is not so surprising.
>
> To make a long story short, I did a bit of a rewrite of the
> WSPRNet::work() method. There were not that many lines of code that I
> changed, but I modified the conceptual idea behind it all to more
> carefully monitor the replies from the server.
>
> The reply objects returned by networkManager->get(request) are added to
> a list, and then removed from the list in the WSPRNet::networkReply()
> method when a request completes in a normal fashion. After 90 seconds
> (a configurable parameter), if there are still pending replies on the
> list, they are explicitly aborted. So the code is now robust in
> situations where the server never responds for some reason.
>
> There was also a minor memory leak that I fixed as reply->deleteLater( )
> was never getting called to clean up after each request.
>
> It seems to be working well, so wondering what to do with my changes?
>
> 73, KD6EKQ John
>
------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
wsjt-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
