Hi Jörg > Am 08.12.2014 um 22:31 schrieb Jörg Hoh <jhoh...@googlemail.com>: > > Hi Felix > > 2014-12-08 14:34 GMT+01:00 Felix Meschberger <fmesc...@adobe.com>: > > > >> >> >>> * The J2E programming model discourages the creation of threads; instead >>> one is supposed to use the threadpools of the application server. This is >>> important in appservers like Websphere AS, where the succesfull lookup of >>> JNDI resources is directly bound to the fact, that the thread, which >> tries >>> it, comes from a Websphere thread pool. >> >> Yes, that *is* a problem. And I am not sure whether we can easily solve >> this. Except by not deploying as a web application. For example in >> WebSphere with Liberty Profile, Sling could be deployed directly into >> WebSphere’s OSGi framework and thus directly access the JNDI resources >> through the OSGi JNDI service. >> > > > And that's the problem I have, and the reason for my proposal :-) > > >> >> Interestingly the actual problem of reading JNDI resources during startup >> — looking up a JNDI DataSource to be used for an Oak Microkernel - is >> harder to solve: This thread is the Felix Framework Startlevel service >> thread which is also created with new Thread and not with some thread >> pooling. >> >> (Yet, it is important to note, that the framework is not able to start if >> the Startlevel thread could not be retrieved) >> > > Hm, if we're talking about about appservers support: in the launchpad we > also create a number of threads; most specifically the Sling Notifier > thread and the OSGI Installer thread. Both of them are involved in the > startup of the bundles and services. > > >> WDYT? >> >> I think it basically is an ok idea, which we might want to follow-up upon. >> Yet, we would not fully solve the problem, since some of the threads >> created are outside of the control of Sling, particularly the Startlevel >> thread used by the framework. >> > > For the moment I would be happy, if we could migrate the threads created by > Sling. The Felix threads are a different story.
Sure, but an essential one. Just solving the OSGi Installer, for example, does not solve the problem on restart … > > > >> >> Yet, there’s JSR 236 (Concurrency Utilities for J2EE). Maybe we should >> look into this ? Unfortunately its only part of J2EE 7 so your favourite >> blend of App Server might not actually support it. >> > > "favourite blend of App servers" ... You owe me a beer now :-) > > Can we split the application specific parts into own bundles and provide a > JSR236 compliant code, plus a simple version with its own thread pool. Maybe we should be retrofitting our ThreadPool support to JSR-236. But, as I said, in a App Server context can you use JSR-236 ? Does WebSphere 7.x provide ? Do they have IBM specific API ? What API ? Which app servers is Sling going to support ? Regards Felix > > > > -- > Cheers, > Jörg Hoh, > > http://cqdump.wordpress.com > Twitter: @joerghoh
