Running multiple instances of OFBiz to the same database

[Mike Z]

Playing around with running multiple instances of OFBiz in it's own VM, in
a cloud environment, to the same DB.

I ran across this on the OpenTaps docs:

Service engine job pool:
Modify the file framework/service/config/serviceengine.xml for each of your
instances and edit the thread-pool's send-to-pool and run-from-pool to be
different for each instance. For example:

<thread-pool send-to-pool="opentaps1"> . . . <run-from-pool
name="opentaps1"/></thread-pool>

What is the purpose of this?  Is this so that jobs originated on each
instance are tracked separately on the DB?  Is there anything else that
needs to be tweaked config-wise so the multiple instances don't collide?

[Brett]

Mike,

I posted a similar question a while ago on this topic.  The subject
was "How to assign JobSandbox jobs to specific application server?"

In the posting I asked if different app servers could be configured to
run against different job pools in the service engine.

Here is a copy of what I posted.

"For Example we could configure our service engine to have a worker1
pool for app server 1 and worker2 pool for app server 2:

        <thread-pool send-to-pool="worker1"
                     purge-job-days="4"
                     failed-retry-min="3"
                     ttl="18000000"
                     wait-millis="750"
                     jobs="10"
                     min-threads="5"
                     max-threads="15"
                     poll-enabled="true"
                     poll-db-millis="20000">
            <run-from-pool name="worker1"/>
        </thread-pool>

        <thread-pool send-to-pool="worker2"
                     purge-job-days="4"
                     failed-retry-min="3"
                     ttl="18000000"
                     wait-millis="750"
                     jobs="10"
                     min-threads="5"
                     max-threads="15"
                     poll-enabled="true"
                     poll-db-millis="20000">
            <run-from-pool name="worker2"/>
        </thread-pool>
"

I believe the service engine still works the same way.  You can also
have multiple app servers hitting the same jobPool in the jobSandbox.
The only time I have run into problems with multiple servers is when
the jobSandbox has a lot of records 50k+ and the different app servers
start to see locks on the JobSandbox table.


Brett

On Wed, Mar 21, 2012 at 12:02 AM, Mike <[hidden email]> wrote:

>
> Playing around with running multiple instances of OFBiz in it's own VM, in
> a cloud environment, to the same DB.
>
> I ran across this on the OpenTaps docs:
>
> Service engine job pool:
> Modify the file framework/service/config/serviceengine.xml for each of your
> instances and edit the thread-pool's send-to-pool and run-from-pool to be
> different for each instance. For example:
>
> <thread-pool send-to-pool="opentaps1"> . . . <run-from-pool
> name="opentaps1"/></thread-pool>
>
> What is the purpose of this?  Is this so that jobs originated on each
> instance are tracked separately on the DB?  Is there anything else that
> needs to be tweaked config-wise so the multiple instances don't collide?

[Jacques Le Roux]

From: "Mike" <[hidden email]>

> Playing around with running multiple instances of OFBiz in it's own VM, in
> a cloud environment, to the same DB.
>
> I ran across this on the OpenTaps docs:
>
> Service engine job pool:
> Modify the file framework/service/config/serviceengine.xml for each of your
> instances and edit the thread-pool's send-to-pool and run-from-pool to be
> different for each instance. For example:
>
> <thread-pool send-to-pool="opentaps1"> . . . <run-from-pool
> name="opentaps1"/></thread-pool>
>
> What is the purpose of this?

You don't need this as long as you don't need to isolate some jobs and want them running only on one of the machines (for
performance or other reasons)

>Is this so that jobs originated on each
> instance are tracked separately on the DB?

Yes, you can say that

>Is there anything else that
> needs to be tweaked config-wise so the multiple instances don't collide?

You should not get multiple instances colliding. If you want only one instance of a job to run at a time I'd recommned to set
semaphore="fail" on the related service

You may also consider unique.instanceId in general.properties, look at this thread http://markmail.org/message/xhc6nfbzsd5ezscg

And if you want to get confused a bit you might look at
https://issues.apache.org/jira/browse/OFBIZ-4602?focusedCommentId=13199868&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13199868

Jacques

[Mike Z]

Here is what I was thinking.

If one of the OFBiz ecommerce VM's crashes (or I restart it), would another
server take over the job?  Would this work If only the pool names were all
the same for all instances?

On Wed, Mar 21, 2012 at 6:08 AM, Brett Palmer <[hidden email]>wrote:

> Mike,
>
> I posted a similar question a while ago on this topic.  The subject
> was "How to assign JobSandbox jobs to specific application server?"
>
> In the posting I asked if different app servers could be configured to
> run against different job pools in the service engine.
>
> Here is a copy of what I posted.
>
> "For Example we could configure our service engine to have a worker1
> pool for app server 1 and worker2 pool for app server 2:
>
>        <thread-pool send-to-pool="worker1"
>                     purge-job-days="4"
>                     failed-retry-min="3"
>                     ttl="18000000"
>                     wait-millis="750"
>                     jobs="10"
>                     min-threads="5"
>                     max-threads="15"
>                     poll-enabled="true"
>                     poll-db-millis="20000">
>            <run-from-pool name="worker1"/>
>        </thread-pool>
>
>        <thread-pool send-to-pool="worker2"
>                     purge-job-days="4"
>                     failed-retry-min="3"
>                     ttl="18000000"
>                     wait-millis="750"
>                     jobs="10"
>                     min-threads="5"
>                     max-threads="15"
>                     poll-enabled="true"
>                     poll-db-millis="20000">
>            <run-from-pool name="worker2"/>
>        </thread-pool>
> "
>
> I believe the service engine still works the same way.  You can also
> have multiple app servers hitting the same jobPool in the jobSandbox.
> The only time I have run into problems with multiple servers is when
> the jobSandbox has a lot of records 50k+ and the different app servers
> start to see locks on the JobSandbox table.
>
>
> Brett
>
> On Wed, Mar 21, 2012 at 12:02 AM, Mike <[hidden email]> wrote:
> >
> > Playing around with running multiple instances of OFBiz in it's own VM,
> in
> > a cloud environment, to the same DB.
> >
> > I ran across this on the OpenTaps docs:
> >
> > Service engine job pool:
> > Modify the file framework/service/config/serviceengine.xml for each of
> your
> > instances and edit the thread-pool's send-to-pool and run-from-pool to be
> > different for each instance. For example:
> >
> > <thread-pool send-to-pool="opentaps1"> . . . <run-from-pool
> > name="opentaps1"/></thread-pool>
> >
> > What is the purpose of this?  Is this so that jobs originated on each
> > instance are tracked separately on the DB?  Is there anything else that
> > needs to be tweaked config-wise so the multiple instances don't collide?
>

[Mike Z]

Thanks Jacques.  It sounds like it is good practice to have separate
"unique.instanceId" for each VM, but having separate pools are optional.
 If I kill a VM, and there were outstanding jobs, will another instance
take over?

On Wed, Mar 21, 2012 at 6:28 AM, Jacques Le Roux <
[hidden email]> wrote:

> From: "Mike" <[hidden email]>
>
>  Playing around with running multiple instances of OFBiz in it's own VM, in
>> a cloud environment, to the same DB.
>>
>> I ran across this on the OpenTaps docs:
>>
>> Service engine job pool:
>> Modify the file framework/service/config/**serviceengine.xml for each of
>> your
>> instances and edit the thread-pool's send-to-pool and run-from-pool to be
>> different for each instance. For example:
>>
>> <thread-pool send-to-pool="opentaps1"> . . . <run-from-pool
>> name="opentaps1"/></thread-**pool>
>>
>> What is the purpose of this?
>>
>
> You don't need this as long as you don't need to isolate some jobs and
> want them running only on one of the machines (for performance or other
> reasons)
>
>
>  Is this so that jobs originated on each
>> instance are tracked separately on the DB?
>>
>
> Yes, you can say that
>
>
>  Is there anything else that
>> needs to be tweaked config-wise so the multiple instances don't collide?
>>
>
> You should not get multiple instances colliding. If you want only one
> instance of a job to run at a time I'd recommned to set
> semaphore="fail" on the related service
>
> You may also consider unique.instanceId in general.properties, look at
> this thread http://markmail.org/message/**xhc6nfbzsd5ezscg<http://markmail.org/message/xhc6nfbzsd5ezscg>
>
> And if you want to get confused a bit you might look at
> https://issues.apache.org/**jira/browse/OFBIZ-4602?**
> focusedCommentId=13199868&**page=com.atlassian.jira.**
> plugin.system.issuetabpanels:**comment-tabpanel#comment-**13199868<https://issues.apache.org/jira/browse/OFBIZ-4602?focusedCommentId=13199868&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13199868>
>
> Jacques
>
>
>

[Jacques Le Roux]

No, because if they were ran before by a crashed/stopped instance they will be only picked again by this instance, see
JobSandbox.runByInstanceId  field and its use in JobManager.poll()

That's whay I prefer the
>> semaphore="fail" on the related service
solution to prevent collisions and still allow jobs to be picked by any machines on the cluster.

The only thing I still wonder about is the impact of maxretry, hence my comment in the Jira I posted below

unique.instanceId is convenient in case you want to explicitly run a job on a machine...

Jacques

From: "Mike" <[hidden email]>

> Thanks Jacques.  It sounds like it is good practice to have separate
> "unique.instanceId" for each VM, but having separate pools are optional.
> If I kill a VM, and there were outstanding jobs, will another instance
> take over?
>
> On Wed, Mar 21, 2012 at 6:28 AM, Jacques Le Roux <
> [hidden email]> wrote:
>
>> From: "Mike" <[hidden email]>
>>
>>  Playing around with running multiple instances of OFBiz in it's own VM, in
>>> a cloud environment, to the same DB.
>>>
>>> I ran across this on the OpenTaps docs:
>>>
>>> Service engine job pool:
>>> Modify the file framework/service/config/**serviceengine.xml for each of
>>> your
>>> instances and edit the thread-pool's send-to-pool and run-from-pool to be
>>> different for each instance. For example:
>>>
>>> <thread-pool send-to-pool="opentaps1"> . . . <run-from-pool
>>> name="opentaps1"/></thread-**pool>
>>>
>>> What is the purpose of this?
>>>
>>
>> You don't need this as long as you don't need to isolate some jobs and
>> want them running only on one of the machines (for performance or other
>> reasons)
>>
>>
>>  Is this so that jobs originated on each
>>> instance are tracked separately on the DB?
>>>
>>
>> Yes, you can say that
>>
>>
>>  Is there anything else that
>>> needs to be tweaked config-wise so the multiple instances don't collide?
>>>
>>
>> You should not get multiple instances colliding. If you want only one
>> instance of a job to run at a time I'd recommned to set
>> semaphore="fail" on the related service
>>
>> You may also consider unique.instanceId in general.properties, look at
>> this thread http://markmail.org/message/**xhc6nfbzsd5ezscg<http://markmail.org/message/xhc6nfbzsd5ezscg>
>>
>> And if you want to get confused a bit you might look at
>> https://issues.apache.org/**jira/browse/OFBIZ-4602?**
>> focusedCommentId=13199868&**page=com.atlassian.jira.**
>> plugin.system.issuetabpanels:**comment-tabpanel#comment-**13199868<https://issues.apache.org/jira/browse/OFBIZ-4602?focusedCommentId=13199868&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13199868>
>>
>> Jacques
>>
>>
>>
>