Hi Matt,

Not sure I checked the right pr but it still uses osgi services instead of
plain instances?

Was more thinking to session.onClose(()-> ....) in the command.
An optional support can be that if the command implements this api (so not
closeable which is too generic) it is autoregistered.

Side note: take care the try catch block must be in the loop and not around
when called ;)

Le jeu. 14 nov. 2024 à 20:11, Matt Pavlovich <mattr...@gmail.com> a écrit :

> Hi Romain-
>
> See the PR link, there is a discussion about just re-using Closeable
> interface as a convention and then doing some session id association as you
> described vs whiteboard.
>
> Thanks JB!
>
> Matt
>
> > On Nov 12, 2024, at 2:17 PM, Romain Manni-Bucau <rmannibu...@gmail.com>
> wrote:
> >
> > Looks good.
> >
> > If it helps, i know in similar apps we just register the cleanup hooks
> in a
> > session attribute (list or map) and when disconnection or tileout occurs
> we
> > just run them.
> > Doesnt change everything but avoids the need of a whiteboard which often
> > has lifecycle complexity (a big pitfall there is that if you drop a
> bundle
> > registering a cleaner what should happen? Cleaner will likely fail until
> > you prevent the bundle to be stopped or uninstalled but you need the
> > cleaner to not leak. You dont see it with the whiteboard, you do with an
> > attribute and it doesnt prevent a generic helper class doing a lazy
> lookup
> > or even reflection but it runs and fails as expected if something is
> wrong).
> >
> > Hope it helps
> >
> > Le mar. 12 nov. 2024 à 19:26, Francois Papon <
> francois.pa...@openobject.fr>
> > a écrit :
> >
> >> Hi JB,
> >>
> >> From my side it looks good, I checked the PR and I think it's a good
> idea.
> >>
> >> regards,
> >>
> >> François
> >> fpa...@apache.org
> >> francois.pa...@openobject.fr
> >>
> >> Le 12/11/2024 à 17:28, Jean-Baptiste Onofré a écrit :
> >>> Hi folks,
> >>>
> >>> I started to work onhttps://issues.apache.org/jira/browse/KARAF-7174
> >>> (finally :)).
> >>>
> >>> Basically, the issue here is the following:
> >>> - log:tail command registers a custom PaxAppender to display log
> >>> events in the terminal (via the printEvent() method)
> >>> - we have a pipe thread created by log:tail command
> >>>
> >>> On a local terminal, all is OK: when the user stops log:tail (using
> >>> CTRL-C), the thread is stopped, all good.
> >>> However, when log:tail is executed from a remote terminal (ssh), then
> >>> we have a problem when the ssh client timeout for instance: the
> >>> log:tail thread is still running on the Karaf side, resulting in an
> >>> accumulation of threads.
> >>>
> >>> To prevent this, and address similar issues in the future, I started
> >>> to prototype a ChannelResourceCleaner whiteboard.
> >>> Basically, a shell command (and generally speaking any class) can
> >>> implement ChannelResourceCleaner interface and register this kind of
> >>> OSGi service.
> >>> The ChannelResourceCleaner interface defines the close() method.
> >>> In the Karaf ssh server, we add a session listener that reacts when a
> >>> disconnect event happens. When a disconnect happens, the Karaf ssh
> >>> server is looking for all ChannelResourceCleaner services and call
> >>> close() on each of them.
> >>>
> >>> I created a draft PR (still WIP) illustrating this mechanism:
> >>> https://github.com/apache/karaf/pull/1884
> >>>
> >>> What do you think about this approach ?
> >>>
> >>> Thanks !
> >>> Regards
> >>> JB
> >>
>
>

Reply via email to