1824422 - NNTP stops showing messages when TB tries to summarize collapsed thread, opens but never closes one connection per message, then exceeds maximum of mail.server.<serverID>.max_cached_connection

Status: RESOLVED FIXED

(MailNews Core :: Networking: NNTP, defect, P2)

Description

[Renato Botelho]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/111.0.0.0 Safari/537.36

Steps to reproduce:

Clicked on a NNTP message in order to read it

Actual results:

While using version 102 this problem used to happen occasionally, specially when Thunderbird was running for days, and my way of working around the issue was to close it and re-open.

After I installed version 112 it happens all the time. I read 4 or 5 messages on an NNTP group and it just stops working until I close and re-open it.

I got console error opened and noticed following message when I selected one message and was able to read it:

mailnews.nntp: Failed to process server response [object Object]. 
Exception { name: "NS_ERROR_XPC_JAVASCRIPT_ERROR_WITH_DETAILS", message: `[JavaScript Error: "aPart is null" {file: "resource:///modules/gloda/MimeMessage.jsm" line: 146}]'[JavaScript Error: "aPart is null" {file: "resource:///modules/gloda/MimeMessage.jsm" line: 146}]' when calling method: [nsIStreamListener::onStopRequest]`, result: 2153185313, filename: "resource:///modules/NntpChannel.jsm", lineNumber: 338, columnNumber: 0, data: XPCWrappedNative_NoHelper, stack: "_readFromServer/</client.onDone@resource:///modules/NntpChannel.jsm:338:24\n_actionDone@resource:///modules/NntpClient.jsm:937:10\n_actionArticleResponse/<@resource:///modules/NntpClient.jsm:761:14\nread@resource:///modules/LineReader.jsm:65:7\n_actionArticleResponse@resource:///modules/NntpClient.jsm:749:22\n_onData@resource:///modules/NntpClient.jsm:225:12\n", location: XPCWrappedNative_NoHelper }
​
columnNumber: 0
​
data: XPCWrappedNative_NoHelper { QueryInterface: QueryInterface() }
​​
QueryInterface: function QueryInterface()
​​
<prototype>: Object { … }
​
filename: "resource:///modules/NntpChannel.jsm"
​
lineNumber: 338
​
location: XPCWrappedNative_NoHelper { QueryInterface: QueryInterface(), filename: Getter, name: Getter, … }
​
message: `[JavaScript Error: "aPart is null" {file: "resource:///modules/gloda/MimeMessage.jsm" line: 146}]'[JavaScript Error: "aPart is null" {file: "resource:///modules/gloda/MimeMessage.jsm" line: 146}]' when calling method: [nsIStreamListener::onStopRequest]`
​
name: "NS_ERROR_XPC_JAVASCRIPT_ERROR_WITH_DETAILS"
​
result: 2153185313
​
stack: "_readFromServer/</client.onDone@resource:///modules/NntpChannel.jsm:338:24\n_actionDone@resource:///modules/NntpClient.jsm:937:10\n_actionArticleResponse/<@resource:///modules/NntpClient.jsm:761:14\nread@resource:///modules/LineReader.jsm:65:7\n_actionArticleResponse@resource:///modules/NntpClient.jsm:749:22\n_onData@resource:///modules/NntpClient.jsm:225:12\n"
​
<prototype>: ExceptionPrototype { toString: toString(), name: Getter, message: Getter, … }
NntpClient.jsm:227:20
    _onData resource:///modules/NntpClient.jsm:227

Then I clicked on next message and after a good number of seconds (I didn't measure it) I got:

<Provider> does not support changing `store` on the fly. It is most likely that you see this error because you updated to Redux 2.x and React Redux 2.x which no longer hot reload reducers automatically. See https://github.com/reactjs/react-redux/releases/tag/v2.0.0 for the migration instructions. react-redux.js:881:13
    Redux 3
        warning$2
        warnAboutReceivingStore
        componentWillReceiveProps
    React 13
        callComponentWillReceiveProps
        updateClassInstance
        updateClassComponent
        beginWork
        performUnitOfWork
        workLoop
        renderRoot
        performWorkOnRoot
        performWork
        performSyncWork
        interactiveUpdates$1
        interactiveUpdates
        dispatchInteractiveEvent

Expected results:

It should show message content

Comment 1

[Alfred Peters [:infofrommozilla]]

I think I (TB112.0b3) see the bug too.
Can you confirm that the bug (only) occurs after you select one or more collapsed threads?
And that it does not occur when you expand¹) the threads before and select only single messages?

¹) e.g. by: Menu: View -> Threads -> Expand all Threads [*]

Comment 2

[Renato Botelho]

(In reply to Alfred Peters from comment #1)

I think I (TB112.0b3) see the bug too.
Can you confirm that the bug (only) occurs after you select one or more collapsed threads?
And that it does not occur when you expand¹) the threads before and select only single messages?

¹) e.g. by: Menu: View -> Threads -> Expand all Threads [*]

Yes, I confirmed this behavior. If I expand all threads I can read all messages and bug never happens.

Comment 3

[Renato Botelho]

I have the impression that the fix applied for #1820077 fixed it. I just need to wait a bit more to be sure, then I will post here

Comment 4

[Renato Botelho]

I couldn't reproduce this error anymore after patch from 1820077 was committed. I'm not sure if that change only worked it around but from user point of view, it is working as expected now.

Comment 5

[Alfred Peters [:infofrommozilla]]

Did you test this with the new beta 4 or a daily?
I just saw the blank window again with TB112.0b4. Only the error message from the log is gone.

{Hint: Just write "Bug" + number -> Bug 1820077 - The rest is scripted magic.}

Comment 6

[Renato Botelho]

(In reply to Alfred Peters from comment #5)

Did you test this with the new beta 4 or a daily?
I just saw the blank window again with TB112.0b4. Only the error message from the log is gone.

{Hint: Just write "Bug" + number -> Bug 1820077 - The rest is scripted magic.}

I'm using 112b4 and didn't see the issue since yesterday. Maybe it's too soon to say it's not happening anymore but at least I could read all mailing lists this morning without any trouble.

It's also good to say that this bug usually to happen occasionally on 102 as well, specially when TB was running for 2 or 3 days in a row. On 112 before b4 it was happening every time.

Comment 7

[Renato Botelho]

Well, The fix from Bug 1820077 actually improved the situation but yes, bug is still happening and I triggered it some times since yesterday

Comment 8

[ruediger]

I don't see any advances with the fix from Bug 1820077 in Daily BuildID=20230329100847
With this Bug, Daily leaves untestable in NEWS-section for me.

Comment 9

[Alfred Peters [:infofrommozilla]]

(In reply to Renato Botelho from comment #6)

I'm using 112b4 and didn't see the issue since yesterday. Maybe it's too soon to say it's not happening anymore but at least I could read all mailing lists this morning without any trouble.

"Mailing lists"? In the bug description you wrote about NNTP!?
Never mind.

Comment 10

[Alfred Peters [:infofrommozilla]]

I also still have the problem with TB112b5.

When TB tries to create the thread summary, it opens a connection to the server for each article in the thread and retrieves the article. But this connection is not closed again!

If the number of connections consumed in this way exceeds the maximum number¹) of allowed connections, TB will not be able to retrieve new items because it cannot open a new connection.

¹) mail.server.<serverID>.max_cached_connections

Comment 11

[MM]

This is easily reproducible by selecting a collapsed thread when pref mail.operate_on_msgs_in_collapsed_threads is at its default true. It seems to be caused by summarising the thread, see bug 1826633. Console output:

Did you try to stream an nttp message? Doesn't work. See bug 545365. 46 MimeMessage.jsm:132:13
TypeError: can't access property "parts", aPart is null
MimeMessage.jsm:146:7
mailnews.nntp: Failed to process server response [object Object]. NS_ERROR_XPC_JAVASCRIPT_ERROR_WITH_DETAILS: [JavaScript Error: "can't access property "parts", aPart is null" {file: "resource:///modules/gloda/MimeMessage.jsm" line: 146}]'[JavaScript Error: "can't access property "parts", aPart is null" {file: "resource:///modules/gloda/MimeMessage.jsm" line: 146}]' when calling method: [nsIStreamListener::onStopRequest]
    onDone resource:///modules/NntpChannel.jsm:338
    _actionDone resource:///modules/NntpClient.jsm:941
    _actionArticleResponse resource:///modules/NntpClient.jsm:765
    read resource:///modules/LineReader.jsm:65
    _actionArticleResponse resource:///modules/NntpClient.jsm:753
    _onData resource:///modules/NntpClient.jsm:225
NntpClient.jsm:227:20

With pref mail.operate_on_msgs_in_collapsed_threads set to false which disables the summarising, I don't see a problem.

Comment 12

[Wayne Mery (:wsmwk)]

Renato, Do you agree this is a duplicate of bug 1826633?

Comment 13

[MM]

Bug 1826633 aggravates the issue here, but it doesn't appear to be a straight duplicate. There seems to be a coding error triggered by summarising, see console output: Did you try to stream an nttp message? Doesn't work. See bug 545365. 46 MimeMessage.jsm:132:13.

Comment 14

[Renato Botelho]

(In reply to Wayne Mery (:wsmwk) from comment #12)

Renato, Do you agree this is a duplicate of bug 1826633?

I agree with MM here, it seems like Bug 1826633 aggravates the issue but it's not a duplicate

Comment 16

[Alfred Peters [:infofrommozilla]]

Bug 1826633 rather complains that with NNTP a summary is displayed at all.
The problem here is that this very summary does not work.

Comment 18

[Thomas D. (:thomas8)]

Is this an issue which is related/caused by supernova's new 3-pane implementation?

Comment 19

[Wayne Mery (:wsmwk)]

(In reply to Thomas D. (:thomas8) from comment #18)

Is this an issue which is related/caused by supernova's new 3-pane implementation?

Let's assume so.

Comment 20

[Wayne Mery (:wsmwk)]

Magnus, can you propose a solutoin for this or bug 1826633?

Comment 21

[Alfred Peters [:infofrommozilla]]

(In reply to Wayne Mery (:wsmwk) from comment #20)

Magnus, can you propose a solutoin

It would be nice to fix the problem before the next release. IMHO this is a blocker for TB115.

for this or bug 1826633?

That TB tries to load dozens of articles just for the summary, I think is a bit silly.

The overview should make do with the existing header or offline data and, if in doubt, rather display nothing.

Basically, I would prefer for newsgroups not to offer the summary at all.

(1(1¢)

Comment 22

[Geoff Lankow (:darktrojan)]

Attachment: Bug 1824422 - Stop trying to get a snippet of summarised NNTP messages. r=mkmelin

I think that displaying a summary of a collapsed thread is the right thing to do (it's consistent
with other types of message) but fetching a snippet is problematic, so let's just not do that.

Comment 23

[Alfred Peters [:infofrommozilla]]

(In reply to Geoff Lankow (:darktrojan) from comment #22)

Created attachment 9336954 [details]
Bug 1824422 - Stop trying to get a snippet of summarised NNTP messages. r=mkmelin

Very nice. That fixes the bug for me.

Comment 24

[Geoff Lankow (:darktrojan)]

Bug 545365 fixed this.