1454658 - Right-clicking to subscribe a newsgroup on an nntp server causes a perceived hang and massive spike in CPU use

Status: RESOLVED DUPLICATE of bug 1466705

(MailNews Core :: Networking: NNTP, defect)

Description

[Arthur K. (he/him)]

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:56.0) Gecko/20100101 Firefox/56.0 SeaMonkey/2.53
Build ID: 20180402185612

Steps to reproduce:

While testing with TB 60.0b2 & 60.0b3, I noticed that if I try and subscribe to a newsgroup by right-clicking of the news server and choosing "Subscribe" or clicking on a news server and clicking on "Manage Newsgroup Subscriptions" the CPU will spike and the app will appear hung but in fact it is doing something in the background. I let it sit for a good long time and it eventually brought up my listed newsgroups. Trying to subscribe to one caused the CPU to spike again and make the app appear to be hung.


Actual results:

Right-clicking a NNTP server causes massive CPU usage and app appears hung/frozen.


Expected results:

Right-clicking a NNTP server should not cause massive CPU usage nor hang the app.

Comment 1

[Wayne Mery (:wsmwk)]

Thank you for the clear description.  With which newsgroups are you seeing this?

I tested with 60.0b3

I do see slowness with news.gmane.org both opening and closing the subscribe dialog. But not what I would call excessive CPU and memory - only 10-15% CPU, and 50mb-100mb more memory.  I get Unresponsive Script, Script: chrome://messenger/content/subscribe.js:117   

I HANG opening subscribe with usenet.ptd.net. Again, only modest CPU ~12% and very slow memory growth ~5MB per minute

With news.mozilla.org, which I use regularly, I see no problem.

Comment 2

[Arthur K. (he/him)]

I have news.forteinc.com set up and see it there. Surprisingly, news.mozilla.org, no problem.

Anything you want me to check on my end in console or elsewhere? If it matters, I have provider for Google Calendar 4.1b3 and lightning 6.2b3. Disabling them doesn't help.

In my case regarding CPU usage, it pegs at 25% but it appears it's being governed. I assume if it ween't, I'd be at 100% on my lowly machine.

Comment 3

[Wayne Mery (:wsmwk)]

This also happens for me with 60.0b1 and 59.0b1 in safe mode. Can't produce with 58.0b1 circa late november.

Comment 4

[Jorg K (CEST = GMT+2)]

In TB 59 beta (https://www.thunderbird.net/en-US/thunderbird/59.0beta/releasenotes/) we replaced the XUL template based subscribe dialogue with a JS solution in bug 1425962. That would likely have caused the performance issues.

For the record, the subscribe dialogue for "huge" NNTP servers is a sensitive issue, Joshua was working on this once, but the work stalled:
Bug 457333 and
https://hg.mozilla.org/users/Pidgeot18_gmail.com/patch-queues/file/tip/patches-derdf/
Especially:
https://hg.mozilla.org/users/Pidgeot18_gmail.com/patch-queues/file/tip/patches-derdf/subscribe-invert
https://hg.mozilla.org/users/Pidgeot18_gmail.com/patch-queues/file/tip/patches-derdf/subscribe-tree

Comment 5

[gene smith]

Tested subscribe with news.charter.net on my trunk build and it hangs badly. Also shows the now "flat" folder structure before it hangs. On 52.7 it is still OK. Just a "me too" comment since I tested this before I saw Jorg's comment 4 above. Also, I made a recent change for imap subscribe but don't think it would affect nntp subscribe.

Comment 6

[Jorg K (CEST = GMT+2)]

We'll re-implement the subscribe dialogue in C++ in bug 1466705 as per comment #4. Work is almost complete.

Comment 7

[:aceman]

It can hang/appear slow on servers with many newgroups. Sadly both servers mentioned here require password so we can't really test it. But the C++ replacement (bug 1466705) of the current temporary JS implementation of the subscribe tree should help.

Comment 8

[Alfred Peters [:infofrommozilla]]

(In reply to :aceman from comment #7)
> It can hang/appear slow on servers with many newgroups. Sadly both servers
> mentioned here require password so we can't really test it.

nntp.aioe.org:119 offers free access and had shown the lag.

> But the C++
> replacement (bug 1466705) of the current temporary JS implementation of the
> subscribe tree should help.

Yes, with the current trunk TB63 the lag is gone.

Comment 9

[:aceman]

Thanks, that server seems to load fine for me too. There is even a progress display in the status bar of the subscribe dialog so even if it took some time, it does not appear as hang.