# "unknown" managed threads

**URL:** <https://discourse.nameko.io/t/unknown-managed-threads/211>\
**Category:** googlegroup\
**Created:** [October 18, 2017, 11:00am UTC](https://discourse.nameko.io/t/unknown-managed-threads/211 "2017-10-18T11:00:44Z")\
**Posts on this page:** 7\
**Page:** 1

<div class="post-metadata">

**Author:** ![simon\_harrison](https://avatars.discourse-cdn.com/v4/letter/s/b5ac83/32.png) [@simon\_harrison](https://discourse.nameko.io/u/simon_harrison)\
**Post date:** [October 18, 2017, 11:00am UTC](https://discourse.nameko.io/t/unknown-managed-threads/211/1 "2017-10-18T11:00:44Z")

</div>

Hi All

Is this considered a problem

```auto
>>> 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](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

---

<div class="post-metadata">

**Author:** ![mattbennett](https://yyz1.discourse-cdn.com/flex031/user_avatar/discourse.nameko.io/mattbennett/32/13_2.png) [@mattbennett](https://discourse.nameko.io/u/mattbennett)\
**Post date:** [October 19, 2017, 11:09pm UTC](https://discourse.nameko.io/t/unknown-managed-threads/211/2 "2017-10-19T23:09:23Z")

</div>

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
> > 
> > ```auto
> > >>> 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](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

---

<div class="post-metadata">

**Author:** ![simon\_harrison](https://avatars.discourse-cdn.com/v4/letter/s/b5ac83/32.png) [@simon\_harrison](https://discourse.nameko.io/u/simon_harrison)\
**Post date:** [October 28, 2017, 11:51am UTC](https://discourse.nameko.io/t/unknown-managed-threads/211/3 "2017-10-28T11:51:56Z")

</div>

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
> > > 
> > > ```auto
> > > >>> 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](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

---

<div class="post-metadata">

**Author:** ![David\_Szotten](https://yyz1.discourse-cdn.com/flex031/user_avatar/discourse.nameko.io/david_szotten/32/6_2.png) [@David\_Szotten](https://discourse.nameko.io/u/David_Szotten)\
**Post date:** [October 28, 2017, 1:18pm UTC](https://discourse.nameko.io/t/unknown-managed-threads/211/4 "2017-10-28T13:18:43Z")

</div>

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
> > > > 
> > > > ```auto
> > > > >>> 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](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

---

<div class="post-metadata">

**Author:** ![simon\_harrison](https://avatars.discourse-cdn.com/v4/letter/s/b5ac83/32.png) [@simon\_harrison](https://discourse.nameko.io/u/simon_harrison)\
**Post date:** [October 28, 2017, 3:41pm UTC](https://discourse.nameko.io/t/unknown-managed-threads/211/5 "2017-10-28T15:41:06Z")

</div>

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)

&nbsp;&nbsp;File "/usr/local/lib/python3.6/site-packages/eventlet/greenthread.py",  
line 218, in main  
&nbsp;&nbsp;&nbsp;&nbsp;result = function(\*args, \*\*kwargs)  
&nbsp;&nbsp;File "/usr/local/lib/python3.6/site-packages/nameko/web/server.py", line  
85, in process\_request  
&nbsp;&nbsp;&nbsp;&nbsp;self.\_serv.process\_request((sock, address))  
&nbsp;&nbsp;File "/usr/local/lib/python3.6/site-packages/eventlet/wsgi.py", line 750,  
in process\_request  
&nbsp;&nbsp;&nbsp;&nbsp;proto.\_\_init\_\_(sock, address, self)  
&nbsp;&nbsp;File "/usr/local/lib/python3.6/socketserver.py", line 696, in \_\_init\_\_  
&nbsp;&nbsp;&nbsp;&nbsp;self.handle()  
&nbsp;&nbsp;File "/usr/local/lib/python3.6/http/server.py", line 418, in handle  
&nbsp;&nbsp;&nbsp;&nbsp;self.handle\_one\_request()  
&nbsp;&nbsp;File "/usr/local/lib/python3.6/site-packages/eventlet/wsgi.py", line 410,  
in handle\_one\_request  
&nbsp;&nbsp;&nbsp;&nbsp;self.handle\_one\_response()  
&nbsp;&nbsp;File "/usr/local/lib/python3.6/site-packages/eventlet/wsgi.py", line 523,  
in handle\_one\_response  
&nbsp;&nbsp;&nbsp;&nbsp;for data in result:  
&nbsp;&nbsp;File  
"/usr/local/lib/python3.6/site-packages/newrelic-2.78.0.57/newrelic/api/web\_transaction.py"  
, line 738, in \_\_iter\_\_  
&nbsp;&nbsp;&nbsp;&nbsp;for item in self.generator:  
&nbsp;&nbsp;File  
"/usr/local/lib/python3.6/site-packages/newrelic-2.78.0.57/newrelic/api/web\_transaction.py"  
, line 1114, in \_\_call\_\_  
&nbsp;&nbsp;&nbsp;&nbsp;self.start\_response)  
&nbsp;&nbsp;File "/usr/local/lib/python3.6/site-packages/nameko/web/server.py", line  
163, in \_\_call\_\_  
&nbsp;&nbsp;&nbsp;&nbsp;rv = provider.handle\_request(request)  
&nbsp;&nbsp;File "/usr/local/lib/python3.6/site-packages/nameko/web/handlers.py",  
line 51, in handle\_request  
&nbsp;&nbsp;&nbsp;&nbsp;result = event.wait()  
&nbsp;&nbsp;File "/usr/local/lib/python3.6/site-packages/eventlet/event.py", line 121,  
in wait  
&nbsp;&nbsp;&nbsp;&nbsp;return hubs.get\_hub().switch()  
&nbsp;&nbsp;File "/usr/local/lib/python3.6/site-packages/eventlet/hubs/hub.py", line  
295, in switch  
&nbsp;&nbsp;&nbsp;&nbsp;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
> > > > > 
> > > > > ```auto
> > > > > >>> 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](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

---

<div class="post-metadata">

**Author:** ![David\_Szotten](https://yyz1.discourse-cdn.com/flex031/user_avatar/discourse.nameko.io/david_szotten/32/6_2.png) [@David\_Szotten](https://discourse.nameko.io/u/David_Szotten)\
**Post date:** [October 28, 2017, 3:58pm UTC](https://discourse.nameko.io/t/unknown-managed-threads/211/6 "2017-10-28T15:58:42Z")

</div>

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](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)  
> > &nbsp;&nbsp;File "/usr/local/lib/python3.6/site-packages/eventlet/greenthread.py",  
> > line 218, in main  
> > &nbsp;&nbsp;&nbsp;&nbsp;result = function(\*args, \*\*kwargs)  
> > &nbsp;&nbsp;File "/usr/local/lib/python3.6/site-packages/nameko/web/server.py",  
> > line 85, in process\_request  
> > &nbsp;&nbsp;&nbsp;&nbsp;self.\_serv.process\_request((sock, address))  
> > &nbsp;&nbsp;File "/usr/local/lib/python3.6/site-packages/eventlet/wsgi.py", line 750  
> > , in process\_request  
> > &nbsp;&nbsp;&nbsp;&nbsp;proto.\_\_init\_\_(sock, address, self)  
> > &nbsp;&nbsp;File "/usr/local/lib/python3.6/socketserver.py", line 696, in \_\_init\_\_  
> > &nbsp;&nbsp;&nbsp;&nbsp;self.handle()  
> > &nbsp;&nbsp;File "/usr/local/lib/python3.6/http/server.py", line 418, in handle  
> > &nbsp;&nbsp;&nbsp;&nbsp;self.handle\_one\_request()  
> > &nbsp;&nbsp;File "/usr/local/lib/python3.6/site-packages/eventlet/wsgi.py", line 410  
> > , in handle\_one\_request  
> > &nbsp;&nbsp;&nbsp;&nbsp;self.handle\_one\_response()  
> > &nbsp;&nbsp;File "/usr/local/lib/python3.6/site-packages/eventlet/wsgi.py", line 523  
> > , in handle\_one\_response  
> > &nbsp;&nbsp;&nbsp;&nbsp;for data in result:  
> > &nbsp;&nbsp;File  
> > "/usr/local/lib/python3.6/site-packages/newrelic-2.78.0.57/newrelic/api/web\_transaction.py"  
> > , line 738, in \_\_iter\_\_  
> > &nbsp;&nbsp;&nbsp;&nbsp;for item in self.generator:  
> > &nbsp;&nbsp;File  
> > "/usr/local/lib/python3.6/site-packages/newrelic-2.78.0.57/newrelic/api/web\_transaction.py"  
> > , line 1114, in \_\_call\_\_  
> > &nbsp;&nbsp;&nbsp;&nbsp;self.start\_response)  
> > &nbsp;&nbsp;File "/usr/local/lib/python3.6/site-packages/nameko/web/server.py",  
> > line 163, in \_\_call\_\_  
> > &nbsp;&nbsp;&nbsp;&nbsp;rv = provider.handle\_request(request)  
> > &nbsp;&nbsp;File "/usr/local/lib/python3.6/site-packages/nameko/web/handlers.py",  
> > line 51, in handle\_request  
> > &nbsp;&nbsp;&nbsp;&nbsp;result = event.wait()  
> > &nbsp;&nbsp;File "/usr/local/lib/python3.6/site-packages/eventlet/event.py", line  
> > 121, in wait  
> > &nbsp;&nbsp;&nbsp;&nbsp;return hubs.get\_hub().switch()  
> > &nbsp;&nbsp;File "/usr/local/lib/python3.6/site-packages/eventlet/hubs/hub.py",  
> > line 295, in switch  
> > &nbsp;&nbsp;&nbsp;&nbsp;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
> > > > > > 
> > > > > > ```auto
> > > > > > >>> 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](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

---

<div class="post-metadata">

**Author:** ![mattbennett](https://yyz1.discourse-cdn.com/flex031/user_avatar/discourse.nameko.io/mattbennett/32/13_2.png) [@mattbennett](https://discourse.nameko.io/u/mattbennett)\
**Post date:** [October 28, 2017, 7:03pm UTC](https://discourse.nameko.io/t/unknown-managed-threads/211/7 "2017-10-28T19:03:02Z")

</div>

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](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)  
> > > &nbsp;&nbsp;File "/usr/local/lib/python3.6/site-packages/eventlet/greenthread.py",  
> > > line 218, in main  
> > > &nbsp;&nbsp;&nbsp;&nbsp;result = function(\*args, \*\*kwargs)  
> > > &nbsp;&nbsp;File "/usr/local/lib/python3.6/site-packages/nameko/web/server.py",  
> > > line 85, in process\_request  
> > > &nbsp;&nbsp;&nbsp;&nbsp;self.\_serv.process\_request((sock, address))  
> > > &nbsp;&nbsp;File "/usr/local/lib/python3.6/site-packages/eventlet/wsgi.py", line  
> > > 750, in process\_request  
> > > &nbsp;&nbsp;&nbsp;&nbsp;proto.\_\_init\_\_(sock, address, self)  
> > > &nbsp;&nbsp;File "/usr/local/lib/python3.6/socketserver.py", line 696, in \_\_init\_\_  
> > > &nbsp;&nbsp;&nbsp;&nbsp;self.handle()  
> > > &nbsp;&nbsp;File "/usr/local/lib/python3.6/http/server.py", line 418, in handle  
> > > &nbsp;&nbsp;&nbsp;&nbsp;self.handle\_one\_request()  
> > > &nbsp;&nbsp;File "/usr/local/lib/python3.6/site-packages/eventlet/wsgi.py", line  
> > > 410, in handle\_one\_request  
> > > &nbsp;&nbsp;&nbsp;&nbsp;self.handle\_one\_response()  
> > > &nbsp;&nbsp;File "/usr/local/lib/python3.6/site-packages/eventlet/wsgi.py", line  
> > > 523, in handle\_one\_response  
> > > &nbsp;&nbsp;&nbsp;&nbsp;for data in result:  
> > > &nbsp;&nbsp;File  
> > > "/usr/local/lib/python3.6/site-packages/newrelic-2.78.0.57/newrelic/api/web\_transaction.py"  
> > > , line 738, in \_\_iter\_\_  
> > > &nbsp;&nbsp;&nbsp;&nbsp;for item in self.generator:  
> > > &nbsp;&nbsp;File  
> > > "/usr/local/lib/python3.6/site-packages/newrelic-2.78.0.57/newrelic/api/web\_transaction.py"  
> > > , line 1114, in \_\_call\_\_  
> > > &nbsp;&nbsp;&nbsp;&nbsp;self.start\_response)  
> > > &nbsp;&nbsp;File "/usr/local/lib/python3.6/site-packages/nameko/web/server.py",  
> > > line 163, in \_\_call\_\_  
> > > &nbsp;&nbsp;&nbsp;&nbsp;rv = provider.handle\_request(request)  
> > > &nbsp;&nbsp;File "/usr/local/lib/python3.6/site-packages/nameko/web/handlers.py",  
> > > line 51, in handle\_request  
> > > &nbsp;&nbsp;&nbsp;&nbsp;result = event.wait()  
> > > &nbsp;&nbsp;File "/usr/local/lib/python3.6/site-packages/eventlet/event.py", line  
> > > 121, in wait  
> > > &nbsp;&nbsp;&nbsp;&nbsp;return hubs.get\_hub().switch()  
> > > &nbsp;&nbsp;File "/usr/local/lib/python3.6/site-packages/eventlet/hubs/hub.py",  
> > > line 295, in switch  
> > > &nbsp;&nbsp;&nbsp;&nbsp;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
> > > > > > > 
> > > > > > > ```auto
> > > > > > > >>> 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](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