nhl / link-move

A model-driven dynamically-configurable framework to acquire data from external sources and save it to your database.
Apache License 2.0
35 stars 15 forks source link

LmRuntimeException on execution of edited link-move xml-extractor #184

Open MProtasevich opened 3 years ago

MProtasevich commented 3 years ago

In our case, we deploy link-move xml extractors separately from main app, which uses LmRuntime to start jobs.

If we redeploy link-move extractors or edit the extractor (xml-file), which is going to be used in next execution, without restarting the application, exception will be thrown

com.nhl.link.move.LmRuntimeException: Multiple values are present for property: extractor.jdbc.sqltemplate
    at com.nhl.link.move.extractor.model.MutableExtractorModel.getPropertyValue(MutableExtractorModel.java:55)
    at com.nhl.link.move.extractor.model.MutableExtractorModel.getProperties(MutableExtractorModel.java:37)
    at com.nhl.link.move.extractor.model.ContainerAwareExtractorModel.getProperties(ContainerAwareExtractorModel.java:49)
    at com.nhl.linkmove.extensions.extension.DefaultExtensionFactory.getExtensions(DefaultExtensionFactory.java:50)
    at com.nhl.linkmove.extensions.DefaultSyncProcessorService.processor(DefaultSyncProcessorService.java:40)

Steps to reproduce:

  1. LinkMove extractors located outside of the jar (somewhere in file system)
  2. Start application which schedules jobs for execution (via cron, for instance)
  3. Wait for any job to finish it's work
  4. Edit xml-extractor of a job, which has been run previously
  5. Wait until next execution
  6. Exception is thrown
andrus commented 3 years ago

Need help reproducing this. I just created a test that changes the extractor and reruns the task. Everything seems to work correctly. Could there be an error in the XML syntax?

MProtasevich commented 3 years ago

Could there be an error in the XML syntax?

No, that issue occurs even if I add a whitespace under tag. No matter, if it's added inside CDATA block out of it.

The only difference between your test and the task we've implemented is that we create new LmTask between job invocations, but in your tests you use only one instance. Maybe that's the point.

P. S. And we use TimestampToken as well