"unknown" managed threads

simon_harrison · October 18, 2017, 11:00am

Hi All

Is this considered a problem

>>> service_container._managed_threads

{<eventlet.greenthread.GreenThread object at 0x7f0d35494e88>: 'run', 
<eventlet.greenthread.GreenThread object at 0x7f0d353b79c8>: 'run', 
<eventlet.greenthread.GreenThread object at 0x7f0d34fb2340>: '<unknown>', 
<eventlet.greenthread.GreenThread object at 0x7f0d34fb23d8>:
'<unknown>', <eventlet.greenthread.GreenThread object at 0x7f0d34fb2d58>: 
'<unknown>', <eventlet.greenthread.GreenThread object at 0x7f0d34fb2768>: 
'<unknown>'}

I was expecting to see the name of the entrypoint? Instead i see
"<unknown>".

Which does look to be nameko
behaviour: https://github.com/nameko/nameko/blob/0d8239a1580b1879c872c77dfcdba601040e064f/nameko/containers.py#L361

So is what I see a clue that an Extension or something is not configured
correctly as I should be seeing a name?

Thanks

mattbennett · October 19, 2017, 11:09pm

The "unknown" part is not a problem. The `identifier` keyword argument to
`spawn_managed_thread` was introduced in 2.4.0 -- if an extension provides
it you'll get better logging when threads are killed.

If you inspect the greenthread objects you'll be able to find out which
extensions aren't using the API fully.

···

On Wednesday, October 18, 2017 at 12:00:44 PM UTC+1, simon harrison wrote:

Hi All

Is this considered a problem
>>> service_container._managed_threads
{<eventlet.greenthread.GreenThread object at 0x7f0d35494e88>: 'run', 
<eventlet.greenthread.GreenThread object at 0x7f0d353b79c8>: 'run', 
<eventlet.greenthread.GreenThread object at 0x7f0d34fb2340>: '<unknown>', 
<eventlet.greenthread.GreenThread object at 0x7f0d34fb23d8>:
'<unknown>', <eventlet.greenthread.GreenThread object at 0x7f0d34fb2d58>: 
'<unknown>', <eventlet.greenthread.GreenThread object at 0x7f0d34fb2768>: 
'<unknown>'}
I was expecting to see the name of the entrypoint? Instead i see
"<unknown>".

Which does look to be nameko behaviour:
https://github.com/nameko/nameko/blob/0d8239a1580b1879c872c77dfcdba601040e064f/nameko/containers.py#L361

So is what I see a clue that an Extension or something is not configured
correctly as I should be seeing a name?

Thanks

simon_harrison · October 28, 2017, 11:51am

Hi Matt

thanks for your answer. It's taken a little while to get back to it, but
i've now tried it out. This is what I see

service_container._managed_threads

{<eventlet.greenthread.GreenThread object at 0x7f97d6f34e88>: 'run', <
eventlet.greenthread.GreenThread object at 0x7f97d6e999c8>: 'run', <eventlet
.greenthread.GreenThread object at 0x7f97d5c9ee88>: '<unknown>', <eventlet.
greenthread.GreenThread object at 0x7f97d6f34a60>: '<unknown>', <eventlet.
greenthread.GreenThread object at 0x7f97d6f34f20>: '<unknown>', <eventlet.
greenthread.GreenThread object at 0x7f97d6cb4508>: '<unknown>', <eventlet.
greenthread.GreenThread object at 0x7f97d5e1d930>: '<unknown>', <eventlet.
greenthread.GreenThread object at 0x7f97d5e1d340>: '<unknown>', <eventlet.
greenthread.GreenThread object at 0x7f97d6f34b90>: '<unknown>', <eventlet.
greenthread.GreenThread object at 0x7f97d5d4d930>: '<unknown>', <eventlet.
greenthread.GreenThread object at 0x7f97d6d210e0>: '<unknown>', <eventlet.
greenthread.GreenThread object at 0x7f97d6d21048>: '<unknown>'}

thread = list(service_container._managed_threads.keys())[-1]
dir(thread)

['GreenletExit', '__bool__', '__class__', '__delattr__', '__dict__',
'__dir__', '__doc__', '__eq__', '__format__', '__ge__', '__getattribute__',
'__getstate__', '__gt__', '__hash__', '__init__', '__init_subclass__',
'__le__', '__lt__', '__module__', '__ne__', '__new__', '__reduce__',
'__reduce_ex__', '__repr__', '__setattr__', '__sizeof__', '__str__',
'__subclasshook__', '_exit_event', '_exit_funcs', '_resolve_links',
'_resolving_links', '_stack_saved', 'cancel', 'dead', 'error', 'getcurrent',
'gettrace', 'gr_frame', 'kill', 'link', 'main', 'parent', 'run', 'settrace',
'switch', 'throw', 'unlink', 'wait']

How do i get a handle on what extension is responsible for the "unknown"
from here? i've had a play about but didn't have much joy.

Ta

···

On Friday, 20 October 2017 00:09:23 UTC+1, Matt Yule-Bennett wrote:

The "unknown" part is not a problem. The `identifier` keyword argument to
`spawn_managed_thread` was introduced in 2.4.0 -- if an extension provides
it you'll get better logging when threads are killed.

If you inspect the greenthread objects you'll be able to find out which
extensions aren't using the API fully.

On Wednesday, October 18, 2017 at 12:00:44 PM UTC+1, simon harrison wrote:
Hi All

Is this considered a problem
>>> service_container._managed_threads
{<eventlet.greenthread.GreenThread object at 0x7f0d35494e88>: 'run', 
<eventlet.greenthread.GreenThread object at 0x7f0d353b79c8>: 'run', 
<eventlet.greenthread.GreenThread object at 0x7f0d34fb2340>: '<unknown>', 
<eventlet.greenthread.GreenThread object at 0x7f0d34fb23d8>:
'<unknown>', <eventlet.greenthread.GreenThread object at 0x7f0d34fb2d58>: 
'<unknown>', <eventlet.greenthread.GreenThread object at 0x7f0d34fb2768>: 
'<unknown>'}
I was expecting to see the name of the entrypoint? Instead i see
"<unknown>".

Which does look to be nameko behaviour:
https://github.com/nameko/nameko/blob/0d8239a1580b1879c872c77dfcdba601040e064f/nameko/containers.py#L361

So is what I see a clue that an Extension or something is not configured
correctly as I should be seeing a name?

Thanks

David_Szotten · October 28, 2017, 1:18pm

Hi Simon,

try

import traceback
traceback.print_stack(thread.gr_frame)

best,
David

···

On Saturday, 28 October 2017 12:51:57 UTC+1, simon harrison wrote:

Hi Matt

thanks for your answer. It's taken a little while to get back to it, but
i've now tried it out. This is what I see

>>> service_container._managed_threads
{<eventlet.greenthread.GreenThread object at 0x7f97d6f34e88>: 'run', <
eventlet.greenthread.GreenThread object at 0x7f97d6e999c8>: 'run', <
eventlet.greenthread.GreenThread object at 0x7f97d5c9ee88>: '<unknown>', <
eventlet.greenthread.GreenThread object at 0x7f97d6f34a60>: '<unknown>', <
eventlet.greenthread.GreenThread object at 0x7f97d6f34f20>: '<unknown>', <
eventlet.greenthread.GreenThread object at 0x7f97d6cb4508>: '<unknown>', <
eventlet.greenthread.GreenThread object at 0x7f97d5e1d930>: '<unknown>', <
eventlet.greenthread.GreenThread object at 0x7f97d5e1d340>: '<unknown>', <
eventlet.greenthread.GreenThread object at 0x7f97d6f34b90>: '<unknown>', <
eventlet.greenthread.GreenThread object at 0x7f97d5d4d930>: '<unknown>', <
eventlet.greenthread.GreenThread object at 0x7f97d6d210e0>: '<unknown>', <
eventlet.greenthread.GreenThread object at 0x7f97d6d21048>: '<unknown>'}

>>> thread = list(service_container._managed_threads.keys())[-1]
>>> dir(thread)
['GreenletExit', '__bool__', '__class__', '__delattr__', '__dict__',
'__dir__', '__doc__', '__eq__', '__format__', '__ge__', '__getattribute__'
, '__getstate__', '__gt__', '__hash__', '__init__', '__init_subclass__',
'__le__', '__lt__', '__module__', '__ne__', '__new__', '__reduce__',
'__reduce_ex__', '__repr__', '__setattr__', '__sizeof__', '__str__',
'__subclasshook__', '_exit_event', '_exit_funcs', '_resolve_links',
'_resolving_links', '_stack_saved', 'cancel', 'dead', 'error',
'getcurrent', 'gettrace', 'gr_frame', 'kill', 'link', 'main', 'parent',
'run', 'settrace', 'switch', 'throw', 'unlink', 'wait']

How do i get a handle on what extension is responsible for the "unknown"
from here? i've had a play about but didn't have much joy.

Ta

On Friday, 20 October 2017 00:09:23 UTC+1, Matt Yule-Bennett wrote:
The "unknown" part is not a problem. The `identifier` keyword argument to
`spawn_managed_thread` was introduced in 2.4.0 -- if an extension provides
it you'll get better logging when threads are killed.

If you inspect the greenthread objects you'll be able to find out which
extensions aren't using the API fully.

On Wednesday, October 18, 2017 at 12:00:44 PM UTC+1, simon harrison wrote:
Hi All

Is this considered a problem
>>> service_container._managed_threads
{<eventlet.greenthread.GreenThread object at 0x7f0d35494e88>: 'run', 
<eventlet.greenthread.GreenThread object at 0x7f0d353b79c8>: 'run', 
<eventlet.greenthread.GreenThread object at 0x7f0d34fb2340>: '<unknown>', 
<eventlet.greenthread.GreenThread object at 0x7f0d34fb23d8>:
'<unknown>', <eventlet.greenthread.GreenThread object at 
0x7f0d34fb2d58>: '<unknown>', <eventlet.greenthread.GreenThread object at 
0x7f0d34fb2768>: '<unknown>'}
I was expecting to see the name of the entrypoint? Instead i see
"<unknown>".

Which does look to be nameko behaviour:
https://github.com/nameko/nameko/blob/0d8239a1580b1879c872c77dfcdba601040e064f/nameko/containers.py#L361

So is what I see a clue that an Extension or something is not configured
correctly as I should be seeing a name?

Thanks

simon_harrison · October 28, 2017, 3:41pm

Thanks David

I'm suspecting a custom New Relic integration to blame! All of my traces,
literally *all* of them, look like this

traceback.print_stack(thread.gr_frame)

  File "/usr/local/lib/python3.6/site-packages/eventlet/greenthread.py",
line 218, in main
    result = function(*args, **kwargs)
  File "/usr/local/lib/python3.6/site-packages/nameko/web/server.py", line
85, in process_request
    self._serv.process_request((sock, address))
  File "/usr/local/lib/python3.6/site-packages/eventlet/wsgi.py", line 750,
in process_request
    proto.__init__(sock, address, self)
  File "/usr/local/lib/python3.6/socketserver.py", line 696, in __init__
    self.handle()
  File "/usr/local/lib/python3.6/http/server.py", line 418, in handle
    self.handle_one_request()
  File "/usr/local/lib/python3.6/site-packages/eventlet/wsgi.py", line 410,
in handle_one_request
    self.handle_one_response()
  File "/usr/local/lib/python3.6/site-packages/eventlet/wsgi.py", line 523,
in handle_one_response
    for data in result:
  File
"/usr/local/lib/python3.6/site-packages/newrelic-2.78.0.57/newrelic/api/web_transaction.py"
, line 738, in __iter__
    for item in self.generator:
  File
"/usr/local/lib/python3.6/site-packages/newrelic-2.78.0.57/newrelic/api/web_transaction.py"
, line 1114, in __call__
    self.start_response)
  File "/usr/local/lib/python3.6/site-packages/nameko/web/server.py", line
163, in __call__
    rv = provider.handle_request(request)
  File "/usr/local/lib/python3.6/site-packages/nameko/web/handlers.py",
line 51, in handle_request
    result = event.wait()
  File "/usr/local/lib/python3.6/site-packages/eventlet/event.py", line 121,
in wait
    return hubs.get_hub().switch()
  File "/usr/local/lib/python3.6/site-packages/eventlet/hubs/hub.py", line
295, in switch
    return self.greenlet.switch()

Thanks Matt and David for helping me figure this out.

Simon

···

On Saturday, 28 October 2017 14:18:43 UTC+1, David Szotten wrote:

Hi Simon,

try

import traceback
traceback.print_stack(thread.gr_frame)

best,
David

On Saturday, 28 October 2017 12:51:57 UTC+1, simon harrison wrote:
Hi Matt

thanks for your answer. It's taken a little while to get back to it, but
i've now tried it out. This is what I see

>>> service_container._managed_threads
{<eventlet.greenthread.GreenThread object at 0x7f97d6f34e88>: 'run', <
eventlet.greenthread.GreenThread object at 0x7f97d6e999c8>: 'run', <
eventlet.greenthread.GreenThread object at 0x7f97d5c9ee88>: '<unknown>',
<eventlet.greenthread.GreenThread object at 0x7f97d6f34a60>: '<unknown>',
<eventlet.greenthread.GreenThread object at 0x7f97d6f34f20>: '<unknown>',
<eventlet.greenthread.GreenThread object at 0x7f97d6cb4508>: '<unknown>',
<eventlet.greenthread.GreenThread object at 0x7f97d5e1d930>: '<unknown>',
<eventlet.greenthread.GreenThread object at 0x7f97d5e1d340>: '<unknown>',
<eventlet.greenthread.GreenThread object at 0x7f97d6f34b90>: '<unknown>',
<eventlet.greenthread.GreenThread object at 0x7f97d5d4d930>: '<unknown>',
<eventlet.greenthread.GreenThread object at 0x7f97d6d210e0>: '<unknown>',
<eventlet.greenthread.GreenThread object at 0x7f97d6d21048>: '<unknown>'}

>>> thread = list(service_container._managed_threads.keys())[-1]
>>> dir(thread)
['GreenletExit', '__bool__', '__class__', '__delattr__', '__dict__',
'__dir__', '__doc__', '__eq__', '__format__', '__ge__',
'__getattribute__', '__getstate__', '__gt__', '__hash__', '__init__',
'__init_subclass__', '__le__', '__lt__', '__module__', '__ne__',
'__new__', '__reduce__', '__reduce_ex__', '__repr__', '__setattr__',
'__sizeof__', '__str__', '__subclasshook__', '_exit_event', '_exit_funcs'
, '_resolve_links', '_resolving_links', '_stack_saved', 'cancel', 'dead',
'error', 'getcurrent', 'gettrace', 'gr_frame', 'kill', 'link', 'main',
'parent', 'run', 'settrace', 'switch', 'throw', 'unlink', 'wait']

How do i get a handle on what extension is responsible for the "unknown"
from here? i've had a play about but didn't have much joy.

Ta

On Friday, 20 October 2017 00:09:23 UTC+1, Matt Yule-Bennett wrote:
The "unknown" part is not a problem. The `identifier` keyword argument
to `spawn_managed_thread` was introduced in 2.4.0 -- if an extension
provides it you'll get better logging when threads are killed.

If you inspect the greenthread objects you'll be able to find out which
extensions aren't using the API fully.

On Wednesday, October 18, 2017 at 12:00:44 PM UTC+1, simon harrison >>> wrote:
Hi All

Is this considered a problem
>>> service_container._managed_threads
{<eventlet.greenthread.GreenThread object at 0x7f0d35494e88>: 'run', 
<eventlet.greenthread.GreenThread object at 0x7f0d353b79c8>: 'run', 
<eventlet.greenthread.GreenThread object at 0x7f0d34fb2340>: '<unknown>', 
<eventlet.greenthread.GreenThread object at 0x7f0d34fb23d8>:
'<unknown>', <eventlet.greenthread.GreenThread object at 
0x7f0d34fb2d58>: '<unknown>', <eventlet.greenthread.GreenThread object at 
0x7f0d34fb2768>: '<unknown>'}
I was expecting to see the name of the entrypoint? Instead i see
"<unknown>".

Which does look to be nameko behaviour:
https://github.com/nameko/nameko/blob/0d8239a1580b1879c872c77dfcdba601040e064f/nameko/containers.py#L361

So is what I see a clue that an Extension or something is not
configured correctly as I should be seeing a name?

Thanks

David_Szotten · October 28, 2017, 3:58pm

No, i think it can probably be considered a bug in nameko. I would expect
bundled extensions to make sure they provide a useful identifier,
but https://github.com/nameko/nameko/blob/0d8239a1580b1879c872c77dfcdba601040e064f/nameko/web/server.py#L80
uses `functools.partial` which hides the function name from the heuristics
that guess the identifier and so should probably specify an identifier
explicitly

best,
david

···

On Saturday, 28 October 2017 16:41:06 UTC+1, simon harrison wrote:

Thanks David

I'm suspecting a custom New Relic integration to blame! All of my traces,
literally *all* of them, look like this

>>> traceback.print_stack(thread.gr_frame)
  File "/usr/local/lib/python3.6/site-packages/eventlet/greenthread.py",
line 218, in main
    result = function(*args, **kwargs)
  File "/usr/local/lib/python3.6/site-packages/nameko/web/server.py",
line 85, in process_request
    self._serv.process_request((sock, address))
  File "/usr/local/lib/python3.6/site-packages/eventlet/wsgi.py", line 750
, in process_request
    proto.__init__(sock, address, self)
  File "/usr/local/lib/python3.6/socketserver.py", line 696, in __init__
    self.handle()
  File "/usr/local/lib/python3.6/http/server.py", line 418, in handle
    self.handle_one_request()
  File "/usr/local/lib/python3.6/site-packages/eventlet/wsgi.py", line 410
, in handle_one_request
    self.handle_one_response()
  File "/usr/local/lib/python3.6/site-packages/eventlet/wsgi.py", line 523
, in handle_one_response
    for data in result:
  File
"/usr/local/lib/python3.6/site-packages/newrelic-2.78.0.57/newrelic/api/web_transaction.py"
, line 738, in __iter__
    for item in self.generator:
  File
"/usr/local/lib/python3.6/site-packages/newrelic-2.78.0.57/newrelic/api/web_transaction.py"
, line 1114, in __call__
    self.start_response)
  File "/usr/local/lib/python3.6/site-packages/nameko/web/server.py",
line 163, in __call__
    rv = provider.handle_request(request)
  File "/usr/local/lib/python3.6/site-packages/nameko/web/handlers.py",
line 51, in handle_request
    result = event.wait()
  File "/usr/local/lib/python3.6/site-packages/eventlet/event.py", line
121, in wait
    return hubs.get_hub().switch()
  File "/usr/local/lib/python3.6/site-packages/eventlet/hubs/hub.py",
line 295, in switch
    return self.greenlet.switch()

Thanks Matt and David for helping me figure this out.

Simon

On Saturday, 28 October 2017 14:18:43 UTC+1, David Szotten wrote:
Hi Simon,

try

import traceback
traceback.print_stack(thread.gr_frame)

best,
David

On Saturday, 28 October 2017 12:51:57 UTC+1, simon harrison wrote:
Hi Matt

thanks for your answer. It's taken a little while to get back to it, but
i've now tried it out. This is what I see

>>> service_container._managed_threads
{<eventlet.greenthread.GreenThread object at 0x7f97d6f34e88>: 'run', <
eventlet.greenthread.GreenThread object at 0x7f97d6e999c8>: 'run', <
eventlet.greenthread.GreenThread object at 0x7f97d5c9ee88>: '<unknown>',
<eventlet.greenthread.GreenThread object at 0x7f97d6f34a60>: '<unknown>'
, <eventlet.greenthread.GreenThread object at 0x7f97d6f34f20>:
'<unknown>', <eventlet.greenthread.GreenThread object at 0x7f97d6cb4508
>: '<unknown>', <eventlet.greenthread.GreenThread object at
0x7f97d5e1d930>: '<unknown>', <eventlet.greenthread.GreenThread object
at 0x7f97d5e1d340>: '<unknown>', <eventlet.greenthread.GreenThread
object at 0x7f97d6f34b90>: '<unknown>', <eventlet.greenthread.
GreenThread object at 0x7f97d5d4d930>: '<unknown>', <eventlet.
greenthread.GreenThread object at 0x7f97d6d210e0>: '<unknown>', <
eventlet.greenthread.GreenThread object at 0x7f97d6d21048>: '<unknown>'}

>>> thread = list(service_container._managed_threads.keys())[-1]
>>> dir(thread)
['GreenletExit', '__bool__', '__class__', '__delattr__', '__dict__',
'__dir__', '__doc__', '__eq__', '__format__', '__ge__',
'__getattribute__', '__getstate__', '__gt__', '__hash__', '__init__',
'__init_subclass__', '__le__', '__lt__', '__module__', '__ne__',
'__new__', '__reduce__', '__reduce_ex__', '__repr__', '__setattr__',
'__sizeof__', '__str__', '__subclasshook__', '_exit_event',
'_exit_funcs', '_resolve_links', '_resolving_links', '_stack_saved',
'cancel', 'dead', 'error', 'getcurrent', 'gettrace', 'gr_frame', 'kill',
'link', 'main', 'parent', 'run', 'settrace', 'switch', 'throw', 'unlink'
, 'wait']

How do i get a handle on what extension is responsible for the "unknown"
from here? i've had a play about but didn't have much joy.

Ta

On Friday, 20 October 2017 00:09:23 UTC+1, Matt Yule-Bennett wrote:
The "unknown" part is not a problem. The `identifier` keyword argument
to `spawn_managed_thread` was introduced in 2.4.0 -- if an extension
provides it you'll get better logging when threads are killed.

If you inspect the greenthread objects you'll be able to find out which
extensions aren't using the API fully.

On Wednesday, October 18, 2017 at 12:00:44 PM UTC+1, simon harrison >>>> wrote:
Hi All

Is this considered a problem
>>> service_container._managed_threads
{<eventlet.greenthread.GreenThread object at 0x7f0d35494e88>: 'run', 
<eventlet.greenthread.GreenThread object at 0x7f0d353b79c8>: 'run', 
<eventlet.greenthread.GreenThread object at 0x7f0d34fb2340>: '<unknown>', 
<eventlet.greenthread.GreenThread object at 0x7f0d34fb23d8>:
'<unknown>', <eventlet.greenthread.GreenThread object at 
0x7f0d34fb2d58>: '<unknown>', <eventlet.greenthread.GreenThread object at 
0x7f0d34fb2768>: '<unknown>'}
I was expecting to see the name of the entrypoint? Instead i see
"<unknown>".

Which does look to be nameko behaviour:
https://github.com/nameko/nameko/blob/0d8239a1580b1879c872c77dfcdba601040e064f/nameko/containers.py#L361

So is what I see a clue that an Extension or something is not
configured correctly as I should be seeing a name?

Thanks

mattbennett · October 28, 2017, 7:03pm

Yes, WebServer.run should definitely pass an identifier to
spawn_managed_thread. There may be other built-in extensions that need
updating too.

Easy PR for anyone that wanted it

···

On Saturday, October 28, 2017 at 4:58:42 PM UTC+1, David Szotten wrote:

No, i think it can probably be considered a bug in nameko. I would expect
bundled extensions to make sure they provide a useful identifier, but
https://github.com/nameko/nameko/blob/0d8239a1580b1879c872c77dfcdba601040e064f/nameko/web/server.py#L80
uses `functools.partial` which hides the function name from the heuristics
that guess the identifier and so should probably specify an identifier
explicitly

best,
david

On Saturday, 28 October 2017 16:41:06 UTC+1, simon harrison wrote:
Thanks David

I'm suspecting a custom New Relic integration to blame! All of my traces,
literally *all* of them, look like this

>>> traceback.print_stack(thread.gr_frame)
  File "/usr/local/lib/python3.6/site-packages/eventlet/greenthread.py",
line 218, in main
    result = function(*args, **kwargs)
  File "/usr/local/lib/python3.6/site-packages/nameko/web/server.py",
line 85, in process_request
    self._serv.process_request((sock, address))
  File "/usr/local/lib/python3.6/site-packages/eventlet/wsgi.py", line
750, in process_request
    proto.__init__(sock, address, self)
  File "/usr/local/lib/python3.6/socketserver.py", line 696, in __init__
    self.handle()
  File "/usr/local/lib/python3.6/http/server.py", line 418, in handle
    self.handle_one_request()
  File "/usr/local/lib/python3.6/site-packages/eventlet/wsgi.py", line
410, in handle_one_request
    self.handle_one_response()
  File "/usr/local/lib/python3.6/site-packages/eventlet/wsgi.py", line
523, in handle_one_response
    for data in result:
  File
"/usr/local/lib/python3.6/site-packages/newrelic-2.78.0.57/newrelic/api/web_transaction.py"
, line 738, in __iter__
    for item in self.generator:
  File
"/usr/local/lib/python3.6/site-packages/newrelic-2.78.0.57/newrelic/api/web_transaction.py"
, line 1114, in __call__
    self.start_response)
  File "/usr/local/lib/python3.6/site-packages/nameko/web/server.py",
line 163, in __call__
    rv = provider.handle_request(request)
  File "/usr/local/lib/python3.6/site-packages/nameko/web/handlers.py",
line 51, in handle_request
    result = event.wait()
  File "/usr/local/lib/python3.6/site-packages/eventlet/event.py", line
121, in wait
    return hubs.get_hub().switch()
  File "/usr/local/lib/python3.6/site-packages/eventlet/hubs/hub.py",
line 295, in switch
    return self.greenlet.switch()

Thanks Matt and David for helping me figure this out.

Simon

On Saturday, 28 October 2017 14:18:43 UTC+1, David Szotten wrote:
Hi Simon,

try

import traceback
traceback.print_stack(thread.gr_frame)

best,
David

On Saturday, 28 October 2017 12:51:57 UTC+1, simon harrison wrote:
Hi Matt

thanks for your answer. It's taken a little while to get back to it,
but i've now tried it out. This is what I see

>>> service_container._managed_threads
{<eventlet.greenthread.GreenThread object at 0x7f97d6f34e88>: 'run', <
eventlet.greenthread.GreenThread object at 0x7f97d6e999c8>: 'run', <
eventlet.greenthread.GreenThread object at 0x7f97d5c9ee88>: '<unknown>'
, <eventlet.greenthread.GreenThread object at 0x7f97d6f34a60>:
'<unknown>', <eventlet.greenthread.GreenThread object at 0x7f97d6f34f20
>: '<unknown>', <eventlet.greenthread.GreenThread object at
0x7f97d6cb4508>: '<unknown>', <eventlet.greenthread.GreenThread object
at 0x7f97d5e1d930>: '<unknown>', <eventlet.greenthread.GreenThread
object at 0x7f97d5e1d340>: '<unknown>', <eventlet.greenthread.
GreenThread object at 0x7f97d6f34b90>: '<unknown>', <eventlet.
greenthread.GreenThread object at 0x7f97d5d4d930>: '<unknown>', <
eventlet.greenthread.GreenThread object at 0x7f97d6d210e0>: '<unknown>'
, <eventlet.greenthread.GreenThread object at 0x7f97d6d21048>:
'<unknown>'}

>>> thread = list(service_container._managed_threads.keys())[-1]
>>> dir(thread)
['GreenletExit', '__bool__', '__class__', '__delattr__', '__dict__',
'__dir__', '__doc__', '__eq__', '__format__', '__ge__',
'__getattribute__', '__getstate__', '__gt__', '__hash__', '__init__',
'__init_subclass__', '__le__', '__lt__', '__module__', '__ne__',
'__new__', '__reduce__', '__reduce_ex__', '__repr__', '__setattr__',
'__sizeof__', '__str__', '__subclasshook__', '_exit_event',
'_exit_funcs', '_resolve_links', '_resolving_links', '_stack_saved',
'cancel', 'dead', 'error', 'getcurrent', 'gettrace', 'gr_frame', 'kill'
, 'link', 'main', 'parent', 'run', 'settrace', 'switch', 'throw',
'unlink', 'wait']

How do i get a handle on what extension is responsible for the
"unknown" from here? i've had a play about but didn't have much joy.

Ta

On Friday, 20 October 2017 00:09:23 UTC+1, Matt Yule-Bennett wrote:
The "unknown" part is not a problem. The `identifier` keyword argument
to `spawn_managed_thread` was introduced in 2.4.0 -- if an extension
provides it you'll get better logging when threads are killed.

If you inspect the greenthread objects you'll be able to find out
which extensions aren't using the API fully.

On Wednesday, October 18, 2017 at 12:00:44 PM UTC+1, simon harrison >>>>> wrote:
Hi All

Is this considered a problem
>>> service_container._managed_threads
{<eventlet.greenthread.GreenThread object at 0x7f0d35494e88>: 'run', 
<eventlet.greenthread.GreenThread object at 0x7f0d353b79c8>: 'run', 
<eventlet.greenthread.GreenThread object at 0x7f0d34fb2340>: '<unknown>', 
<eventlet.greenthread.GreenThread object at 0x7f0d34fb23d8>:
'<unknown>', <eventlet.greenthread.GreenThread object at 
0x7f0d34fb2d58>: '<unknown>', <eventlet.greenthread.GreenThread object at 
0x7f0d34fb2768>: '<unknown>'}
I was expecting to see the name of the entrypoint? Instead i see
"<unknown>".

Which does look to be nameko behaviour:
https://github.com/nameko/nameko/blob/0d8239a1580b1879c872c77dfcdba601040e064f/nameko/containers.py#L361

So is what I see a clue that an Extension or something is not
configured correctly as I should be seeing a name?

Thanks

Topic		Replies	Views
Concurrent webrequests seem threaded instead of greenthreaded	5	513	May 25, 2021
Service that dynamically spawns and kills managed threads?	3	304	February 26, 2023
DependencyProvider with an eventlet.pool?	3	589	February 25, 2019
Nameko DeadLock - Sharing Experience googlegroup	5	1060	June 2, 2017
Issues with Eventlet 0.21 and ftplib in Python3 googlegroup	3	454	February 20, 2018

"unknown" managed threads

Related Topics