Thank you all for your insights. I opted to drop back and take a slightly
different approach, since statvfs was problematic.I created a pyt... a
jython function that employs subprocess.Popen against an argument I pass in
for deviceToCheck. My NiFi jython environment seems to allow the
subprocess.Popen. Not sure too many folks have the requirement to check
device usage before running a workflow, but in case you do this is an
inelegant but effective means to get the info:

deviceToCheck = 'content_repo'

In the function:
p1 = subprocess.Popen(["df","-hk"],stdout=subprocess.PIPE)
next_command = ["egrep",
                             "{}".format(deviceToCheck)]
p2 =subprocess.Popen(next_command, stdin=p1.stdout,stdout=subprocess.PIPE)
p1.stdout.close()
result = (p2.communicate()[0]).split()[-2].translate(None,'%')
p2.stdout.close()
I then compare this to my minimum capacity required threshold and return a
True or a False.

Thanks again for your assistance. -Jim

On Mon, Apr 16, 2018 at 9:27 AM, Mike Thomsen <mikerthom...@gmail.com>
wrote:

> James,
>
> The reason you can't use "Python" is because the scripting bundle only
> works with JVM-based scripting languages like JRuby, Jython and Groovy.
> Java 6 introduced javax.script which is a package that adds a standard API
> for calling JVM scripting languages from a Java app.
>
> From from overcomplicating it, this is what simplifies the support for
> multiple scripting languages without getting into solutions like Py4j or
> doing weird things with inter-process communication like the Python API for
> Storm.
>
> On Sun, Apr 15, 2018 at 8:35 AM James McMahon <jsmcmah...@gmail.com>
> wrote:
>
>> I'm not sure I understand. The ExecuteScript processor forces me into a
>> Jython environment - despite selecting Python as the scripting language in
>> the processor configuration. I'll never understand why that route was opted
>> for in the first place. Why overcomplicate this, introducing yet another
>> dependency (on Jython)? Let the selection of python as the script language
>> use the installed python on my server, and decouple me from any Jython
>> dependencies. It's been nothing but trouble. Python code that works just
>> fine from the command line fails for all manner of issues with Jython when
>> I call it from ExecuteScript.
>>
>> I gather you've called Flask-driven python microservices from NiFi. What
>> NiFi processor allows you to do that? I'll look into Flask-driven
>> microservices now, and am certainly willing to try this. Thanks very much.
>>
>> On Sat, Apr 14, 2018 at 12:25 PM, Mike Thomsen <mikerthom...@gmail.com>
>> wrote:
>>
>>> From a lot of your posts, it seems like you're running into the same
>>> sort of problem that some of my colleagues ran into with Jython. The fact
>>> is that Jython is just not well supported by the Python community, and it's
>>> going to keep getting worse as Python 2.X EOL deadline in 2020 (IIRC) gets
>>> closer. As a Python developer, I think you might find it a lot easier to
>>> switch to Python 3 for your code and turn these scripts into Flask-driven
>>> microservices that are called by NiFi.
>>>
>>> Mike
>>>
>>> On Fri, Apr 13, 2018 at 5:47 PM James McMahon <jsmcmah...@gmail.com>
>>> wrote:
>>>
>>>> No sir. When I run from the command line - I encapsulate
>>>> script-specific command sequences in  code triggered by SCRIPT var value,
>>>> and NiFi sequences encapsulated within NIFI var values - it runs in a
>>>> Python environment. I attempted jython -V at the command line, and it was
>>>> unable to find an installation of jython independent of that which comes
>>>> embedded in NiFi 0.7.1.c.
>>>>
>>>> Assuming that I am operating in a Jython 2.7.0 environment when in
>>>> NiFi, are there specific libraries or packages I should import to get it to
>>>> recognize what seem to be very fundamental os package commands? Is it
>>>> possible to override the use of the jython packages that I suspect are
>>>> missing, and force it to use the python packages that I know are there?
>>>>
>>>> If I must abandon os.statvfs to get this to work in NiFi, have you seen
>>>> anyone harvest disk usage information from any native NiFi processors? My
>>>> thinking is this: if I can't climb the Jython mountain, maybe I can precede
>>>> my ExecuteScript processor with something that does this check in advance.
>>>> I would then rip these calls out of my python script (NIFI sections).
>>>>
>>>> Jim
>>>>
>>>> On Fri, Apr 13, 2018 at 2:59 PM, Joe Witt <joe.w...@gmail.com> wrote:
>>>>
>>>>> Independent of NiFi have you successfully used any version of Jython
>>>>> to make that call?
>>>>>
>>>>> With the NiFi 1.x line that processor has been updated a little bit
>>>>> and in particular i think we have Jython 2.7.1 (off memory so could be
>>>>> totally nonsense) where as before we had 2.7.0 or something older...
>>>>>
>>>>> Thanks
>>>>>
>>>>> On Fri, Apr 13, 2018 at 6:37 PM, James McMahon <jsmcmah...@gmail.com>
>>>>> wrote:
>>>>> > Good afternoon. I am running a python script from an ExecuteScript
>>>>> processor
>>>>> > in NiFi 0.7.1.c. I'm assuming this is actually running in a Jython
>>>>> > environment under the hood of the processor.
>>>>> >
>>>>> > General question: How can I tell what version of Jython i am
>>>>> employing?
>>>>> >
>>>>> > Specific problem: I employ an os.statvfs call to check available
>>>>> capacity on
>>>>> > my disk devices that host my content repo, and that host my data
>>>>> landing
>>>>> > zone. In my command line environment - not jython - Python has this
>>>>> library
>>>>> > and so I can successfully make this call.
>>>>> >
>>>>> > In NiFi, I get this error at run time:
>>>>> >
>>>>> > javax.script.ScriptException: AttributeError: 'module' object has no
>>>>> > attribute ;statvfs'
>>>>> >
>>>>> > How can I correct this? I am happy to replace it if necessary with
>>>>> something
>>>>> > Jython provides, but don't fully understand the Jython environment
>>>>> within
>>>>> > NiFi. Is there a suitable Jython equivalent to fix this problem? What
>>>>> > package or module must i include in my script to get at that?
>>>>> >
>>>>> > Thanks in advance for your help.
>>>>> >
>>>>> > Jim
>>>>>
>>>>
>>

Reply via email to