Весна: одновременные JMS-слушатели в ActiveMQ вызывают проблемы в режиме SESSION_TRANSACTED - PullRequest
Новая
       51

Весна: одновременные JMS-слушатели в ActiveMQ вызывают проблемы в режиме SESSION_TRANSACTED

0 голосов
/ 11 февраля 2019

Мы используем qpid-jms для настройки одновременных прослушивателей в долговременной очереди в брокере ActiveMQ (версия 6.2.1), работающем на JBOSS.

При использовании одновременных прослушивателей в сочетании с набором sessionAcknowledgeModeдо SESSION_TRANSACTED мы постоянно получаем ошибки, которые указывают на то, что транзакции не могут быть зафиксированы и откатаны.Эти ошибки печатаются без фактических сообщений в очереди, кажется, что они происходят, когда qpid пытается проверить, есть ли новые сообщения в очереди.

Очень простая установка, где мы можем видеть эти ошибки, выглядит следующим образом: 

    @Bean
    fun inboundRequestListenerContainerFactory(
            provider: Provider,
            factory: ConnectionFactory,
            configurer: DefaultJmsListenerContainerFactoryConfigurer
    ): JmsListenerContainerFactory<*> {
        val containerFactory = DefaultJmsListenerContainerFactory().apply {
            setPubSubDomain(false)
            setSessionAcknowledgeMode(Session.SESSION_TRANSACTED)
            setSessionTransacted(true)

            setConcurrency("2-5")
            setMessageConverter(SimpleMessageConverter())
            setAutoStartup(true)
            setConnectionFactory(factory)
        }

        return containerFactory
    }

    @Bean
    fun jmsConnectionFactory(
            provider: Provider,
            config: ConfigProperties): ConnectionFactory {
        val fac = JmsConnectionFactory()
        fac.properties = config.otherProperties
        fac.remoteURI = config.remoteURI

        return SingleConnectionFactory(fac).apply {
            setClientId(provider.providerId)
        }
    }

    @JmsListener(
            destination = "anything",
            containerFactory = "ourBean"
    )
    fun handleRequestFromEurex(
            session: Session,
            jmsMessage: javax.jms.Message
    ) {
        println("Handling message....")
    }

Вывод журнала на стороне клиента выглядит следующим образом: 

2019-02-11T10:48:57,079 [INFO ] [DefaultMessageListenerContainer-476] JmsLocalTransactionContext - Commit failed for transaction: TX:ID:04012beb-0cbc-43d7-994d-2229e5dd6260:1:1691
2019-02-11T10:48:58,096 [INFO ] [DefaultMessageListenerContainer-475] JmsLocalTransactionContext - Commit failed for transaction: TX:ID:04012beb-0cbc-43d7-994d-2229e5dd6260:1:1693
2019-02-11T10:48:58,124 [WARN ] [DefaultMessageListenerContainer-475] DefaultMessageListenerContainer - Setup of JMS message listener invoker failed for destination 'APP.ReqQueueOut' - trying to recover. Cause: Transaction 'TX:ID:ourhostname-42322-1582645535088-4:310:2' has not been started. [condition = failed]
2019-02-11T10:48:58,124 [INFO ] [DefaultMessageListenerContainer-475] DefaultMessageListenerContainer - Successfully refreshed JMS Connection
(Message block repeated roughly every second)

Помимо того, что это спамит наши журналы, также кажется, что связь в очередине работает правильно.Бывает, что при отправке в очередь происходит сбой, и, как следствие, сообщение доставляется повторно.

Кажется, что эта проблема решается следующим образом:

  • Отключение параллелизма (с использованием `setConcurrency (" 1"))
  • Переключение с SESSION_TRANSACTED на CLIENT_ACKNOWLEDGE
  • Переключение с одного общего подключения на неиспользуемые подключения.

Мы видимследующие журналы, напечатанные на стороне брокера: 

rollback: TX:ID:ourhostname-42322-1582645535088-4:310:2 syncCount: 0
Error occured while processing sync command: TransactionInfo {commandId = 7363, responseRequired = true, type = 2, connectionId = ID:ourhostname-42322-1582645535088-4:310, transactionId = TX:ID:ourhostname-42322-1582645535088-4:310:2}, exception: javax.jms.JMSException: Transaction 'TX:ID:ourhostname-42322-1582645535088-4:310:2' has not been started.
javax.jms.JMSException: Transaction 'TX:ID:ourhostname-42322-1582645535088-4:310:2' has not been started.

Несмотря на то, что вышеизложенное, похоже, решает эту проблему, мы хотели бы понять, что вызывает эту проблему / если мы делаем что-то очень неправильное при настройке наших bean-компонентов.Кто-нибудь сталкивался с подобными ошибками?

...