Bug 853151 - "No object (name: translator) has been registered for this thread" due to private threading
Summary: "No object (name: translator) has been registered for this thread" due to pri...
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: luci
Version: 6.3
Hardware: Unspecified
OS: Unspecified
Target Milestone: rc
: ---
Assignee: Jan Pokorný [poki]
QA Contact: Cluster QE
Depends On:
Blocks: 826951
TreeView+ depends on / blocked
Reported: 2012-08-30 15:34 UTC by Jan Pokorný [poki]
Modified: 2013-07-09 19:54 UTC (History)
4 users (show)

Fixed In Version: luci-0.26.0-15.el6
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2013-02-21 08:22:29 UTC
Target Upstream Version:

Attachments (Terms of Use)

System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2013:0309 normal SHIPPED_LIVE luci bug fix and enhancement update 2013-02-20 20:35:24 UTC
Red Hat Knowledge Base (Solution) 420273 None None None Never

Description Jan Pokorný [poki] 2012-08-30 15:34:07 UTC
PWorker(threading.Thread) from luci/lib/ricci_helpers represents
a partly separated environment from its per-request thread.
One of the side-effects is that "translator" is not present
natively as in case of the framework-managed threads.

As a consequence, a request towards ricci handled by PWorker
can, if any error/exception occur, can be silently dropped.
The symptoms are:
- unexpected behavior: looks like the action has never been initiated
  by the user
- messages like these in /var/log/luci/luci.log:

16:15:45,344 ERROR [luci.lib.ricci_helpers]
  No object (name: translator) has been registered for this thread
16:15:45,350 ERROR [luci.lib.ricci_helpers]
  Error retrieving batch number from rhel63-64kvm-1:
  No object (name: translator) has been registered for this thread

This is due to such circumstances that fulfillment of request towards
ricci (done via PWorker/private threading) will fail and the message
to be presented to the user is arranged as lazily translated string.
Apparently, this works well outside private threading (so the user
is informed correctly about the problem), but fails in private
threading environment lacking the explicitly set translator.

Based on brief investigation, there are two options to solve this:
a/ make lazily translated strings as standard strings
   - easy, but non-systemic solution
b/ try to register translator object in the private threading
   - seems like a right way to solve it
   - see [1] for further hints

Tested reproducer:

1. cluster added into luci
2. within luci, select specific cluster, then fence devices tab
3. add any fence device, using non-ascii for, e.g., name

Expected behavior in this case is that the user is visually
informed in the spirit of "this went wrong".  Currently, nothing
happens from user's standpoint, previous page is just refreshed.

[1] http://comments.gmane.org/gmane.comp.web.turbogears/46896

Comment 2 Jan Pokorný [poki] 2012-08-31 09:53:55 UTC
Correcting myself, expected behavior is that something sensible is pushed
into luci.log instead of "No object (name: translator)...".

That is to say the latter is failure to inform about the failure and we
want to see just that original one.

Comment 5 Jan Pokorný [poki] 2012-08-31 13:46:45 UTC
Upstream change:

Comment 13 errata-xmlrpc 2013-02-21 08:22:29 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.


Note You need to log in before you can comment on or make changes to this bug.