Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [hudson-dev] Going to a event driven architecture?

On 3/6/12 1:59 AM, Henrik Lynggaard Hansen wrote:

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

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.registerListener(ClaimEvent.class, new ClaimListener());

in a publisher

@Inject EventRegistry

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

- Winston

Best regards

Back to the top