[PATCH] AsyncTask: Propagate cherrypy request information to worker threads
From: Zhou Zheng Sheng <zhshzhou@linux.vnet.ibm.com> cherrypy.request is a proxy for cherrypy.serving.request, and cherrypy.serving stores the request information on the thread local storage. When new threads created by Kimchi code, the related request information is not propagated to the new threads. The problem is that exception message translation code needs the Accept-Language header or session cookie to determine which language the user speaks. If the request information is missing, it assumes the language is English. Usually this is not a problem because most of the threads in Kimchi just run in background, and the exception message is written to log, so English in log is OK. However the AsyncTask catches the exception in thread and reports to the front-end, and this is not friendly to the user without proper translation. This patch propagates the request information to the new threads started by the AsyncTask, so exception message gets translated according to the request header or session cookie. Signed-off-by: Zhou Zheng Sheng <zhshzhou@linux.vnet.ibm.com> --- src/kimchi/asynctask.py | 2 ++ 1 file changed, 2 insertions(+) diff --git a/src/kimchi/asynctask.py b/src/kimchi/asynctask.py index 8f0d96c..b54f143 100644 --- a/src/kimchi/asynctask.py +++ b/src/kimchi/asynctask.py @@ -37,6 +37,7 @@ class AsyncTask(object): self.status = 'running' self.message = 'OK' self._save_helper() + self._cp_request = cherrypy.serving.request self.thread = threading.Thread(target=self._run_helper, args=(opaque, self._status_cb)) self.thread.setDaemon(True) @@ -63,6 +64,7 @@ class AsyncTask(object): session.store('task', self.id, obj) def _run_helper(self, opaque, cb): + cherrypy.serving.request = self._cp_request try: self.fn(cb, opaque) except Exception, e: -- 1.8.5.3
Hi, As I test, after apply this patch, it would triggers another Kimchi bug. The problem is in kimchi.model.debugreports.DebugReportsModel.sosreport_generate . In sosreport_generate there is a big "try" block to catch exceptions and translate into another exception OperationFailed. However the inner exception raised can also be Kimchi specific exception such as OperationFailed. So the error message gets translated and encoded twice and it would raise UnicodeEncodeError. This bug is related to but not caused by this patch. If you apply the patch and run into this bug, it's good because it proves the translation is working at least... on 2014/04/01 15:55, zhshzhou@linux.vnet.ibm.com wrote:
From: Zhou Zheng Sheng <zhshzhou@linux.vnet.ibm.com>
cherrypy.request is a proxy for cherrypy.serving.request, and cherrypy.serving stores the request information on the thread local storage. When new threads created by Kimchi code, the related request information is not propagated to the new threads. The problem is that exception message translation code needs the Accept-Language header or session cookie to determine which language the user speaks. If the request information is missing, it assumes the language is English.
Usually this is not a problem because most of the threads in Kimchi just run in background, and the exception message is written to log, so English in log is OK. However the AsyncTask catches the exception in thread and reports to the front-end, and this is not friendly to the user without proper translation.
This patch propagates the request information to the new threads started by the AsyncTask, so exception message gets translated according to the request header or session cookie.
Signed-off-by: Zhou Zheng Sheng <zhshzhou@linux.vnet.ibm.com> --- src/kimchi/asynctask.py | 2 ++ 1 file changed, 2 insertions(+)
diff --git a/src/kimchi/asynctask.py b/src/kimchi/asynctask.py index 8f0d96c..b54f143 100644 --- a/src/kimchi/asynctask.py +++ b/src/kimchi/asynctask.py @@ -37,6 +37,7 @@ class AsyncTask(object): self.status = 'running' self.message = 'OK' self._save_helper() + self._cp_request = cherrypy.serving.request self.thread = threading.Thread(target=self._run_helper, args=(opaque, self._status_cb)) self.thread.setDaemon(True) @@ -63,6 +64,7 @@ class AsyncTask(object): session.store('task', self.id, obj)
def _run_helper(self, opaque, cb): + cherrypy.serving.request = self._cp_request try: self.fn(cb, opaque) except Exception, e:
-- Thanks and best regards! Zhou Zheng Sheng / 周征晟 E-mail: zhshzhou@linux.vnet.ibm.com Telephone: 86-10-82454397
On 04/01/2014 05:07 AM, Zhou Zheng Sheng wrote:
Hi,
As I test, after apply this patch, it would triggers another Kimchi bug.
The problem is in kimchi.model.debugreports.DebugReportsModel.sosreport_generate .
In sosreport_generate there is a big "try" block to catch exceptions and translate into another exception OperationFailed. However the inner exception raised can also be Kimchi specific exception such as OperationFailed. So the error message gets translated and encoded twice and it would raise UnicodeEncodeError.
This bug is related to but not caused by this patch. If you apply the patch and run into this bug, it's good because it proves the translation is working at least...
Yes, I have already noticed this issue too. Are you going to send a patch to it?
on 2014/04/01 15:55, zhshzhou@linux.vnet.ibm.com wrote:
From: Zhou Zheng Sheng <zhshzhou@linux.vnet.ibm.com>
cherrypy.request is a proxy for cherrypy.serving.request, and cherrypy.serving stores the request information on the thread local storage. When new threads created by Kimchi code, the related request information is not propagated to the new threads. The problem is that exception message translation code needs the Accept-Language header or session cookie to determine which language the user speaks. If the request information is missing, it assumes the language is English.
Usually this is not a problem because most of the threads in Kimchi just run in background, and the exception message is written to log, so English in log is OK. However the AsyncTask catches the exception in thread and reports to the front-end, and this is not friendly to the user without proper translation.
This patch propagates the request information to the new threads started by the AsyncTask, so exception message gets translated according to the request header or session cookie.
Signed-off-by: Zhou Zheng Sheng <zhshzhou@linux.vnet.ibm.com> --- src/kimchi/asynctask.py | 2 ++ 1 file changed, 2 insertions(+)
diff --git a/src/kimchi/asynctask.py b/src/kimchi/asynctask.py index 8f0d96c..b54f143 100644 --- a/src/kimchi/asynctask.py +++ b/src/kimchi/asynctask.py @@ -37,6 +37,7 @@ class AsyncTask(object): self.status = 'running' self.message = 'OK' self._save_helper() + self._cp_request = cherrypy.serving.request self.thread = threading.Thread(target=self._run_helper, args=(opaque, self._status_cb)) self.thread.setDaemon(True) @@ -63,6 +64,7 @@ class AsyncTask(object): session.store('task', self.id, obj)
def _run_helper(self, opaque, cb): + cherrypy.serving.request = self._cp_request try: self.fn(cb, opaque) except Exception, e:
on 2014/04/02 03:13, Aline Manera wrote:
On 04/01/2014 05:07 AM, Zhou Zheng Sheng wrote:
Hi,
As I test, after apply this patch, it would triggers another Kimchi bug.
The problem is in kimchi.model.debugreports.DebugReportsModel.sosreport_generate .
In sosreport_generate there is a big "try" block to catch exceptions and translate into another exception OperationFailed. However the inner exception raised can also be Kimchi specific exception such as OperationFailed. So the error message gets translated and encoded twice and it would raise UnicodeEncodeError.
This bug is related to but not caused by this patch. If you apply the patch and run into this bug, it's good because it proves the translation is working at least...
Yes, I have already noticed this issue too. Are you going to send a patch to it?
Sure. Will do it today. -- Thanks and best regards! Zhou Zheng Sheng / 周征晟 E-mail: zhshzhou@linux.vnet.ibm.com Telephone: 86-10-82454397
Reviewed-by: Aline Manera <alinefm@linux.vnet.ibm.com> On 04/01/2014 04:55 AM, zhshzhou@linux.vnet.ibm.com wrote:
From: Zhou Zheng Sheng <zhshzhou@linux.vnet.ibm.com>
cherrypy.request is a proxy for cherrypy.serving.request, and cherrypy.serving stores the request information on the thread local storage. When new threads created by Kimchi code, the related request information is not propagated to the new threads. The problem is that exception message translation code needs the Accept-Language header or session cookie to determine which language the user speaks. If the request information is missing, it assumes the language is English.
Usually this is not a problem because most of the threads in Kimchi just run in background, and the exception message is written to log, so English in log is OK. However the AsyncTask catches the exception in thread and reports to the front-end, and this is not friendly to the user without proper translation.
This patch propagates the request information to the new threads started by the AsyncTask, so exception message gets translated according to the request header or session cookie.
Signed-off-by: Zhou Zheng Sheng <zhshzhou@linux.vnet.ibm.com> --- src/kimchi/asynctask.py | 2 ++ 1 file changed, 2 insertions(+)
diff --git a/src/kimchi/asynctask.py b/src/kimchi/asynctask.py index 8f0d96c..b54f143 100644 --- a/src/kimchi/asynctask.py +++ b/src/kimchi/asynctask.py @@ -37,6 +37,7 @@ class AsyncTask(object): self.status = 'running' self.message = 'OK' self._save_helper() + self._cp_request = cherrypy.serving.request self.thread = threading.Thread(target=self._run_helper, args=(opaque, self._status_cb)) self.thread.setDaemon(True) @@ -63,6 +64,7 @@ class AsyncTask(object): session.store('task', self.id, obj)
def _run_helper(self, opaque, cb): + cherrypy.serving.request = self._cp_request try: self.fn(cb, opaque) except Exception, e:
participants (3)
-
Aline Manera -
Zhou Zheng Sheng -
zhshzhou＠linux.vnet.ibm.com