Description of problem: In order for evolution to function properly, it is necessary to quit and restart it periodically throughout the day. It reaches a point where no new messages are brought over, or messages are partially brought over (from exchange). Verification against outlook or outlook web show that there ARE new messages, but none are transmitted, or they are transmitted without subjects, or with subjects but no body, or the headers come over, but the message cannot be read. Version-Release number of selected component (if applicable): Same behaviour is apparent in 2.28.2 and 2.29.5 of evolution / 0.28.2 and 0.29.5volution-mapi How reproducible: constantly throughout the day. I haven't found the catalyst yet (though it could very well be that exchange gets busy and doesn't respond in a timely manner) Steps to Reproduce: 1.start evolution 2.use it for some period of time 3. Actual results: messages stop coming over from exchange, or come over missing subject/content matter. Expected results: messages come over when send/receive is pressed, or when the configured time period elapses for it to automatically check for new messages, and I expect messages to come over in their entirety. Additional info:
Thanks for a bug report. Could you try these to identify the issue, please? a) run evolution from console in this way: $ evolution &>evo.log Then use it as before. b) when it gets to the state of not receiving any new messages run this on another console: $ gdb --batch --ex "t a a bt" -pid=EVO_PID &>bt.log where EVO_PID is a process ID of running evolution (ps -A | grep evo) Then close evolution and attach both logs here, please, only make sure you'll not include any private information in them, like passwords, emails, server names and addresses and such. Thanks in advance.
I'm attaching the requested documents now.
Created attachment 386912 [details] Evolution output The requested output from evolution.
Created attachment 386913 [details] gdb output The requested gdb output
... I'm going to re-upload the evo.log as I realized I had not closed evolution prior to grabbing the log. I figure if I don't, then you'll ask for it ;)
Created attachment 386914 [details] Evolution output The requested output from Evolution (obsoletes the earlier upload as that was grabbed prior to shutting down evolution)
Thanks for the update. I hoped there will be something specific in the logs, but it unfortunately isn't. What I see there, in evo console log, is that it's working properly until ~ middle, when suddenly a connection to the server was lost probably, and it prints on the console the only error: > camel-mapi-provider-WARNING **: Could not get folder list.. after that it fails to operate. The gdb log isn't showing anything unusual, few threads due to db-summary. From the above it seems it cannot recover after connection lost to the exchange server.
I have the exact same behaviour though my ability to send messages drops out first then I loose the ability to receive any new messages. THis has also been confirmed using outlook/OWA. I am running: kernel 2.6.31.9-174.fc12.i686.PAE evolution-exchange-2.28.2-1.fc12.i686 evolution-mapi-0.28.2-1.fc12.i686
I've noticed the same thing, regarding the ability to send messages. It will place new messages in the outbox, but will not send them, merely popping up an error that it is unable to send. But that would fall in what what was said above, that it never successfully recovers from losing its connection to exchange.
Thanks for the update. I had a chat with an upstream developer and he suggested me to upstream this bug, thus I'm doing so. Please follow [1] for more updates on this issue. [1] https://bugzilla.gnome.org/show_bug.cgi?id=608327
*** Bug 595337 has been marked as a duplicate of this bug. ***
*** Bug 722880 has been marked as a duplicate of this bug. ***
*** Bug 739319 has been marked as a duplicate of this bug. ***
I'll note that there has been no movement on the upstream bug in well over 9 months.
(In reply to comment #14) > I'll note that there has been no movement on the upstream bug in well over 9 > months. I'm wondering how much it is related to lost connection, at least this bug. There was a bug that openchange didn't close its connection towards the server, and because the e-addressbook-factory is opening/closing connection often, more-or-less, then the server could come to a state when it rejected any new connections through MAPI. This is fixed in openchange 0.11, which is part of Fedora 16. It doesn't cover evolution-exchange at all (as it is mentioned above as being able to reproduce it with it too).
Which server is rejecting the connection? The evo data server? Or Exchange? The fact that File -> Work Offline ; wait 30s ; File -> Work Online does not reset the connection implies (to me) that there are deeper issues.
(In reply to comment #16) > Which server is rejecting the connection? The evo data server? Or Exchange? I meant the exchange server. > The fact that File -> Work Offline ; wait 30s ; File -> Work Online does not > reset the connection implies (to me) that there are deeper issues. The issue I was talking on is this [1]. Try to grep for your server connections on the factory, to see how many you've them opened [2]. The issue was better visibly on the e-addressbook-factory, rather than on e-calendar-factory, but still, if one factory lefts opened connections, then the other can be rejected by exchange server, because it's still the same machine trying to open another connection. Note it cannot disconnect when you work offline in this case, because there is no handle to the connection, it's left behind the scene, in the case [1]. Still, this is just what I recalled, and what can, but may not be, relevant to evolution-mapi connection issues when having application opened for longer time with no connection interruptions. [1] http://tracker.openchange.org/issues/361 [2] lsof -p $PID | grep server.address
I put a comment referring t othis bugzilla in https://bugzilla.redhat.com/show_bug.cgi?id=741842