Understood. Thanks!
Srikanth
On Fri, Sep 4, 2015 at 8:31 AM, Bryan Bende wrote:
> Srikanth,
>
> Sure... if you have two nifi instances, or clusters, you can send data
> between them using site-to-site communication. You can do a push or pull
> model, but lets say a push model...
> The receiving
Srikanth,
Sure... if you have two nifi instances, or clusters, you can send data
between them using site-to-site communication. You can do a push or pull
model, but lets say a push model...
The receiving nifi instance would have an Input Port on the graph, and the
sending nifi instance would have
Bryan,
That was my first thought too but then I felt I was over complicating it ;-)
I didn't realize such pattern was used in other processors.
If you don't mind, can you elaborate more on this...
> *"In a cluster you would likely set this up by having
> DistributeSolrCommand send to a Remote Pr
Here is a JIRA for it: https://issues.apache.org/jira/browse/NIFI-338
And a related one: https://issues.apache.org/jira/browse/NIFI-540
There may also be some discussion in the mailing list about it but I
think the main points are captured in those JIRA tickets.
Thanks
joe
On Thu, Sep 3, 2015 at
Joe,
Yes, that will be a really nice feature to have.
Is there a jira or wiki on the discussion you guys had on HA NCM?
Srikanth
On Wed, Sep 2, 2015 at 11:08 PM, Joe Witt wrote:
> <- general commentary not specific to the solr case ->
>
> This concept of being able to have nodes share informat
Srikanth/Joe,
I think I understand the scenario a little better now, and to Joe's points
- it will probably be clearer how to do this in a more generic way as we
work towards the High-Availability NCM.
Thinking out loud here given the current state of things, I'm wondering if
the desired function
<- general commentary not specific to the solr case ->
This concept of being able to have nodes share information about
'which partition' they should be responsible for is a generically
useful and very powerful thing. We need to support it. It isn't
immediately obvious to me how best to do this
Bryan,
* --> "I'm still a little bit unclear about the use case for
querying the shards individually... is the reason to do this because of a
performance/failover concern?"*
--> Reason to do this is to achieve better performance with the
convenience of automatic failover.
In the current mode, we
Srikanth,
Sorry you hadn't seen the reply, but hopefully you are subscribed to both
the dev and users list now :)
I'm still a little bit unclear about the use case for querying the shards
individually... is the reason to do this because of a performance/failover
concern? or is it something specif
Bryan,
That is correct, having the ability to query nodes with "distrib=false" is
what I was talking about.
Instead of user having to configure each Solr node in a separate NiFi
processor, can we provide a single configuration??
It would be great if we can take just Zookeeper(ZK) host as input fr
Hi Srikanth,
You are correct that in a NiFi cluster the intent would be to schedule
GetSolr on the primary node only (on the scheduling tab) so that only one
node in your cluster was extracting data.
GetSolr determines which SolrJ client to use based on the "Solr Type"
property, so if you select
11 matches
Mail list logo
