Hi Daling Xu,

Daling Xu wrote:
>  
>   In my project, I need to execute multiple (dosens, even hundreds) JavaScript files at the same time.
Wow! What is it about?

> And for each script file, I need to register a bean object for it. I need to use that bean in my script file, e.g.
> myBeanName.method1(). But for each scipt, the bean object should be different. Also, I need to be able to stop specific script files at the run time.
>   To satisfy all these requirements, I start a new BSFManager() for each script file:
>   ...
> Map threadMap = new Hashtable(); //
> ...
>  
... cut ...

>   Then, later when I call beanName.method1() in each script file, I am sure I called it on the correct beanObject instance. Also, I can stop the runnging script for scriptFileX by:
>  Thread t = (Thread) threadMap.get( scriptFileX );
>  t.stop();
>  
>  
> But, I have some consern about the drawback which is the overhead of creating a BSFManager object for each script. By looking at the source code, I notice that each BSFManager maintain the loaded class of the script engine, e.g. JavaScriptEngine here.  Does that mean I am holding dosens even hundreds JavaScriptEngine class loaded in the memory by the former code scripet??
>   Now my question is how big is this overhead? How much memory does it take? Can I avoid it?
>   If I do it this way :
>    BSFManager manager = new BSFManager();
>  
>  for( each scriptFileName ) {
>          
>       String lang = "JavaScript";
>       manager.declareBean("beanName", beanObjectForScriptI, MyBeanClass.class );    
>       manager.exec( lang,
>        "Java", 0, 0,
>        IOUtils.getStringFromReader(new FileReader(scriptFileName) ));
>  
>  }
>   I am afraid that the declareBean method could overwrite the previously declared bean. Also, how can I stop the script execution for certain script files but keep others running at the runtime?
>  
... cut ...

Just a few remarks:

    * to know for sure, you should profile some test runs,
    * a BSFManager instance reuses a loaded script engine, so you could
      pool BSFManager instances,
    * ad BSF registry/registering beans:
          o you could use the same bean registry and register beans
            under different names and supply the script the name of the
            bean which is meant for it for retrieval in the script;
          o also you could create one bean registry which should be
            accessible to a group or all invoked scripts by cascading it
            with a new instance of the registry meant for it; cf.
            getObjectRegistry(), setObjectRegistry(), and of course the
            class "org.apache.bsf.util.ObjectRegistry" which has two
            constructors, one for supplying a parent ObjectRegistry (for
            cascading)

Please let us know how you fare, o.k.?

---rony