[jira] [Commented] (NIFI-4957) Enable JoltTransformJSON to pickup a Jolt Spec file from a file location
[ https://issues.apache.org/jira/browse/NIFI-4957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16847246#comment-16847246 ] Dirk Arends commented on NIFI-4957: --- [~rahst12] Hoping this might be close. I have been considering attempting a Nifi processor solution (using FetchFile among others) which wouldn't be anywhere near as clean as a built in Jolt Body attribute. It sounds ideal! > Enable JoltTransformJSON to pickup a Jolt Spec file from a file location > > > Key: NIFI-4957 > URL: https://issues.apache.org/jira/browse/NIFI-4957 > Project: Apache NiFi > Issue Type: Improvement >Reporter: Ryan Hendrickson >Assignee: Ryan Hendrickson >Priority: Minor > Attachments: image-2018-03-09-23-56-43-912.png > > > Add a property to allow the Jolt Spec to be read from a file on disk and/or > the classpath. > !image-2018-03-09-23-56-43-912.png! -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (MINIFICPP-841) agent does not do anything
[ https://issues.apache.org/jira/browse/MINIFICPP-841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Porzio resolved MINIFICPP-841. Resolution: Fixed Fix Version/s: 0.7.0 Placed all processors at the root level and removed the unsupported ones, and the agent started to process the config. > agent does not do anything > -- > > Key: MINIFICPP-841 > URL: https://issues.apache.org/jira/browse/MINIFICPP-841 > Project: Apache NiFi MiNiFi C++ > Issue Type: Bug >Affects Versions: 0.7.0 > Environment: Windows 10 - 64bits > Compiled from Visual Studio 2017 - without JNI support >Reporter: Christian Porzio >Priority: Critical > Labels: windows > Fix For: 0.7.0 > > Attachments: krystyan_minifi-cpp.zip > > > This is my first attempt to run minifi.exe cpp - I believe the compile is > fine but I might be missing some config components. > Basically when I launch that *minifi.exe* using a production _*config.yml*_ > that works with the java agent, nothing much seems to happen. I know it > consumes my config.yml because if I create an error in it, now it complains > about it. > However when it runs nothing is being sent to my remote processor and none of > the defined processor for that agent seem to be actually running. > I have attached the whole runtime environment -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MINIFICPP-841) agent does not do anything
[ https://issues.apache.org/jira/browse/MINIFICPP-841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16847129#comment-16847129 ] Christian Porzio commented on MINIFICPP-841: Hi, Sorry for the delay. Had to put that on the back burner. Yes, indeed placing all the processors at the same level got it to start, and yes I had to remove the unsupported (SplitText, FetchFile and LogAttribute). But now I am facing a number of other issues. LEt me close that ticket because frankly it was about the config not doing anything and did answer to the problem. Thanks again for that! > agent does not do anything > -- > > Key: MINIFICPP-841 > URL: https://issues.apache.org/jira/browse/MINIFICPP-841 > Project: Apache NiFi MiNiFi C++ > Issue Type: Bug >Affects Versions: 0.7.0 > Environment: Windows 10 - 64bits > Compiled from Visual Studio 2017 - without JNI support >Reporter: Christian Porzio >Priority: Critical > Labels: windows > Attachments: krystyan_minifi-cpp.zip > > > This is my first attempt to run minifi.exe cpp - I believe the compile is > fine but I might be missing some config components. > Basically when I launch that *minifi.exe* using a production _*config.yml*_ > that works with the java agent, nothing much seems to happen. I know it > consumes my config.yml because if I create an error in it, now it complains > about it. > However when it runs nothing is being sent to my remote processor and none of > the defined processor for that agent seem to be actually running. > I have attached the whole runtime environment -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] [nifi] rfellows opened a new pull request #3489: NIFI-6316 - Upgrade jQuery to the latest version (3.4.1).
rfellows opened a new pull request #3489: NIFI-6316 - Upgrade jQuery to the latest version (3.4.1). URL: https://github.com/apache/nifi/pull/3489 Thank you for submitting a contribution to Apache NiFi. In order to streamline the review of the contribution we ask you to ensure the following steps have been taken: ### For all changes: - [X] Is there a JIRA ticket associated with this PR? Is it referenced in the commit message? - [X] Does your PR title start with NIFI- where is the JIRA number you are trying to resolve? Pay particular attention to the hyphen "-" character. - [X] Has your PR been rebased against the latest commit within the target branch (typically master)? - [X] Is your initial contribution a single, squashed commit? ### For code changes: - [X] Have you ensured that the full suite of tests is executed via mvn -Pcontrib-check clean install at the root nifi folder? - [ ] Have you written or updated unit tests to verify your changes? - [ ] If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under [ASF 2.0](http://www.apache.org/legal/resolved.html#category-a)? - [ ] If applicable, have you updated the LICENSE file, including the main LICENSE file under nifi-assembly? - [ ] If applicable, have you updated the NOTICE file, including the main NOTICE file found under nifi-assembly? - [ ] If adding new Properties, have you added .displayName in addition to .name (programmatic access) for each of the new properties? ### For documentation related changes: - [ ] Have you ensured that format looks appropriate for the output in which it is rendered? ### Note: Please ensure that once the PR is submitted, you check travis-ci for build issues and submit an update to your PR as soon as possible. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Resolved] (MINIFICPP-877) Create a thread safe way to call thirdparty global initializers
[ https://issues.apache.org/jira/browse/MINIFICPP-877?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mr TheSegfault resolved MINIFICPP-877. -- Resolution: Fixed Resolved per merged PR, feel free to re-open if the need arises. > Create a thread safe way to call thirdparty global initializers > --- > > Key: MINIFICPP-877 > URL: https://issues.apache.org/jira/browse/MINIFICPP-877 > Project: Apache NiFi MiNiFi C++ > Issue Type: New Feature >Reporter: Daniel Bakai >Assignee: Daniel Bakai >Priority: Major > Fix For: 0.7.0 > > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] [nifi-minifi-cpp] asfgit closed pull request #567: MINIFICPP-877 - Add initializers to ObjectFactories
asfgit closed pull request #567: MINIFICPP-877 - Add initializers to ObjectFactories URL: https://github.com/apache/nifi-minifi-cpp/pull/567 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Assigned] (NIFI-6315) Track remote input/output ports at any level when creating versioned flows
[ https://issues.apache.org/jira/browse/NIFI-6315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Bende reassigned NIFI-6315: - Assignee: Bryan Bende > Track remote input/output ports at any level when creating versioned flows > -- > > Key: NIFI-6315 > URL: https://issues.apache.org/jira/browse/NIFI-6315 > Project: Apache NiFi > Issue Type: Improvement >Reporter: Bryan Bende >Assignee: Bryan Bende >Priority: Major > Fix For: 1.10.0 > > Time Spent: 10m > Remaining Estimate: 0h > > NIFI-2933 added the ability to create remote input/output ports at any level. > This information needs to be tracked when creating versioned flows that are > saved to registry, otherwise it will be lost on import. > The registry 0.4.0 release added a boolean to VersionedPort for this purpose: > [https://github.com/apache/nifi-registry/blob/master/nifi-registry-core/nifi-registry-data-model/src/main/java/org/apache/nifi/registry/flow/VersionedPort.java#L26] > NiFi's master branch needs to be updated to the 0.4.0 client which is part of > NIFI-6311: > [https://github.com/apache/nifi/pull/3485] > CC: [~ijokarumawak] [~markap14] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (NIFI-6315) Track remote input/output ports at any level when creating versioned flows
[ https://issues.apache.org/jira/browse/NIFI-6315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Bende updated NIFI-6315: -- Status: Patch Available (was: Open) > Track remote input/output ports at any level when creating versioned flows > -- > > Key: NIFI-6315 > URL: https://issues.apache.org/jira/browse/NIFI-6315 > Project: Apache NiFi > Issue Type: Improvement >Reporter: Bryan Bende >Priority: Major > Fix For: 1.10.0 > > Time Spent: 10m > Remaining Estimate: 0h > > NIFI-2933 added the ability to create remote input/output ports at any level. > This information needs to be tracked when creating versioned flows that are > saved to registry, otherwise it will be lost on import. > The registry 0.4.0 release added a boolean to VersionedPort for this purpose: > [https://github.com/apache/nifi-registry/blob/master/nifi-registry-core/nifi-registry-data-model/src/main/java/org/apache/nifi/registry/flow/VersionedPort.java#L26] > NiFi's master branch needs to be updated to the 0.4.0 client which is part of > NIFI-6311: > [https://github.com/apache/nifi/pull/3485] > CC: [~ijokarumawak] [~markap14] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] [nifi] bbende opened a new pull request #3488: NIFI-6315 Ensuring remote ports get tracked correctly when saving/ret…
bbende opened a new pull request #3488: NIFI-6315 Ensuring remote ports get tracked correctly when saving/ret… URL: https://github.com/apache/nifi/pull/3488 …rieving versioned flows @markap14 @ijokarumawak Everything in this PR appears to work in terms of saving to registry and importing, but I did want to ask what should happen when there are public ports with the same name in multiple process groups? For example, I setup PG1 with public Input Port "IN" -> Update Attribute, and save it to registry. Then I created a GenerateFlowFile -> RPG connected to the "IN". Then I import a new PG and choose the same one I just saved to registry, so now I have two of the same PGs, both with an input port named "IN". It seemed as though the RPG never recognized the second and continued sending to the original one. Then I renamed the second input port to "IN2" which showed as a local change on the PG, and I stopped the original input port. The RPG somehow refreshed and renamed the connection from "IN" to "IN2". This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Assigned] (NIFI-6316) UI - Upgrade jQuery
[ https://issues.apache.org/jira/browse/NIFI-6316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Fellows reassigned NIFI-6316: Assignee: Robert Fellows > UI - Upgrade jQuery > --- > > Key: NIFI-6316 > URL: https://issues.apache.org/jira/browse/NIFI-6316 > Project: Apache NiFi > Issue Type: Bug > Components: Core UI >Reporter: Matt Gilman >Assignee: Robert Fellows >Priority: Major > > Upgrade to a newer version of jQuery. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (NIFI-6316) UI - Upgrade jQuery
Matt Gilman created NIFI-6316: - Summary: UI - Upgrade jQuery Key: NIFI-6316 URL: https://issues.apache.org/jira/browse/NIFI-6316 Project: Apache NiFi Issue Type: Bug Components: Core UI Reporter: Matt Gilman Upgrade to a newer version of jQuery. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (NIFI-6311) Bump nifi.registry.version to 0.4.0 release
[ https://issues.apache.org/jira/browse/NIFI-6311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Bende updated NIFI-6311: -- Resolution: Fixed Status: Resolved (was: Patch Available) > Bump nifi.registry.version to 0.4.0 release > --- > > Key: NIFI-6311 > URL: https://issues.apache.org/jira/browse/NIFI-6311 > Project: Apache NiFi > Issue Type: Improvement >Reporter: Bryan Bende >Assignee: Bryan Bende >Priority: Minor > Fix For: 1.10.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > Start using the 0.4.0 client in master. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (NIFI-6311) Bump nifi.registry.version to 0.4.0 release
[ https://issues.apache.org/jira/browse/NIFI-6311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16846855#comment-16846855 ] ASF subversion and git services commented on NIFI-6311: --- Commit b09b84226c28a01452d4e0c0796056140392ec58 in nifi's branch refs/heads/master from Bryan Bende [ https://gitbox.apache.org/repos/asf?p=nifi.git;h=b09b842 ] NIFI-6311 Upgrade to nifi-registry-client 0.4.0 This closes #3485. > Bump nifi.registry.version to 0.4.0 release > --- > > Key: NIFI-6311 > URL: https://issues.apache.org/jira/browse/NIFI-6311 > Project: Apache NiFi > Issue Type: Improvement >Reporter: Bryan Bende >Assignee: Bryan Bende >Priority: Minor > Fix For: 1.10.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Start using the 0.4.0 client in master. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] [nifi] asfgit closed pull request #3485: NIFI-6311 Upgrade to nifi-registry-client 0.4.0
asfgit closed pull request #3485: NIFI-6311 Upgrade to nifi-registry-client 0.4.0 URL: https://github.com/apache/nifi/pull/3485 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [nifi] joewitt commented on issue #3485: NIFI-6311 Upgrade to nifi-registry-client 0.4.0
joewitt commented on issue #3485: NIFI-6311 Upgrade to nifi-registry-client 0.4.0 URL: https://github.com/apache/nifi/pull/3485#issuecomment-495296537 +1. not sure what is up with travis for oracle builds though This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [nifi-minifi-cpp] arpadboda opened a new pull request #569: MINIFICPP-865 - Statically link AWS SDK to libminifi
arpadboda opened a new pull request #569: MINIFICPP-865 - Statically link AWS SDK to libminifi URL: https://github.com/apache/nifi-minifi-cpp/pull/569 Thank you for submitting a contribution to Apache NiFi - MiNiFi C++. In order to streamline the review of the contribution we ask you to ensure the following steps have been taken: ### For all changes: - [ ] Is there a JIRA ticket associated with this PR? Is it referenced in the commit message? - [ ] Does your PR title start with MINIFICPP- where is the JIRA number you are trying to resolve? Pay particular attention to the hyphen "-" character. - [ ] Has your PR been rebased against the latest commit within the target branch (typically master)? - [ ] Is your initial contribution a single, squashed commit? ### For code changes: - [ ] If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under [ASF 2.0](http://www.apache.org/legal/resolved.html#category-a)? - [ ] If applicable, have you updated the LICENSE file? - [ ] If applicable, have you updated the NOTICE file? ### For documentation related changes: - [ ] Have you ensured that format looks appropriate for the output in which it is rendered? ### Note: Please ensure that once the PR is submitted, you check travis-ci for build issues and submit an update to your PR as soon as possible. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Created] (NIFI-6315) Track remote input/output ports at any level when creating versioned flows
Bryan Bende created NIFI-6315: - Summary: Track remote input/output ports at any level when creating versioned flows Key: NIFI-6315 URL: https://issues.apache.org/jira/browse/NIFI-6315 Project: Apache NiFi Issue Type: Improvement Reporter: Bryan Bende Fix For: 1.10.0 NIFI-2933 added the ability to create remote input/output ports at any level. This information needs to be tracked when creating versioned flows that are saved to registry, otherwise it will be lost on import. The registry 0.4.0 release added a boolean to VersionedPort for this purpose: [https://github.com/apache/nifi-registry/blob/master/nifi-registry-core/nifi-registry-data-model/src/main/java/org/apache/nifi/registry/flow/VersionedPort.java#L26] NiFi's master branch needs to be updated to the 0.4.0 client which is part of NIFI-6311: [https://github.com/apache/nifi/pull/3485] CC: [~ijokarumawak] [~markap14] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] [nifi-minifi-cpp] asfgit closed pull request #568: MINIFICPP-878 - Fix AWS build
asfgit closed pull request #568: MINIFICPP-878 - Fix AWS build URL: https://github.com/apache/nifi-minifi-cpp/pull/568 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Commented] (MINIFICPP-877) Create a thread safe way to call thirdparty global initializers
[ https://issues.apache.org/jira/browse/MINIFICPP-877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16846792#comment-16846792 ] Daniel Bakai commented on MINIFICPP-877: I see, I think we should be alright for now then. If we were to create a really dynamic extension loading, where a new extension can be loaded into the agent at runtime, and that extension's ObjectFactoryInitializer would init OpenSSL, and at the same time an another thread were to create the first TLSSocket, we would have a problem, but as far as I see this is not something that can currently happen. > Create a thread safe way to call thirdparty global initializers > --- > > Key: MINIFICPP-877 > URL: https://issues.apache.org/jira/browse/MINIFICPP-877 > Project: Apache NiFi MiNiFi C++ > Issue Type: New Feature >Reporter: Daniel Bakai >Assignee: Daniel Bakai >Priority: Major > Fix For: 0.7.0 > > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (MINIFICPP-877) Create a thread safe way to call thirdparty global initializers
[ https://issues.apache.org/jira/browse/MINIFICPP-877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16846783#comment-16846783 ] Mr TheSegfault edited comment on MINIFICPP-877 at 5/23/19 3:26 PM: --- In the case of agents, [https://github.com/apache/nifi-minifi-cpp/blob/master/main/MiNiFiMain.cpp#L96] ensures that static functions are all called well before any functionality is initialized to support things like sockets or file system activities. It occurs there first to provide initialization at the earliest possible phase. Edit: not sure what was going on with the quotes. was (Author: phrocker): In the case of agents, [https://github.com/apache/nifi-minifi-cpp/blob/master/main/MiNiFiMain.cpp#L96] ensures that static functions are all called well before any functionality is initialized to support things like "sockets" or "file system activities. It occurs there first to provide initialization at the earliest possible phase. > Create a thread safe way to call thirdparty global initializers > --- > > Key: MINIFICPP-877 > URL: https://issues.apache.org/jira/browse/MINIFICPP-877 > Project: Apache NiFi MiNiFi C++ > Issue Type: New Feature >Reporter: Daniel Bakai >Assignee: Daniel Bakai >Priority: Major > Fix For: 0.7.0 > > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MINIFICPP-877) Create a thread safe way to call thirdparty global initializers
[ https://issues.apache.org/jira/browse/MINIFICPP-877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16846783#comment-16846783 ] Mr TheSegfault commented on MINIFICPP-877: -- In the case of agents, [https://github.com/apache/nifi-minifi-cpp/blob/master/main/MiNiFiMain.cpp#L96] ensures that static functions are all called well before any functionality is initialized to support things like "sockets" or "file system activities. It occurs there first to provide initialization at the earliest possible phase. > Create a thread safe way to call thirdparty global initializers > --- > > Key: MINIFICPP-877 > URL: https://issues.apache.org/jira/browse/MINIFICPP-877 > Project: Apache NiFi MiNiFi C++ > Issue Type: New Feature >Reporter: Daniel Bakai >Assignee: Daniel Bakai >Priority: Major > Fix For: 0.7.0 > > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MINIFICPP-877) Create a thread safe way to call thirdparty global initializers
[ https://issues.apache.org/jira/browse/MINIFICPP-877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16846781#comment-16846781 ] Daniel Bakai commented on MINIFICPP-877: If OpenSSLInitializer::getInstance() (creating a TLSSocket) only happens after the ObjectFactoryInitializers are called then we do not have a problem. I was just not sure that this is the case. > Create a thread safe way to call thirdparty global initializers > --- > > Key: MINIFICPP-877 > URL: https://issues.apache.org/jira/browse/MINIFICPP-877 > Project: Apache NiFi MiNiFi C++ > Issue Type: New Feature >Reporter: Daniel Bakai >Assignee: Daniel Bakai >Priority: Major > Fix For: 0.7.0 > > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MINIFICPP-877) Create a thread safe way to call thirdparty global initializers
[ https://issues.apache.org/jira/browse/MINIFICPP-877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16846774#comment-16846774 ] Mr TheSegfault commented on MINIFICPP-877: -- Thanks, the KNOWN_BUGS in docs makes the interpretation much clearer, as do the related tickets. It's open source, so unless someone wants to work on those changes, admittedly it is what it is. In which case we can assume that the initializer will initialize both. Since TLSSocket is guaranteed to initialize after these initializers, where does the thread safety issue originate other than another extension? > Create a thread safe way to call thirdparty global initializers > --- > > Key: MINIFICPP-877 > URL: https://issues.apache.org/jira/browse/MINIFICPP-877 > Project: Apache NiFi MiNiFi C++ > Issue Type: New Feature >Reporter: Daniel Bakai >Assignee: Daniel Bakai >Priority: Major > Fix For: 0.7.0 > > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MINIFICPP-877) Create a thread safe way to call thirdparty global initializers
[ https://issues.apache.org/jira/browse/MINIFICPP-877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16846771#comment-16846771 ] Daniel Bakai commented on MINIFICPP-877: About the documentation: what you describe is how curl used to work, but if you see the caveat under CURL_GLOBAL_SSL "This flag's presence or absence serves no meaning since 7.57.0. The description below is for older libcurl versions.". It might not be completely clear, but also see this description, referencing the commit where the change was made: [https://github.com/curl/curl/blob/master/docs/KNOWN_BUGS#L270] I can not interpret neither the description nor the code any other way than that curl now unconditionally initializes the SSL backend. > Create a thread safe way to call thirdparty global initializers > --- > > Key: MINIFICPP-877 > URL: https://issues.apache.org/jira/browse/MINIFICPP-877 > Project: Apache NiFi MiNiFi C++ > Issue Type: New Feature >Reporter: Daniel Bakai >Assignee: Daniel Bakai >Priority: Major > Fix For: 0.7.0 > > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MINIFICPP-877) Create a thread safe way to call thirdparty global initializers
[ https://issues.apache.org/jira/browse/MINIFICPP-877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16846764#comment-16846764 ] Mr TheSegfault commented on MINIFICPP-877: -- We can't assume that TLSSocket initializes first, hence my suggestion to initialize via the singleton in a potential chain. TLSSocket may not be used at any point, and hence initialization isn't needed. The curl curl initializer will come before TLSSocket, so SSL_library_init will be called twice. I have read that it is suggested that you init it once, but nothing indicates failure otherwise ( even anecdotal tests support that theory ). The singleton idea only comes into play with the unknown that SSL_library_init may be called more than once. I'm suggesting that with the assumption that documentation is unclear. If we can call that more than once than if curl initializes, a later use of TLSSocket will be guaranteed to come after curl. That is not how I read that documentation, It seems that CURL_GLOBAL_WIN32 instead of DEFAULT or ALL would NOT enable OpenSSL. I don't quite understand this rationale: "I would prefer to avoid having dependencies between initializers: all third party libraries that has these kind of global initializers are designed to handle calling their _init and _deinit functions more than once (and only deallocate when their refcounter reaches 0)" How does that preclude the capability to chain initializers? This only matters if we shouldn't call SSL_library_init twice, and we need to ensure curl doesn't call it and we don't call it. > Create a thread safe way to call thirdparty global initializers > --- > > Key: MINIFICPP-877 > URL: https://issues.apache.org/jira/browse/MINIFICPP-877 > Project: Apache NiFi MiNiFi C++ > Issue Type: New Feature >Reporter: Daniel Bakai >Assignee: Daniel Bakai >Priority: Major > Fix For: 0.7.0 > > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MINIFICPP-877) Create a thread safe way to call thirdparty global initializers
[ https://issues.apache.org/jira/browse/MINIFICPP-877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16846759#comment-16846759 ] Daniel Bakai commented on MINIFICPP-877: If we can assume that OpenSSLInitializer::getInstance() is not called before ObjectFactories are created, we could add an ObjectFactory whose initializer calls it. This way the first call would be synchronized with the rest of the ObjectFactoryInitializers and subsequent calls would not really call SSL initializers. > Create a thread safe way to call thirdparty global initializers > --- > > Key: MINIFICPP-877 > URL: https://issues.apache.org/jira/browse/MINIFICPP-877 > Project: Apache NiFi MiNiFi C++ > Issue Type: New Feature >Reporter: Daniel Bakai >Assignee: Daniel Bakai >Priority: Major > Fix For: 0.7.0 > > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (MINIFICPP-877) Create a thread safe way to call thirdparty global initializers
[ https://issues.apache.org/jira/browse/MINIFICPP-877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16846758#comment-16846758 ] Daniel Bakai edited comment on MINIFICPP-877 at 5/23/19 2:42 PM: - [~phrocker] You can't actually tell cURL not to initialise OpenSSL since 7.57.0 (CURL_GLOBAL_SSL is ignored since that version, see [https://curl.haxx.se/libcurl/c/curl_global_init.html]). So if we can't assume that TLSSocket's singleton is created before any ObjectFactory is created, then it is bad for us either way. However, if we can assume that TLSSocket's singleton is created before any ObjectFactory is created, then we don't have a problem: you will not have parallel calls to OpenSSL's initializers and we can avoid adding a chaining/dependency API to initializers. I would prefer to avoid having dependencies between initializers: all third party libraries that has these kind of global initializers are designed to handle calling their _init and _deinit functions more than once (and only deallocate when their refcounter reaches 0): we just have to provide synchronization and ObjectFactoryInitializers can be kept simple. So if we can't ensure that the TLSSocket singleton is created before ObjectFactoryInitializers are called, then we wouldn't be in a better position even if we could tell cURL not to initialize OpenSSL. If we can ensure that, we are ready. If we can't, we have to find some other method of synchronization. was (Author: bakaid): [~phrocker] You can't actually tell cURL not to initialise OpenSSL since 7.57.0 (CURL_GLOBAL_SSL is ignored since that version, see [https://curl.haxx.se/libcurl/c/curl_global_init.html]). So if we can't assume that TLSSocket's singleton is created before any ObjectFactory is created, then it is bad for us either way. However, if we can assume that TLSSocket's singleton is created before any ObjectFactory is created, then we don't have a problem: you will not have parallel calls to OpenSSL's initializers and we can avoid adding a chaining/dependency API to initializers. I would prefer to avoid having dependencies between initializers: all third party libraries that has these kind of global initializers are designed to handle calling their _init and _deinit functions more than once (and only deallocate when their refcounter reaches 0): we just have to provide synchronization. So if we can't ensure that the TLSSocket singleton is created before ObjectFactoryInitializers are called, then we wouldn't be in a better position even if we could tell cURL not to initialize OpenSSL. If we can ensure that, we are ready. If we can't, we have to find some other method of synchronization. > Create a thread safe way to call thirdparty global initializers > --- > > Key: MINIFICPP-877 > URL: https://issues.apache.org/jira/browse/MINIFICPP-877 > Project: Apache NiFi MiNiFi C++ > Issue Type: New Feature >Reporter: Daniel Bakai >Assignee: Daniel Bakai >Priority: Major > Fix For: 0.7.0 > > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MINIFICPP-877) Create a thread safe way to call thirdparty global initializers
[ https://issues.apache.org/jira/browse/MINIFICPP-877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16846758#comment-16846758 ] Daniel Bakai commented on MINIFICPP-877: [~phrocker] You can't actually tell cURL not to initialise OpenSSL since 7.57.0 (CURL_GLOBAL_SSL is ignored since that version, see [https://curl.haxx.se/libcurl/c/curl_global_init.html]). So if we can't assume that TLSSocket's singleton is created before any ObjectFactory is created, then it is bad for us either way. However, if we can assume that TLSSocket's singleton is created before any ObjectFactory is created, then we don't have a problem: you will not have parallel calls to OpenSSL's initializers and we can avoid adding a chaining/dependency API to initializers. I would prefer to avoid having dependencies between initializers: all third party libraries that has these kind of global initializers are designed to handle calling their _init and _deinit functions more than once (and only deallocate when their refcounter reaches 0): we just have to provide synchronization. So if we can't ensure that the TLSSocket singleton is created before ObjectFactoryInitializers are called, then we wouldn't be in a better position even if we could tell cURL not to initialize OpenSSL. If we can ensure that, we are ready. If we can't, we have to find some other method of synchronization. > Create a thread safe way to call thirdparty global initializers > --- > > Key: MINIFICPP-877 > URL: https://issues.apache.org/jira/browse/MINIFICPP-877 > Project: Apache NiFi MiNiFi C++ > Issue Type: New Feature >Reporter: Daniel Bakai >Assignee: Daniel Bakai >Priority: Major > Fix For: 0.7.0 > > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] [nifi] mcgilman opened a new pull request #3487: NIFI-6302: Updating integration tests to verify pruned results
mcgilman opened a new pull request #3487: NIFI-6302: Updating integration tests to verify pruned results URL: https://github.com/apache/nifi/pull/3487 NIFI-6302: - Updating integration tests to verify pruned results. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Commented] (MINIFICPP-877) Create a thread safe way to call thirdparty global initializers
[ https://issues.apache.org/jira/browse/MINIFICPP-877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16846752#comment-16846752 ] Mr TheSegfault commented on MINIFICPP-877: -- I guess I should re-phrase that to assume that the singleton exists within TLSSocket ( it's part of core, if only because it pre-dates extensions ), and then allow initializers to be chained maybe in some order that Curl relies on OpenSSL? So that if curl isn't built, TLSSocket still calls that same initializer? It may mean that initializer changes to support the same model in this PR. > Create a thread safe way to call thirdparty global initializers > --- > > Key: MINIFICPP-877 > URL: https://issues.apache.org/jira/browse/MINIFICPP-877 > Project: Apache NiFi MiNiFi C++ > Issue Type: New Feature >Reporter: Daniel Bakai >Assignee: Daniel Bakai >Priority: Major > Fix For: 0.7.0 > > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MINIFICPP-877) Create a thread safe way to call thirdparty global initializers
[ https://issues.apache.org/jira/browse/MINIFICPP-877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16846747#comment-16846747 ] Mr TheSegfault commented on MINIFICPP-877: -- Would it make sense to not init SSL in curl and instead doing it through another initializer? > Create a thread safe way to call thirdparty global initializers > --- > > Key: MINIFICPP-877 > URL: https://issues.apache.org/jira/browse/MINIFICPP-877 > Project: Apache NiFi MiNiFi C++ > Issue Type: New Feature >Reporter: Daniel Bakai >Assignee: Daniel Bakai >Priority: Major > Fix For: 0.7.0 > > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Reopened] (NIFI-6302) Prune Process Group contents
[ https://issues.apache.org/jira/browse/NIFI-6302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Gilman reopened NIFI-6302: --- Reopening to updating some unit tests. > Prune Process Group contents > > > Key: NIFI-6302 > URL: https://issues.apache.org/jira/browse/NIFI-6302 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Reporter: Matt Gilman >Assignee: Matt Gilman >Priority: Major > Fix For: 1.10.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > Need to ensure the Process Group contents are appropriately pruned when > necessary. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (NIFI-5029) CLI - Handling of embedded versioned process groups during export/import
[
https://issues.apache.org/jira/browse/NIFI-5029?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16846729#comment-16846729
]
Bryan Bende commented on NIFI-5029:
---
Here is a new Jira to track the issue being discussed here in the comments:
https://issues.apache.org/jira/browse/NIFI-6314
> CLI - Handling of embedded versioned process groups during export/import
>
>
> Key: NIFI-5029
> URL: https://issues.apache.org/jira/browse/NIFI-5029
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Flow Versioning, SDLC, Tools and Build
>Reporter: Pierre Villard
>Priority: Major
> Labels: SDLC
>
> I'm in a situation where, in my dev environment, I have a versioned process
> group A in bucket bA containing an embedded process group B from bucket bB.
> Both A and B are versioned in the NiFi Registry of my dev environment.
> I'm using the CLI to export both A and B from my dev Registry, and then
> importing A and B in my prod Registry. The issue is that in the json
> representing A, there is a reference to B containing the url of the dev
> Registry, the bucket ID and the workflow ID representing B.
> To import B in my prod registry, I first created a bucket bB and a workflow
> B. New UUIDs have been generated for both in the prod registry. Then I did
> the import of the JSON representing B.
> Now I manually update the JSON representing A to set the UUIDs related to B
> with the new values of my prod registry. Then I created a bucket and a
> workflow for A in my prod registry, and did the import.
> Problem occurs when I try to import the process group A in my prod NiFi.
> It'll fail with an error looking like this:
> {code:java}
> #> nifi pg-change-version -fv 2 -pgid &1 -u http://localhost:8080
> > Using a positional back-reference for 'A'
> ERROR: Error executing command 'pg-change-version' : Error updating version
> control information: The Flow Registry with ID
> 56a49113-0162-1000-0a7e-4959d312d445 reports that no Flow exists with Bucket
> 9d87ccc4-7084-4069-850a-7704135ea9e9, Flow
> 7e47aeba-4908-41a6-88d7-e6deb1abef98, Version 2{code}
> I guess there are multiple ways of handling it. It could be on the CLI side
> or on the Registry side (could be related to NIFIREG-148).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (NIFI-6314) Nested versioned process groups do not update properly
[ https://issues.apache.org/jira/browse/NIFI-6314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Bende updated NIFI-6314: -- Description: Steps to reproduce: # NiFi#1 Create PGA # NiFI#1 Create PGB inside PGA # NiFI#1 Create some processors inside PGB # NIFI#1 Start version control PGB # NIFI#1 Start version control PGA # NIFI#2 Import a new PG and select PGA v1 (at this point the same exact flow is now in both NiFi's) # NIFI#1 Go into PGB and modify the properties of some processors # NIFI#1 Commit changes on PGB # NIFI#1 Commit changes on PGA # NIFI#2 Change version on PGA from v1 to v2 (caused PGB to be updated to v2 since PGA v2 points to PGB v2) At this point PGB in NIFI#2 thinks it has been updated to v2 according to the version info in flow.xml.gz, but it the actual changes from v2 have not been applied, and it shows local changes that looks like they undid what should be the real changes. Choosing to revert the local changes will actually get back to the real v2 state. You can also reproduce this using a single NiFi and having two instances of the same versioned process group described above, or by having a single instance of the versioned process group and changing the outer PGA back and forth between v2 and v1. was: Steps to reproduce: # NiFi#1 Create PGA # NiFI#1 Create PGB inside PGA # NiFI#1 Create some processors inside PGB # NIFI#1 Start version control PGB # NIFI#1 Start version control PGA # NIFI#2 Import a new PG and select PGA v1 (at this point the same exact flow is now in both NiFi's) # NIFI#1 Go into PGB and modify the properties of some processors # NIFI#1 Commit changes on PGB # NIFI#1 Commit changes on PGA # NIFI#2 Change version on PGA from v1 to v2 (caused PGB to be updated to v2 since PGA v2 points to PGB v2) At this point PGB in NIFI#2 thinks it has been updated to v2 according to the version info in flow.xml.gz, but it the actual changes from v2 have not been applied, and it shows local changes that looks like they undid what should be the real changes. Choosing to revert the local changes will actually get back to the real v2 state. > Nested versioned process groups do not update properly > -- > > Key: NIFI-6314 > URL: https://issues.apache.org/jira/browse/NIFI-6314 > Project: Apache NiFi > Issue Type: Bug >Affects Versions: 1.9.0, 1.9.1, 1.9.2 >Reporter: Bryan Bende >Priority: Major > Labels: SDLC > > Steps to reproduce: > # NiFi#1 Create PGA > # NiFI#1 Create PGB inside PGA > # NiFI#1 Create some processors inside PGB > # NIFI#1 Start version control PGB > # NIFI#1 Start version control PGA > # NIFI#2 Import a new PG and select PGA v1 (at this point the same exact > flow is now in both NiFi's) > # NIFI#1 Go into PGB and modify the properties of some processors > # NIFI#1 Commit changes on PGB > # NIFI#1 Commit changes on PGA > # NIFI#2 Change version on PGA from v1 to v2 (caused PGB to be updated to v2 > since PGA v2 points to PGB v2) > At this point PGB in NIFI#2 thinks it has been updated to v2 according to the > version info in flow.xml.gz, but it the actual changes from v2 have not been > applied, and it shows local changes that looks like they undid what should be > the real changes. Choosing to revert the local changes will actually get back > to the real v2 state. > You can also reproduce this using a single NiFi and having two instances of > the same versioned process group described above, or by having a single > instance of the versioned process group and changing the outer PGA back and > forth between v2 and v1. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (NIFI-6314) Nested versioned process groups do not update properly
Bryan Bende created NIFI-6314: - Summary: Nested versioned process groups do not update properly Key: NIFI-6314 URL: https://issues.apache.org/jira/browse/NIFI-6314 Project: Apache NiFi Issue Type: Bug Affects Versions: 1.9.2, 1.9.1, 1.9.0 Reporter: Bryan Bende Steps to reproduce: # NiFi#1 Create PGA # NiFI#1 Create PGB inside PGA # NiFI#1 Create some processors inside PGB # NIFI#1 Start version control PGB # NIFI#1 Start version control PGA # NIFI#2 Import a new PG and select PGA v1 (at this point the same exact flow is now in both NiFi's) # NIFI#1 Go into PGB and modify the properties of some processors # NIFI#1 Commit changes on PGB # NIFI#1 Commit changes on PGA # NIFI#2 Change version on PGA from v1 to v2 (caused PGB to be updated to v2 since PGA v2 points to PGB v2) At this point PGB in NIFI#2 thinks it has been updated to v2 according to the version info in flow.xml.gz, but it the actual changes from v2 have not been applied, and it shows local changes that looks like they undid what should be the real changes. Choosing to revert the local changes will actually get back to the real v2 state. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (NIFI-6314) Nested versioned process groups do not update properly
[ https://issues.apache.org/jira/browse/NIFI-6314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Bende updated NIFI-6314: -- Labels: SDLC (was: ) > Nested versioned process groups do not update properly > -- > > Key: NIFI-6314 > URL: https://issues.apache.org/jira/browse/NIFI-6314 > Project: Apache NiFi > Issue Type: Bug >Affects Versions: 1.9.0, 1.9.1, 1.9.2 >Reporter: Bryan Bende >Priority: Major > Labels: SDLC > > Steps to reproduce: > # NiFi#1 Create PGA > # NiFI#1 Create PGB inside PGA > # NiFI#1 Create some processors inside PGB > # NIFI#1 Start version control PGB > # NIFI#1 Start version control PGA > # NIFI#2 Import a new PG and select PGA v1 (at this point the same exact > flow is now in both NiFi's) > # NIFI#1 Go into PGB and modify the properties of some processors > # NIFI#1 Commit changes on PGB > # NIFI#1 Commit changes on PGA > # NIFI#2 Change version on PGA from v1 to v2 (caused PGB to be updated to v2 > since PGA v2 points to PGB v2) > At this point PGB in NIFI#2 thinks it has been updated to v2 according to the > version info in flow.xml.gz, but it the actual changes from v2 have not been > applied, and it shows local changes that looks like they undid what should be > the real changes. Choosing to revert the local changes will actually get back > to the real v2 state. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (NIFI-6313) PutGCSObject performance seems slow
Jasper Knulst created NIFI-6313: --- Summary: PutGCSObject performance seems slow Key: NIFI-6313 URL: https://issues.apache.org/jira/browse/NIFI-6313 Project: Apache NiFi Issue Type: Improvement Components: Core Framework, Extensions Affects Versions: 1.9.2 Reporter: Jasper Knulst Fix For: 1.10.0 The PutGCSObject processor to transfer files to Google Cloud Platform bucket has bad transfer speeds. It is impossible to put any hard figures on the throughput as it seems dependent on: -Network location of the Nifi node (situated in GC or not) -Network bandwidth -Nifi node specs After performing benchmarks on multiple Nifi clusters (ranging from test setups to prod. sites) the throughput can range from 8MB/s to 800MB/s. Slow really means, slow in comparison to gsutil. If you run gsutil directly from the Nifi node the throughput speed goes up 5 to 8 times (without 'parallel_composite_upload') and up to 16 times faster with 'parallel_composite_upload'. The GC Java API on which Nifi's GCS processors are built, does not have the same optimizations as gsutil and maybe isn't supported/maintained. The Storage.create method is even deprecated. Still there must be ways to speed up transfers the GCS by implementing parallel composite uploads in chuncks and config options on the GCS processors -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] [nifi-minifi-cpp] arpadboda opened a new pull request #568: MINIFICPP-878 - Fix AWS build
arpadboda opened a new pull request #568: MINIFICPP-878 - Fix AWS build URL: https://github.com/apache/nifi-minifi-cpp/pull/568 Thank you for submitting a contribution to Apache NiFi - MiNiFi C++. In order to streamline the review of the contribution we ask you to ensure the following steps have been taken: ### For all changes: - [ ] Is there a JIRA ticket associated with this PR? Is it referenced in the commit message? - [ ] Does your PR title start with MINIFICPP- where is the JIRA number you are trying to resolve? Pay particular attention to the hyphen "-" character. - [ ] Has your PR been rebased against the latest commit within the target branch (typically master)? - [ ] Is your initial contribution a single, squashed commit? ### For code changes: - [ ] If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under [ASF 2.0](http://www.apache.org/legal/resolved.html#category-a)? - [ ] If applicable, have you updated the LICENSE file? - [ ] If applicable, have you updated the NOTICE file? ### For documentation related changes: - [ ] Have you ensured that format looks appropriate for the output in which it is rendered? ### Note: Please ensure that once the PR is submitted, you check travis-ci for build issues and submit an update to your PR as soon as possible. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Created] (MINIFICPP-878) Fix AWS build
Arpad Boda created MINIFICPP-878: Summary: Fix AWS build Key: MINIFICPP-878 URL: https://issues.apache.org/jira/browse/MINIFICPP-878 Project: Apache NiFi MiNiFi C++ Issue Type: Bug Reporter: Arpad Boda Assignee: Arpad Boda Fix For: 0.7.0 We need this fix to compile AWS: https://github.com/aws/aws-sdk-cpp/commit/18ddaa9746b6ea40b247272ab8f804082943b503 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MINIFICPP-877) Create a thread safe way to call thirdparty global initializers
[ https://issues.apache.org/jira/browse/MINIFICPP-877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16846587#comment-16846587 ] Daniel Bakai commented on MINIFICPP-877: I have also realized that we compile, but don't run InvokeHTTPTests, and it actually fails if ran manually. > Create a thread safe way to call thirdparty global initializers > --- > > Key: MINIFICPP-877 > URL: https://issues.apache.org/jira/browse/MINIFICPP-877 > Project: Apache NiFi MiNiFi C++ > Issue Type: New Feature >Reporter: Daniel Bakai >Assignee: Daniel Bakai >Priority: Major > Fix For: 0.7.0 > > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MINIFICPP-877) Create a thread safe way to call thirdparty global initializers
[ https://issues.apache.org/jira/browse/MINIFICPP-877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16846573#comment-16846573 ] Daniel Bakai commented on MINIFICPP-877: OpenSSLInitializer from TLSSocket is still problematic. Because curl_global_init and OpenSSL initialization is unsafe to call simultaneously, and I don't see any synchronization between HTTPClientInitializer and OpenSSLInitializer, it was potentially unsafe so far, and because TLSSocket is not part of an extension it is still unsafe. There might be a way to make this initializer conform to the new framework provided by this pull request, but I don't yet see how it could be done best. > Create a thread safe way to call thirdparty global initializers > --- > > Key: MINIFICPP-877 > URL: https://issues.apache.org/jira/browse/MINIFICPP-877 > Project: Apache NiFi MiNiFi C++ > Issue Type: New Feature >Reporter: Daniel Bakai >Assignee: Daniel Bakai >Priority: Major > Fix For: 0.7.0 > > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] [nifi-minifi-cpp] bakaid opened a new pull request #567: MINIFICPP-877 - Add initializers to ObjectFactories
bakaid opened a new pull request #567: MINIFICPP-877 - Add initializers to ObjectFactories URL: https://github.com/apache/nifi-minifi-cpp/pull/567 Thank you for submitting a contribution to Apache NiFi - MiNiFi C++. In order to streamline the review of the contribution we ask you to ensure the following steps have been taken: ### For all changes: - [ ] Is there a JIRA ticket associated with this PR? Is it referenced in the commit message? - [ ] Does your PR title start with MINIFICPP- where is the JIRA number you are trying to resolve? Pay particular attention to the hyphen "-" character. - [ ] Has your PR been rebased against the latest commit within the target branch (typically master)? - [ ] Is your initial contribution a single, squashed commit? ### For code changes: - [ ] If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under [ASF 2.0](http://www.apache.org/legal/resolved.html#category-a)? - [ ] If applicable, have you updated the LICENSE file? - [ ] If applicable, have you updated the NOTICE file? ### For documentation related changes: - [ ] Have you ensured that format looks appropriate for the output in which it is rendered? ### Note: Please ensure that once the PR is submitted, you check travis-ci for build issues and submit an update to your PR as soon as possible. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Updated] (MINIFICPP-877) Create a thread safe way to call thirdparty global initializers
[ https://issues.apache.org/jira/browse/MINIFICPP-877?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Bakai updated MINIFICPP-877: --- Issue Type: New Feature (was: Bug) > Create a thread safe way to call thirdparty global initializers > --- > > Key: MINIFICPP-877 > URL: https://issues.apache.org/jira/browse/MINIFICPP-877 > Project: Apache NiFi MiNiFi C++ > Issue Type: New Feature >Reporter: Daniel Bakai >Assignee: Daniel Bakai >Priority: Major > Fix For: 0.7.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (MINIFICPP-877) Create a thread safe way to call thirdparty global initializers
Daniel Bakai created MINIFICPP-877: -- Summary: Create a thread safe way to call thirdparty global initializers Key: MINIFICPP-877 URL: https://issues.apache.org/jira/browse/MINIFICPP-877 Project: Apache NiFi MiNiFi C++ Issue Type: Bug Reporter: Daniel Bakai Assignee: Daniel Bakai Fix For: 0.7.0 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
