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
thousands).
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 combination)
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 made
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 own
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 servers)
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 instance
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.r...@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...
Jacques
a patch.
my 2 cents
regds
mallah.
On Wed, Aug 29, 2018 at 6:19 PM Shi Jinghai <huaru...@hotmail.com
<mailto:huaru...@hotmail.com>> wrote:
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.r...@les7arts.com
<mailto:jacques.le.r...@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]
[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 way?
Opinions?
Jacques
