I get this error after 30-40 minutes of inactivity "The underlying socket is having troubles when processing connection to imap.gmail.com:993: Remote host closed connection" I'm connecting to imap gmail server and it looks like that after some time of inactivity, gmail closing connection. After that trojita not working and restart of application is required. Reproducible: Always Steps to Reproduce: 1. Configure gmail imap account 2. Start Trojita and do nothing (no folder opening) 3. Wait about 30-40 minutes Actual Results: Trojita show error message "The underlying socket is having troubles when processing connection to imap.gmail.com:993: Remote host closed connection" And all imap folders are empty. Trojita cannot connect to imap server again, restart of application is required. Expected Results: At least Trojita should try to reconnect after server close connection. Maybe some periodical NOP command could be usefull to prevent disconnecting due to inactivity.
Do you have a log of that situation? Disk based logging is probably useful in this situation (IMAP -> Debugging -> Log into ...). > After that trojita not working and restart of application is required. This is strange -- Trojita should notice that it's offline, indicate that in the network mode indicator, and a simple switch to online should fix this. What happens when you try to do this? Could you please attach the log of *that* as well? > Maybe some periodical NOP command could be usefull to prevent disconnecting > due to inactivity. Trojita will periodically ask for a STATUS of the visible mailboxes ("visible" == shown on the left). The IMAP standard guarantees that INBOX shall always be present, so there will always be at least one mailbox to poll. However, this polling does not happen when no mailboxes are "visible" (It's based on calls to QAbstractItemModel::data() via QTreeView after the model emits dataChanged; I know for sure that those mailboxes which are not visible in the view's viewport are not polled, and I don't know whether this hapens also when the window is minimized or in the systray, for example. Should be pretty easy to test -- check the m_periodicMailboxNumbersRefresh in Model.cpp.). There is also no polling when in the Expensive Network mode.
(In reply to comment #1) > Trojita will periodically ask for a STATUS of the visible mailboxes > ("visible" == shown on the left). The IMAP standard guarantees that INBOX > shall always be present, so there will always be at least one mailbox to > poll. However, this polling does not happen when no mailboxes are "visible" > (It's based on calls to QAbstractItemModel::data() via QTreeView after the > model emits dataChanged; I know for sure that those mailboxes which are not > visible in the view's viewport are not polled, and I don't know whether > this hapens also when the window is minimized or in the systray, for > example. I didn't see any explicit calls to data() for "visible" items in the code, so this probably relies on the access through the repaint in return of the protected dataChanged() slot of the view - and in this case the answer is "no". All widget repaints are compressed for invisible widgets since "show" will trigger a repaint anyway, so repaint won't cause a paintEvent here. This should fail if - the "left" splitter part is collapsed - the "one item" layout is used and on the "wrong" view too long - the window is minimized (and not kept mapped by the compositor for a "live thumbnail") - trojita "minimized" (actually "closed" ;-) to systray This is also the pending main issue (resp. it's trigger) with multiple accounts and there needs resolution to either explicitlly disconnecting collapsed resp. completely invisible (out of widget bounds) accounts or by explicitly calling to the data of one index (per account) when focusing on merging that.
> - the "left" splitter part is collapsed Only if nothing is shown anywhere else in Trojita. If that is the case, the user has bigger problems than Trojita disconnecting after half an hour, IMHO. > - the "one item" layout is used and on the "wrong" view too long In that case, either IDLE or the periodic NOOP polling is active, and the connection won't come offline. > - trojita "minimized" (actually "closed" ;-) to systray Interesting; the systray code actually only checks for messageCountPossiblyChanged(QModelIndex), a more specific signal than dataChanged(). That's likely a bug; patch for this is at https://git.reviewboard.kde.org/r/112474/ .
(In reply to comment #1) > Do you have a log of that situation? Disk based logging is probably useful > in this situation (IMAP -> Debugging -> Log into ...). > I will generate one. > > After that trojita not working and restart of application is required. > > This is strange -- Trojita should notice that it's offline, indicate that > in the network mode indicator, and a simple switch to online should fix > this. What happens when you try to do this? Could you please attach the log > of *that* as well? > How to switch it back to online? When I click on INBOX folder nothing happen and folder is empty. I have configured trojita to do not use offline cache and network access is free access.
On Tuesday, 3 September 2013 15:11:42 CEST, Pali Rohár wrote: > How to switch it back to online? IMAP -> Network Access -> Free Access There's also an icon in the lower right for this purpose.
Created attachment 82132 [details] trojita-connection-log It is not so easy to reproduce this bug and provide log file. But it is possible. I needed to modify trojita code to automatically start logging to file at startup, because it is not possible to start logging via GUI button and reproducing this bug (see steps why). I think this is race condition bug. I will update steps to reproduce: 1. configure trojita to do not store IMAP password and ask it at startup and enable systray icon 2. start trojita and wait until password dialog appear 3. enter password, click OK and immediately click on systray icon which hide trojita main window 4. it is needed that trojita main window will be hidden before it connect to imap server 5. wait 30 minutes and you will see that error message If I clicked on systray icon later (not immediately after entering password), then I'm not able to reproduce this bug.
(In reply to comment #5) > On Tuesday, 3 September 2013 15:11:42 CEST, Pali Rohár wrote: > > How to switch it back to online? > > IMAP -> Network Access -> Free Access > > There's also an icon in the lower right for this purpose. I cannot do that from standalone trojita version, because of bug #324458. Will try it in Kontact version.
OK, thanks for reporting this -- it made me fix a long-standing bug in mailbox discovery at least :). Your steps to reproduce were also very helpful -- indeed, even when the QTreeView on the left is collapsed so that it is not shown at all, its headers are still rendered which request a call to QAIM::rowCount() and the resulting activity gets noticed and a call to QAIM::data gets made which ultimately results in STATUS being sent. (The widgets are collapsed after a short delay when restoring their sizes.) This is tricky to fix properly -- the mailbox discovery is asynchronous in nature and there is no component which would "asynchronously wait for mailbox to become available". Some code is at src/XtConnect/MailboxFinder.cpp; it will have to be moved to a better location, changed so that it handles disconnects and unit-tested. When that is in place, we can also fix bug #321078, and *perhaps* also unconditionally open INBOX at the beginning.
Git commit ba2b2b0f4a17cb04e6265be71da2bd29ea8b907a by Jan Kundrát. Committed on 03/09/2013 at 06:22. Pushed by jkt into branch 'master'. Model: emit messageCountPossiblyChanged when periodically invalidating the message counts The code which takes care of periodically refreshing the view of mailboxes emits dataChanged() whenever it invalidates the cached message counts for a particular mailbox. The systray code was, however, only listening to the messageCountPossiblyChanged signal. During normal operation, this is not an issue because the GUI's views would intercept the dataChanged and ask for the actual data, which triggers an IMAP STATUS which in turn updates the message counts and systray therefore notices that the numbers might have changed. However, when the views are hidden for some reason, this process does not happen and the systray icon is not updated. REVIEW: 112474 M +1 -2 src/Imap/Model/Model.cpp http://commits.kde.org/trojita/ba2b2b0f4a17cb04e6265be71da2bd29ea8b907a
Thank you for the bug report. As this report hasn't seen any changes in 5 years or more, we ask if you can please confirm that the issue still persists. If this bug is no longer persisting or relevant please change the status to resolved.