|Re: [hudson-dev] Going to a event driven architecture?|
On 3/6/12 1:59 AM, Henrik Lynggaard Hansen wrote:
Hi During the discussion on performance, one of the topics that has come up frequently is How often do we need to refresh this information or how long can we cache this result e.g. when talking about the ajax results, rss feeds etc. The more I think about it, the more I think we are going in the wrong direction, because the right answer to questions like that is not a amount of time, but rather he simple answer we need to refresh the calculated information when the information or state changes e.g the ajax build queue should change when the actual build queue changes.
Assume the model is currently constructed or refreshed at the time of HTTP request, then it makes sense to construct and populate the model using events for better performance.
Performance can be further improved by- Reducing the number of Ajax requests (by eliminating number of Jelly rendering). - Increasing the caching time of the rendered HTML (either at Apache proxy level or at Stapler via some settings)
That is why I think we need to think more in terms of events invalidating caches or results rather than time.
I believe here you are not meaning the rendered HTML cache right? Because that cache is in the container level which the model has no access to.
I have used this approach in our status board plugin I mentioned on the call. It performs a one time calculation of the data needed for the web page, and only does a recalculation when a build changes state by implementing RunListener.
Right any model manipulation (which may be time consuming calculation) can be limited to event handling time .
There are only 2 things which isn't cached and that is the "Time since" strings and the claim information because that information is added after the build is completed and there isn't an event to listen for. That brings me to my suggestion, I think there maybe should be a Hudson component that provides a gateway to publishing and subscribing to events like below In a subscriber @Inject EventRegistry events events.registerListener(ClaimEvent.class, new ClaimListener()); in a publisher @Inject EventRegistry events. EventQueue<ClaimEvent> claimEvents = events.registerEvent(ClaimEvent.class) claimEvents.fireClaimAdded(new ClaimEvent(...)) claimEvents.fireClaimRemoved(new ClaimEvent(...)) Another approach would be to be Listerners as extentionPoints like RunListener. I don't know which is the best approach my goal is just that people start thinking in events, and it should be as easy as possible for plugin developers to add new event types to the system, and not spend their time managing lists of subscribers etc.
Having a Event Registry does makes sense, if the consumers of the events are known like RSS
Best regards Henrik
Back to the top