gt; > > > > on
> > > > > > >> the
> > > > > > >> > > > > server,
> > > > > > >> > > > > > then we could automatically cancel services that are
> > > > already
8:34, Dmitriy Setrakyan <
> > > > d...@gridgain.com
> > > > > >:
> > > > > >> > > > > >
> > > > > >> > > > > > > On Wed, Aug 16, 2017 at 8:17 AM, Denis Mekhanikov <
> > > > &
t; > >> > > stick
> > > >> > > > to
> > > >> > > > > > > this
> > > >> > > > > > > > principle for services.
> > > >> > > > > > > >
> > > >>
gt; > >> > > > to
> > >> > > > > > > this
> > >> > > > > > > > principle for services.
> > >> > > > > > > >
> > >> > > > > >
; > services will have to either be deployed or failed. However,
> >> hot
> >> > do
> >> > > > you
> >> > > > > > > ensure atomicity here? If you are deploying 10 services, and
> >> > only 1
> >> > > > &
gt; > fails,
>> > > > > > > what do you do with the other 9, given that they have already
>> > been
>> > > > > > deployed
>> > > > > > > and may have started serving API requests?
throw
> > an
> > > > > > > exception?
> > > > > > >
> > > > > >
> > > > > > Makes sense to me. I think throwing exception from async method
> is
> > > > plain
> > > >
> > > > > > вт, 15 авг. 2017 г. в 11:42, Dmitriy Setrakyan <
> > > dsetrak...@apache.org
> > > > >:
> > > > > >
> > > > > > > Denis,
> > > > > > >
> > > > > > > I don't think
> > > >
> > > > > > The "deployAllAsync" method should never throw an exception, it
> > > should
> > > > > > always return the future. However, the IgniteFuture.get(...)
> method
> > > > does
> > > > > > throw an
d scenario here. If we use
> > deployAllAsync
> > > > > method
> > > > > > and it throws an exception, then the constructed future won't be
> > > > returned
> > > > > > and we won't have a way to wait for the r
Github user dmekhanikov closed the pull request at:
https://github.com/apache/ignite/pull/2450
---
or your reply!
> > > > >
> > > > > I see a possibility of a bad scenario here. If we use
> deployAllAsync
> > > > method
> > > > > and it throws an exception, then the constructed future won't be
> > > returned
> &
> Dmitriy, thank you for your reply!
> > > >
> > > > I see a possibility of a bad scenario here. If we use deployAllAsync
> > > method
> > > > and it throws an exception, then the constructed future won't be
> > returned
> > > > and we won't
d future won't be
> returned
> > > and we won't have a way to wait for the rest of the services to deploy.
> > > Maybe we should return some king of deployment result, containing a
> > future
> > > along with a collection of failed services, instead of throwing a
gt; > Maybe we should return some king of deployment result, containing a
> future
> > along with a collection of failed services, instead of throwing an
> > exception?
> >
> > пн, 14 авг. 2017 г. в 18:03, Dmitriy Setrakyan <dsetrak...@apache.org>:
> >
&g
GitHub user dmekhanikov opened a pull request:
https://github.com/apache/ignite/pull/2450
IGNITE-5145 add batch service deployment methods
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite ignite-5145
of deployment result, containing a future
along with a collection of failed services, instead of throwing an
exception?
пн, 14 авг. 2017 г. в 18:03, Dmitriy Setrakyan <dsetrak...@apache.org>:
> Hi Denis, I agree, we should have an API for batch service deployment. My
> comments are inline..
Hi Denis, I agree, we should have an API for batch service deployment. My
comments are inline...
On Mon, Aug 14, 2017 at 2:22 AM, Denis Mekhanikov <dmekhani...@gmail.com>
wrote:
> Hi Igniters!
>
> Currently Ignite doesn't have support for batch service deployment, but it
> ma
Hi Igniters!
Currently Ignite doesn't have support for batch service deployment, but it
may be a very useful feature in case of a big number of nodes in a cluster
and services to be deployed. Each deployment includes write into an
internal transactional cache, which is the longest part
19 matches
Mail list logo
