hstaudacher
commented
9 years ago Hi sounds good. Here is some feedback:
1) Checking for the annotation is not enough. We can also register Feature types.
2) Sounds reasonable. Looking forward to see how you handle it ;)
3) Sounds creepy but ok.
4) Are you planing to have those hooks available as API? If yes we need to follow the whiteboard pattern.
5) Hmm, ok ;)
What would really help if you can do a separate pull request for each topic because the changes sound big.
kolkoo
I've identified several things I intend to fix in a pull request soon that affect performance especially on slower embedded devices. Firstly I'm going to say that Jersey initialization/reload is really slow on the particular embedded device I'm testing with, so in light of that there are several problems:
1) ResourceTracker - in the addingService method if a service does not have jax-rs annotations we should unget the service and return null in order to not track the service anymore. This also allows us to remove the isResource() checks in the {removed,modified}Service methods.
2) Currently the connector is tracking ApplicationConfiguration, ServletConfiguration and also ConfigAdmin Configuration, when these three appear the way things are handled a new JerseyContext is created - so on a slower device we may end up with up to 4 Jersey initializations as follows: 2.1) Once when first resource appears 2.2) Another one when ConfigAdmin Configuration appears 2.3) Another one when ApplicationConfiguration appears 2.4) And a last one when ServletConfiguration appears On a device where Jersey configuration is really slow (10-20 seconds) this is quite a heavy hit. I intend to optimize this by including Configuration/ApplicationConfiguration/ServletConfiguration into the same/similar mechanism that is used by Resources (using publishDelay).
3) This is related to 2.1). When the first resource appears we register our servlet with OSGi - which is fine but this currently causes Jersey ServletContainer.init() to be called which initializes jersey, then after resources all appear we reload jersey - so at minimum two Jersey loads in most cases. Another problem is that while Jersey is reloading asynchronously we could try to access our servlet and we get a nasty exception from Jersey while that is happening. I intend to have the ServletContainerBridge extend HttpServlet and wrap the Jersey ServletContainer, so if Jersey is loading/reloading we can return Error 503 not available for example.
4) In relation to 3) I think it's good to have some sort of listener/hook mechanism before and after the Jersey Asynchronous initialization is performed. I currently need to include some device specific code to disable security checks for the Jersey thread and would also be good to know when Jersey is fully ready.
5) Possibly also include a way to delay initialization until it is manually triggered. This way I can trigger Jersey initialization at a time where all my resources should already be registered and avoid most of the problems described in 2). Of course if no such trigger is present we would fall back to the default behavior.
Would really appreciate if you let me know whether or not you feel this is something you would consider merging as a heads up :)
Thanks in advance,
Ivan