[
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:
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
- Winston
Best regards
Henrik
