Re: Users - Debugging Scheduled Jobs Tip

Posted by David E. Jones on Feb 16, 2006; 5:28pm
URL: http://ofbiz.116.s1.nabble.com/Users-Debugging-Scheduled-Jobs-Tip-tp137457p137463.html


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