Hi Mahesh and all,
I have another suggestion. We should keep the dev, test, prod subscribers
in the respective Stratos controllers. This is because it will reduce the
load on the network.
The architecture stays the same.
thanks,
dimuthu
On Fri, Dec 19, 2014 at 2:16 PM, Dimuthu Leelarathne
Hi Dimuthu,
Noted.
thanks.
On Mon, Jan 5, 2015 at 10:34 AM, Dimuthu Leelarathne dimut...@wso2.com
wrote:
Hi Mahesh and all,
I have another suggestion. We should keep the dev, test, prod subscribers
in the respective Stratos controllers. This is because it will reduce the
load on the
Hi Mahesh,
What is the possibility of removing the second REST call. If we are putting
an additional moving part we need to justify why. For example we could say
in this point you can put a LB and horizontally scale (Just one of many
possible answers). In this case I don't see such a use case
Hi all,
Im working on Making the tenants subscription to stratos environments fault
tolerant [1]
This has been discussed in mail thread with subject - [Architecture] [AF]
Tenant subscribing to stratos environments - making it fault tolerant
*Issue*
**
There are some possible failure
Hi Harsha,
I see your point.
If you follow tenant creation bpel you may see initializeBuildManager
and initializeRepositoryManager
happens one after the other in a row. If it got failed in any step the
process won't continue.
But in last step of bpel you can see that initializeCloudManager is
Hi Mahesh,
+1 for the current design. I assume you have multiple instances of durable
subscribers for each subscription made to Stratos cartridges. For example,
if we have multiple tenant aware cartridges(App Server, UES Server, BPS
Server etc), the durable subscriber should be able to
