new shell behavior regarding the threads pooling with Karaf 4.1

[Nicolas Brasey <ni...@gmail.com>]

Hi guys!

We are currently migrating from karaf 4.0.8 to 4.1.1 and discovered a new
behavior in the shell. The new karaf does not dedicate a thread to the
shell session, that means different commands in the same shell session
might run in a different thread, which break our authentication mechanism
which is maintained in a threadlocal.

In the past, we never experienced karaf using different threads for
executing different commands in the same shell session.

So the question is: Is this change intentional from the Karaf team, or our
assumption to have a single threaded session is wrong ?

Thanks a lot!

Nicolas

Re: new shell behavior regarding the threads pooling with Karaf 4.1

[Nicolas Brasey <ni...@gmail.com>]

Hi Guillaume,

Thanks for your detailed answer, I was not aware the possibility to have
background jobs in the karaf shell, it makes sense now. This shell is a
really powerful tool :-)

Okay, I'll give a try with a InheritableThreadLocal as you proposed and let
you know. Thanks a lot for your help!

Nicolas







On Thu, Jun 8, 2017 at 9:17 AM, Guillaume Nodet <gn...@apache.org> wrote:

> It has changed due to support for redirections and jobs in the console.
> However, the assumption was already wrong with 4.0.x, for example:
>
> *karaf*@root()> thread-name = { ((($.context bundle) loadClass
> java.lang.Thread) currentThread) name }
>
> ((($.context bundle) loadClass java.lang.Thread) currentThread) name
>
> *karaf*@root()> echo $(thread-name)
>
> Karaf local console user karaf
>
> *karaf*@root()> echo foo | echo $(thread-name)
>
> pipe-[echo, $(thread-name)]
>
> As you can see, in the second case, the thread is not the main one.
> In Karaf 4.1.x, you can launch jobs in the background using the & operator,
> or move them in the background at a later time using ^Z + fg.  So jobs have
> to be launched in a separate thread.
>
> On the security side, the way to obtain the karaf user is to use the jaas
> subject.  It should be propagated throughout the session (though I just
> found KARAF-5183).  I think if you're using a InheritableThreadLocal, it
> should almost work (though you'll have the same problems as described in
> KARAF-5183 I suppose).
>
> 2017-06-07 16:45 GMT+02:00 Nicolas Brasey <ni...@gmail.com>:
>
>> Hi guys!
>>
>> We are currently migrating from karaf 4.0.8 to 4.1.1 and discovered a new
>> behavior in the shell. The new karaf does not dedicate a thread to the
>> shell session, that means different commands in the same shell session
>> might run in a different thread, which break our authentication mechanism
>> which is maintained in a threadlocal.
>>
>> In the past, we never experienced karaf using different threads for
>> executing different commands in the same shell session.
>>
>> So the question is: Is this change intentional from the Karaf team, or
>> our assumption to have a single threaded session is wrong ?
>>
>> Thanks a lot!
>>
>> Nicolas
>>
>
>
>
> --
> ------------------------
> Guillaume Nodet
>
>

Re: new shell behavior regarding the threads pooling with Karaf 4.1

[Guillaume Nodet <gn...@apache.org>]

It has changed due to support for redirections and jobs in the console.
However, the assumption was already wrong with 4.0.x, for example:

*karaf*@root()> thread-name = { ((($.context bundle) loadClass
java.lang.Thread) currentThread) name }

((($.context bundle) loadClass java.lang.Thread) currentThread) name

*karaf*@root()> echo $(thread-name)

Karaf local console user karaf

*karaf*@root()> echo foo | echo $(thread-name)

pipe-[echo, $(thread-name)]

As you can see, in the second case, the thread is not the main one.
In Karaf 4.1.x, you can launch jobs in the background using the & operator,
or move them in the background at a later time using ^Z + fg.  So jobs have
to be launched in a separate thread.

On the security side, the way to obtain the karaf user is to use the jaas
subject.  It should be propagated throughout the session (though I just
found KARAF-5183).  I think if you're using a InheritableThreadLocal, it
should almost work (though you'll have the same problems as described in
KARAF-5183 I suppose).

2017-06-07 16:45 GMT+02:00 Nicolas Brasey <ni...@gmail.com>:

> Hi guys!
>
> We are currently migrating from karaf 4.0.8 to 4.1.1 and discovered a new
> behavior in the shell. The new karaf does not dedicate a thread to the
> shell session, that means different commands in the same shell session
> might run in a different thread, which break our authentication mechanism
> which is maintained in a threadlocal.
>
> In the past, we never experienced karaf using different threads for
> executing different commands in the same shell session.
>
> So the question is: Is this change intentional from the Karaf team, or our
> assumption to have a single threaded session is wrong ?
>
> Thanks a lot!
>
> Nicolas
>



-- 
------------------------
Guillaume Nodet