Re: Users - Debugging Scheduled Jobs Tip
Posted by David E. Jones on Feb 16, 2006; 5:54pm
URL: http://ofbiz.116.s1.nabble.com/Users-Debugging-Scheduled-Jobs-Tip-tp137457p137465.html
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
URL: http://ofbiz.116.s1.nabble.com/Users-Debugging-Scheduled-Jobs-Tip-tp137457p137465.html
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
smime.p7s (3K) | Free forum by Nabble | Edit this page |