In case it helps, Matt B was nice enough to quickly put up a PR for
the API change discussed yesterday:
https://github.com/apache/nifi/pull/2658
Once this is tested and merged it make it would make it easier to
implement Charlie's approach without needing a new interface.
On Thu, Apr 26, 2018
Hello,
I'm working to see what we can share, but for a start, here is how we
handle the delegating controller service:
package com.civitaslearning.nifi.service.impl;
import org.apache.nifi.components.PropertyDescriptor;
import org.apache.nifi.controller.AbstractControllerService;
import
Hi Charlie,
Thanks for the reply. It seems that you already have a solution to my
problem. If possible, can you please share you code for the custom
controller service and the custom processor?
-
RP
--
Sent from: http://apache-nifi-developer-list.39713.n7.nabble.com/
Yes, this was just one idea based on Charlie's solution.
I'm not saying that approach solves the original request in this
email, I was just saying its another nice idea that could be easily
implemented once we make the changes in the JIRA.
There can be as many "dynamic" DBCPService
Okay.. but two questions:
1. We are passing the attribute 'db.id' that means, we'll be using
'UpdateAttribute' to do add that attribute to flowfile?
2. If we are to use 'UpdateAttribute' to set the value for 'db.id', we
need to know before hand, right?
-
Sivaprasanna
On Wed, Apr
Charlie,
That is a really nice solution, thanks for sharing.
If we make the API changes in that JIRA I just sent, I could see
having a new implementation of DBCPService that does something very
similar.
Basically there could be "DelegatingDBCPService" which still
implemented the same
Chiming in a bit late on this, but we faced this same issue and got around
it by implementing a custom controller service which acts as a "router" to
different dbcp services. It exposes a method which given a uuid, returns
back the DBCPservice that corresponds with that uuid if it exists using
Here is a proposal for how to modify the existing API to support both scenarios:
https://issues.apache.org/jira/browse/NIFI-5121
The scope of that ticket would be to make the interface change, and
then update all of NiFi's DB processors to pass in the attribute map.
Then a separate effort to
To Otto's question...
For simplicity sake, there is a new implementation of
DBCPConnectionPool that behind the scenes has two connection pools,
one for DB A and one for DB B, it doesn't matter how these are
configured.
Now a flow file comes into the ExecuteSQL and it goes to
Option 2 and 3 seem to be a probable approach. However creating varying
number of connections based on *each* flowfile still sounds to be
suboptimal. If the requirement still demands to take that road, then it’s
better to do some prep-work.. as in the list of probable connections that
are required
If any controller service optionally supported this external service ( like
the AWS processors optional support the credentials service )
then there is no need for the processor to change though right?
On April 25, 2018 at 08:37:50, Bryan Bende (bbe...@gmail.com) wrote:
The issue here is more
Or you could just call every time you needed properties more likely.
This would still be custom unless integrated….
On April 25, 2018 at 08:26:57, Otto Fowler (ottobackwa...@gmail.com) wrote:
Can services work with other controller services?
Maybe a PropertiesControllerService,
Can services work with other controller services?
Maybe a PropertiesControllerService, FilePropertiesControllerService could
work with your service?
the PCS could fire events on property changes etc.
On April 25, 2018 at 08:05:27, Mike Thomsen (mikerthom...@gmail.com) wrote:
Shot in the dark
Shot in the dark here, but what you try to do is create a custom connection
pool service that uses dynamic properties to build a "pool of connection
pools." You could then use the property names as hints for where to send
the queries.
On Wed, Apr 25, 2018 at 6:19 AM Rishab Prasad
Hello,
Others who have worked on the DB related services and processors can
correct me if I'm wrong here, but...
In general the idea of a connection pool is that creating connections
is somewhat expensive, and for a high-volume of operations you don't
want to create a connection for each DB
Varun,
You didn't say what type of database is it. Can you share that info?
On Thu, Mar 8, 2018 at 1:15 AM, varun yadav
wrote:
> Hii,
>
> I am trying to create a custom controller service for connection to a local
> database.
> I am getting so many issues in that. If
Varun,
Bryan Bende has a github repo with examples[1] as well as nifi.rocks[2] has
an example.
Thanks,
Chad
1. https://github.com/bbende/nifi-dependency-example
2. http://nifi.rocks/developing-a-custom-apache-nifi-controller-service/
On Thu, Mar 8, 2018 at 1:47 AM Sivaprasanna
Hey Varun,
It would br helpful if you could share the error stacktrace. By the way,
you can use DBCP Connection Pool for connecting to databases.
On Thu, 8 Mar 2018 at 12:14 PM, varun yadav
wrote:
> Hii,
>
> I am trying to create a custom controller service for
Matt and Bryan,
Thanks for the detailed explanation. The class loading aspect makes
perfect sense, and yes, importing as disabled is understood as well.
I do think I've come across a small bug with automatically creating
Controller Services on template imports though. NiFi is not automatically
Brian,
I see the same behavior regarding Controller Service creation when
referenced by Processor's in sub Groups. Please file the JIRA ticket and it
will be addressed in our release. Thanks!
Matt
On Fri, Aug 14, 2015 at 11:30 AM, Brian Ghigiarelli briang...@gmail.com
wrote:
Matt and Bryan,
20 matches
Mail list logo