If you're on a linux system, a alternative i've used in the past is to
create another directory, full of symlinks pointing to the original
directory.
As an example, assuming you have a directory: /data/input_files/ full of
files, create a directory /data/input_links/, and from that new directory,
Github user olegz commented on the pull request:
https://github.com/apache/nifi/pull/123#issuecomment-157029989
@trkurc @joewitt @apiri
Guys, please see the latest commit. Didn't squash it, so its easier to read
and see what's been addressed. In summary:
1. Since based on the
re: NIFI-1165 I also have a windows 7 laptop I can test on. (though it is
low power)
On Sun, Nov 15, 2015 at 10:48 AM, Aldrin Piri wrote:
> I have another set of eyes for NIFI-748. Will do so now.
>
> On Sun, Nov 15, 2015 at 10:39 AM, Tony Kurc wrote:
>
> > For those not watching commits@nifi
Oooh, neat idea Salvatore. +1 to creativity. Really interesting.
Adam
On Mon, Nov 16, 2015 at 6:25 AM, Salvatore Papa
wrote:
> If you're on a linux system, a alternative i've used in the past is to
> create another directory, full of symlinks pointing to the original
> directory.
>
> As an ex
Github user naveenmadhire closed the pull request at:
https://github.com/apache/nifi/pull/125
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is
Github user naveenmadhire commented on the pull request:
https://github.com/apache/nifi/pull/125#issuecomment-157086151
Closing the pull request. As I've messed up with the commits. I will open a
new one soon. Sorry for the trouble.
---
If your project is set up for it, you can reply
Per NiFi-1165: a discussion is occurring on the ticket:
https://issues.apache.org/jira/browse/NIFI-1165
Overall, most of the issues are identified and pending a fix from Mark, Oleg
and I. The issues were encountered on two different windows 8 machines by me
and on windows 2012 R2 by Mark.
Github user trkurc commented on the pull request:
https://github.com/apache/nifi/pull/123#issuecomment-157122546
I'm mostly okay with package private. On the off chance someone was using
this API it will be marginally more challenging to adapt to this change, but is
possible.
---
I
GitHub user olegz opened a pull request:
https://github.com/apache/nifi/pull/126
NIFI-1164 decreased the chances of race condition
Removed checks for 'if (getState() != ControllerServiceState.DISABLED)â
from StandardControllerServiceNode.verifyCanEnable(..) operations based on the
Github user jskora commented on a diff in the pull request:
https://github.com/apache/nifi/pull/121#discussion_r44967382
--- Diff:
nifi-nar-bundles/nifi-aws-bundle/nifi-aws-processors/src/main/java/org/apache/nifi/processors/aws/s3/PutS3ObjectMultipart.java
---
@@ -0,0 +1,550 @@
Github user jskora commented on a diff in the pull request:
https://github.com/apache/nifi/pull/121#discussion_r44967657
--- Diff:
nifi-nar-bundles/nifi-aws-bundle/nifi-aws-processors/src/main/java/org/apache/nifi/processors/aws/s3/PutS3ObjectMultipart.java
---
@@ -0,0 +1,550 @@
Github user markap14 commented on the pull request:
https://github.com/apache/nifi/pull/125#issuecomment-157140757
@naveenmadhire no trouble at all :) Looking forward to the new pull request.
---
If your project is set up for it, you can reply to this email and have your
reply appear
GitHub user naveenmadhire opened a pull request:
https://github.com/apache/nifi/pull/127
NIFI-1146 Allow GetKafka to be configured with auto.offset.reset to
"largest" or "smallest"
Pull request with changes.
@markap14 I removed the writeAttributes ones, since there is no need
Github user markap14 commented on a diff in the pull request:
https://github.com/apache/nifi/pull/126#discussion_r44975323
--- Diff:
nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-framework-core/src/main/java/org/apache/nifi/controller/service/StandardControllerServiceProvi
Github user olegz commented on a diff in the pull request:
https://github.com/apache/nifi/pull/126#discussion_r44976221
--- Diff:
nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-framework-core/src/main/java/org/apache/nifi/controller/service/StandardControllerServiceProvider
I am trying to extract data into attribute using EvaluateJsonPath. when what
JsonPath return complex type, I am getting error: Unable to return a scalar
value for the expression $['data'] for FlowFile 152. Evaluated value was
{id=1…..}. Transferring to failure
data - $.data <— Error
id
Sumo,
The scalar option has the processor looking for the resultant value of the
expression to provide a non-Map/List representation of the targeted
expression. In this case, if you change the property to json, it should
work as anticipated. The property itself is more of a validation of the
dat
Thanks Aldrin.
it works after I changed Return Type to JSON.
> On Nov 16, 2015, at 12:47 PM, Aldrin Piri wrote:
>
> Sumo,
>
> The scalar option has the processor looking for the resultant value of the
> expression to provide a non-Map/List representation of the targeted
> expression. In this
Github user olegz commented on the pull request:
https://github.com/apache/nifi/pull/126#issuecomment-157173562
Pulling back, see comments in JIRA
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not h
Github user olegz closed the pull request at:
https://github.com/apache/nifi/pull/126
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled
The documentation is a little unclear and light. Made a ticket [1] to
clarify how these properties are interpreted.
Thanks!
[1] https://issues.apache.org/jira/browse/NIFI-1177
On Mon, Nov 16, 2015 at 3:52 PM, Sumanth Chinthagunta
wrote:
> Thanks Aldrin.
> it works after I changed Return Type
Github user asfgit closed the pull request at:
https://github.com/apache/nifi/pull/127
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enable
Github user markap14 commented on the pull request:
https://github.com/apache/nifi/pull/127#issuecomment-157179517
@naveenmadhire - code looks good. Builds without problem, and testing on my
Kafka instance shows the expected results. Nice work! And thanks for the
contribution. On beha
Github user markap14 commented on the pull request:
https://github.com/apache/nifi/pull/123#issuecomment-157182575
@trkurc Personally, I have exactly 0 qualms about changing it to package
private. If I choose to take some random util class from a release of Apache
Tomcat, for example
Github user markap14 commented on a diff in the pull request:
https://github.com/apache/nifi/pull/123#discussion_r44989850
--- Diff:
nifi-nar-bundles/nifi-provenance-repository-bundle/nifi-persistent-provenance-repository/src/main/java/org/apache/nifi/provenance/lucene/DocsReader.java
Github user naveenmadhire commented on the pull request:
https://github.com/apache/nifi/pull/127#issuecomment-157187138
@markap14 Thanks. I will see if there are any other issues which I can work
on. ;)
---
If your project is set up for it, you can reply to this email and have your
r
Github user trkurc commented on a diff in the pull request:
https://github.com/apache/nifi/pull/116#discussion_r44999861
--- Diff:
nifi-nar-bundles/nifi-update-attribute-bundle/nifi-update-attribute-processor/src/main/java/org/apache/nifi/processors/attributes/UpdateAttribute.java
---
Github user trkurc commented on the pull request:
https://github.com/apache/nifi/pull/116#issuecomment-157213254
@jskora what would you expect the following unit tests to do?
```
@Test
public void testInvalidRegex() {
final TestRunner runner = TestRu
Github user trkurc commented on the pull request:
https://github.com/apache/nifi/pull/116#issuecomment-157218572
I think what I'm getting at is that I think having a property that requires
the expression to evaluate to a valid regex might mean it is time for a failure
relationship for
Guys
I am noticing many modules where we have things like "new Thread(..).start()”,
creation of new executors and schedulers, Thread.sleep(..) etc.,. I am sure
many would agree that taking such liberties with Threads will have consequences
(not IF but WHEN)
On several threads several of us men
Github user olegz commented on the pull request:
https://github.com/apache/nifi/pull/124#issuecomment-157221978
General question primarily for NiFi leadership team. JSoup MIT License -
http://jsoup.org/license
Are there any conflicts?
---
If your project is set up for it, you can
Github user joewitt commented on the pull request:
https://github.com/apache/nifi/pull/124#issuecomment-15742
MIT is perfectly fine both for source and binary dependency. Details can
be found here with links to all sorts of goodness
"https://nifi.apache.org/licensing-guide.html";
Github user olegz commented on a diff in the pull request:
https://github.com/apache/nifi/pull/124#discussion_r45008293
--- Diff: nifi-nar-bundles/nifi-html-bundle/nifi-html-processors/pom.xml ---
@@ -0,0 +1,59 @@
+
+
+http://maven.apache.org/POM/4.0.0";
xmlns:xsi="http
the issue with a best practices guide on this subject is it will be
dominated by edge cases. The common case should be "don't produce any
threads".
That being said, I commented on a jira somewhere about LinkedBlockingQueues
used in so many producer/consumer style processors and possibly needing a
Taking liberties - so let me throw few example. I am sure you’d agree that
Thread creation and management is an expensive and hard and error prone, hence
new java.util.concurrent and all the goodies in it.
- There is a patch currently in the queue where there is a creation of new
Thread() and t
so, I believe threads in a processor in nifi are much, much easier than
general threading in many other applications. There are defined boundaries
on when a processor is built and torn down. Pretty much any state in the
middle is up to the processor. you know when resources need to be stood up.
you
Is there a common use case for a single extra thread? I'm asking in ignorance
but if the answer is yes then I'd think there'd be best practices around that?
Regards,
Matt
Sent from my iPhone
> On Nov 16, 2015, at 8:22 PM, Tony Kurc wrote:
>
> so, I believe threads in a processor in nifi are m
Tony, thanks for your input. At least we have some discussion going. See in
line for the rest.
> On Nov 16, 2015, at 8:22 PM, Tony Kurc wrote:
>
> so, I believe threads in a processor in nifi are much, much easier than
> general threading in many other applications. There are defined boundaries
The only one I've seen is the catch 22 where you need to shut down executor
from the task executed by this executor. So in this case you have no choice but
to create a Thread and start it
Sent from my iPhone
> On Nov 16, 2015, at 20:33, Matt Burgess wrote:
>
> Is there a common use case for a
So back in the day...
Here is the thought process behind how it works today at a high level
and taking some generalities. Developers of extensions, and that
primarily means processors, begin process sessions. In a process
session a processor can access, create, destroy zero or more flow
files an
Github user jskora commented on the pull request:
https://github.com/apache/nifi/pull/116#issuecomment-157265254
Interesting. Before I enabled EL support, it had a
REGULAR_EXPRESSION_VALIDATOR which would have caught those. Is there a way to
validate a property that supports express
Github user apiri commented on the pull request:
https://github.com/apache/nifi/pull/116#issuecomment-157265218
@trkurc I am onboard with what you are driving toward. I had created an
issue around the same thought process.
https://issues.apache.org/jira/browse/NIFI-813
The co
Github user trkurc commented on the pull request:
https://github.com/apache/nifi/pull/116#issuecomment-157266419
@jskora as @apiri pointed out, i think that we may have to live with the
problem until NIFI-813 is resolved. I tried wrapping my head around a validator
that handled the fi
Github user trkurc commented on the pull request:
https://github.com/apache/nifi/pull/116#issuecomment-157266895
@apiri you have some history with this - what is a greater evil, no el
support or possibly breaking? this is already a processor that appears to have
a "beware of el" sign
Github user jskora commented on the pull request:
https://github.com/apache/nifi/pull/116#issuecomment-157272302
@trkurc, this is not a problem fix but an enhancement based on discussion
that occurred on [NIFI-641|https://issues.apache.org/jira/browse/NIFI-641]. It
seemed easy enough
45 matches
Mail list logo