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