Axonframework: EmbeddedEventStore Thread Factory

[tgippi]

Hi,

we've noticed, that the EmbeddedEventStore is fetching events from the store without any transaction.
In our case the EmbeddedEventStore is configured with an instance of the NoTransactionManager, what is causing an issue in the underlying Postgres database, because Large Objects may not be used in auto-commit mode.

So we've tried to configure the EmbeddedEventStore with a real transaction manager, but the transaction needs to run inside a Java EE managed thread.
Unfortunately there is no possibility to configure the thread factory in the EmbeddedEventStore (private final attribute). There is only a hard coded AxonThreadFactory that is assigned to that property in the constructor.

How can we configure the EmbeddedEventStore to create it's EventProducer threads with a customizable thread factory?
Shouldn't there be a possibility to register a global thread factory for all Axon threads?

Thank you in advance & best regards,
Tobias

[pepperbob]

It shouldn't be too much hassle to inject the ThreadFactory via a constructor. But as the the same would apply to the required instance of ScheduledExecutorService - I wonder if the Eventstore shouldn't have access to the GlobalConfiguration where this may already be registered - a similar approach is implemented for the TrackingEventProcessor.

[tgippi]

Injecting the ThreadFactory via the constructor would be an improvement for us.
Using the global configuration would also be a good (maybe even better) option, but currently I cannot find any possibility to do so on the DefaultConfigurer.

We configure the ThreadFactory for each single registered TrackingEventProcessor by using the andThreadFactory-method on its TrackingEventProcessorConfiguration, though that doesn't make any trouble.

TrackingEventProcessorConfiguration.forParallelProcessing(config.getThreadCount())
                                   .andThreadFactory { threadFactory }

[smcvb]

It is a correct assumption that the ThreadFactory should be configurable for the EmbeddedEventStore. We will schedule this work to be performed in the near future.
Thanks for providing the thorough ticket description @tgippi, that helps us out a lot.

[smcvb]

I will make sure this issue is definitely resolved in #754

[mvonrenteln]

For us this has a high priority. Would you accept a fix that uses the old principles (constructor) when we provide a pull request?

[smcvb]

Any held on this would be much appreciated @mvonrenteln! So if you have the time to provide a simple pull request to implement this logic, by all means.

Pointing it to master, so 3.4, would have my preference by the way.
Would that work out for you too?

[mvonrenteln]

3.4 would be okay. We will discuss it when this can be done.

[tgippi]

@smcvb I've just created a pull request, which contains an overloaded version of the EmbeddedEventStore constructor (see #787 )

[mvonrenteln]

Thanks @tgippi!

This way one can define the thread factory the "right way".

But I fear it is still contra intuitive and error prone that the default thread factory is not automatically propagated to the EmbeddedEventStore. Therefore I think the default thread factory should be the one already defined in the configurer when the configurer creates the EmbeddedEventStore. So the configurer should call the new constructor with its thread factory as parameter.

[smcvb]

@mvonrenteln do you mind sharing where the current Configuration API specifies 'a default thread factory for all components'? The DefaultConfigurer does not specify something along the lines you're suggesting. The idea isn't to weird though, but I think you might have got a misconception there.