Ignite.createCache(CacheConfiguration) hangs if some exception occurs during cache initialization Ignite-1049

[voipp]

Hi, Igntrs!
https://issues.apache.org/jira/browse/IGNITE-1094

I've come up with solution. Put exception into
GridDhtPartitionsSingleMessage indicating cache creation failed on local
node. Send it to coordinator.
Coordinator's GridCachePartitionExchangeManager while processing would
extract exchangeId from message and find GridDhtPartitionsExchangeFuture
with the same exchangeId.


Exactly this exchange future must contain DynamicCacheChangeRequest with
cache , causing exception.
Then the cache descriptor could be removed.


But im concerning about exchangeId uniqueness.

--

*Best Regards,*

*Kuznetsov Aleksey*

[Vladimir Ozerov]

Aleksey,
I am thinking on whether we should do this during exchange step or not. In
principle, validation is rather fast operation, so we can do it inside
discovery thread even before descriptor is created and registered.

Alex G., Semen,
What do you think?

On Fri, Apr 28, 2017 at 12:36 PM, ALEKSEY KUZNETSOV <
[hidden email]> wrote:

> Hi, Igntrs!
> https://issues.apache.org/jira/browse/IGNITE-1094
>
> I've come up with solution. Put exception into
> GridDhtPartitionsSingleMessage indicating cache creation failed on local
> node. Send it to coordinator.
> Coordinator's GridCachePartitionExchangeManager while processing would
> extract exchangeId from message and find GridDhtPartitionsExchangeFuture
> with the same exchangeId.
>
>
> Exactly this exchange future must contain DynamicCacheChangeRequest with
> cache , causing exception.
> Then the cache descriptor could be removed.
>
>
> But im concerning about exchangeId uniqueness.
>
> --
>
> *Best Regards,*
>
> *Kuznetsov Aleksey*
>

[voipp]

validation must have involve calling StoreFactory.create() . So we create
store at first?

If so, should we notify coordinator and other nodes about bad cache ?
Perhaps, initiating node should throw exception and don't notify
coordinator, and other nodes should silently keep on working ?

пт, 28 апр. 2017 г. в 16:41, Vladimir Ozerov <[hidden email]>:

> Aleksey,
> I am thinking on whether we should do this during exchange step or not. In
> principle, validation is rather fast operation, so we can do it inside
> discovery thread even before descriptor is created and registered.
>
> Alex G., Semen,
> What do you think?
>
> On Fri, Apr 28, 2017 at 12:36 PM, ALEKSEY KUZNETSOV <
> [hidden email]> wrote:
>
> > Hi, Igntrs!
> > https://issues.apache.org/jira/browse/IGNITE-1094
> >
> > I've come up with solution. Put exception into
> > GridDhtPartitionsSingleMessage indicating cache creation failed on local
> > node. Send it to coordinator.
> > Coordinator's GridCachePartitionExchangeManager while processing would
> > extract exchangeId from message and find GridDhtPartitionsExchangeFuture
> > with the same exchangeId.
> >
> >
> > Exactly this exchange future must contain DynamicCacheChangeRequest with
> > cache , causing exception.
> > Then the cache descriptor could be removed.
> >
> >
> > But im concerning about exchangeId uniqueness.
> >
> > --
> >
> > *Best Regards,*
> >
> > *Kuznetsov Aleksey*
> >
>

--

*Best Regards,*

*Kuznetsov Aleksey*

[voipp]

So, any thoughts?




пт, 28 апр. 2017 г. в 16:54, ALEKSEY KUZNETSOV <[hidden email]>:

> validation must have involve calling StoreFactory.create() . So we create
> store at first?
>
> If so, should we notify coordinator and other nodes about bad cache ?
> Perhaps, initiating node should throw exception and don't notify
> coordinator, and other nodes should silently keep on working ?
>
> пт, 28 апр. 2017 г. в 16:41, Vladimir Ozerov <[hidden email]>:
>
>> Aleksey,
>> I am thinking on whether we should do this during exchange step or not. In
>> principle, validation is rather fast operation, so we can do it inside
>> discovery thread even before descriptor is created and registered.
>>
>> Alex G., Semen,
>> What do you think?
>>
>> On Fri, Apr 28, 2017 at 12:36 PM, ALEKSEY KUZNETSOV <
>> [hidden email]> wrote:
>>
>> > Hi, Igntrs!
>> > https://issues.apache.org/jira/browse/IGNITE-1094
>> >
>> > I've come up with solution. Put exception into
>> > GridDhtPartitionsSingleMessage indicating cache creation failed on local
>> > node. Send it to coordinator.
>> > Coordinator's GridCachePartitionExchangeManager while processing would
>> > extract exchangeId from message and find GridDhtPartitionsExchangeFuture
>> > with the same exchangeId.
>> >
>> >
>> > Exactly this exchange future must contain DynamicCacheChangeRequest with
>> > cache , causing exception.
>> > Then the cache descriptor could be removed.
>> >
>> >
>> > But im concerning about exchangeId uniqueness.
>> >
>> > --
>> >
>> > *Best Regards,*
>> >
>> > *Kuznetsov Aleksey*
>> >
>>
> --
>
> *Best Regards,*
>
> *Kuznetsov Aleksey*
>

--

*Best Regards,*

*Kuznetsov Aleksey*