The EIP subproject in the template-jersey app should only ever contain outbound flow configurations and not inbound flow configurations
What is the most appropriate definition of a ProchainProcessor in terms of our new way of doing things
A prochain processor is a deployable component that can service multiple activemq queues and each queue can have multiple consumers to process the message
A prochain processor is a deployable component that can service multiple activemq queues and each queue only has one consumer to process the message
A prochain processor is a deployable component that services only one activemq queue and that queue will have only one consumer to process the message
A prochain processor can place a message directly on an activemq queue which is serviced by a prochain processor associated with another intapi
What is the most appropriate way of adding a consumer on an activemq queue in production
Change the prochain processor configuration to have one more consumer on the queue in question
Bring up another instance of the same prochain processor in production on its on aws instance
What is the purpose of the camel config file in the eip subproject
its only something that is used for testing and starting a broker
it is used to configure a camel route between queues if we want to
It is a way to know which queues are configured for exponential retry of message redelivery using the AMQ_SCHEDULED_DELAY header in the message headers.
The @EipRetry annotation should only be used on a method that has a @ServiceActivator annotation
Each service activator can have its own exponential retry configuration
If you do not use an EIPRetry annotation on a service activator and dont have any other error handling configuration setup in the flow then what does spring integration do with exceptions?
Spring integration just throws these exceptions away
A MessageHandlingException message is sent to a global jms channel called errorChannel.
What is the most appropriate EIPRetry annotation?
@EipRetry( redeliveryChannel =TEMPLATE_CREATION_GATEWAY_CHANNEL_NAME, retryConfig = 'taulia.PROJECTNAME.prochains.templateCreation' )
@EipRetry( errorChannel = ERROR_CHANNEL_NAME, redeliveryChannel = TEMPLATE_CREATION_GATEWAY_CHANNEL_NAME, retryConfig = 'taulia.PROJECTNAME.prochains.templateCreation' )
What does the templateMessagePublishingErrorHandler in the template-jersey-app demonstrate?
Demonstrates that you can send exceptions to an error channel without using the @EipRetry annotation on the service activator
Demonstrates absolutely nothing
What does the templateNotificationErrorChannel integrationFlow in the TemplateNotificationFlowConfiguration demonstrate?
In order to send the messages from the errorChannel to an activemq queue so that application support can look at them we need to define a outbound flow between the jms error channel and a queue name
It demonstrates that we cannot process error messages once they have gone to the error channel.
