ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Denis Magda <dma...@apache.org>
Subject Re: Service grid redesign
Date Thu, 17 Jan 2019 21:05:33 GMT
Vyacheslav,

Let me speak for the community and Ignite users and thank you for achieving
this milestone! Seems that the foundation for much bigger and impactful
improvements is ready. Tremendous job.

Are you going to start working on the services hot redeployment next?


-
Denis


On Wed, Jan 16, 2019 at 1:36 AM Vyacheslav Daradur <daradurvs@gmail.com>
wrote:

> The wiki's article [1] has been updated according to the merged solution
> [2].
>
> [1]
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95654584
> [2] https://issues.apache.org/jira/browse/IGNITE-9607
>
> On Fri, Dec 28, 2018 at 1:10 PM Vyacheslav Daradur <daradurvs@gmail.com>
> wrote:
> >
> > Igniters,
> >
> > to have an opportunity to test both new and old service grid
> > implementations, we added new config-plans on TC:
> > - Service Grid [1] - runs tests in new (default) mode
> > - Service Grid (legacy mode) [2] - runs tests in old (legacy) mode
> >
> > Both plans contain the following test-suites:
> > - IgniteServiceGridTestSuite (newly added suite)
> > - IgniteServiceConfigVariationsFullApiTestSuite (was moved from "Basic
> 2")
> >
> > Also, the plans have been included in RunAll.
> >
> > [1]
> https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_ServiceGrid
> > [2]
> https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_ServiceGridLegacyMode
> >
> > On Thu, Dec 27, 2018 at 6:24 AM Nikolay Izhikov <nizhikov@apache.org>
> wrote:
> > >
> > > Hello, Igniters.
> > >
> > > I've merged Service Grid Redesign - Phase 1 to the master.
> > > Vyacheslav, great contribution!
> > >
> > > Thanks for all Ignite veterans both for the code and design review.
> > >
> > > В Пн, 24/12/2018 в 20:50 +0300, Nikolay Izhikov пишет:
> > > > Hello, Igniters.
> > > >
> > > > Please, let us know, if someone want to do additional review of this
> PR.
> > > >
> > > > В Пн, 24/12/2018 в 20:23 +0300, Vyacheslav Daradur пишет:
> > > > > Igniters, especially future reviewers,
> > > > >
> > > > > Discovery listener registered by 'IgniteServiceProcessor' become
> > > > > implemented 'HighPriorityListener', seems it's best lock-free
> > > > > solutions discussed during the review. This change is covered by
> > > > > `ServiceDeploymentDiscoveryListenerNotificationOrderTest` which
> should
> > > > > protect us if the order of listeners will be changed.
> > > > >
> > > > > It's about the problem of custom messages which are nullified by
> PME
> > > > > [1] and are listened by service deployment to manage the lifecycle
> of
> > > > > affinity services. This guarantees that service deployment
> discovery
> > > > > listener will be notified earlier than PME's discovery listener and
> > > > > will be able to capture custom messages which may be nullified in
> PME
> > > > > process.
> > > > >
> > > > > Looks like we do not have any controversial questions now.
> > > > >
> > > > > Thanks!
> > > > >
> > > > > [1]
> http://apache-ignite-developers.2346864.n4.nabble.com/Danger-change-of-DiscoveryCustomEvent-in-GridDhtPartitionsExchangeFuture-onDone-td35946.html
> > > > >
> > > > >
> > > > > On Mon, Dec 24, 2018 at 4:23 PM Vyacheslav Daradur <
> daradurvs@gmail.com> wrote:
> > > > > >
> > > > > > Stanislav, thank you for the notes, most of them have been
> resolved. I
> > > > > > answered on GitHub.
> > > > > >
> > > > > >
> > > > > > On Sun, Dec 23, 2018 at 9:34 PM Stanislav Lukyanov
> > > > > > <stanlukyanov@gmail.com> wrote:
> > > > > > >
> > > > > > > I’ve done a quick superficial review. Didn’t look at
the
> tests, didn’t dive into the design, etc, just the code.
> > > > > > > I’ve left some comments – almost all are about minor
issues,
> grammar and code style.
> > > > > > >
> > > > > > > Stan
> > > > > > >
> > > > > > > From: Vyacheslav Daradur
> > > > > > > Sent: 21 декабря 2018 г. 14:58
> > > > > > > To: dev@ignite.apache.org
> > > > > > > Subject: Re: Service grid redesign
> > > > > > >
> > > > > > > Igniters,
> > > > > > >
> > > > > > > Please, let us know if someone is going to do an additional
> review?
> > > > > > >
> > > > > > > We should know can we merge the PR since it has been approved
> by
> > > > > > > Nikolay Izhikov and Denis Mekhanikov or we should wait
for
> other
> > > > > > > community members.
> > > > > > >
> > > > > > > On Thu, Dec 20, 2018 at 7:52 PM Vyacheslav Daradur <
> daradurvs@gmail.com> wrote:
> > > > > > > >
> > > > > > > > I think I found names which should satisfy me and
Denis, and
> possibly Nikolay )
> > > > > > > >
> > > > > > > > See the following names (Actual name <- Previously
used):
> > > > > > > >
> > > > > > > > - ServiceDeploymentManager <- ServicesDeploymentManager
> > > > > > > > - ServiceDeploymentActions <- ServicesDeploymentActions
> > > > > > > > - ServiceDeploymentProcessId <- ServicesDeploymentProcessId
> > > > > > > > - ServiceDeploymentTask <- ServicesDeploymentTask
> > > > > > > >
> > > > > > > > - ServiceDeploymentRequest <- ServiceDeploymentChange
> > > > > > > > - ServiceUndeploymentRequest <- ServiceUndeploymentChange
> > > > > > > > - ServiceChangeAbstractRequest <- ServiceAbstractChange
> > > > > > > >
> > > > > > > > - ServiceSingleNodeDeploymentResult <-
> ServiceSingleDeploymentsResults
> > > > > > > > - ServiceSingleNodeDeploymentResultBatch <-
> ServicesSingleDeploymentsMessage
> > > > > > > >
> > > > > > > > - ServiceClusterDeploymentResult <-
> ServiceFullDeploymentsResults
> > > > > > > > - ServiceClusterDeploymentResultBatch <-
> ServicesFullDeploymentsMessage
> > > > > > > >
> > > > > > > > - ServiceProcessorCommonDiscoveryData <-
> ServicesCommonDiscoveryData
> > > > > > > > - ServiceProcessorJoinNodeDiscoveryData <-
> ServicesJoinNodeDiscoveryData
> > > > > > > >
> > > > > > > > Also, I had a short talk with Alexey Goncharuk about
the
> problem of
> > > > > > > > nullified custom messages. I changed the implementation
to a
> lock-free
> > > > > > > > solution which allows us to nullify messages depend
on an
> using
> > > > > > > > counter.
> > > > > > > >
> > > > > > > > In comparison with high priority listener, this allows
us to
> not copy
> > > > > > > > custom discovery event in service deployment manager
and
> work with the
> > > > > > > > original object.
> > > > > > > >
> > > > > > > > On Thu, Dec 20, 2018 at 8:57 AM Nikolay Izhikov <
> nizhikov@apache.org> wrote:
> > > > > > > > >
> > > > > > > > > Denis, great news!
> > > > > > > > >
> > > > > > > > > Alexey, Vova, Yakov, do you want to take a look
at this PR?
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > В Ср, 19/12/2018 в 18:47 +0300, Denis Mekhanikov
пишет:
> > > > > > > > > > Guys,
> > > > > > > > > >
> > > > > > > > > > I finished my code review. The pool request
looks good
> to me.
> > > > > > > > > >
> > > > > > > > > > Does anybody else want to look at the changes?
> > > > > > > > > > There are a few points, that we didn't meet
an agreement
> on,
> > > > > > > > > > though they don't affect the behaviour in
any way:
> > > > > > > > > >
> > > > > > > > > >    - *Class naming. * See the discussion
above.
> > > > > > > > > >    - *Unnecessary task object cleaning.
*
> > > > > > > > > >    IMO, ServicesDeploymentTask#clear() method
doesn't do
> anything useful,
> > > > > > > > > >    and it should be removed.
> > > > > > > > > >    By the moment, when this method is called,
the task
> object is removed
> > > > > > > > > >    from all collections anyway, so it's
ready for
> garbage collection.
> > > > > > > > > >    Removing data from it doesn't help anybody.
> > > > > > > > > >    -
> > > > > > > > > > *Unnecessary tests. *ServiceInfoSelfTest
and
> > > > > > > > > >    ServicesDeploymentProcessIdSelfTest look
excessive to
> me.
> > > > > > > > > >    I don't see any point in testing an interface
> implementation, that only
> > > > > > > > > >    saves some objects and returns them from
certain
> methods.
> > > > > > > > > >    - Interface for events with
> servicesDeploymentActions() method.
> > > > > > > > > >    Take a look at the discussion:
> > > > > > > > > >
> https://github.com/apache/ignite/pull/4434/files/30e69d9a53ce6ea16c4e9d15354e94360caa719d#r239442342
> > > > > > > > > >
> > > > > > > > > > Also solution with
> *DiscoveryCustomEvent#nullifyingCustomMsgLock* looks
> > > > > > > > > > clumsy to me.
> > > > > > > > > > The problem with nullifying of
> *DiscoveryCustomEvent#customMsg* field can
> > > > > > > > > > be solved
> > > > > > > > > > by making *ServiceDiscoveryListener* a high
priority
> listener.
> > > > > > > > > >
> > > > > > > > > > Or *DiscoveryCustomEvent#customMessage()*
method could
> be marked
> > > > > > > > > > synchronized and
> > > > > > > > > > *GridEventStorageManager#notifyListeners(..)*
method
> could synchronize on
> > > > > > > > > > the event object.
> > > > > > > > > > But this solution is the same, it's just
a matter of
> taste.
> > > > > > > > > >
> > > > > > > > > > If anybody wants to look the the code of
the PR, please
> consider these
> > > > > > > > > > points as well.
> > > > > > > > > >
> > > > > > > > > > Denis
> > > > > > > > > >
> > > > > > > > > > ср, 19 дек. 2018 г. в 17:37, Nikolay
Izhikov <
> nizhikov@apache.org>:
> > > > > > > > > >
> > > > > > > > > > > Denis,
> > > > > > > > > > >
> > > > > > > > > > > I don't think that differences with
your and my naming
> is huge :)
> > > > > > > > > > > And, it's definetely a matter of taste.
> > > > > > > > > > >
> > > > > > > > > > > If there is no any other issues with
PR let's rename
> and move on! :)
> > > > > > > > > > >
> > > > > > > > > > > ср, 19 дек. 2018 г. в 17:32,
Vyacheslav Daradur <
> daradurvs@gmail.com>:
> > > > > > > > > > >
> > > > > > > > > > > > > We have IgniteServiceProcessor
and
> GridServiceProcessor with singular
> > > > > > > > > > > >
> > > > > > > > > > > > "Service"
> > > > > > > > > > > >
> > > > > > > > > > > > Maybe we should rename new 'IgniteServiceProcessor'
> to
> > > > > > > > > > > > 'IgniteServicesProcessor'?
> > > > > > > > > > > >
> > > > > > > > > > > > > And ServiceSingleDeploymentsResults
name doesn't
> make sense to me.
> > > > > > > > > > > > > "Single deployments" doesn't
sound right.
> > > > > > > > > > > >
> > > > > > > > > > > > 'Single' means 'single node',
maybe we should use
> one of the following:
> > > > > > > > > > > > - 'ServicesSingleNodeDeploymentsResults'
> > > > > > > > > > > > - 'ServicesNodeDeploymentsResults'
> > > > > > > > > > > > - 'ServicesInstanceDeploymentsResults'
> > > > > > > > > > > >
> > > > > > > > > > > > On Wed, Dec 19, 2018 at 4:26 PM
Denis Mekhanikov <
> dmekhanikov@gmail.com>
> > > > > > > > > > > > wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > Slava,
> > > > > > > > > > > > > I think, it's better to replace
word "Change" with
> "Request".
> > > > > > > > > > > > >
> > > > > > > > > > > > > Nik,
> > > > > > > > > > > > > We have IgniteServiceProcessor
and
> GridServiceProcessor with singular
> > > > > > > > > > > > > "Service",
> > > > > > > > > > > > > ServicesDeploymentManager
and
> ServicesDeploymentTask with plural
> > > > > > > > > > > >
> > > > > > > > > > > > "Services"
> > > > > > > > > > > > > for some reason.
> > > > > > > > > > > > > So, you need to remember,
where Service and where
> Services is used.
> > > > > > > > > > > > > I think, we should unify
these names.
> > > > > > > > > > > > > And ServiceSingleDeploymentsResults
name doesn't
> make sense to me.
> > > > > > > > > > > > > "Single deployments" doesn't
sound right.
> > > > > > > > > > > > >
> > > > > > > > > > > > > ServicesFullDeploymentsMessage
is derived
> > > > > > > > > > > > > from GridDhtPartitionsFullMessage.
> > > > > > > > > > > > > It doesn't really reflect
its function. This
> message is supposed to
> > > > > > > > > > >
> > > > > > > > > > > mark
> > > > > > > > > > > > > the point in time, when deployment
is finished.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Denis
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > пт, 14 дек. 2018 г.
в 11:30, Vyacheslav Daradur <
> daradurvs@gmail.com>:
> > > > > > > > > > > > >
> > > > > > > > > > > > > > > *1. Testing of
the cache-based implementation
> of the service grid.*
> > > > > > > > > > > > > > > I think, we should
make a test suite, that
> will test the old
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > implementation
> > > > > > > > > > > > > > > until we remove
it from the project.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Agree. This is exactly
what should be done as
> the first step once
> > > > > > > > > > > > > > phase 1 will be merged.
> > > > > > > > > > > > > > I think all tests in
the package:
> > > > > > > > > > > > > > "org.apache.ignite.internal.processors.service"
> should be moved to
> > > > > > > > > > > > > > separate test-suite
and new build-plan should be
> added on TC and
> > > > > > > > > > > > > > included in RunAll.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > *2. DynamicServiceChangeRequest.*
> > > > > > > > > > > > > > > I think, this class
should be splat into two.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Personally, I agree,
but I have faced opposition
> at the design step.
> > > > > > > > > > > > > > I changed to the following
structure:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > abstract class ServiceAbstractChange
implements
> Serializable {
> > > > > > > > > > > > > >     protected final
IgniteUuid srvcId;
> > > > > > > > > > > > > > }
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > class ServiceDeploymentChange
extends
> ServiceAbstractChange {
> > > > > > > > > > > > > >     ServiceConfiguration
cfg;
> > > > > > > > > > > > > > }
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > class ServiceUndeploymentChange
extends
> ServiceAbstractChange { }
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > I hope that further
reviewers will agree with us.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > *3. Naming.*
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > About "Services" ->
"Service" and "Deployments"
> -> "Deployment"
> > > > > > > > > > > > > > Personally, I agree
with Nikolay, because it's
> more descriptive since
> > > > > > > > > > > > > > manages several services,
not single.
> > > > > > > > > > > > > > But, I understand Denis's
point of view, we have
> a lot of classes
> > > > > > > > > > >
> > > > > > > > > > > with
> > > > > > > > > > > > > > "Service" prefix in
naming and "Services" looks
> a bit alien.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > *DynamicServicesChangeRequestBatchMessage
->
> > > > > > > > > > > >
> > > > > > > > > > > > DynamicServiceChangeRequest*
> > > > > > > > > > > > > > Prefix "Dynamic" has
no sense anymore since we
> reworked message
> > > > > > > > > > > > > > structure as in p.2.
so
> "ServiceChangeBatchRequest" will be better
> > > > > > > > > > > > > > name.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > *ServicesSingleDeploymentsMessage
->
> ServiceDeploymentResponse*
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > It's not a response
and is not sent to the
> sender. This message is
> > > > > > > > > > > > > > sent to the coordinator
and contains *single
> node* deployments.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > *ServicesFullDeploymentsMessage
->
> ServiceDeploymentFinishMessage*
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > This should be named
similar way as the previous
> one, but the message
> > > > > > > > > > > > > > contains deployments
of *full set of nodes*.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On Fri, Dec 14, 2018
at 10:58 AM Nikolay Izhikov
> <
> > > > > > > > > > >
> > > > > > > > > > > nizhikov@apache.org>
> > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Hello, Denis.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Great news.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > *1. Testing
of the cache-based
> implementation of the service
> > > > > > > > > > >
> > > > > > > > > > > grid.*
> > > > > > > > > > > > > > > > I think, we
should make a test suite, that
> will test the old
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > implementation> until
we> remove it from the
> project.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Aggree. Let's do
it.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > *2. DynamicServiceChangeRequest.*
> > > > > > > > > > > > > > > > I think, this
class should be splat into two.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Agree. Lets's do
it.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > *ServicesDeploymentManager*,
> *ServicesDeploymentTask *and all
> > > > > > > > > > >
> > > > > > > > > > > other
> > > > > > > > > > > > > > classes> with Services
word in them.
> > > > > > > > > > > > > > > > I think, they
would look better if we use a
> singular word
> > > > > > > > > > >
> > > > > > > > > > > *Service
> > > > > > > > > > > > > > *instead.
> > > > > > > > > > > > > > > > Same for *Deployments*.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Personally, I want
that names as clearly as
> possible reflects class
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > content for reader.
> > > > > > > > > > > > > > > If we deploy *several*
services then it has to
> be Service*S*.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Same for deployment
- if this message will
> initiate single
> > > > > > > > > > >
> > > > > > > > > > > deployment
> > > > > > > > > > > > > > process then it should
use deployment.
> > > > > > > > > > > > > > > otherwise - deployments.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > So my opinion -
it's better to keep current
> naming.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > В Чт, 13/12/2018
в 19:36 +0300, Denis
> Mekhanikov пишет:
> > > > > > > > > > > > > > > > Guys,
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > I've been
looking through the PR by
> Vyacheslav for past few
> > > > > > > > > > >
> > > > > > > > > > > weeks.
> > > > > > > > > > > > > > > > Slava, great
job! You've done an impressive
> amount of work.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > I posted my
comments to the PR and had a few
> calls with Slava.
> > > > > > > > > > > > > > > > I am close
to finishing my review.
> > > > > > > > > > > > > > > > There are
some points, that I'd like to
> settle in this discussion
> > > > > > > > > > > >
> > > > > > > > > > > > to
> > > > > > > > > > > > > > avoid
> > > > > > > > > > > > > > > > controversy.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > *1. Testing
of the cache-based
> implementation of the service
> > > > > > > > > > >
> > > > > > > > > > > grid.*
> > > > > > > > > > > > > > > > I think, we
should make a test suite, that
> will test the old
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > implementation
> > > > > > > > > > > > > > > > until we
> > > > > > > > > > > > > > > > remove it
from the project.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > *2. DynamicServiceChangeRequest.*
> > > > > > > > > > > > > > > > I think, this
class should be splat into two.
> > > > > > > > > > > > > > > > I don't see
any point in having a single
> class with "*flags"*
> > > > > > > > > > > >
> > > > > > > > > > > > field,
> > > > > > > > > > > > > > that
> > > > > > > > > > > > > > > > shows, what
action it actually represents.
> > > > > > > > > > > > > > > > Usage of *deploy(),
markDeploy(...),
> undeploy(),
> > > > > > > > > > >
> > > > > > > > > > > markUndeploy(...)*
> > > > > > > > > > > > > > looks
> > > > > > > > > > > > > > > > wrong.
> > > > > > > > > > > > > > > > Why not have
a separate message type for
> each action instead?
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > *3. Naming.*
> > > > > > > > > > > > > > > > I suggest
renaming the following classes:
> > > > > > > > > > > > > > > > *ServicesDeploymentManager*,
> *ServicesDeploymentTask *and all
> > > > > > > > > > >
> > > > > > > > > > > other
> > > > > > > > > > > > > > classes
> > > > > > > > > > > > > > > > with Services
word in them.
> > > > > > > > > > > > > > > > I think, they
would look better if we use a
> singular word
> > > > > > > > > > >
> > > > > > > > > > > *Service
> > > > > > > > > > > > > > *instead.
> > > > > > > > > > > > > > > > Same for *Deployments*.
> > > > > > > > > > > > > > > > I propose
the following class names:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > *ServicesDeploymentManager
->
> ServiceDeploymentManager*
> > > > > > > > > > > > > > > > *ServicesDeploymentActions
->
> ServiceDeploymentActions*
> > > > > > > > > > > > > > > > *ServicesDeploymentTask
->
> ServiceDeploymentTask*
> > > > > > > > > > > > > > > > *ServicesCommonDiscoveryData
->
> ServiceCommonDiscoveryData*
> > > > > > > > > > > > > > > > *ServicesJoinNodeDiscoveryData
->
> > > > > > > > > > >
> > > > > > > > > > > ServiceJoiningNodeDiscoveryData*
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > *DynamicServicesChangeRequestBatchMessage
->
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > DynamicServiceChangeRequest*
> > > > > > > > > > > > > > > > *ServicesSingleDeploymentsMessage
->
> ServiceDeploymentResponse*
> > > > > > > > > > > > > > > > *ServicesFullDeploymentsMessage
->
> > > > > > > > > > >
> > > > > > > > > > > ServiceDeploymentFinishMessage*
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > *ServiceSingleDeploymentsResults
->
> > > > > > > > > > >
> > > > > > > > > > > ServiceSingleDeploymentResult*
> > > > > > > > > > > > > > > > *ServiceFullDeploymentsResults
->
> ServiceFullDeploymentResult*
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Let's do this
as the final step of the code
> review to avoid
> > > > > > > > > > > >
> > > > > > > > > > > > repeated
> > > > > > > > > > > > > > > > renaming.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Denis
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > чт, 6 дек.
2018 г. в 15:21, Denis Mekhanikov
> <
> > > > > > > > > > > >
> > > > > > > > > > > > dmekhanikov@gmail.com>:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Alexey,
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > I don't
see any problem in letting
> services work on a
> > > > > > > > > > >
> > > > > > > > > > > deactivated
> > > > > > > > > > > > > > cluster.
> > > > > > > > > > > > > > > > > All services
need is discovery messages
> and compute tasks.
> > > > > > > > > > > > > > > > > Both
of these features are available at
> all times.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > But it
should be configurable. Services
> may need caches for
> > > > > > > > > > >
> > > > > > > > > > > their
> > > > > > > > > > > > > > work,
> > > > > > > > > > > > > > > > > so it's
better to undeploy such services
> on cluster
> > > > > > > > > > >
> > > > > > > > > > > deactivation.
> > > > > > > > > > > > > > > > > We may
introduce a new property in
> ServiceConfiguration.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > I think,
this topic deserves a separate
> discussion.
> > > > > > > > > > > > > > > > > Could
you start another thread?
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Denis
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > чт,
6 дек. 2018 г. в 13:27, Alexey
> Kuznetsov <
> > > > > > > > > > > >
> > > > > > > > > > > > akuznetsov@apache.org
> > > > > > > > > > > > > > > :
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
Hi,   Vyacheslav!
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
I'm thinking about to use Services API
> to implement Web Agent
> > > > > > > > > > > >
> > > > > > > > > > > > as a
> > > > > > > > > > > > > > cluster
> > > > > > > > > > > > > > > > > >
singleton service.
> > > > > > > > > > > > > > > > > >
It will improve Web Console UX, because
> it will not needed to
> > > > > > > > > > > >
> > > > > > > > > > > > start
> > > > > > > > > > > > > > > > > >
separate java program.
> > > > > > > > > > > > > > > > > >
Just start cluster with Web agent
> enabled on cluster
> > > > > > > > > > > >
> > > > > > > > > > > > configuration.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
But in order to do this, I need that
> services should:
> > > > > > > > > > > > > > > > > >
  1) Work when cluster NOT ACTIVE.
> > > > > > > > > > > > > > > > > >
  2) Auto restart with cluster (when
> cluster was restarted).
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
Could we support mentioned features on
> "Service Grid
> > > > > > > > > > >
> > > > > > > > > > > redesign -
> > > > > > > > > > > > > > phase 2" ?
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
Please let me know.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
--
> > > > > > > > > > > > > > > > > >
Alexey Kuznetsov
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > --
> > > > > > > > > > > > > > Best Regards, Vyacheslav
D.
> > > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > --
> > > > > > > > > > > > Best Regards, Vyacheslav D.
> > > > > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > > Best Regards, Vyacheslav D.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Best Regards, Vyacheslav D.
> > > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Best Regards, Vyacheslav D.
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Best Regards, Vyacheslav D.
> >
> >
> >
> > --
> > Best Regards, Vyacheslav D.
>
>
>
> --
> Best Regards, Vyacheslav D.
>

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