Gwibber 2.0 does not fetch new messages

Bug #422864 reported by Mary Gardiner
12
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Gwibber
Fix Released
Undecided
Unassigned
gwibber (Ubuntu)
Fix Released
Wishlist
Unassigned

Bug Description

Package is 2.0.0~bzr400-0ubuntu1~daily1~jaunty

Gwibber has not refreshed messages for 17 hours. Explicitly invoking refresh from the menu or via Ctrl+R does nothing.

I don't have a lot else for you. This is Gwibber running on the command line:

$ gwibber -v -d
DEBUG:root:Launched from /usr/bin
DEBUG:root:Assuming path is correct
WARNING:root:desktopcouch is not available. . falling back to gconf
INFO:root:Found existing Gwibber interface: invoking...
INFO:root:No existing Gwibber session: starting...

[at this point I click on the Messages tab in the Account Tree which I have visible. I then press Ctrl+R and also select Refresh from the menus. Gwibber does not refresh or produce any further commandline output.]

summary: - Gwibber 2.0 does not refresh
+ Gwibber 2.0 does not fetch new messages
Revision history for this message
Alexander Telenga (telenga) wrote :

I confirm this bug.

Revision history for this message
Mary Gardiner (puzzlement) wrote : Re: [Bug 422864] Re: Gwibber 2.0 does not fetch new messages

Fetching new messages is working again for me at gwibber_2.0.0~bzr406-0ubuntu1~daily1~jaunty. The only thing that was noticeable as a user was that I was explicitly asked to reauthorise to Facebook.

Revision history for this message
Ryan Paul (segphault) wrote :

The Gwibber daemon has a threadpool which starts out with a finite number of threads. These threads are used to perform message retrieval operations. When all of the threads are occupied, new operations are put into a queue. When there is a bug in the Gwibber code for one of the services, it causes an exception to be raised in the thread and sometimes the thread will basically lock up and not be returned to the threadpool. When this happens enough times that all of the threads are hanging, Gwibber will not be able to refresh. It will queue the operations, but it will never actually start them because there no free threads available to do it.

My guess is that your Facebook account didn't have all of the requisite Gwibber permissions set up and so it was causing an exception to be raised in the threads that were trying to retrieve the Facebook messages, eventually locking up all of the threads in the threadpool. I recently added a fix to the Gwibber client that will make it check for Facebook permissions on startup and seek authorization if some are missing. It seems like that must have fixed the specific instance of this issue that you were encountering.

The hanging threads are a broader problem that still remains unresolved. I need to add a timeout mechanism or something like that. I'm going to leave this report open for now so we remember to address that issue.

Revision history for this message
Mary Gardiner (puzzlement) wrote :

Thanks for the information. Even with the Facebook authorisation, Gwibber only refreshed successfully a couple of times in the end, and now it is again not refreshing new messages.

Both times this has persisted across restarts of the process, and I don't know therefore that a blocked threadpool could be the explanation: wouldn't the threadpool be re-created on restart?

Revision history for this message
Ryan Paul (segphault) wrote :

The threadpool is recreated when the daemon is restarted. Are you restarting the daemon too, or just the GUI frontend process?

Try this:

  * Close the frontend and kill the gwibber-daemon process
  * Start gwibber-daemon manually from the command line
  * Then start the frontend and use it as normal

If the daemon is hitting exceptions, you should see them come out at the terminal where you started the daemon. If you could paste the traceback here, it might be really helpful.

Thanks!

Revision history for this message
Mary Gardiner (puzzlement) wrote :

It took me a couple of days after killing and starting the daemon to find Gwibber in a non-reloading state, and unfortunately this is what the daemon's output looks like (when I press Ctrl+R):

DEBUG:gwibber:Queueing Op: <private:identica>
DEBUG:gwibber:Queueing Op: <private:twitter>
DEBUG:gwibber:Queueing Op: <user_messages:twitter>
DEBUG:gwibber:Queueing Op: <receive:identica>
DEBUG:gwibber:Queueing Op: <receive:facebook>
DEBUG:gwibber:Queueing Op: <responses:identica>
DEBUG:gwibber:Queueing Op: <responses:twitter>
DEBUG:gwibber:Queueing Op: <receive:twitter>

No tracebacks, but no new content either (and there are new messages to fetch).

I have to scroll back some hundreds of lines to see a traceback, which was:

DEBUG:gwibber:Failed Op: <receive:twitter> - Traceback (most recent call last):
  File "/usr/lib/python2.6/dist-packages/gwibber/microblog/__init__.py", line 130, in run
    messages = self.perform_operation(opdata)
  File "/usr/lib/python2.6/dist-packages/gwibber/microblog/__init__.py", line 107, in perform_operation
    for message in output:
  File "/usr/lib/python2.6/dist-packages/gwibber/microblog/twitter.py", line 212, in receive
    for data in self.get_messages():
  File "/usr/lib/python2.6/dist-packages/gwibber/microblog/twitter.py", line 163, in get_messages
    urllib.urlencode({"count": self.account["receive_count"] or "20"})))
  File "/usr/lib/python2.6/dist-packages/gwibber/microblog/twitter.py", line 158, in connect
    "https://twitter.com/%s" % url, data, headers = {"Authorization": self.get_auth()}))
  File "/usr/lib/python2.6/urllib2.py", line 124, in urlopen
    return _opener.open(url, data, timeout)
  File "/usr/lib/python2.6/urllib2.py", line 383, in open
    response = self._open(req, data)
  File "/usr/lib/python2.6/urllib2.py", line 401, in _open
    '_open', req)
  File "/usr/lib/python2.6/urllib2.py", line 361, in _call_chain
    result = func(*args)
  File "/usr/lib/python2.6/urllib2.py", line 1138, in https_open
    return self.do_open(httplib.HTTPSConnection, req)
  File "/usr/lib/python2.6/urllib2.py", line 1105, in do_open
    raise URLError(err)
URLError: <urlopen error [Errno 104] Connection reset by peer>

Revision history for this message
Ryan Paul (segphault) wrote :

This is now fixed in trunk. Facebook's output was apparently confusing urllib2 and causing it hang indefinitely, completely ignoring the timout. Using PyCurl for Facebook solved the problem. I plan to drop urllib2 entirely in favor of PyCurl at some point in the future.

Changed in gwibber:
status: New → Fix Committed
Changed in gwibber (Ubuntu):
status: New → Confirmed
importance: Undecided → Wishlist
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package gwibber - 2.0.0~bzr467-0ubuntu1

---------------
gwibber (2.0.0~bzr467-0ubuntu1) karmic; urgency=low

  * New upstream snapshot - r467
    - set timeouts for connection and calls to facebook (LP: #422864)

 -- Ken VanDine <email address hidden> Mon, 19 Oct 2009 10:48:40 -0400

Changed in gwibber (Ubuntu):
status: Confirmed → Fix Released
Omer Akram (om26er)
Changed in gwibber:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.