-
Notifications
You must be signed in to change notification settings - Fork 98
Performances issues when adding or removing multiple resources #60
Comments
We are using the connector for several productive applications with high load. It would be good if you can provide a standalone example. E.g. an example where you can easily configure the service instances registered to reproduce the performance problem. It would also be nice to have some tim measurement in it to see the startup time. Can you provide such an example? |
Hi holger, I’ll try to find the time to create a standalone example, but as mentioned in the issue, this problem can only be noticed on an embedded or very slow platform. When testing the same application on a standard PC, everything works smoothly. In the mean time, I have made a “dirty” modification in JerseyContext class by using a Timer that is triggered on the add/remove resource to introduce a delay in resource registration. If another resource is registered before the timer is triggered, we cancel the timer and re-run it. This allows me to reduce the startup and stop time of the publisher bundle from 40 seconds to around 1 second. Mathieu CRETEAU Référent Système BG Hager Controls SAS 11 rue Pablo Neruda 33140 Villenave d’Ornon France N° Tel 0557359496 N° Fax 0556806662 Adresse : [email protected] Adresse : [email protected]SAS au capital de 5 000 000€ N° Id. TVA FR 75 451 540 744 / APE 2712Z RCS Saverne 451 540 744 N° Siret 451 540 744 000 13 A member of the Hager GroupDe : Holger Staudacher [mailto:[email protected]] We are using the connector for several productive applications with high load. It would be good if you can provide a standalone example. E.g. an example where you can easily configure the service instances registered to reproduce the performance problem. It would also be nice to have some tim measurement in it to see the startup time. Can you provide such an example? — |
Hi,
Running the same on my MacBook, it looks of course much better:
Would love to have a solution for this as well as otherwise the OSGi-JAXRS-Connector disqualifies itself for use on embedded hardware (which would be a pity)! |
I will have time in the next two weeks to work on the connector again. This issue will b fixed in this period. @kaikreuzer can I send you a pre-release to test? Just to see if the performance issue is resolved. |
Sure, I'd love to be your beta tester :-) |
Ping - two weeks are over :-) |
I would recommend amdatu jax-rs [1]. I know the people from luminis are using it in production. Unfortunately it's not available on Maven Central, but I think you can deploy it manually if needed. |
Thanks for the hint, this looks indeed interesting as well. |
Scheduled for today. Sorry for the delay |
Hey guys, @kaikreuzer can you test it out and report if it works? I have tested it with one of our applications that registers about 60 resources and it improves the startup tremandously. Regarding the solution. I searched a better way to modify the jersey resource model at runtime but from what I found it is not possible. Implementations like JRebel and co also call the reload method on the ServletContainer to do hot swaping. So, we still rely on the reload method but I wrapped it in a ScheduledExecutorService. It runs a runnable every 2500ms (configurable). The runnable checks if there are new or deleted resources and does a reload if true. If not it simply does nothing. The runnable starts with a delay of 1 second (felt best to during testing). I creates the issue60 branch which contains the fix. i just wanted to hear your opinion before it goes to master. |
Hi Holger,
and I guess with configuring the runnable with a bigger value, I could get it down to just one? |
Hi @kaikreuzer I have created a test build. Could you please test it and verify? Thanks. https://dl.dropboxusercontent.com/u/5808972/com.eclipsesource.jaxrs.repository-4.2.0-issue60fix.zip |
Hm, with this version I do not get any log entry from Jersey anymore. The REST services are also not available until I restart the bundle com.eclipsesource.jaxrs.publisher (might be a startup order issue, I didn't further investigate this). The startup time has again increased by 10-15 seconds - so it does not seem to fully solve the problem. |
Akward. So, the fix from this issue is still needed. Will merge it today and test it further. |
Hi
I'm currently using JAXRSConnector on an embedded target, such as a Raspberry Pi. This works fine and I'm able to host and use my Rest API through JAXRS.
One problem I'm facing is that as my project is growing, I register more and more Rest Resources. At the beginning the startup time of the publisher bundle was fast, now with around 20 resources, the publisher bundle takes around 40 seconds to start on my embedded target (with CPU to 100%).
After debugging, I saw that this was due to the fact that the ServletContainer.Reload method is called each time a new service is added (or removed) via the ResourceTracker. This Reload method seems quiet CPU intensive, and during start/stop phases, it will be called for each resources although it would only require one call after init.
The same problem exists when stopping the publisher bundle (for the same reason).
The text was updated successfully, but these errors were encountered: