how to write date to redis

[L Robin]

Hello everyone,
Now I want write the flowfile data to redis,I use the ExecuteScript processor 
with python,buth the performance is too low,Who can give me some advice！

Thanks

[CALL FOR ACTION] Peer reviews & testing of new code

[Andre]

Dev,

Those following the git commit log probably noticed that there has been a
lot of action by some of the developers behind some significant
improvements in 1.2.0.

As these developers get busy I would like to remind the rest of the list
about importance of our contribution around code review and *testing* of
[proposed] changes to the NiFi code base.

So long history short. No matter if you have committer privilege to the
NiFi git, you can still contribute to this great community.

You can still contribute by providing extra testing of the introduced code
(I am myself running SNAPSHOT in prod-like conditions with the new
provenance WAL and it is so fast that I reckon you should be doing the
same...).


You can contribute by helping with the peer review process. [1]


So if you have some cycles available and is keen be more active in our
vibrant community, feel free to get involved!



Cheers!



[1] I admit that some of these PRs is daunting to the non-initiated (myself
included), but trust me when I say that some are perfectly within reach of
those that are familiar with NiFi and have also dealt with things like:
HDFS, Azure Cloud, Websockets, etc etc etc. (To be honest, sometimes the
contribution may be as simple as spell checking!!)

nifi-extension-utils

[Bryan Bende]

All,

As part of NIFI-3724 which was merged to master earlier today, I made
some slight refactoring to the organization of some utility code and
wanted to mention it in case anyone is wondering where things moved...

Previously under nifi-commons we had nifi-processor-utils and
nifi-hadoop-utils which had become places to put abstract processors
and processor related code. This type of utility code is a bit
different from the rest of nifi-commons which is completely
independent of anything under nifi-nar-bundles.

So I created nifi-extension-utils under nifi-nar-bundles to contain
code like abstract processors and things that need to reference
controller service APIs. The structure currently looks like the
following:

nifi-nar-bundles
- nifi-extension-utils
  - nifi-processor-utils
  - nifi-hadoop-utils
  - nifi-record-utils
- nifi-standard-record-utils
- nifi-avro-record-utils
- nifi-hadoop-record-utils

Going forward the goal would be for nifi-commons to be independent of
anything in nifi-nar-bundles.

After rebasing you may have the residual projects still under
nifi-commons and will want to clean up appropriately. "git clean -dn"
will dry run the clean and then "git clean -df" will delete it.

Thanks,

Bryan

Re: [DISCUSS] Component deprecation annotation

[Joseph Niemiec]

It would be really nice if this could be part of a summary or bulletin list
that an Admin/Ops could check frequently to find out if any of the tenants
on the NiFi service are using deprecated processors//controllers.

On Mon, May 1, 2017 at 8:24 AM, Rob Moran  wrote:

> I agree on treating these as we do restricted ones. I will work on some
> recommendations for a unique icon that the chooser dialog can display as
> well as how to best carry that over onto the canvas component.
>
> It would also be nice to suggest the alternative in the UI, for example
> when the user hovers the deprecated icon in the Add Processor dialog,
> specifically call out the alternative(s) by name.
>
> Rob
>
> On Apr 30, 2017 10:05 PM, "Andre"  wrote:
>
> All,
>
> Thank you for the feedback.
>
> I will extend the PR so that the required endpoints are in place but will
> leave the effective UI design to our UX experts.
>
> Hopefully I should be able to use the @Restricted as a basis for this work.
> Otherwise I will shout for some guidance.
>
> Cheers
>
>
> On Mon, May 1, 2017 at 11:23 AM, Joe Witt  wrote:
>
> > Agreed on both the icon being preferable as the vehicle to show this
> > for processors on the graph instead of color and also in emphasizing
> > this during processor selection.
> >
> > Thanks
> >
> > On Sun, Apr 30, 2017 at 7:21 PM, Matt Burgess 
> wrote:
> > > Visual indication on existing processors is a good thing, but IMO we'll
> > definitely need indication on the processor selection dialog, so the user
> > will know that we suggest they choose an alternative.
> > >
> > > Regards,
> > > Matt
> > >
> > >> On Apr 30, 2017, at 7:12 PM, Jeff  wrote:
> > >>
> > >> I think an icon on the processor would be best to denote an upcoming
> > >> deprecation.  That leaves all colors available to the flow design,
> since
> > >> any color may have specific meaning to any current flow out there.
> > >>
> > >>> On Sat, Apr 29, 2017 at 3:58 PM Juan Sequeiros 
> > wrote:
> > >>>
> > >>> In same train of though maybe make it default to some color other
> than
> > >>> white, instinct says red but that might be used to represent an
> > important
> > >>> processor. So suggest maybe default beige?
> > >>>
> > >>>
> > >>> On Sat, Apr 29, 2017 at 8:20 AM Andy LoPresto <
> > alopresto.apa...@gmail.com>
> > >>> wrote:
> > >>>
> >  I'd leave the graphics work/decisions to someone like Rob Moran, but
> I
> > >>> see
> >  it as similar to the restricted components -- an icon on the
> > processors
> > >>> on
> >  the canvas and the dialog to add components, with additional
> > explanation
> >  (and maybe a target release for full deprecation) in the help notes.
> > 
> >  Andy LoPresto
> >  alopre...@apache.org
> >  alopresto.apa...@gmail.com
> >  PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69
> > 
> > > On Apr 29, 2017, at 05:16, Andre  wrote:
> > >
> > > dev,
> > >
> > > In light of the some recent deprecations (ListenLumberjack) and
> some
> > > potential deprecation (PutJMS/GetJMS) I started some progress on
> how
> > to
> > > document the depreciation of NiFi components using annotations.
> > >
> > > In the absence of any better name I called the annotation
> > > @DeprecationWarning (so not overlap with Java's @Deprecated)
> > >
> > > The suggested modifications are part of PR#1718 and I am keen to
> hear
> >  your
> > > thoughts.
> > >
> > > While the documentation can be displayed as part of the usage,
> > however
> > >>> I
> > > would imagine the frequency a user browses to the usage pages will
> > >>> reduce
> > > as her/him becomes familiar with the components.
> > >
> > > In light of this it may be a good idea to use  the web UI to
> > highlight
> > >>> a
> > > processor has been deprecated.
> > >
> > > Would anyone suggest a way of doing so without disrupting the user
> > > experience?
> > >
> > > Cheers
> > 
> > >>>
> >
>



-- 
Joseph

Re: [DISCUSS] Component deprecation annotation

[Rob Moran]

I agree on treating these as we do restricted ones. I will work on some
recommendations for a unique icon that the chooser dialog can display as
well as how to best carry that over onto the canvas component.

It would also be nice to suggest the alternative in the UI, for example
when the user hovers the deprecated icon in the Add Processor dialog,
specifically call out the alternative(s) by name.

Rob

On Apr 30, 2017 10:05 PM, "Andre"  wrote:

All,

Thank you for the feedback.

I will extend the PR so that the required endpoints are in place but will
leave the effective UI design to our UX experts.

Hopefully I should be able to use the @Restricted as a basis for this work.
Otherwise I will shout for some guidance.

Cheers


On Mon, May 1, 2017 at 11:23 AM, Joe Witt  wrote:

> Agreed on both the icon being preferable as the vehicle to show this
> for processors on the graph instead of color and also in emphasizing
> this during processor selection.
>
> Thanks
>
> On Sun, Apr 30, 2017 at 7:21 PM, Matt Burgess  wrote:
> > Visual indication on existing processors is a good thing, but IMO we'll
> definitely need indication on the processor selection dialog, so the user
> will know that we suggest they choose an alternative.
> >
> > Regards,
> > Matt
> >
> >> On Apr 30, 2017, at 7:12 PM, Jeff  wrote:
> >>
> >> I think an icon on the processor would be best to denote an upcoming
> >> deprecation.  That leaves all colors available to the flow design,
since
> >> any color may have specific meaning to any current flow out there.
> >>
> >>> On Sat, Apr 29, 2017 at 3:58 PM Juan Sequeiros 
> wrote:
> >>>
> >>> In same train of though maybe make it default to some color other than
> >>> white, instinct says red but that might be used to represent an
> important
> >>> processor. So suggest maybe default beige?
> >>>
> >>>
> >>> On Sat, Apr 29, 2017 at 8:20 AM Andy LoPresto <
> alopresto.apa...@gmail.com>
> >>> wrote:
> >>>
>  I'd leave the graphics work/decisions to someone like Rob Moran, but
I
> >>> see
>  it as similar to the restricted components -- an icon on the
> processors
> >>> on
>  the canvas and the dialog to add components, with additional
> explanation
>  (and maybe a target release for full deprecation) in the help notes.
> 
>  Andy LoPresto
>  alopre...@apache.org
>  alopresto.apa...@gmail.com
>  PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69
> 
> > On Apr 29, 2017, at 05:16, Andre  wrote:
> >
> > dev,
> >
> > In light of the some recent deprecations (ListenLumberjack) and some
> > potential deprecation (PutJMS/GetJMS) I started some progress on how
> to
> > document the depreciation of NiFi components using annotations.
> >
> > In the absence of any better name I called the annotation
> > @DeprecationWarning (so not overlap with Java's @Deprecated)
> >
> > The suggested modifications are part of PR#1718 and I am keen to
hear
>  your
> > thoughts.
> >
> > While the documentation can be displayed as part of the usage,
> however
> >>> I
> > would imagine the frequency a user browses to the usage pages will
> >>> reduce
> > as her/him becomes familiar with the components.
> >
> > In light of this it may be a good idea to use  the web UI to
> highlight
> >>> a
> > processor has been deprecated.
> >
> > Would anyone suggest a way of doing so without disrupting the user
> > experience?
> >
> > Cheers
> 
> >>>
>