Users - Debugging Scheduled Jobs Tip
Locked
Users - Debugging Scheduled Jobs Tip
 
|
Re: Users - Debugging Scheduled Jobs Tip
|
|
Re: Users - Debugging Scheduled Jobs Tip
|
|
Re: Users - Debugging Scheduled Jobs Tip
|
|
Re: Users - Debugging Scheduled Jobs Tip
|
|
In reply to this post by David E. Jones
Patches are generally easier to maintain... They can also be applied using ant if you create sets of build targets. -David On Feb 16, 2006, at 10:20 AM, Lon F. Binder wrote: > David (and everyone), > > That's a good idea. Alternatively, this is bigger-picture- > approach, perhaps > we should alter the build file to include build targets by > environment, that > way we can standardize ofbiz projects on a file extension that can > be picked > up and removed per target. > > Using Florin's great tip as an example, I might have: > serviceengine.xml@Lon > serviceengine.xml@B1 > serviceengine.xml@production > Where the String following the '@' is free form. > > Then we could add a build target that accepts a parameter. When > files end > in "@${param}" that extension is removed locally. > > So if I did a "build B1" upon build it would choose > "servicengine.xml@B1" as > listed above, and create a copy in the same folder called > "serviceengine.xml". > > The goal being to use the same freeform extension for whatever > means across > the entire fileset for environment-sensitive files. Having a freeform > extension would allow for unlimited environments (which is > particularly > helpful on projects with many devs). And doesn't require any special > repository work to maintain. > > Thoughts? > > - Lon > > -----Original Message----- > From: [hidden email] [mailto:users- > [hidden email]] > On Behalf Of David E. Jones > Sent: Thursday, February 16, 2006 11:42 AM > To: OFBiz Users / Usage Discussion > Subject: Re: [OFBiz] Users - Debugging Scheduled Jobs Tip > > > Yes, this is the way to go... > > We usually recommend keeping a local repository with a base set of > code and > configuration files for a "development" mode, and then keeping a > directory > with patches (in the repository) for the various servers. When > OFBiz is > deployed on each server (test, staging, production, perhaps > multiple of > each) you just check out the rev you want to deploy, apply the > patch for > that server, and build and run. > This makes things more easy to reproduce and allows for configuration > variations between servers. > > -David > > > On Feb 16, 2006, at 8:58 AM, Florin T.PATRASCU (work) wrote: > >> Hi, >> >> The way to avoid this is to use the service engine *pool* feature >> that >> allows each service engine instance to specify which pool it >> "publishes" >> to by default, and which pool(s) it "subscribes" to. >> >> excerpt from serviceengine.xml installed on a Test server: >> >> <!-- Thread pool configuration (max/min threads, uses to live and >> time to live) --> >> <thread-pool send-to-pool="hobbit1" >> purge-job-days="4" >> .... >> poll-db-millis="20000"> >> <run-from-pool name="hobbit1"/> >> </thread-pool> >> >> >> while the same serviceengine config file but on a Production machine >> will look different a bit: >> >> <thread-pool send-to-pool="everest01" >> .... >> poll-db-millis="20000"> >> <run-from-pool name="everest01"/> >> </thread-pool> >> >> Just make sure they have different names for your development servers >> and your production servers and this problem should go away. We >> encountered this issue in the past. So you can still share your db >> and >> get advantages from that;) >> >> I hope it helps. >> >> -florin >> >> PS >> Sorry for my English if it is confusing :( but I believe is better >> than the one Andrew Dupa is "using" ;) >> >> Lon F. Binder wrote: >>> All - >>> >>> After spending a few hours working through an issue, I'd like to >>> provide an interesting (albeit obvious in hindsight) tip. >>> >>> We had two different OFBiz installations sharing the same database. >>> One was a dev environment, the other was a QA environment (for the >>> same target application). This led to different versions of the >>> same >>> codebase across the two environments. All in all, this was a fine >>> approach for sharing the general data (store, catalog, parties, >>> etc.). >>> >>> However, a consequence was overlapping job queue workers. Depending >>> on the timing jobs would be worked on by the two applications >>> running. And because the code base was slightly different (due to >>> ongoing development), sometimes the jobs would work and sometimes >>> they wouldn't. >>> >>> TIP: Don't let multiple OFBiz application environments (dev, qa, >>> etc.) >>> share a single OFBiz database, at least while you're >>> testing/developing scheduled jobs. >>> >>> - Lon >>> >>> -------------------------------------------------------------------- >>> - >>> --- >>> >>> >>> _______________________________________________ >>> Users mailing list >>> [hidden email] >>> http://lists.ofbiz.org/mailman/listinfo/users >> >> >> >> _______________________________________________ >> Users mailing list >> [hidden email] >> http://lists.ofbiz.org/mailman/listinfo/users > > > _______________________________________________ > Users mailing list > [hidden email] > http://lists.ofbiz.org/mailman/listinfo/users > > > > _______________________________________________ > Users mailing list > [hidden email] > http://lists.ofbiz.org/mailman/listinfo/users _______________________________________________ Users mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/users |
smime.p7s (3K)
Re: Users - Debugging Scheduled Jobs Tip
|
|
Re: Users - Debugging Scheduled Jobs Tip
|
|
Hmmmm... I always considered the serviceengine.xml file to _be_ a "local config" file.... -David On Feb 16, 2006, at 10:47 AM, Florin T.PATRASCU (work) wrote: > Guys, I don't know if this sounds alien, but David, how difficult will > be to improve the UtilXml.getXmlRootElement(...) (or a better > place?) to > "decorate" the loaded xml config files with parameters defined in a > properties file or coming from the System properties, classpath, JVM > params or etc...?? > > In our case this will look like this: > > local property file defining: > send-to-pool=devServerA > > And then in the serviceengine.xml we could simply have: > ... > <thread-pool send-to-pool="${send-to-pool}" > purge-job-days="4" > failed-retry-min="3" > > ... > > And then the developer only has to tweak his local config file. > > I don't know how realistic my proposal is, but I was just thinking > about, anyway please consider it my 2 CAD cents intervention to this > thread ;) > > -florin > > > David E. Jones wrote: >> >> Patches are generally easier to maintain... >> >> They can also be applied using ant if you create sets of build >> targets. >> >> -David >> >> >> On Feb 16, 2006, at 10:20 AM, Lon F. Binder wrote: >> >>> David (and everyone), >>> >>> That's a good idea. Alternatively, this is bigger-picture-approach, >>> perhaps >>> we should alter the build file to include build targets by >>> environment, that >>> way we can standardize ofbiz projects on a file extension that >>> can be >>> picked >>> up and removed per target. >>> >>> Using Florin's great tip as an example, I might have: >>> serviceengine.xml@Lon >>> serviceengine.xml@B1 >>> serviceengine.xml@production >>> Where the String following the '@' is free form. >>> >>> Then we could add a build target that accepts a parameter. When >>> files end >>> in "@${param}" that extension is removed locally. >>> >>> So if I did a "build B1" upon build it would choose >>> "servicengine.xml@B1" as >>> listed above, and create a copy in the same folder called >>> "serviceengine.xml". >>> >>> The goal being to use the same freeform extension for whatever means >>> across >>> the entire fileset for environment-sensitive files. Having a >>> freeform >>> extension would allow for unlimited environments (which is >>> particularly >>> helpful on projects with many devs). And doesn't require any >>> special >>> repository work to maintain. >>> >>> Thoughts? >>> >>> - Lon >>> >>> -----Original Message----- >>> From: [hidden email] >>> [mailto:[hidden email]] >>> On Behalf Of David E. Jones >>> Sent: Thursday, February 16, 2006 11:42 AM >>> To: OFBiz Users / Usage Discussion >>> Subject: Re: [OFBiz] Users - Debugging Scheduled Jobs Tip >>> >>> >>> Yes, this is the way to go... >>> >>> We usually recommend keeping a local repository with a base set of >>> code and >>> configuration files for a "development" mode, and then keeping a >>> directory >>> with patches (in the repository) for the various servers. When >>> OFBiz is >>> deployed on each server (test, staging, production, perhaps >>> multiple of >>> each) you just check out the rev you want to deploy, apply the >>> patch for >>> that server, and build and run. >>> This makes things more easy to reproduce and allows for >>> configuration >>> variations between servers. >>> >>> -David >>> >>> >>> On Feb 16, 2006, at 8:58 AM, Florin T.PATRASCU (work) wrote: >>> >>>> Hi, >>>> >>>> The way to avoid this is to use the service engine *pool* >>>> feature that >>>> allows each service engine instance to specify which pool it >>>> "publishes" >>>> to by default, and which pool(s) it "subscribes" to. >>>> >>>> excerpt from serviceengine.xml installed on a Test server: >>>> >>>> <!-- Thread pool configuration (max/min threads, uses to live >>>> and >>>> time to live) --> >>>> <thread-pool send-to-pool="hobbit1" >>>> purge-job-days="4" >>>> .... >>>> poll-db-millis="20000"> >>>> <run-from-pool name="hobbit1"/> >>>> </thread-pool> >>>> >>>> >>>> while the same serviceengine config file but on a Production >>>> machine >>>> will look different a bit: >>>> >>>> <thread-pool send-to-pool="everest01" >>>> .... >>>> poll-db-millis="20000"> >>>> <run-from-pool name="everest01"/> >>>> </thread-pool> >>>> >>>> Just make sure they have different names for your development >>>> servers >>>> and your production servers and this problem should go away. We >>>> encountered this issue in the past. So you can still share your >>>> db and >>>> get advantages from that;) >>>> >>>> I hope it helps. >>>> >>>> -florin >>>> >>>> PS >>>> Sorry for my English if it is confusing :( but I believe is better >>>> than the one Andrew Dupa is "using" ;) >>>> >>>> Lon F. Binder wrote: >>>>> All - >>>>> >>>>> After spending a few hours working through an issue, I'd like to >>>>> provide an interesting (albeit obvious in hindsight) tip. >>>>> >>>>> We had two different OFBiz installations sharing the same >>>>> database. >>>>> One was a dev environment, the other was a QA environment (for the >>>>> same target application). This led to different versions of >>>>> the same >>>>> codebase across the two environments. All in all, this was a fine >>>>> approach for sharing the general data (store, catalog, parties, >>>>> etc.). >>>>> >>>>> However, a consequence was overlapping job queue workers. >>>>> Depending >>>>> on the timing jobs would be worked on by the two applications >>>>> running. And because the code base was slightly different (due to >>>>> ongoing development), sometimes the jobs would work and sometimes >>>>> they wouldn't. >>>>> >>>>> TIP: Don't let multiple OFBiz application environments (dev, qa, >>>>> etc.) >>>>> share a single OFBiz database, at least while you're >>>>> testing/developing scheduled jobs. >>>>> >>>>> - Lon >>>>> >>>>> ------------------------------------------------------------------ >>>>> --- >>>>> --- >>>>> >>>>> >>>>> _______________________________________________ >>>>> Users mailing list >>>>> [hidden email] >>>>> http://lists.ofbiz.org/mailman/listinfo/users >>>> >>>> >>>> >>>> _______________________________________________ >>>> Users mailing list >>>> [hidden email] >>>> http://lists.ofbiz.org/mailman/listinfo/users >>> >>> >>> _______________________________________________ >>> Users mailing list >>> [hidden email] >>> http://lists.ofbiz.org/mailman/listinfo/users >>> >>> >>> >>> _______________________________________________ >>> Users mailing list >>> [hidden email] >>> http://lists.ofbiz.org/mailman/listinfo/users >> >> --------------------------------------------------------------------- >> --- >> >> >> _______________________________________________ >> Users mailing list >> [hidden email] >> http://lists.ofbiz.org/mailman/listinfo/users > > > > _______________________________________________ > Users mailing list > [hidden email] > http://lists.ofbiz.org/mailman/listinfo/users _______________________________________________ Users mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/users |
Re: Users - Debugging Scheduled Jobs Tip
|
|
Re: Users - Debugging Scheduled Jobs Tip
|
|
Re: Users - Debugging Scheduled Jobs Tip
|
|
Re: Users - Debugging Scheduled Jobs Tip
|
|
Re: Users - Debugging Scheduled Jobs Tip
|
|
| Free forum by Nabble | Edit this page |