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 >>
