You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@ofbiz.apache.org by Imre András Róbert <im...@mail.tvnet.hu> on 2007/03/23 15:31:54 UTC

Re[6]: Bean Shell Scripting

Friday, March 23, 2007, 2:28:50 PM, you wrote:
> András,

>> I did. I'm sorry, but I have to disagree with this approach.
>>
>> Setting a low timeout causes an overhead of putting in and dumping
>> out almost immediately, which effectively acts as a brake.

> I guess David means setting a low timeout for developpement. This is to
> "turn off" caches to ease developement.

Yes. I just tried to point out that it causes overhead which
might slow down things. Which can be acceptable if you do not
want to modify the ofbiz code.

>> IMO turning off a cache should not cause this behavior.
>> IMO turning off means just dont do anything with that specific cache,
>> as if it never existed.
>> So I would not consider this as a real substitute or workaround.

> Only for developement, are you really suffrering of slowness in
> development ?

No, but I use my little modification which actually gets rid of
the BeanShellScripts cache. This is a real turn-off with no
overhead. Currently hardwired, but with a little more coding
it could easily be controlled via properties, if needed. Could
be applied to all caches not just BeanShellScripts.

>>
>> Btw this overhead/brake thing is indeed mentioned on this wiki page:
>> http://ofbizwiki.go-integral.com/Wiki.jsp?page=Optimizing
>> ---------------------------------------------------------------------
>> However, here are some things you should do in every production
> system:
>>  1. comment out the settings in cache.properties that effectively
> disable
>>  the FTL, BSH and other caches by setting their timeouts to 1ms
>>  (this is great for development, but wreaks havoc on a production
> server)
>> ---------------------------------------------------------------------
>>
>> (Also a bit of contradiction here. Things that I should do on prod
>> system will wreak havoc on prod system. :? )

> I thing I explained above (prod cached vs dev "not" cached)  or I'm
> still missing something ?

The section tells things you should do in prd. 1st bullet tells about
commenting out things which will cause overhead and wreak havoc in
prd. This is obviously something you do not want to happen, therefore
I would not consider it as a 'should do'.


Regards,
  András

> Jacques

>>
>> Regards,
>>   András
>>
>>
>> Thursday, March 22, 2007, 6:04:54 PM, you wrote:
>>
>>
>> > Why not take the easy approach and read the comments in the
>> > cache.properties file?
>>
>> > When we say "turn off" a cache, that usually just means setting a
> low
>> > timeout.
>>
>> > -David
>>
>>
>> > On Mar 22, 2007, at 11:03 AM, Imre András Róbert wrote:
>>
>> >> Yeah, I agree, that would be the place but...
>> >>
>> >> The cache settings docs is a bit outdate with respect to properties
>> >> prefix and contains no info whatsoever about how to turn off a
>> >> cache. (Non-technical users bail out at this point. No, kidding,
>> >> they were lost even before, at the no release-svn checkout and
> build
>> >> thingy. >:) Often running into outdated docs tends to discourage
>> >> even those who are keen readers otherwise. People adapt to
> situations
>> >> damn fast.)
>> >>
>> >> No problem, lets do a little exploration. Lets go and see web
> admin.
>> >> Maxsize=0 means no limit, and this fact comes through only by
>> >> experience,
>> >> not the docs. Web admin shows me I can set maxSize and expireTime,
>> >> but none of this can turn off a cache.
>> >>
>> >> No problem, lets see the cache.properties file for existing
>> >> property names.
>> >> Though softReference comes into the picture, no commented out
>> >> example here
>> >> about turning specific cache off, so still no clue. (Non-
>> >> experienced java
>> >> programmers and those who have not enough time are likely to be out
>> >> of the
>> >> picture at this point.)
>> >>
>> >> No problem, open source, lets see the source code. (Hmmm, we ended
> up
>> >> here, again.) Ofbiz is well-designed, and this pays off here,
> because
>> >> only a little analysis of UtilCache.java tells all property names,
>> >> of which none seems to be what we are looking for.
>> >>
>> >> At this point we're finished, and I can tell that either turning
> off a
>> >> specific cache via cache.properties is not possible, or I really
>> >> missed
>> >> something... (Non-ofbiz contributors leave us at this point. One of
>> >> those
>> >> who are still standing will probably implement this. Hopefully
> someone
>> >> who sees the whole picture about cacheing.)
>> >>
>> >> Guys, dont take this to the heart, ofbiz is great, and has a robust
>> >> design, but the 'no release' and lack and inaccurate documentation
>> >> 'features' are a real pain in the ass. Every time, not just with
>> >> cacheing. And these explorations take way too much time to build sg
>> >> upon it.
>> >> I suspect I'm not the first one telling this.
>> >> I really hope you find a documentation tool/framework that suits
>> >> ofbiz in
>> >> its stability and usability and 'automationability' and these
>> >> annoyances
>> >> will be gone forever.
>> >>
>> >>
>> >> Btw, what is the difference between the following three that all
> seem
>> >> to govern beanshell script execution?
>> >>   BeanShellScripts    <- for me only turning off this onl worked
>> >> for .bsh scripts
>> >>   script.BshLocationParsedCache
>> >>   script.BshBsfParsedCache
>> >>
>> >>
>> >> Thanks,
>> >>   András
>> >>
>> >>
>> >> Thursday, March 22, 2007, 4:14:27 PM, you wrote:
>> >>
>> >>> András,
>> >>
>> >>> Even better than changing anything in code read the doc :
>> >>> http://tinyurl.com/2ztz4t ;o)
>> >>
>> >>> Jacques
>> >>
>> >>>> Just one thing to mention:
>> >>>> Beanshell scripts get cached, so dont forget to clear
>> >>>> the cache after script modification. Or even better, you
>> >>>> can tinker a little with the ofbiz code to turn cacheing
>> >>>> off for development.
>> >>>>
>> >>>>
>> >>>> Regards,
>> >>>>   András
>> >>>>
>> >>>>
>> >>>> Thursday, March 22, 2007, 8:28:42 AM, you wrote:
>> >>>>
>> >>>>> Welcome to OFBiz.
>> >>>>
>> >>>>> Because you don't need to recompile them and reload all OFBiz.
>> >>>>
>> >>>>> Jacques
>> >>>>
>> >>>>
>> >>>>> ----- Message d'origine -----
>> >>>>> De : "OFBiz" <vr...@gmail.com>
>> >>>>> À : <us...@ofbiz.apache.org>
>> >>>>> Envoyé : jeudi 22 mars 2007 07:25
>> >>>>> Objet : Bean Shell Scripting
>> >>>>
>> >>>>
>> >>>>>>
>> >>>>>> Hai this is Veerraju.I am new to OFBiz.
>> >>>>>>
>> >>>>>>               In OFBiz we use Bean shell Scripting and Free
> Marker
>> >>>>>> Templates.Why we need to go for Beanshell Scripting and Free
>> >>> Markers.
>> >>>>>>
>> >>>>>> -- 
>> >>>>>> View this message in context:
>> >>>>>
>> >>>>
> http://www.nabble.com/Bean-Shell-Scripting-tf3445725.html#a9609116
>> >>>>>> Sent from the OFBiz - User mailing list archive at Nabble.com.
>> >>
>>


Re: Bean Shell Scripting

Posted by "David E. Jones" <jo...@hotwaxmedia.com>.
On Mar 26, 2007, at 9:38 PM, Jonathon -- Improov wrote:

> Hi Imre,
>
> Turning off caching will mean OFBiz reloads/recompiles on every web  
> request, right?
>
> Say the caching is set to have a expiration time of 0, then OFBiz  
> would simply:

Just an FYI: an expire time of 0 means no expiration, or expiration  
disabled. If you want to "disable" the cache through expiration, an  
expire time of 1 means 1 millisecond which effectively kills it.

On a side note for Imre and to add to what Jonathon said: for  
development we DO NOT want a hard disable because certain resources  
would be read many time in a single page request... in some cases  
dozens! So, we do a 10 second timeout which is a nice balance between  
refresh time, and not making single requests super inefficient.

-David



Re: Bean Shell Scripting

Posted by Jonathon -- Improov <jo...@improov.com>.
Hi Imre,

Turning off caching will mean OFBiz reloads/recompiles on every web request, right?

Say the caching is set to have a expiration time of 0, then OFBiz would simply:

1. Check the cache engine and find out that the cache is expired.

2. Reload/recompile whatever needs reloading/recompiling.

As David said, step 2 is way more computationally expensive than step 1. It is my opinion too that 
removing/optimizing step 1 wouldn't give any more than maybe 1% performance improvement.

In short, the cost of step 1 is amortized by the cost of step 2.

Jonathon

Imre András Róbert wrote:
> Friday, March 23, 2007, 9:08:04 PM, you wrote:
>>>> No, but I use my little modification which actually gets rid of
>>>> the BeanShellScripts cache. This is a real turn-off with no
>>>> overhead. Currently hardwired, but with a little more coding
>>>> it could easily be controlled via properties, if needed. Could
>>>> be applied to all caches not just BeanShellScripts.
>>> This might be interesting. Would you consider to open a Jira issue for
>>> this ?
> 
>> Why would we want to do this?
> 
>> The main reason I consider a cache timeout to be an adequate disable
>> mechanism is that the performance overhead for maintain the cache is
>> NOTHING compared to the performance impact of having the cache  
>> disabled (maybe 1000:1, perhaps 100,000:1 for reloading and parsing a
>> BSH script).
> 
> I think all this boils down to the following:
> 
> - In either production or development we should always use cache for
>   performance, but with adequately large expiration time in order to
>   avoid the overhead.
> - In development we can simulate turning off with setting expiration
>   time to an extremely low level with a tradeoff
> - To turn off the cache entirely implementing a new feature would be
>   needed (would also help later to decide whether a certain problem
>   is cache related or not)
> 
> So far it is only me who is not happy with the workaround. Jacques
> might also find this idea useful.
> 
> I think it's up to the ofbiz community to decide, whether a real turn
> off of cacheing feature is needed or not. Please let me know how the
> community decides about this (vote/jira etc).
> 
> 
> Thanks,
>   András
> 
>> -David
> 
> 
> 


Re[8]: Bean Shell Scripting

Posted by Imre András Róbert <im...@mail.tvnet.hu>.
Friday, March 23, 2007, 9:08:04 PM, you wrote:
>>> No, but I use my little modification which actually gets rid of
>>> the BeanShellScripts cache. This is a real turn-off with no
>>> overhead. Currently hardwired, but with a little more coding
>>> it could easily be controlled via properties, if needed. Could
>>> be applied to all caches not just BeanShellScripts.
>>
>> This might be interesting. Would you consider to open a Jira issue for
>> this ?

> Why would we want to do this?

> The main reason I consider a cache timeout to be an adequate disable
> mechanism is that the performance overhead for maintain the cache is
> NOTHING compared to the performance impact of having the cache  
> disabled (maybe 1000:1, perhaps 100,000:1 for reloading and parsing a
> BSH script).

I think all this boils down to the following:

- In either production or development we should always use cache for
  performance, but with adequately large expiration time in order to
  avoid the overhead.
- In development we can simulate turning off with setting expiration
  time to an extremely low level with a tradeoff
- To turn off the cache entirely implementing a new feature would be
  needed (would also help later to decide whether a certain problem
  is cache related or not)

So far it is only me who is not happy with the workaround. Jacques
might also find this idea useful.

I think it's up to the ofbiz community to decide, whether a real turn
off of cacheing feature is needed or not. Please let me know how the
community decides about this (vote/jira etc).


Thanks,
  András

> -David



Re: Re[6]: Bean Shell Scripting

Posted by "David E. Jones" <jo...@hotwaxmedia.com>.
On Mar 23, 2007, at 10:04 AM, Jacques Le Roux wrote:

>
> De : "Imre András Róbert" <im...@mail.tvnet.hu>
>>>> IMO turning off a cache should not cause this behavior.
>>>> IMO turning off means just dont do anything with that specific
> cache,
>>>> as if it never existed.
>>>> So I would not consider this as a real substitute or workaround.
>>
>>> Only for developement, are you really suffrering of slowness in
>>> development ?
>>
>> No, but I use my little modification which actually gets rid of
>> the BeanShellScripts cache. This is a real turn-off with no
>> overhead. Currently hardwired, but with a little more coding
>> it could easily be controlled via properties, if needed. Could
>> be applied to all caches not just BeanShellScripts.
>
> This might be interesting. Would you consider to open a Jira issue for
> this ?

Why would we want to do this?

The main reason I consider a cache timeout to be an adequate disable  
mechanism is that the performance overhead for maintain the cache is  
NOTHING compared to the performance impact of having the cache  
disabled (maybe 1000:1, perhaps 100,000:1 for reloading and parsing a  
BSH script).

-David


Re: Re[6]: Bean Shell Scripting

Posted by Jacques Le Roux <ja...@les7arts.com>.
De : "Imre András Róbert" <im...@mail.tvnet.hu>
> >> IMO turning off a cache should not cause this behavior.
> >> IMO turning off means just dont do anything with that specific
cache,
> >> as if it never existed.
> >> So I would not consider this as a real substitute or workaround.
>
> > Only for developement, are you really suffrering of slowness in
> > development ?
>
> No, but I use my little modification which actually gets rid of
> the BeanShellScripts cache. This is a real turn-off with no
> overhead. Currently hardwired, but with a little more coding
> it could easily be controlled via properties, if needed. Could
> be applied to all caches not just BeanShellScripts.

This might be interesting. Would you consider to open a Jira issue for
this ?

> >> Btw this overhead/brake thing is indeed mentioned on this wiki
page:
> >> http://ofbizwiki.go-integral.com/Wiki.jsp?page=Optimizing
>
>> ---------------------------------------------------------------------
> >> However, here are some things you should do in every production
> > system:
> >>  1. comment out the settings in cache.properties that effectively
> > disable
> >>  the FTL, BSH and other caches by setting their timeouts to 1ms
> >>  (this is great for development, but wreaks havoc on a production
> > server)
>
>> ---------------------------------------------------------------------
> >>
> >> (Also a bit of contradiction here. Things that I should do on prod
> >> system will wreak havoc on prod system. :? )
>
> > I thing I explained above (prod cached vs dev "not" cached)  or I'm
> > still missing something ?
>
> The section tells things you should do in prd. 1st bullet tells about
> commenting out things which will cause overhead and wreak havoc in
> prd. This is obviously something you do not want to happen, therefore
> I would not consider it as a 'should do'.

It's because OOTB OFBiz is configured for development (it's a
framework). That's why reading the setup documententation is really
important. But at this stage (production) hopefully everybody has been
thru at least this documentation.

Jacques

> Regards,
>   András
>
> > Jacques
>
> >>
> >> Regards,
> >>   András
> >>
> >>
> >> Thursday, March 22, 2007, 6:04:54 PM, you wrote:
> >>
> >>
> >> > Why not take the easy approach and read the comments in the
> >> > cache.properties file?
> >>
> >> > When we say "turn off" a cache, that usually just means setting a
> > low
> >> > timeout.
> >>
> >> > -David
> >>
> >>
> >> > On Mar 22, 2007, at 11:03 AM, Imre András Róbert wrote:
> >>
> >> >> Yeah, I agree, that would be the place but...
> >> >>
> >> >> The cache settings docs is a bit outdate with respect to
properties
> >> >> prefix and contains no info whatsoever about how to turn off a
> >> >> cache. (Non-technical users bail out at this point. No, kidding,
> >> >> they were lost even before, at the no release-svn checkout and
> > build
> >> >> thingy. >:) Often running into outdated docs tends to discourage
> >> >> even those who are keen readers otherwise. People adapt to
> > situations
> >> >> damn fast.)
> >> >>
> >> >> No problem, lets do a little exploration. Lets go and see web
> > admin.
> >> >> Maxsize=0 means no limit, and this fact comes through only by
> >> >> experience,
> >> >> not the docs. Web admin shows me I can set maxSize and
expireTime,
> >> >> but none of this can turn off a cache.
> >> >>
> >> >> No problem, lets see the cache.properties file for existing
> >> >> property names.
> >> >> Though softReference comes into the picture, no commented out
> >> >> example here
> >> >> about turning specific cache off, so still no clue. (Non-
> >> >> experienced java
> >> >> programmers and those who have not enough time are likely to be
out
> >> >> of the
> >> >> picture at this point.)
> >> >>
> >> >> No problem, open source, lets see the source code. (Hmmm, we
ended
> > up
> >> >> here, again.) Ofbiz is well-designed, and this pays off here,
> > because
> >> >> only a little analysis of UtilCache.java tells all property
names,
> >> >> of which none seems to be what we are looking for.
> >> >>
> >> >> At this point we're finished, and I can tell that either turning
> > off a
> >> >> specific cache via cache.properties is not possible, or I really
> >> >> missed
> >> >> something... (Non-ofbiz contributors leave us at this point. One
of
> >> >> those
> >> >> who are still standing will probably implement this. Hopefully
> > someone
> >> >> who sees the whole picture about cacheing.)
> >> >>
> >> >> Guys, dont take this to the heart, ofbiz is great, and has a
robust
> >> >> design, but the 'no release' and lack and inaccurate
documentation
> >> >> 'features' are a real pain in the ass. Every time, not just with
> >> >> cacheing. And these explorations take way too much time to build
sg
> >> >> upon it.
> >> >> I suspect I'm not the first one telling this.
> >> >> I really hope you find a documentation tool/framework that suits
> >> >> ofbiz in
> >> >> its stability and usability and 'automationability' and these
> >> >> annoyances
> >> >> will be gone forever.
> >> >>
> >> >>
> >> >> Btw, what is the difference between the following three that all
> > seem
> >> >> to govern beanshell script execution?
> >> >>   BeanShellScripts    <- for me only turning off this onl worked
> >> >> for .bsh scripts
> >> >>   script.BshLocationParsedCache
> >> >>   script.BshBsfParsedCache
> >> >>
> >> >>
> >> >> Thanks,
> >> >>   András
> >> >>
> >> >>
> >> >> Thursday, March 22, 2007, 4:14:27 PM, you wrote:
> >> >>
> >> >>> András,
> >> >>
> >> >>> Even better than changing anything in code read the doc :
> >> >>> http://tinyurl.com/2ztz4t ;o)
> >> >>
> >> >>> Jacques
> >> >>
> >> >>>> Just one thing to mention:
> >> >>>> Beanshell scripts get cached, so dont forget to clear
> >> >>>> the cache after script modification. Or even better, you
> >> >>>> can tinker a little with the ofbiz code to turn cacheing
> >> >>>> off for development.
> >> >>>>
> >> >>>>
> >> >>>> Regards,
> >> >>>>   András
> >> >>>>
> >> >>>>
> >> >>>> Thursday, March 22, 2007, 8:28:42 AM, you wrote:
> >> >>>>
> >> >>>>> Welcome to OFBiz.
> >> >>>>
> >> >>>>> Because you don't need to recompile them and reload all
OFBiz.
> >> >>>>
> >> >>>>> Jacques
> >> >>>>
> >> >>>>
> >> >>>>> ----- Message d'origine -----
> >> >>>>> De : "OFBiz" <vr...@gmail.com>
> >> >>>>> À : <us...@ofbiz.apache.org>
> >> >>>>> Envoyé : jeudi 22 mars 2007 07:25
> >> >>>>> Objet : Bean Shell Scripting
> >> >>>>
> >> >>>>
> >> >>>>>>
> >> >>>>>> Hai this is Veerraju.I am new to OFBiz.
> >> >>>>>>
> >> >>>>>>               In OFBiz we use Bean shell Scripting and Free
> > Marker
> >> >>>>>> Templates.Why we need to go for Beanshell Scripting and Free
> >> >>> Markers.
> >> >>>>>>
> >> >>>>>> -- 
> >> >>>>>> View this message in context:
> >> >>>>>
> >> >>>>
> > http://www.nabble.com/Bean-Shell-Scripting-tf3445725.html#a9609116
> >> >>>>>> Sent from the OFBiz - User mailing list archive at
Nabble.com.
> >> >>
> >>