[jira] [Commented] (NIFI-5869) JMS Connection Fails After JMS servers Change behind JNDI
[ https://issues.apache.org/jira/browse/NIFI-5869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16767543#comment-16767543 ] ASF subversion and git services commented on NIFI-5869: --- Commit 3492313d0b3436cdd0f7390d46d403fed9d65b77 in nifi's branch refs/heads/master from Ed [ https://gitbox.apache.org/repos/asf?p=nifi.git;h=3492313 ] NIFI-5869 Support Reconnection for JMS resets worker if it doesn't work anymore for any reason. this will add "reconnect" capabilities. Will solve issues for following use cases: - authentication changed after successful connection - JNDI mapping changed and requires recaching. - JMS server isn't available anymore or restarted. improved controller reset on exception Signed-off-by: Matthew Burgess This closes #3261 > 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 > Attachments: 3261.patch.txt, JNDI_JMS_Exception.txt > > Time Spent: 1h > Remaining Estimate: 0h > > 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)
[jira] [Commented] (NIFI-5869) JMS Connection Fails After JMS servers Change behind JNDI
[ https://issues.apache.org/jira/browse/NIFI-5869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16747212#comment-16747212 ] Ed Berezitsky commented on NIFI-5869: - update patch > 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 > Attachments: 3261.patch.txt, JNDI_JMS_Exception.txt > > Time Spent: 50m > Remaining Estimate: 0h > > 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)
[jira] [Commented] (NIFI-5869) JMS Connection Fails After JMS servers Change behind JNDI
[ https://issues.apache.org/jira/browse/NIFI-5869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16746902#comment-16746902 ] Ed Berezitsky commented on NIFI-5869: - Fix provided in PR #3261: When worker fails to connect to JMS, it will set a worker into invalid state. A processor (ConsumeJMS/PublishJMS) will get Controller Service and call "resetConnectionFactory", then will try to rebuild a worker. Fix has been tested as described for reproduction. Also regression tests has been performed against live JMS server. > 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 > Attachments: 3261.patch.txt, JNDI_JMS_Exception.txt > > Time Spent: 0.5h > Remaining Estimate: 0h > > 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)
