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 "Noble Paul (JIRA)" <ji...@apache.org> on 2009/01/20 05:20:59 UTC
[jira] Commented: (SOLR-972) EventListener-s creation changed from
a per request ( full / delta-imports) scenario to once through the lifetime
of the DIH plugin.
[ https://issues.apache.org/jira/browse/SOLR-972?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12665328#action_12665328 ]
Noble Paul commented on SOLR-972:
---------------------------------
bq.Also EventListener is changed to an interface rather than an abstract class for better decoupling
interfaces are generally discouraged in Lucene/Solr because it can make the API hard to modify. Though there is a slight inconvenience of creating a separate class i guess it should be fine.
bq.No state is stored between successive invocations of events as it is a new object
We must find a better way to do this than making it a part of the object lifecycle. We can add an extra scope to the Context#setSessionAttribute which can persist between multiple invocations. This can hekp all the components to share the same object
bq.- it is very inefficient to do a class loader lookup by reflection / instantiate an instance and call a method on the same.
can we quantify that ?
> EventListener-s creation changed from a per request ( full / delta-imports) scenario to once through the lifetime of the DIH plugin.
> ------------------------------------------------------------------------------------------------------------------------------------
>
> 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.