You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ignite.apache.org by Ognen Duzlevski <og...@gmail.com> on 2015/04/30 22:27:32 UTC
javax.cache close()
This may not be a question for the dev list - can someone point me to a
javadoc explaining the close() method on a javax cache (and hence ignite
cache)?
I have found (in a most unpleasant way ;) that .close() on a cache closes
the cache not only for the current client using it but for everyone
(basically deletes if off the ignite cluster).
Thanks!
Re: javax.cache close()
Posted by Dmitriy Setrakyan <ds...@apache.org>.
On Fri, May 1, 2015 at 11:17 AM, Konstantin Boudnik <co...@apache.org> wrote:
> On Fri, May 01, 2015 at 06:57AM, Ognen Duzlevski wrote:
> > On Fri, May 1, 2015 at 12:59 AM, Andrey Kornev <andrewkornev@hotmail.com
> >
> > wrote:
> >
> > > Dmitriy,
> > > It seems the JCache spec doesn't explicitly require the cache data to
> be
> > > destroyed by a Cache.close() call. See page 38.
> > > The way I interpret (perhaps incorrectly) the semantics on the close()
> is
> > > more like closing of an OS file: all data structures and buffers
> allocated
> > > and managed by the OS kernel on behalf of an application get released,
> but
> > > the file and its data are still there. It's just the application no
> longer
> > > holds a handle to it...
> > > Essentially, Cache.close() closes a specific *instance* of the cache
> > > class. That instance becomes unusable from this moment on, but other
> > > instances of the Cache class for the same named cache may still be
> alive
> > > and kickin'.According to the spec to actually destroy the cache and its
> > > data one should use CacheManager.destroyCache(cacheName)
> > > instead.RegardsAndrey
> > >
> >
> > Andrey, hah, that was exactly my expectation. Imagine my surprise when I
> > found out that a client app I wrote obliterated a multi Gb+ cache in one
> > operation (close) ;)
>
> Agree: that'd seems to be reasonable separation of the functionality. Can
> someone open the JIRA and, perhaps, contribute the patch? From my layman
> standpoint - it might be one of those newbie tickets, but I've been wrong
> before ;)
>
I would like someone from the community to confirm that if Cache.close()
method does not destroy the cache, the JCache TCK still passes. If TCK
still passes, I think we should make the change.
>
> Cos
>
>
Re: javax.cache close()
Posted by Konstantin Boudnik <co...@apache.org>.
On Fri, May 01, 2015 at 06:57AM, Ognen Duzlevski wrote:
> On Fri, May 1, 2015 at 12:59 AM, Andrey Kornev <an...@hotmail.com>
> wrote:
>
> > Dmitriy,
> > It seems the JCache spec doesn't explicitly require the cache data to be
> > destroyed by a Cache.close() call. See page 38.
> > The way I interpret (perhaps incorrectly) the semantics on the close() is
> > more like closing of an OS file: all data structures and buffers allocated
> > and managed by the OS kernel on behalf of an application get released, but
> > the file and its data are still there. It's just the application no longer
> > holds a handle to it...
> > Essentially, Cache.close() closes a specific *instance* of the cache
> > class. That instance becomes unusable from this moment on, but other
> > instances of the Cache class for the same named cache may still be alive
> > and kickin'.According to the spec to actually destroy the cache and its
> > data one should use CacheManager.destroyCache(cacheName)
> > instead.RegardsAndrey
> >
>
> Andrey, hah, that was exactly my expectation. Imagine my surprise when I
> found out that a client app I wrote obliterated a multi Gb+ cache in one
> operation (close) ;)
Agree: that'd seems to be reasonable separation of the functionality. Can
someone open the JIRA and, perhaps, contribute the patch? From my layman
standpoint - it might be one of those newbie tickets, but I've been wrong
before ;)
Cos
Re: javax.cache close()
Posted by Nikita Ivanov <ni...@gmail.com>.
I may have missed that - but did anyone suggest to simply document the
current incorrect behaviour?!? Of course, it has to be fixed according to
spec...
--
Nikita Ivanov
On Sat, May 2, 2015 at 2:18 PM, Andrey Kornev <an...@hotmail.com>
wrote:
> In the spirit of the principle of least surprise, the Cache.close() should
> have non-destructive semantics and only do what the spec's section 4.1.6
> says it should:
>
> "close and release all resources being coordinated on behalf of the Cache
> by the CacheManager. This includes calling the close method on configured
> CacheLoader, CacheWriter, registered CacheEntryListeners and ExpiryPolicy
> instances that implement the java.io.Closeable interface".
>
> And as Brane has said, no amount documentation will prevent people from
> making the same mistake if the close() implementation is left as is now.
>
> Regards
> Andrey
>
> > Date: Fri, 1 May 2015 21:17:19 +0200
> > From: brane@apache.org
> > To: dev@ignite.incubator.apache.org
> > Subject: Re: javax.cache close()
> >
> > On 01.05.2015 13:57, Ognen Duzlevski wrote:
> > > On Fri, May 1, 2015 at 12:59 AM, Andrey Kornev <
> andrewkornev@hotmail.com>
> > > wrote:
> > >
> > >> Dmitriy,
> > >> It seems the JCache spec doesn't explicitly require the cache data to
> be
> > >> destroyed by a Cache.close() call. See page 38.
> > >> The way I interpret (perhaps incorrectly) the semantics on the
> close() is
> > >> more like closing of an OS file: all data structures and buffers
> allocated
> > >> and managed by the OS kernel on behalf of an application get
> released, but
> > >> the file and its data are still there. It's just the application no
> longer
> > >> holds a handle to it...
> > >> Essentially, Cache.close() closes a specific *instance* of the cache
> > >> class. That instance becomes unusable from this moment on, but other
> > >> instances of the Cache class for the same named cache may still be
> alive
> > >> and kickin'.According to the spec to actually destroy the cache and
> its
> > >> data one should use CacheManager.destroyCache(cacheName)
> > >> instead.RegardsAndrey
> > >>
> > > Andrey, hah, that was exactly my expectation. Imagine my surprise when
> I
> > > found out that a client app I wrote obliterated a multi Gb+ cache in
> one
> > > operation (close) ;)
> >
> > Yeah, that really violates the principle of least surprise. No amount of
> > javadoc explanations can fix that ... I'd categorize this as an API
> > implementation bug.
> >
> > -- Brane
>
RE: javax.cache close()
Posted by Andrey Kornev <an...@hotmail.com>.
In the spirit of the principle of least surprise, the Cache.close() should have non-destructive semantics and only do what the spec's section 4.1.6 says it should:
"close and release all resources being coordinated on behalf of the Cache by the CacheManager. This includes calling the close method on configured CacheLoader, CacheWriter, registered CacheEntryListeners and ExpiryPolicy instances that implement the java.io.Closeable interface".
And as Brane has said, no amount documentation will prevent people from making the same mistake if the close() implementation is left as is now.
Regards
Andrey
> Date: Fri, 1 May 2015 21:17:19 +0200
> From: brane@apache.org
> To: dev@ignite.incubator.apache.org
> Subject: Re: javax.cache close()
>
> On 01.05.2015 13:57, Ognen Duzlevski wrote:
> > On Fri, May 1, 2015 at 12:59 AM, Andrey Kornev <an...@hotmail.com>
> > wrote:
> >
> >> Dmitriy,
> >> It seems the JCache spec doesn't explicitly require the cache data to be
> >> destroyed by a Cache.close() call. See page 38.
> >> The way I interpret (perhaps incorrectly) the semantics on the close() is
> >> more like closing of an OS file: all data structures and buffers allocated
> >> and managed by the OS kernel on behalf of an application get released, but
> >> the file and its data are still there. It's just the application no longer
> >> holds a handle to it...
> >> Essentially, Cache.close() closes a specific *instance* of the cache
> >> class. That instance becomes unusable from this moment on, but other
> >> instances of the Cache class for the same named cache may still be alive
> >> and kickin'.According to the spec to actually destroy the cache and its
> >> data one should use CacheManager.destroyCache(cacheName)
> >> instead.RegardsAndrey
> >>
> > Andrey, hah, that was exactly my expectation. Imagine my surprise when I
> > found out that a client app I wrote obliterated a multi Gb+ cache in one
> > operation (close) ;)
>
> Yeah, that really violates the principle of least surprise. No amount of
> javadoc explanations can fix that ... I'd categorize this as an API
> implementation bug.
>
> -- Brane
Re: javax.cache close()
Posted by Branko Čibej <br...@apache.org>.
On 01.05.2015 13:57, Ognen Duzlevski wrote:
> On Fri, May 1, 2015 at 12:59 AM, Andrey Kornev <an...@hotmail.com>
> wrote:
>
>> Dmitriy,
>> It seems the JCache spec doesn't explicitly require the cache data to be
>> destroyed by a Cache.close() call. See page 38.
>> The way I interpret (perhaps incorrectly) the semantics on the close() is
>> more like closing of an OS file: all data structures and buffers allocated
>> and managed by the OS kernel on behalf of an application get released, but
>> the file and its data are still there. It's just the application no longer
>> holds a handle to it...
>> Essentially, Cache.close() closes a specific *instance* of the cache
>> class. That instance becomes unusable from this moment on, but other
>> instances of the Cache class for the same named cache may still be alive
>> and kickin'.According to the spec to actually destroy the cache and its
>> data one should use CacheManager.destroyCache(cacheName)
>> instead.RegardsAndrey
>>
> Andrey, hah, that was exactly my expectation. Imagine my surprise when I
> found out that a client app I wrote obliterated a multi Gb+ cache in one
> operation (close) ;)
Yeah, that really violates the principle of least surprise. No amount of
javadoc explanations can fix that ... I'd categorize this as an API
implementation bug.
-- Brane
Re: javax.cache close()
Posted by Ognen Duzlevski <og...@gmail.com>.
On Fri, May 1, 2015 at 12:59 AM, Andrey Kornev <an...@hotmail.com>
wrote:
> Dmitriy,
> It seems the JCache spec doesn't explicitly require the cache data to be
> destroyed by a Cache.close() call. See page 38.
> The way I interpret (perhaps incorrectly) the semantics on the close() is
> more like closing of an OS file: all data structures and buffers allocated
> and managed by the OS kernel on behalf of an application get released, but
> the file and its data are still there. It's just the application no longer
> holds a handle to it...
> Essentially, Cache.close() closes a specific *instance* of the cache
> class. That instance becomes unusable from this moment on, but other
> instances of the Cache class for the same named cache may still be alive
> and kickin'.According to the spec to actually destroy the cache and its
> data one should use CacheManager.destroyCache(cacheName)
> instead.RegardsAndrey
>
Andrey, hah, that was exactly my expectation. Imagine my surprise when I
found out that a client app I wrote obliterated a multi Gb+ cache in one
operation (close) ;)
Re: javax.cache close()
Posted by Andrey Kornev <an...@hotmail.com>.
Dmitriy,
It seems the JCache spec doesn't explicitly require the cache data to be destroyed by a Cache.close() call. See page 38.
The way I interpret (perhaps incorrectly) the semantics on the close() is more like closing of an OS file: all data structures and buffers allocated and managed by the OS kernel on behalf of an application get released, but the file and its data are still there. It's just the application no longer holds a handle to it...
Essentially, Cache.close() closes a specific *instance* of the cache class. That instance becomes unusable from this moment on, but other instances of the Cache class for the same named cache may still be alive and kickin'.According to the spec to actually destroy the cache and its data one should use CacheManager.destroyCache(cacheName) instead.RegardsAndrey
_____________________________
From: Dmitriy Setrakyan <ds...@apache.org>
Sent: Thursday, April 30, 2015 6:34 PM
Subject: Re: javax.cache close()
To: <de...@ignite.incubator.apache.org>
On Thu, Apr 30, 2015 at 3:27 PM, Ognen Duzlevski <og...@gmail.com>
wrote:
> This may not be a question for the dev list - can someone point me to a
> javadoc explaining the close() method on a javax cache (and hence ignite
> cache)?
>
> I have found (in a most unpleasant way ;) that .close() on a cache closes
> the cache not only for the current client using it but for everyone
> (basically deletes if off the ignite cluster).
>
Added this javadoc in "ignite-sprint-4" branch: Completely deletes the
cache with all its data from the system on all cluster nodes.
Should get into the next release.
>
> Thanks!
>
Re: javax.cache close()
Posted by Dmitriy Setrakyan <ds...@apache.org>.
On Thu, Apr 30, 2015 at 3:27 PM, Ognen Duzlevski <og...@gmail.com>
wrote:
> This may not be a question for the dev list - can someone point me to a
> javadoc explaining the close() method on a javax cache (and hence ignite
> cache)?
>
> I have found (in a most unpleasant way ;) that .close() on a cache closes
> the cache not only for the current client using it but for everyone
> (basically deletes if off the ignite cluster).
>
Added this javadoc in "ignite-sprint-4" branch: Completely deletes the
cache with all its data from the system on all cluster nodes.
Should get into the next release.
>
> Thanks!
>