Hi Romain That's a good point. That's right the command can register a "close hook" in the session and we call those hooks at session disconnect/timeout. Let me experiment with this approach (I will update the draft PR).
Thanks ! Regards JB On Tue, Nov 12, 2024 at 9: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 > >
