Matt, Thanks. On Tue, May 5, 2015 at 8:33 AM, Matt Gilman <[email protected]> wrote:
> Rob, > > The fix for the issue you were seeing has been committed to the develop > branch. I'm pretty sure based off that behavior you were already running > 0.1.0-incubating-SNAPSHOT. The release should be put together today and > then it has to go through the normal voting process making it available end > of this week/early next week. If you want to address the issues your seeing > before then, you could build another SNAPSHOT locally. Thanks. > > Matt > > On Mon, May 4, 2015 at 2:05 PM, Rob Weiss <[email protected]> wrote: > > > Matt, > > Thanks! Glad I am not crazy! > > > > On Mon, May 4, 2015 at 1:06 PM, Matt Gilman <[email protected]> > > wrote: > > > > > Rob, > > > > > > I was able to replicate the behavior your seeing locally. We are in the > > > process of cutting a release but I think we can get this addressed and > > > included. > > > > > > Matt > > > > > > On Mon, May 4, 2015 at 12:16 PM, Rob Weiss <[email protected]> > wrote: > > > > > > > Matt, > > > > I am not seeing any error messages at all related to the JMS server > > > > connection. I am also not seeing and connection tear down messages. > > This > > > is > > > > really odd. > > > > > > > > It seems fairly easy to replicate, just add a GetJMS processor, then > > > remove > > > > it then add another one. I am using ActiveMQ as the broker. > > > > > > > > On Mon, May 4, 2015 at 12:05 PM, Matt Gilman < > [email protected]> > > > > wrote: > > > > > > > > > Rob, > > > > > > > > > > It looks as though the connection is closed when the processor is > > > > stopped. > > > > > If that is not the behavior you're seeing can you check the logs > for > > > any > > > > > warnings that contain the message > > > > > > > > > > "unable to close connection to JMS Server due to " > > > > > > > > > > followed by a more detailed explanation. Thanks. > > > > > > > > > > Matt > > > > > > > > > > On Mon, May 4, 2015 at 11:59 AM, Rob Weiss <[email protected]> > > > wrote: > > > > > > > > > > > All, > > > > > > What is the expectation of the connection state when the > processor > > is > > > > not > > > > > > in a running state? We have seen that the connection does not > > release > > > > and > > > > > > has to be forced to release by shutting the NiFi process down. > This > > > is > > > > > > causing a major headache when trying to consume the queue via > > another > > > > > > process (either within NiFi or outside of NiFi). > > > > > > > > > > > > Thoughts? > > > > > > > > > > > > Thanks, > > > > > > Rob. > > > > > > > > > > > > > > > > > > > > >
