ofbiz-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jacques Le Roux <jacques.le.r...@les7arts.com>
Subject Re: Should we keep the multi-tenants feature in OFBiz?
Date Sun, 02 Sep 2018 08:29:58 GMT
Hi Rajesh,

Rest inline...

Le 29/08/2018 à 15:27, Rajesh Mallah a écrit :
> Hi  ,
> I strongly feel we should.
> For me, multi-tenency is the key feature in supporting more number of organisations
> with a single instance of Java/tomcat. Think of running 20  under-utilized OFBiz instances
> each *locking* up say 1GB ram versus 1 multi-tenant OFBiz instance allocated with a
> copious amount of RAM say 4-8GB ram.
>     a dozens or maybe even few hundreds tenants, after it begin to be a lot of DBs!
> I would want to understand for whom does it becomes a *lot* of DB ?
I worked with a startup. They had a business model where they would only win if they could
have tens of thousands of tenants (if not hundreds of 
Their goal was to ultimately get millions of them. It was not about URIs, but *separated *DBs.
Obviously OFBiz multi-tenant could not sustain that.

> In case it is about persistent connections to 100s' of distinct uris (ie. host+user+db
> from the JDBC pool, we can offload the connection pooling feature to an external
> pooler , (eg: pgpool or pgbouncer , in case of postgreSQL) , and convert the connection
> mode from persistent to non-persistent at the tomcat level . So a *new* connection is
> on a HTTP request and disconnected as soon as the request is served.
> in oracle we have: https://docs.oracle.com/cd/B28359_01/appdev.111/b28395/oci09adv.htm#LNOCI87721
> in postgreSQL: https://dba.stackexchange.com/questions/56559/postgresql-high-availability-scalability-using-haproxy-and-pgbouncer
> In case it is the sheer number of db connections i feel users can come up with their
> architectures suiting their environment.
Are you using your suggestions in production?

> (disclaimer: I am not expert in tomcat but i am trying to draw parallels with other application
> And its not only a matter of resource sharing only, deploying  a new client on a multi
tenant OFBiz
> instance is 10 times simpler than creating a new instance and configuring a new OFBiz
> itself ( discounting the factor or chef/puppet /salt/ansible/your favorite automation
tool) .
Actually in their case the instance would have been initially always the same. So deploying
copies was not a problem.

> I feel It will be a big loss unless an equivalent feature is found out ,
> the equivalent  IMHO is multi-tenant feature itself without the warts :-).
You are not the only one to express concerns. We need to consider that, but we also need to
consider what tenants entails in OFBiz code.

> @Jacques Le Roux <mailto:jacques.le.roux@les7arts.com> there is also:
> https://issues.apache.org/jira/browse/OFBIZ-10284 for which i had worked on
Thanks for the reminder, more on that later...


> a patch.
> my 2 cents
> regds
> mallah.
> On Wed, Aug 29, 2018 at 6:19 PM Shi Jinghai <huaruhai@hotmail.com <mailto:huaruhai@hotmail.com>>
>     Hi Jacques,
>     Honestly I was shocked by this email, I'm working on deploying OFBiz in Kubernetes,
are you monitoring me?
>     In 2010, Kubernetes was quite new and not good enough, now it's the standard on cloud
deploy management, and we can support it.
>     Before doing that, we have to answer some common questions in cloud running lifecycle,
such as how may instances/requests can share one CPU, how
>     to deliver(create) an instance, how to isolate an instance, how to offline, how to
remove, how to online again and etc.
>     Personally I don't think we have to remove current multi-tenants implements, add
a SAAS implement would be OK.
>     Kind Regards,
>     Shi Jinghai
>     -----邮件原件-----
>     发件人: Jacques Le Roux [mailto:jacques.le.roux@les7arts.com <mailto:jacques.le.roux@les7arts.com>]
>     发送时间: 2018年8月29日 17:46
>     收件人: dev@ofbiz.apache.org <mailto:dev@ofbiz.apache.org>
>     主题: Should we keep the multi-tenants feature in OFBiz?
>     Hi,
>     The multi-tenants feature in OFBiz only allows a dozens or maybe even few hundreds
tenants, after it begin to be a lot of DBs!
>     I faced that with a startup which wanted to handle thousands, if not millions (actually
they failed), of tenants, obviously OFBiz can't do that.
>     I don't break any secret to say that I was working with David (and Andrew) on a project
in 2010 when David had to quickly answer to the client's
>     demand who wanted to have tenants. David brilliantly and quickly delivered, but it
was only a start.
>     After many improvements, this feature still have some issues
>     https://issues.apache.org/jira/browse/OFBIZ-6066
>     https://issues.apache.org/jira/browse/OFBIZ-7900
>     https://issues.apache.org/jira/browse/OFBIZ-6164
>     https://issues.apache.org/jira/browse/OFBIZ-6065
>     Also this is somehow related
>     https://issues.apache.org/jira/browse/OFBIZ-6712
>     And most importantly
>     https://issues.apache.org/jira/browse/OFBIZ-7112
>     https://issues.apache.org/jira/browse/OFBIZ-7754
>     I recently read this article
>     https://www.linkedin.com/pulse/architecture-constraints-end-multi-tenancy-gregor-hohpe/
>     and, after my experiences with multi-tenant as is in OFBiz, it made me wonder if
we should not think about how it's done now in OFBiz in 2018
>     with the
>     clouds being everywhere!
>     Before sending this email, I quickly exchanged with David about how Moqui handles
that now. And we are on the same page, see
>     https://www.linkedin.com/groups/4640689/4640689-6180851287941201924
>     https://stackoverflow.com/questions/41952818/does-moqui-framework-2-0-still-support-mutli-tenency?rq=1
>     [1] Initially David gave me this link
>     https://www.linkedin.com/pulse/multi-instance-moqui-docker-david-e-jones/
>     but it seems LinkedIn has lost it, as said in the stackoverflow comment.
>     So IMO why not deprecating the multi-tenants as is now and rather push a multi-instances
>     Opinions?
>     Jacques

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message