[
https://issues.apache.org/jira/browse/SOLR-972?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12665842#action_12665842
]
Kay Kay commented on SOLR-972:
------------------------------
| All components are created on a per import basis. If we must cache , then we
must think of it for or all the the components
I am not sure if we can apply such generality since Context is bound to be
different for different invocations (at least , most of the time) whereas
EventListener usually take the form of register / unregister but are not
created every time. If EventListener-s are going to be recreated everytime
then it would mean that the impl. has no state ( fields ) in it - which seems
not so intuitive to the programmer.
> 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.
