ode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sathwik B P <sathwik...@gmail.com>
Subject Re: Deploying process in the cluster
Date Sat, 06 Jun 2015 10:03:58 GMT
Hi Sudharma/Tammo,

Kindly review attached document on my proposed approach. Let me know if you
have any concerns or doubts on it.

regards,
sathwik

On Fri, Jun 5, 2015 at 6:56 PM, Sathwik B P <sathwik.bp@gmail.com> wrote:

> find response inline
>
> On Wed, Jun 3, 2015 at 10:22 PM, sudharma subasinghe <
> suba.11@cse.mrt.ac.lk> wrote:
>
>> Hi,
>>
>> Sorry for the late reply. I was trying to achieve a proper solution.
>> Following is my approach.
>>
>> 1) I elected master node for deploying purpose. So when a master node goes
>> down hazelcast will elect the next oldest node for master.
>>
>
>     Perfect
>
>
>> 2) ODEServer can identify whether clustering is enabled or not by getting
>> the property value in ode-axis2.properties file. So I introduced new
>> property called "ode-axis2.hazelcast.clustering.enabled". If there is no
>> clustering enabled server will work as it is. If clustering is enabled,
>> cluster will be initialized.
>>
>
>     Perfect
>
>
>> 3) In manual deployment its responsibility is taken by the
>> DeploymentPoller. So I give the deployment capability to master node,s
>> poller by setting "isDeploymentFromODEFileSystemAllowed()" to true.So
>> others will not be able to go into check() method in DeploymentPoller. So
>> deployment will be done by only the master node.
>>
>
>     Perfect
>
>
>>
>> 4) In DeploymentWebService, I had to consider few cases.If the deploy
>> request goes to the master node, it will deploy the process through web
>> service.Others pollers will not go into check() method as they are not
>> masters. So master can continue without any involvement of others.
>>
>>
>     Perfect
>
>
>> 5) If the deploy request goes to a slave node, it will do up to file
>> creation in the file system.Slave will be stopped at that point. As only
>> master poller is checking, master can continue from created files in the
>> file system.
>>
>
>     DeploymentWebService provides synchronous operations. The status of
> the operation should be communicated to the calling client in the same call.
>     DeploymentPoller is a backend thread that goes over each and every
> directory under the Deployment directory checking for any changes to
> deploy.xml in existing processes and deploy newly added processes. This
> process is  sequential and time consuming. As the process directories
> grows, so does the time taken for execution of the thread.
>
>     Since the request is on a slave node and the processing is done on
> master node, how do you check for the completion of the
> deployment/undeployment of processes and respond back to the client since
> the web service call is a synchronous operation. As DeploymentPoller is
> taking a lot of time in processing, your request will time out right.
>
>
>>
>> 6) But there was problem with _deploymentUnits in ProcessStoreImpl. Each
>> _deploymentUnits stores only what its server has deployed. So think, that
>> a
>> master node goes down another master node appears.But its
>> __deploymentUnits
>> does not have dus which has deployed by the earlier master node. Hence it
>> will not be able retire earlier version of the process which is deployed
>> by
>> previous master. So there will two process which are in "ACTIVE" state
>
>
>> 7) To avoid this, I add the ODEServer as an Observer to check when a new
>> master is electing, then load all the deployment units out of the store.
>> So
>> new master node can have all the dus and can retire appropriate version.
>> Usually loadAll() is called at the server start-up time. But there is no
>> other way to solve this. I tried to use Hazelcast IMap to store all dus
>> among all nodes. But it wasn't success as du is not serializable object.
>>
>
>> 8) I figured out that we do not need send cluster message to others as all
>> the dus' data are persisted to the shared DB. So each node can take the du
>> and retrieve necessary data using already implemented methods in Process
>> Store.
>>
>> 9) But there is an another problem.The axis2 service corresponding to a
>> deployed process does not appear on all nodes of the cluster. That is
>> because each server add du which is deployed by it to the process
>> store.That is why I had use loadAll() when masters are changing. How to
>> solve this?
>>
>
>     I do appriciate your efforts in understanding the implmentation and
> changes that need to be done. You are bang on it.
>     fireEvent(..) is the method that triggers process activation and
> necessary service creation.
>
>
>     But with this given apporach from steps 6 to 8, ODE cannot have
> atleast 2 Active servers for Load balancing. You are concentrating on only
> one active node that will do deployments and cater to process invocations.
>     We should also think about scaling ODE to multiple servers to handle
> load.
>
>     What do you think.
>
>
>> Thank you,
>> Sudharma
>>
>> On 2 June 2015 at 08:51, Sathwik B P <sathwik.bp@gmail.com> wrote:
>>
>> > Sudharma,
>> >
>> > Any updates?
>> >
>> > regards,
>> > sathwik
>> >
>> > On Fri, May 29, 2015 at 5:26 PM, Sathwik B P <sathwik.bp@gmail.com>
>> wrote:
>> >
>> > > Sudharma,
>> > >
>> > > Can you elaborate on your option 1).
>> > >
>> > > Response to your option 2).
>> > >
>> > >     Process Store is the component that handles process metadata,
>> > > compilation and deployment in ODE. Integration layers in ODE (Axis2,
>> JBI)
>> > > use the process store.
>> > >     Future implementations of IL for ODE will also use the process
>> store.
>> > > We should not be thinking of moving the process store functionality to
>> > the
>> > > integration layers.
>> > >
>> > >
>> > > On Thu, May 28, 2015 at 9:33 PM, sudharma subasinghe <
>> > > suba.11@cse.mrt.ac.lk> wrote:
>> > >
>> > >> Hi,
>> > >>
>> > >> I understood the problem within dynamic master/slave configuration.
>> In
>> > my
>> > >> approach, when a deployment request is routed to a slave node there
>> will
>> > >> not be a deployment. I suggest two options to avoid it.
>> > >> 1) Have static master/slave configuration only for deploy process
>> > >>
>> > > 2) Modify the deployment web service to complie and verify the process
>> > and
>> > >> then copy it to the deploy folder irrespective of whether its a
>> master
>> > or
>> > >> slave, then deployment poller should take care of the deployment
>> > >>
>> > >>
>> > >
>> > >>
>> > >> On 28 May 2015 at 14:43, Sathwik B P <sathwik.bp@gmail.com> wrote:
>> > >>
>> > >> > Sudharma,
>> > >> >
>> > >> > We definitely need a master/slave in the hazelcast cluster. This
is
>> > >> > probably needed for the job migration in the Scheduler to migrate
>> the
>> > >> jobs
>> > >> > associated with a down node. Let hold on this topic for future
>> > >> discussion.
>> > >> >
>> > >> > Going by the explanation where the master/slave nodes have certain
>> > >> > predefined tasks to perform is perfectly fine.
>> > >> >
>> > >> > I have this scenario,
>> > >> >
>> > >> > I am using HAProxy as my load balancer and configured 3 nodes
in
>> the
>> > >> > cluster.
>> > >> >
>> > >> > Node1 - Active
>> > >> > Node2 - Active
>> > >> > Node3 - Backup
>> > >> >
>> > >> > Load balancing algorithm: RoundRobin
>> > >> >
>> > >> > A Backup node (Node3) is one which the load balancer will not
route
>> > >> > requests to, until one of the Active node i.e either Node1 or
Node2
>> > has
>> > >> > gone down.
>> > >> >
>> > >> > All these 3 nodes are also part of the hazelcast cluster as well.
>> > >> >
>> > >> > In the hazelcast cluster, assume Node1 is elected as the
>> leader/master
>> > >> and
>> > >> > Node2,Node3 as slaves.
>> > >> >
>> > >> > I initiate the deploy operation on the DeploymentWebService which
>> the
>> > >> load
>> > >> > balancer routes it to one of the Active nodes in the cluster,
lets
>> say
>> > >> it's
>> > >> > the Node1. Since Node1 is also the master in the hazelcast cluster,
>> > >> > deployment is a success.
>> > >> >
>> > >> > I initiate another deploy operation on the DeploymentWebService
>> which
>> > >> the
>> > >> > load balancer routes it to the next active node which is Node2.
>> Since
>> > >> Node2
>> > >> > is a slave in the Hazelcast cluster, What happens to the
>> deployment?
>> > >> >
>> > >> > regards,
>> > >> > sathwik
>> > >> >
>> > >> > On Wed, May 27, 2015 at 10:55 PM, sudharma subasinghe <
>> > >> > suba.11@cse.mrt.ac.lk
>> > >> > > wrote:
>> > >> >
>> > >> > > Hi,
>> > >> > >
>> > >> > > I will explain my approach as much as possible. The oldest
node
>> in
>> > the
>> > >> > > hazelcast cluster is elected as the master node. In the failure
>> of
>> > the
>> > >> > > master node, next oldest node will be elected as the master
node.
>> > This
>> > >> > > master-slave configuration is just for deployment. When the
>> > hazelcast
>> > >> > > cluster elected the master node, that node becomes a master
node
>> for
>> > >> > > deploying process. So it will do the deploying artifacts.
If you
>> > want
>> > >> to
>> > >> > > get the idea of electing master node please refer the code
which
>> I
>> > >> have
>> > >> > > located in the github. (
>> > >> > > https://github.com/Subasinghe/ode/tree/ode_clustering)
>> > >> > >
>> > >> > > I identified separated actions which should be followed by
the
>> > master
>> > >> and
>> > >> > > salve nodes.
>> > >> > > Actions which are followed by master node only
>> > >> > > 1) create deployment unit
>> > >> > > 2) set the version nu to deployment unit
>> > >> > > 3) compile deployment unit
>> > >> > > 4) scan deployment unit
>> > >> > > 5) retire previous versions
>> > >> > > Master node and slave nodes should create _processes which
stores
>> > >> > > ProcessConfImpl
>> > >> > > Only master node will write the version nu to database, create
>> > >> .deployed
>> > >> > > file
>> > >> > >
>> > >> > > So there are some actions which should be followed only by
master
>> > node
>> > >> > > while other actions should be followed by all the nodes.The
idea
>> of
>> > >> > having
>> > >> > > a master node is deploying artifacts and avoid others from
>> writing
>> > the
>> > >> > > version nu to database.
>> > >> > > Whether a node is active or passive, all nodes should do
the
>> > >> > > deployment.Master
>> > >> > > and slaves will follow necessary actions as in above.
>> > >> > >
>> > >> > >
>> > >> > >
>> > >> > >
>> > >> > >
>> > >> > > On 27 May 2015 at 15:49, Sathwik B P <sathwik.bp@gmail.com>
>> wrote:
>> > >> > >
>> > >> > > > Nandika,
>> > >> > > >
>> > >> > > > I very well understand what you have put across, but
it's
>> > secondary
>> > >> to
>> > >> > me
>> > >> > > > now.
>> > >> > > >
>> > >> > > > Sudharma,
>> > >> > > > My primary concern is to understand at a high level
the
>> deployment
>> > >> > > > architecture and how would master-slave configuration
fit in.
>> Are
>> > >> there
>> > >> > > any
>> > >> > > > restrictions imposed by the in-progress design?
>> > >> > > >
>> > >> > > > Firstly, how would ODE process deployment work under
these
>> cluster
>> > >> > > > configurations?
>> > >> > > >
>> > >> > > > Sample Cluster configurations: A load balancer is frontending
>> the
>> > >> > > servers.
>> > >> > > > 1) Cluster consisting of 2 nodes all Active-Active.
>> > >> > > > 2) Cluster consisting of 2 nodes Active-Passive.
>> > >> > > > 3) Cluster with 2+ nodes with additional nodes either
in
>> Active or
>> > >> > > Passive.
>> > >> > > >
>> > >> > > > regards,
>> > >> > > > sathwik
>> > >> > > >
>> > >> > > >
>> > >> > > >
>> > >> > > >
>> > >> > > >
>> > >> > > >
>> > >> > > >
>> > >> > > > On Wed, May 27, 2015 at 3:04 PM, Nandika Jayawardana
<
>> > >> > jayawark@gmail.com
>> > >> > > >
>> > >> > > > wrote:
>> > >> > > >
>> > >> > > > > Hi Sathwik,
>> > >> > > > >
>> > >> > > > > According to my understanding, in the clustering
scenario,
>> the
>> > >> master
>> > >> > > > node
>> > >> > > > > should perform all the deployment actions and the
slave nodes
>> > also
>> > >> > need
>> > >> > > > to
>> > >> > > > > perform some deployment actions. For example, the
slave nodes
>> > also
>> > >> > > should
>> > >> > > > > handle the process ACTIVATED event so that the
process
>> > >> configuration
>> > >> > is
>> > >> > > > > added to the engine and necessary web services
are created so
>> > that
>> > >> > when
>> > >> > > > the
>> > >> > > > > load balancer send requests to any node in the
cluster, it is
>> > >> ready
>> > >> > to
>> > >> > > > > accept those requests.
>> > >> > > > >
>> > >> > > > > Regards
>> > >> > > > > Nandika
>> > >> > > > >
>> > >> > > > >
>> > >> > > > >
>> > >> > > > >
>> > >> > > > > On Wed, May 27, 2015 at 12:30 PM, Sathwik B P <
>> > >> sathwik.bp@gmail.com>
>> > >> > > > > wrote:
>> > >> > > > >
>> > >> > > > > > Sudharma,
>> > >> > > > > >
>> > >> > > > > > Where are you going to configure the master-slaves,
is it
>> in
>> > the
>> > >> > web
>> > >> > > > > > application level or at the load balancer?
>> > >> > > > > >
>> > >> > > > > > regards,
>> > >> > > > > > sathwik
>> > >> > > > > >
>> > >> > > > > > On Tue, May 26, 2015 at 7:42 PM, sudharma
subasinghe <
>> > >> > > > > > suba.11@cse.mrt.ac.lk>
>> > >> > > > > > wrote:
>> > >> > > > > >
>> > >> > > > > > > Hi Tammo,
>> > >> > > > > > >
>> > >> > > > > > > Can you suggest the best method from
these to implement?
>> As
>> > >> > first I
>> > >> > > > > > > suggested the master-slaves scenario
I think it is easy
>> to
>> > >> > > implement
>> > >> > > > > than
>> > >> > > > > > > distributed lock scenario. However if
you can suggest one
>> > from
>> > >> > > these
>> > >> > > > > two,
>> > >> > > > > > > then I can think about it.
>> > >> > > > > > >
>> > >> > > > > > > Thank you
>> > >> > > > > > >
>> > >> > > > > > > On 21 May 2015 at 12:40, Sathwik B P
<
>> sathwik.bp@gmail.com>
>> > >> > wrote:
>> > >> > > > > > >
>> > >> > > > > > > > With respect to the hotdeployment,
>> > >> > > > > > > >
>> > >> > > > > > > > We can drop the deployment archive
onto the deployment
>> > >> folder.
>> > >> > > > Since
>> > >> > > > > > the
>> > >> > > > > > > > DeploymentPoller are acquiring the
distributed lock for
>> > the
>> > >> > > > > > > DeploymentUnit,
>> > >> > > > > > > > only one of the nodes will get the
lock and initiate
>> the
>> > >> > > > deployment.
>> > >> > > > > > > > DeploymentPollers on other nodes
will fail in acquiring
>> > the
>> > >> > lock
>> > >> > > > and
>> > >> > > > > > > hence
>> > >> > > > > > > > will silently ignore it.
>> > >> > > > > > > >
>> > >> > > > > > > > On Thu, May 21, 2015 at 12:30 PM,
Sathwik B P <
>> > >> > > > sathwik.bp@gmail.com>
>> > >> > > > > > > > wrote:
>> > >> > > > > > > >
>> > >> > > > > > > > > Hi Tammo,
>> > >> > > > > > > > >
>> > >> > > > > > > > > The distributed lock acquisition
on the
>> DeploymentUnit
>> > >> should
>> > >> > > be
>> > >> > > > > > added
>> > >> > > > > > > to
>> > >> > > > > > > > > both DeploymentWebService and
DeploymentPoller.
>> > >> > > > > > > > >
>> > >> > > > > > > > > When a deployment operation
is initiated through the
>> > >> > > > > > > > DeploymentWebService,
>> > >> > > > > > > > > The load balancer routes it
to any of the available
>> > nodes.
>> > >> > > > > > > > >
>> > >> > > > > > > > > On the routed node, the DeploymentWebService
acquires
>> > the
>> > >> > > > > Distributed
>> > >> > > > > > > > > lock. On the remaining nodes
the DeploymentPoller
>> will
>> > >> try to
>> > >> > > > > acquire
>> > >> > > > > > > the
>> > >> > > > > > > > > distributed lock and will not
get it and hence will
>> > >> silently
>> > >> > > > ignore
>> > >> > > > > > it.
>> > >> > > > > > > > >
>> > >> > > > > > > > > Once the routed node completes
the deployment, it
>> will
>> > >> > release
>> > >> > > > the
>> > >> > > > > > > lock.
>> > >> > > > > > > > > This way we don't have to stall
the DeploymentPoller
>> in
>> > >> other
>> > >> > > > > nodes.
>> > >> > > > > > > > >
>> > >> > > > > > > > > Does it answer the concerns?
>> > >> > > > > > > > >
>> > >> > > > > > > > >
>> > >> > > > > > > > > Now, if we give the responsibility
of identifying the
>> > >> master
>> > >> > > node
>> > >> > > > > to
>> > >> > > > > > > the
>> > >> > > > > > > > > hazelcast, how do we plan to
intimate the load
>> balancer
>> > to
>> > >> > > change
>> > >> > > > > > it's
>> > >> > > > > > > > > configuration about the master
node?
>> > >> > > > > > > > > Assuming there are 3 nodes
in the cluster,
>> > >> > > > > > > > > node1 -master
>> > >> > > > > > > > > node2 - slave
>> > >> > > > > > > > > node3 - slave
>> > >> > > > > > > > >
>> > >> > > > > > > > > Node1 goes down, the LB will
promote Node2 as master
>> > node,
>> > >> > but
>> > >> > > > > > > hazelcast
>> > >> > > > > > > > > might promote Node3 as master
node. They are out of
>> > sync.
>> > >> > > > > > > > >
>> > >> > > > > > > > > Is this argument valid?
>> > >> > > > > > > > >
>> > >> > > > > > > > > regards,
>> > >> > > > > > > > > sathwik
>> > >> > > > > > > > >
>> > >> > > > > > > > > On Wed, May 20, 2015 at 1:51
PM, Tammo van Lessen <
>> > >> > > > > > > tvanlessen@gmail.com>
>> > >> > > > > > > > > wrote:
>> > >> > > > > > > > >
>> > >> > > > > > > > >> Hi Sudharma,
>> > >> > > > > > > > >>
>> > >> > > > > > > > >> what do you expect from
the "other nodes
>> deployment"?
>> > >> > > > Compilation
>> > >> > > > > is
>> > >> > > > > > > not
>> > >> > > > > > > > >> needed since the CBP file
is written to the (shared)
>> > FS.
>> > >> > > > > > Registration
>> > >> > > > > > > is
>> > >> > > > > > > > >> also not needed, since
it is done via the shared
>> > >> database.
>> > >> > So
>> > >> > > > the
>> > >> > > > > > only
>> > >> > > > > > > > >> thing that might be needed
is to tell the engine
>> that
>> > >> there
>> > >> > > is a
>> > >> > > > > new
>> > >> > > > > > > > >> deployment. I'd need to
check that. If this is
>> needed,
>> > I
>> > >> > > revert
>> > >> > > > my
>> > >> > > > > > > last
>> > >> > > > > > > > >> statement, then it is perhaps
better to just send an
>> > >> event
>> > >> > > over
>> > >> > > > > > > > Hazelcast
>> > >> > > > > > > > >> to all nodes that the deployment
has changed.
>> > >> > > > > > > > >>
>> > >> > > > > > > > >> Best,
>> > >> > > > > > > > >>   Tammo
>> > >> > > > > > > > >>
>> > >> > > > > > > > >> On Wed, May 20, 2015 at
10:13 AM, sudharma
>> subasinghe <
>> > >> > > > > > > > >> suba.11@cse.mrt.ac.lk
>> > >> > > > > > > > >> > wrote:
>> > >> > > > > > > > >>
>> > >> > > > > > > > >> > Hi Tammo,
>> > >> > > > > > > > >> >
>> > >> > > > > > > > >> > The master node writes
meta data. But runtime
>> > >> information
>> > >> > > must
>> > >> > > > > be
>> > >> > > > > > > > >> available
>> > >> > > > > > > > >> > in all nodes.Since
the folder is shared, all nodes
>> > will
>> > >> > see
>> > >> > > > the
>> > >> > > > > > > > >> > availability of a
new process. My idea is for
>> master
>> > >> node
>> > >> > to
>> > >> > > > > write
>> > >> > > > > > > the
>> > >> > > > > > > > >> meta
>> > >> > > > > > > > >> > data and other nodes
to just read the meta data
>> and
>> > >> load
>> > >> > > > > > process.So
>> > >> > > > > > > we
>> > >> > > > > > > > >> need
>> > >> > > > > > > > >> > a small delay between
master node deployment and
>> > other
>> > >> > nodes
>> > >> > > > > > > > deployment.
>> > >> > > > > > > > >> >
>> > >> > > > > > > > >> > Is there anyway to
set the delay between master
>> node
>> > >> and
>> > >> > > > slaves
>> > >> > > > > > > until
>> > >> > > > > > > > >> > master node finish
the deployment?
>> > >> > > > > > > > >> >
>> > >> > > > > > > > >> > Thank you
>> > >> > > > > > > > >> > Sudharma
>> > >> > > > > > > > >> >
>> > >> > > > > > > > >> >
>> > >> > > > > > > > >> > On 20 May 2015 at
13:01, Tammo van Lessen <
>> > >> > > > tvanlessen@gmail.com
>> > >> > > > > >
>> > >> > > > > > > > wrote:
>> > >> > > > > > > > >> >
>> > >> > > > > > > > >> > > Hi Sathwik,
>> > >> > > > > > > > >> > >
>> > >> > > > > > > > >> > > On Wed, May 20,
2015 at 6:40 AM, Sathwik B P <
>> > >> > > > > > > sathwik.bp@gmail.com>
>> > >> > > > > > > > >> > wrote:
>> > >> > > > > > > > >> > >
>> > >> > > > > > > > >> > > > Sudharma/Tammo,
>> > >> > > > > > > > >> > > >
>> > >> > > > > > > > >> > > > 1) How do
we plan to decide which is the
>> master
>> > >> node
>> > >> > in
>> > >> > > > the
>> > >> > > > > > > > cluster?
>> > >> > > > > > > > >> > > >
>> > >> > > > > > > > >> > >
>> > >> > > > > > > > >> > > I think the easiest
approach is to always elect
>> the
>> > >> > oldest
>> > >> > > > > node
>> > >> > > > > > in
>> > >> > > > > > > > the
>> > >> > > > > > > > >> > > cluster to be
the master. AFAIK Hazelcast can
>> > easily
>> > >> > asked
>> > >> > > > for
>> > >> > > > > > > this
>> > >> > > > > > > > >> > > information.
>> > >> > > > > > > > >> > >
>> > >> > > > > > > > >> > >
>> > >> > > > > > > > >> > >
>> > >> > > > > > > > >> > > > 2) Don't
we need to stall the Deployment
>> Pollers
>> > in
>> > >> > the
>> > >> > > > > slave
>> > >> > > > > > > > nodes?
>> > >> > > > > > > > >> > > >
>> > >> > > > > > > > >> > > >
>> > >> > > > > > > > >> > > Absolutely.
>> > >> > > > > > > > >> > >
>> > >> > > > > > > > >> > > Suggestion:
>> > >> > > > > > > > >> > > > I am not
sure whether do we need
>> Master-SLaves.
>> > Why
>> > >> > not
>> > >> > > > give
>> > >> > > > > > > every
>> > >> > > > > > > > >> node
>> > >> > > > > > > > >> > > in
>> > >> > > > > > > > >> > > > the cluster
the same status (Active-Active).
>> > >> > > > > > > > >> > > >
>> > >> > > > > > > > >> > > > When a new
deployment is made, the load
>> balancer
>> > >> can
>> > >> > > push
>> > >> > > > it
>> > >> > > > > > to
>> > >> > > > > > > > any
>> > >> > > > > > > > >> of
>> > >> > > > > > > > >> > > the
>> > >> > > > > > > > >> > > > available
nodes. That node will probably
>> acquire
>> > a
>> > >> > > > > distributed
>> > >> > > > > > > > lock
>> > >> > > > > > > > >> on
>> > >> > > > > > > > >> > > the
>> > >> > > > > > > > >> > > > deployment
unit and acts as master for that
>> > >> > deployment.
>> > >> > > > This
>> > >> > > > > > > > ensures
>> > >> > > > > > > > >> > > > optimum
usage of the cluster nodes. Probably
>> no
>> > >> static
>> > >> > > > > > > > >> configuration of
>> > >> > > > > > > > >> > > > Master-Slave
in the load balancer nor in the
>> > >> > hazelcast.
>> > >> > > > > > > > >> > > >
>> > >> > > > > > > > >> > >
>> > >> > > > > > > > >> > > But this would
not allow to have the
>> hotdeployment
>> > >> via
>> > >> > > > > > filesystem
>> > >> > > > > > > > >> still
>> > >> > > > > > > > >> > > enabled, right?
>> > >> > > > > > > > >> > >
>> > >> > > > > > > > >> > > Best,
>> > >> > > > > > > > >> > >   Tammo
>> > >> > > > > > > > >> > >
>> > >> > > > > > > > >> > >
>> > >> > > > > > > > >> > > --
>> > >> > > > > > > > >> > > Tammo van Lessen
- http://www.taval.de
>> > >> > > > > > > > >> > >
>> > >> > > > > > > > >> >
>> > >> > > > > > > > >>
>> > >> > > > > > > > >>
>> > >> > > > > > > > >>
>> > >> > > > > > > > >> --
>> > >> > > > > > > > >> Tammo van Lessen - http://www.taval.de
>> > >> > > > > > > > >>
>> > >> > > > > > > > >
>> > >> > > > > > > > >
>> > >> > > > > > > >
>> > >> > > > > > >
>> > >> > > > > >
>> > >> > > > >
>> > >> > > >
>> > >> > >
>> > >> >
>> > >>
>> > >
>> > >
>> >
>>
>
>

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