[
https://issues.apache.org/jira/browse/NIFI-5869?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ed Berezitsky updated NIFI-5869:
--------------------------------
Description:
JMS Connection Fails After JMS servers Change behind JNDI.
Reproduce:
# Define and enable JNDI Controller Service
# Create a flow with ConsumeJMS or PublishJMS processors with controller
service defined in #1.
# Consume and publish at least one message to ensure the connectivity can be
established.
# Change JNDI configuration for the same connection factory to point to new
JMS servers.
# Stop JMS service on previous servers
# Observe failure in ConsumeJMS/PublishJMS (Caused by: javax.jms.JMSException:
Failed to connect to any server at: tcp://jms_server1:12345)
Work Around:
# Disable JNDI Controller Service
# Enable JNDI Controller Service and dependent processors.
Possible Issue/Fix:
* AbstractJMSProcessor has a method "buildTargetResource", in which connection
factory is instantiated and then cached in workerPool in onTrigger .
* Issue: Once cached, it will be reused forever.
* Fix: on connectivity failure there should be an attempt to rebuild the
worker.
was:
JMS Connection Fails After JMS servers Change behind JNDI.
Reproduce:
# Define and enable JNDI Controller Service
# Create a flow with ConsumeJMS or PublishJMS processors with controller
service defined in #1.
# Consume and publish at least one message to ensure the connectivity can be
established.
# Change JNDI configuration for the same connection factory to point to new
JMS servers.
# Stop JMS service on previous servers
# Observe failure in ConsumeJMS/PublishJMS (Caused by: javax.jms.JMSException:
Failed to connect to any server at: tcp://jms_server1:12345)
Work Around:
# Disable JNDI Controller Service
# Enable JNDI Controller Service and dependent processors.
Possible Issue/Fix:
* AbstractJMSProcessor has a method "buildTargetResource", in which connection
factory in instantiated and then cached in workerPool in onTrigger .
* Issues: Once cached, it will be reused forever.
* Fix: on connectivity failure there should be an attempt to rebuild the
worker.
> JMS Connection Fails After JMS servers Change behind JNDI
> ---------------------------------------------------------
>
> Key: NIFI-5869
> URL: https://issues.apache.org/jira/browse/NIFI-5869
> Project: Apache NiFi
> Issue Type: Bug
> Components: Extensions
> Affects Versions: 1.8.0
> Reporter: Ed Berezitsky
> Assignee: Ed Berezitsky
> Priority: Major
> Fix For: 1.8.0
>
> Attachments: JNDI_JMS_Exception.txt
>
>
> JMS Connection Fails After JMS servers Change behind JNDI.
> Reproduce:
> # Define and enable JNDI Controller Service
> # Create a flow with ConsumeJMS or PublishJMS processors with controller
> service defined in #1.
> # Consume and publish at least one message to ensure the connectivity can be
> established.
> # Change JNDI configuration for the same connection factory to point to new
> JMS servers.
> # Stop JMS service on previous servers
> # Observe failure in ConsumeJMS/PublishJMS (Caused by:
> javax.jms.JMSException: Failed to connect to any server at:
> tcp://jms_server1:12345)
>
> Work Around:
> # Disable JNDI Controller Service
> # Enable JNDI Controller Service and dependent processors.
>
> Possible Issue/Fix:
> * AbstractJMSProcessor has a method "buildTargetResource", in which
> connection factory is instantiated and then cached in workerPool in onTrigger
> .
> * Issue: Once cached, it will be reused forever.
> * Fix: on connectivity failure there should be an attempt to rebuild the
> worker.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
