You are viewing a plain text version of this content. The canonical link for it is here.
Posted to solr-dev@lucene.apache.org by "Kay Kay (JIRA)" <ji...@apache.org> on 2009/01/19 23:18:59 UTC
[jira] Updated: (SOLR-972) EventListener are not created per
request ( full / delta-imports) but rather instantiated once per lifetime
of the application - maintaining state + efficient
[ https://issues.apache.org/jira/browse/SOLR-972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kay Kay updated SOLR-972:
-------------------------
Attachment: SOLR-972.patch
> EventListener are not created per request ( full / delta-imports) but rather instantiated once per lifetime of the application - maintaining state + efficient
> ---------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: SOLR-972
> URL: https://issues.apache.org/jira/browse/SOLR-972
> Project: Solr
> Issue Type: Improvement
> Components: contrib - DataImportHandler
> Environment: Java 6, Tomcat 6
> Reporter: Kay Kay
> Fix For: 1.4
>
> Attachments: SOLR-972.patch
>
> Original Estimate: 2h
> Remaining Estimate: 2h
>
> The EventListener plugin for notification of start / end import events (SOLR-938) creates an instance of EventListener before every notification. This has 2 drawbacks.
> * No state is stored between successive invocations of events as it is a new object
> * When writing plugins for delta imports - it is very inefficient to do a class loader lookup by reflection / instantiate an instance and call a method on the same.
> Attached patch has one EventListener through the lifetime of the DIH plugin .
> Also EventListener is changed to an interface rather than an abstract class for better decoupling (especially painful when the start/end eventlistener has an independent hierarchy by itself ).
> By default, a no-op listener is registered to avoid boiler plate code to check if there is a start / end listener specified. Efficient JRE impls should be able to optimize the no-op for minimum overhead compared to checking the reference for null and branching out.
> Specifying an onImportStart / onImportEnd overrides the default handler though.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.