Re-entrant and multi-entrant Groovy calls

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Re-entrant and multi-entrant Groovy calls

Blake McBride
Greetings,

Does Groovy safely support re-entrant and multi-entrant calls?  What I mean by that is the following:

Re-entrant:  on a single OS thread - my Java program calls into Groovy, then Groovy calls into my Java application, and then the Java application calls back into Groovy.  So the stack has Java, Groovy, JAVA, and then Groovy again.

Multi-entrant:  my Java application has many threads.  One of my threads calls into Groovy.  Then, while one thread is still in Groovy, another thread evokes Groovy.  So now we have two calls into Groovy by two independent Java/OS threads running at the same time.

I understand the typical problems associated with application-level shared variables.  This is expected.  The question revolves around Groovy's internals.  I presume Groovy may have some shared data that is internal to Groovy.  That's what I am unclear about.  Groovy would have had to be designed for these scenarios from the ground up.

This is a little hard to test because if it can't always correctly handle these situations, it may not become clear until certain scenarios arrive.  It may be hard for any "test" program I write to cause those scenarios, so I thought this may be a known answer.

Thanks!

Blake McBride

Reply | Threaded
Open this post in threaded view
|

Re: Re-entrant and multi-entrant Groovy calls

Jochen Theodorou


Am 20.04.2018 um 11:21 schrieb Blake McBride:

> Greetings,
>
> Does Groovy safely support re-entrant and multi-entrant calls?  What I
> mean by that is the following:
>
> Re-entrant:  on a single OS thread - my Java program calls into Groovy,
> then Groovy calls into my Java application, and then the Java
> application calls back into Groovy.  So the stack has Java, Groovy,
> JAVA, and then Groovy again.
>
> Multi-entrant:  my Java application has many threads.  One of my threads
> calls into Groovy.  Then, while one thread is still in Groovy, another
> thread evokes Groovy.  So now we have two calls into Groovy by two
> independent Java/OS threads running at the same time.

this is actually difficult to answer. The runtime system is designed to
be safe for multi entrant usages (minus bugs of course). But just like
in Java that does not mean all parts of the API are safe for this usage,
not even groovy.lang

bye Jochen
Reply | Threaded
Open this post in threaded view
|

Re: Re-entrant and multi-entrant Groovy calls

Blake McBride
Thanks.  Speaking of Java alone, I understand that many Java API's are not thread safe.  That's fine.  However, with respect to Java alone, I can have any number of threads and so long as no thread touches the same (application) variables at the same time, I'm always safe.

I understand that I must take this into account when using Groovy too.  My problem is that I don't know if Groovy has some internal stuff that will break even if I have no application variable problems.

Thanks.

Blake McBride


On Fri, Apr 20, 2018 at 6:34 AM, Jochen Theodorou <[hidden email]> wrote:


Am 20.04.2018 um 11:21 schrieb Blake McBride:
Greetings,

Does Groovy safely support re-entrant and multi-entrant calls?  What I mean by that is the following:

Re-entrant:  on a single OS thread - my Java program calls into Groovy, then Groovy calls into my Java application, and then the Java application calls back into Groovy.  So the stack has Java, Groovy, JAVA, and then Groovy again.

Multi-entrant:  my Java application has many threads.  One of my threads calls into Groovy.  Then, while one thread is still in Groovy, another thread evokes Groovy.  So now we have two calls into Groovy by two independent Java/OS threads running at the same time.

this is actually difficult to answer. The runtime system is designed to be safe for multi entrant usages (minus bugs of course). But just like in Java that does not mean all parts of the API are safe for this usage, not even groovy.lang

bye Jochen

Reply | Threaded
Open this post in threaded view
|

Re: Re-entrant and multi-entrant Groovy calls

Wolfgang Pedot
In reply to this post by Blake McBride
For Groovy-scripts you need to know that each instance of a script has a
Binding to store variables in it and that may cause re-entrance or
concurrency issues if you dont create a new script instance for each call.

Wolfgang

Am 20.04.2018 um 11:21 schrieb Blake McBride:

> Greetings,
>
> Does Groovy safely support re-entrant and multi-entrant calls? What I
> mean by that is the following:
>
> Re-entrant: on a single OS thread - my Java program calls into Groovy,
> then Groovy calls into my Java application, and then the Java
> application calls back into Groovy. So the stack has Java, Groovy,
> JAVA, and then Groovy again.
>
> Multi-entrant: my Java application has many threads.  One of my
> threads calls into Groovy. Then, while one thread is still in Groovy,
> another thread evokes Groovy. So now we have two calls into Groovy by
> two independent Java/OS threads running at the same time.
>
> I understand the typical problems associated with application-level
> shared variables.  This is expected.  The question revolves around
> Groovy's internals.  I presume Groovy may have some shared data that
> is internal to Groovy. That's what I am unclear about. Groovy would
> have had to be designed for these scenarios from the ground up.
>
> This is a little hard to test because if it can't always correctly
> handle these situations, it may not become clear until certain
> scenarios arrive.  It may be hard for any "test" program I write to
> cause those scenarios, so I thought this may be a known answer.
>
> Thanks!
>
> Blake McBride
>

Reply | Threaded
Open this post in threaded view
|

Re: Re-entrant and multi-entrant Groovy calls

Kerridge, Jon
In reply to this post by Blake McBride

I have intermixed Groovy and JCSP easily and reliably, but not at the low-level thread level. 


I use two libraries JCSP (CSP for Java) which provides a process based interface that enables the construction of multiprocess applications, either on a multi-core machine or on a cluster of multi-core machines. 


In addition I have created a set of Groovy helper classes, groovyJCSP, that create a much simpler user enviroment to the underlying JCSP library.  These libraries have been used for more than 10 years, mostly in teaching but also to undertake large scale application development. 


My github account has these libraries available (https://github.com/JonKerridge), which has examples of the use of the library including much higher level management of access to shared variables, including access to partitioned data structures such that two processes can read all the data but only one can write to a specific partition.


Jon

Professor Jon Kerridge
School of Computing
Edinburgh Napier University
Merchiston Campus
Edinburgh EH10 5DT
 
0131 455 2777
 

From: Blake McBride <[hidden email]>
Sent: 20 April 2018 12:45:31
To: [hidden email]
Subject: Re: Re-entrant and multi-entrant Groovy calls
 
Thanks.  Speaking of Java alone, I understand that many Java API's are not thread safe.  That's fine.  However, with respect to Java alone, I can have any number of threads and so long as no thread touches the same (application) variables at the same time, I'm always safe.

I understand that I must take this into account when using Groovy too.  My problem is that I don't know if Groovy has some internal stuff that will break even if I have no application variable problems.

Thanks.

Blake McBride


On Fri, Apr 20, 2018 at 6:34 AM, Jochen Theodorou <[hidden email]> wrote:


Am 20.04.2018 um 11:21 schrieb Blake McBride:
Greetings,

Does Groovy safely support re-entrant and multi-entrant calls?  What I mean by that is the following:

Re-entrant:  on a single OS thread - my Java program calls into Groovy, then Groovy calls into my Java application, and then the Java application calls back into Groovy.  So the stack has Java, Groovy, JAVA, and then Groovy again.

Multi-entrant:  my Java application has many threads.  One of my threads calls into Groovy.  Then, while one thread is still in Groovy, another thread evokes Groovy.  So now we have two calls into Groovy by two independent Java/OS threads running at the same time.

this is actually difficult to answer. The runtime system is designed to be safe for multi entrant usages (minus bugs of course). But just like in Java that does not mean all parts of the API are safe for this usage, not even groovy.lang

bye Jochen

This message and its attachment(s) are intended for the addressee(s) only and should not be read, copied, disclosed, forwarded or relied upon by any person other than the intended addressee(s) without the permission of the sender. If you are not the intended addressee you must not take any action based on this message and its attachment(s) nor must you copy or show them to anyone. Please respond to the sender and ensure that this message and its attachment(s) are deleted.

It is your responsibility to ensure that this message and its attachment(s) are scanned for viruses or other defects. Edinburgh Napier University does not accept liability for any loss or damage which may result from this message or its attachment(s), or for errors or omissions arising after it was sent. Email is not a secure medium. Emails entering Edinburgh Napier University's system are subject to routine monitoring and filtering by Edinburgh Napier University.

Edinburgh Napier University is a registered Scottish charity. Registration number SC018373

Reply | Threaded
Open this post in threaded view
|

Re: Re-entrant and multi-entrant Groovy calls

Blake McBride
In reply to this post by Wolfgang Pedot
Every time I call Groovy from Java I do the following code snippets.  Does this have the problem you are referring to?

public void runGroovy(String fileName) { 
    JSONObject injson = ...
    JSONObject outjson = ...
    HibernateSessionUtil hsu = ...

GroovyClass gclass = loadClass(fileName, true);
if (gclass != null) {
Class[] ca = {
JSONObject.class,
JSONObject.class,
HibernateSessionUtil.class,
HTMLFlex.class
};

try {
@SuppressWarnings("unchecked")
Method methp = gclass.getMethod(_method, ca);
if (methp == null) {
errorReturn(response, "Method " + _method + " not found in class " + this.getClass().getName(), null);
return;
}
methp.invoke(null, injson, outjson, hsu, this);
} catch (Exception e) {
errorReturn(response, "Error running method " + _method + " in class " + this.getClass().getName(), e);
return;
}
} else {
errorReturn(response, "Error loading " + fileName, null);
return;
}
}
public synchronized static GroovyClass loadClass(String fileName, boolean report) {
GroovyClass gclass;
[some class cacheing code]
try {
gclass =
new GroovyClass(false, fileName);
classCache.put(fileName, new ClassInfo(gclass, (new File(fileName)).lastModified()));
}
catch (FileNotFoundException e) {
if (report)
logger.error("File " + fileName + " not found", e);
return null;
}
catch (Exception e) {
if (report)
logger.error("Error loading " + fileName, e);
return null;
}
return gclass;
}


On Fri, Apr 20, 2018 at 7:15 AM, Wolfgang Pedot <[hidden email]> wrote:
For Groovy-scripts you need to know that each instance of a script has a Binding to store variables in it and that may cause re-entrance or concurrency issues if you dont create a new script instance for each call.

Wolfgang


Am 20.04.2018 um 11:21 schrieb Blake McBride:
Greetings,

Does Groovy safely support re-entrant and multi-entrant calls? What I mean by that is the following:

Re-entrant: on a single OS thread - my Java program calls into Groovy, then Groovy calls into my Java application, and then the Java application calls back into Groovy. So the stack has Java, Groovy, JAVA, and then Groovy again.

Multi-entrant: my Java application has many threads.  One of my threads calls into Groovy. Then, while one thread is still in Groovy, another thread evokes Groovy. So now we have two calls into Groovy by two independent Java/OS threads running at the same time.

I understand the typical problems associated with application-level shared variables.  This is expected.  The question revolves around Groovy's internals.  I presume Groovy may have some shared data that is internal to Groovy. That's what I am unclear about. Groovy would have had to be designed for these scenarios from the ground up.

This is a little hard to test because if it can't always correctly handle these situations, it may not become clear until certain scenarios arrive.  It may be hard for any "test" program I write to cause those scenarios, so I thought this may be a known answer.

Thanks!

Blake McBride



Reply | Threaded
Open this post in threaded view
|

Re: Re-entrant and multi-entrant Groovy calls

Wolfgang Pedot
I dont know, your code looks like it is calling a static method on a class.

What I was referring to was using something like
GroovyScriptEngine.createScript and reusing the returned Script-Object.

Wolfgang

Am 20.04.2018 um 14:32 schrieb Blake McBride:

> Every time I call Groovy from Java I do the following code snippets. 
> Does this have the problem you are referring to?
>
> public void runGroovy(String fileName) {
>      JSONObject injson = ...
>      JSONObject outjson = ...
>      HibernateSessionUtil hsu = ...
>
>      GroovyClass gclass =loadClass(fileName,true);
>      if (gclass !=null) {
>          Class[] ca = {
>                  JSONObject.class,
>                  JSONObject.class,
>                  HibernateSessionUtil.class,
>                  HTMLFlex.class };
>
>          try {
>              @SuppressWarnings("unchecked")
>              Method methp = gclass.getMethod(_method, ca);
>              if (methp ==null) {
>                  errorReturn(response,"Method " + _method +" not found in class " +this.getClass().getName(),null);
>                  return;
>              }
>              methp.invoke(null, injson, outjson, hsu,this);
>          }catch (Exception e) {
>              errorReturn(response,"Error running method " + _method +" in class " +this.getClass().getName(), e);
>              return;
>          }
>      }else {
>          errorReturn(response,"Error loading " + fileName,null);
>          return;
>      }
> }
> public synchronized static GroovyClass loadClass(String fileName,
> boolean report) { GroovyClass gclass; *[some class cacheing code]*try
> { gclass = new GroovyClass(false, fileName); classCache.put(fileName,
> new ClassInfo(gclass, (new File(fileName)).lastModified())); } catch
> (FileNotFoundException e) { if (report) logger.error("File " +
> fileName + " not found", e); return null; } catch (Exception e) { if
> (report) logger.error("Error loading " + fileName, e); return null; }
> return gclass; }
>
>
> On Fri, Apr 20, 2018 at 7:15 AM, Wolfgang Pedot
> <[hidden email] <mailto:[hidden email]>> wrote:
>
>     For Groovy-scripts you need to know that each instance of a script
>     has a Binding to store variables in it and that may cause
>     re-entrance or concurrency issues if you dont create a new script
>     instance for each call.
>
>     Wolfgang
>
>     Am 20.04.2018 um 11:21 schrieb Blake McBride:
>
>         Greetings,
>
>         Does Groovy safely support re-entrant and multi-entrant calls?
>         What I mean by that is the following:
>
>         Re-entrant: on a single OS thread - my Java program calls into
>         Groovy, then Groovy calls into my Java application, and then
>         the Java application calls back into Groovy. So the stack has
>         Java, Groovy, JAVA, and then Groovy again.
>
>         Multi-entrant: my Java application has many threads.  One of
>         my threads calls into Groovy. Then, while one thread is still
>         in Groovy, another thread evokes Groovy. So now we have two
>         calls into Groovy by two independent Java/OS threads running
>         at the same time.
>
>         I understand the typical problems associated with
>         application-level shared variables.  This is expected.  The
>         question revolves around Groovy's internals.  I presume Groovy
>         may have some shared data that is internal to Groovy. That's
>         what I am unclear about. Groovy would have had to be designed
>         for these scenarios from the ground up.
>
>         This is a little hard to test because if it can't always
>         correctly handle these situations, it may not become clear
>         until certain scenarios arrive.  It may be hard for any "test"
>         program I write to cause those scenarios, so I thought this
>         may be a known answer.
>
>         Thanks!
>
>         Blake McBride
>

Reply | Threaded
Open this post in threaded view
|

Re: Re-entrant and multi-entrant Groovy calls

Kerridge, Jon
In reply to this post by Blake McBride

Hi,

Not really, becasue you have just specified the groovy the crucial bit is how this is called and how data is shared / passed between between the Java and Groovy


Jon

Professor Jon Kerridge
School of Computing
Edinburgh Napier University
Merchiston Campus
Edinburgh EH10 5DT
 
0131 455 2777
 

From: Blake McBride <[hidden email]>
Sent: 20 April 2018 13:32:17
To: [hidden email]
Subject: Re: Re-entrant and multi-entrant Groovy calls
 
Every time I call Groovy from Java I do the following code snippets.  Does this have the problem you are referring to?

public void runGroovy(String fileName) { 
    JSONObject injson = ...
    JSONObject outjson = ...
    HibernateSessionUtil hsu = ...

GroovyClass gclass = loadClass(fileName, true);
if (gclass != null) {
Class[] ca = {
JSONObject.class,
JSONObject.class,
HibernateSessionUtil.class,
HTMLFlex.class
};

try {
@SuppressWarnings("unchecked")
Method methp = gclass.getMethod(_method, ca);
if (methp == null) {
errorReturn(response, "Method " + _method + " not found in class " + this.getClass().getName(), null);
return;
}
methp.invoke(null, injson, outjson, hsu, this);
} catch (Exception e) {
errorReturn(response, "Error running method " + _method + " in class " + this.getClass().getName(), e);
return;
}
} else {
errorReturn(response, "Error loading " + fileName, null);
return;
}
}
public synchronized static GroovyClass loadClass(String fileName, boolean report) {
GroovyClass gclass;
[some class cacheing code]
try {
gclass =
new GroovyClass(false, fileName);
classCache.put(fileName, new ClassInfo(gclass, (new File(fileName)).lastModified()));
}
catch (FileNotFoundException e) {
if (report)
logger.error("File " + fileName + " not found", e);
return null;
}
catch (Exception e) {
if (report)
logger.error("Error loading " + fileName, e);
return null;
}
return gclass;
}


On Fri, Apr 20, 2018 at 7:15 AM, Wolfgang Pedot <[hidden email]> wrote:
For Groovy-scripts you need to know that each instance of a script has a Binding to store variables in it and that may cause re-entrance or concurrency issues if you dont create a new script instance for each call.

Wolfgang


Am 20.04.2018 um 11:21 schrieb Blake McBride:
Greetings,

Does Groovy safely support re-entrant and multi-entrant calls? What I mean by that is the following:

Re-entrant: on a single OS thread - my Java program calls into Groovy, then Groovy calls into my Java application, and then the Java application calls back into Groovy. So the stack has Java, Groovy, JAVA, and then Groovy again.

Multi-entrant: my Java application has many threads.  One of my threads calls into Groovy. Then, while one thread is still in Groovy, another thread evokes Groovy. So now we have two calls into Groovy by two independent Java/OS threads running at the same time.

I understand the typical problems associated with application-level shared variables.  This is expected.  The question revolves around Groovy's internals.  I presume Groovy may have some shared data that is internal to Groovy. That's what I am unclear about. Groovy would have had to be designed for these scenarios from the ground up.

This is a little hard to test because if it can't always correctly handle these situations, it may not become clear until certain scenarios arrive.  It may be hard for any "test" program I write to cause those scenarios, so I thought this may be a known answer.

Thanks!

Blake McBride



This message and its attachment(s) are intended for the addressee(s) only and should not be read, copied, disclosed, forwarded or relied upon by any person other than the intended addressee(s) without the permission of the sender. If you are not the intended addressee you must not take any action based on this message and its attachment(s) nor must you copy or show them to anyone. Please respond to the sender and ensure that this message and its attachment(s) are deleted.

It is your responsibility to ensure that this message and its attachment(s) are scanned for viruses or other defects. Edinburgh Napier University does not accept liability for any loss or damage which may result from this message or its attachment(s), or for errors or omissions arising after it was sent. Email is not a secure medium. Emails entering Edinburgh Napier University's system are subject to routine monitoring and filtering by Edinburgh Napier University.

Edinburgh Napier University is a registered Scottish charity. Registration number SC018373

Reply | Threaded
Open this post in threaded view
|

Re: Re-entrant and multi-entrant Groovy calls

Blake McBride
In reply to this post by Wolfgang Pedot
Yes, it is calling a static method on a Groovy class.  Is there a problem with what I am doing in term of re-entrant or multi-entrant interference?

Thanks.

Blake


On Fri, Apr 20, 2018 at 8:16 AM, Wolfgang Pedot <[hidden email]> wrote:
I dont know, your code looks like it is calling a static method on a class.

What I was referring to was using something like GroovyScriptEngine.createScript and reusing the returned Script-Object.

Wolfgang

Am 20.04.2018 um 14:32 schrieb Blake McBride:
Every time I call Groovy from Java I do the following code snippets.  Does this have the problem you are referring to?

public void runGroovy(String fileName) {
     JSONObject injson = ...
     JSONObject outjson = ...
     HibernateSessionUtil hsu = ...

     GroovyClass gclass =loadClass(fileName,true);
     if (gclass !=null) {
         Class[] ca = {
                 JSONObject.class,
                 JSONObject.class,
                 HibernateSessionUtil.class,
                 HTMLFlex.class };

         try {
             @SuppressWarnings("unchecked")
             Method methp = gclass.getMethod(_method, ca);
             if (methp ==null) {
                 errorReturn(response,"Method " + _method +" not found in class " +this.getClass().getName(),null);
                 return;
             }
             methp.invoke(null, injson, outjson, hsu,this);
         }catch (Exception e) {
             errorReturn(response,"Error running method " + _method +" in class " +this.getClass().getName(), e);
             return;
         }
     }else {
         errorReturn(response,"Error loading " + fileName,null);
         return;
     }
}
public synchronized static GroovyClass loadClass(String fileName, boolean report) { GroovyClass gclass; *[some class cacheing code]*try { gclass = new GroovyClass(false, fileName); classCache.put(fileName, new ClassInfo(gclass, (new File(fileName)).lastModified())); } catch (FileNotFoundException e) { if (report) logger.error("File " + fileName + " not found", e); return null; } catch (Exception e) { if (report) logger.error("Error loading " + fileName, e); return null; } return gclass; }



On Fri, Apr 20, 2018 at 7:15 AM, Wolfgang Pedot <[hidden email] <mailto:[hidden email]>> wrote:

    For Groovy-scripts you need to know that each instance of a script
    has a Binding to store variables in it and that may cause
    re-entrance or concurrency issues if you dont create a new script
    instance for each call.

    Wolfgang

    Am 20.04.2018 um 11:21 schrieb Blake McBride:

        Greetings,

        Does Groovy safely support re-entrant and multi-entrant calls?
        What I mean by that is the following:

        Re-entrant: on a single OS thread - my Java program calls into
        Groovy, then Groovy calls into my Java application, and then
        the Java application calls back into Groovy. So the stack has
        Java, Groovy, JAVA, and then Groovy again.

        Multi-entrant: my Java application has many threads.  One of
        my threads calls into Groovy. Then, while one thread is still
        in Groovy, another thread evokes Groovy. So now we have two
        calls into Groovy by two independent Java/OS threads running
        at the same time.

        I understand the typical problems associated with
        application-level shared variables.  This is expected.  The
        question revolves around Groovy's internals.  I presume Groovy
        may have some shared data that is internal to Groovy. That's
        what I am unclear about. Groovy would have had to be designed
        for these scenarios from the ground up.

        This is a little hard to test because if it can't always
        correctly handle these situations, it may not become clear
        until certain scenarios arrive.  It may be hard for any "test"
        program I write to cause those scenarios, so I thought this
        may be a known answer.

        Thanks!

        Blake McBride



Reply | Threaded
Open this post in threaded view
|

Re: Re-entrant and multi-entrant Groovy calls

Wolfgang Pedot
I would not expect any problems because of Groovy here, so far
Groovy-Classes have behaved like Java-Classes in my projects

Wolfgang

Am 20.04.2018 um 17:03 schrieb Blake McBride:

> Yes, it is calling a static method on a Groovy class.  Is there a
> problem with what I am doing in term of re-entrant or multi-entrant
> interference?
>
> Thanks.
>
> Blake
>
>
> On Fri, Apr 20, 2018 at 8:16 AM, Wolfgang Pedot
> <[hidden email] <mailto:[hidden email]>> wrote:
>
>     I dont know, your code looks like it is calling a static method on
>     a class.
>
>     What I was referring to was using something like
>     GroovyScriptEngine.createScript and reusing the returned
>     Script-Object.
>
>     Wolfgang
>
>     Am 20.04.2018 um 14:32 schrieb Blake McBride:
>
>         Every time I call Groovy from Java I do the following code
>         snippets.  Does this have the problem you are referring to?
>
>         public void runGroovy(String fileName) {
>              JSONObject injson = ...
>              JSONObject outjson = ...
>              HibernateSessionUtil hsu = ...
>
>              GroovyClass gclass =loadClass(fileName,true);
>              if (gclass !=null) {
>                  Class[] ca = {
>                          JSONObject.class,
>                          JSONObject.class,
>                          HibernateSessionUtil.class,
>                          HTMLFlex.class };
>
>                  try {
>                      @SuppressWarnings("unchecked")
>                      Method methp = gclass.getMethod(_method, ca);
>                      if (methp ==null) {
>                          errorReturn(response,"Method " + _method +"
>         not found in class " +this.getClass().getName(),null);
>                          return;
>                      }
>                      methp.invoke(null, injson, outjson, hsu,this);
>                  }catch (Exception e) {
>                      errorReturn(response,"Error running method " +
>         _method +" in class " +this.getClass().getName(), e);
>                      return;
>                  }
>              }else {
>                  errorReturn(response,"Error loading " + fileName,null);
>                  return;
>              }
>         }
>         public synchronized static GroovyClass loadClass(String
>         fileName, boolean report) { GroovyClass gclass; *[some class
>         cacheing code]*try { gclass = new GroovyClass(false,
>         fileName); classCache.put(fileName, new ClassInfo(gclass, (new
>         File(fileName)).lastModified())); } catch
>         (FileNotFoundException e) { if (report) logger.error("File " +
>         fileName + " not found", e); return null; } catch (Exception
>         e) { if (report) logger.error("Error loading " + fileName, e);
>         return null; } return gclass; }
>
>
>
>         On Fri, Apr 20, 2018 at 7:15 AM, Wolfgang Pedot
>         <[hidden email]
>         <mailto:[hidden email]>
>         <mailto:[hidden email]
>         <mailto:[hidden email]>>> wrote:
>
>             For Groovy-scripts you need to know that each instance of
>         a script
>             has a Binding to store variables in it and that may cause
>             re-entrance or concurrency issues if you dont create a new
>         script
>             instance for each call.
>
>             Wolfgang
>
>             Am 20.04.2018 um 11:21 schrieb Blake McBride:
>
>                 Greetings,
>
>                 Does Groovy safely support re-entrant and
>         multi-entrant calls?
>                 What I mean by that is the following:
>
>                 Re-entrant: on a single OS thread - my Java program
>         calls into
>                 Groovy, then Groovy calls into my Java application,
>         and then
>                 the Java application calls back into Groovy. So the
>         stack has
>                 Java, Groovy, JAVA, and then Groovy again.
>
>                 Multi-entrant: my Java application has many threads. 
>         One of
>                 my threads calls into Groovy. Then, while one thread
>         is still
>                 in Groovy, another thread evokes Groovy. So now we
>         have two
>                 calls into Groovy by two independent Java/OS threads
>         running
>                 at the same time.
>
>                 I understand the typical problems associated with
>                 application-level shared variables. This is expected.  The
>                 question revolves around Groovy's internals.  I
>         presume Groovy
>                 may have some shared data that is internal to Groovy.
>         That's
>                 what I am unclear about. Groovy would have had to be
>         designed
>                 for these scenarios from the ground up.
>
>                 This is a little hard to test because if it can't always
>                 correctly handle these situations, it may not become clear
>                 until certain scenarios arrive.  It may be hard for
>         any "test"
>                 program I write to cause those scenarios, so I thought
>         this
>                 may be a known answer.
>
>                 Thanks!
>
>                 Blake McBride
>