ApacheDS cache changes

[Emmanuel Lécharny <el...@gmail.com>]

Hi guys,


I'm (slowly) reviewing the way we use cache in ApacheDS, as we need to
use one in Mavibot. Currently, we have a CacheService that is managing
the caches, hidding a bit of their initialization and such things.

I'm not sure it's really well implemented :

- it does not abstract the cache system we use (it's dependent on
ehcache atm)

- it just provide a way to add a cache, remove it or get it

- it depends on a configuration file on disk


The third part is really annoying, especially for those who want to
embed the system.


I do think we have all we need in teh ApacheDS configuration, ie the
cache size. We don't persist anything on disk, we don't use any specific
feature related to the cache system we use.


Here is what I suggest we do :

- make the CacheService cache agnostic : it should work with ehcahce or
any other cache system we might want to use

- mahe the Cache instance we return be an abstraction over the cache
returned by the underlying cache system

- get rid of the configuration file


I don't think it would take long, it's quite isolated in the code (and
that is the only good aspect of the cache service).


If ayone of you have some better idea, or proposal, please feel free to
express yourselves :-)


Thanks !


-- 
Emmanuel Lecharny

Symas.com
directory.apache.org

Re: ApacheDS cache changes

[Emmanuel Lecharny <el...@apache.org>]

Rude words??? It was just the right words to use, I was certainly not
offended at all !!!


Le dim. 5 nov. 2017 à 13:10, Stefan Seelmann <ma...@stefan-seelmann.de> a
écrit :

> On 11/05/2017 12:17 PM, Emmanuel Lecharny wrote:
> > Never mind. I don’t have to commit everything now, I can do that after
> the
> > git conversion.
> >
> > Apacheds trunk is clean, please fell free to proceed !
>
> Ok, thanks Emmanuel, and apolgize for my rude words yesterday :/
>
> > Le sam. 4 nov. 2017 à 15:31, Emmanuel Lécharny <el...@gmail.com> a
> > écrit :
> >
> >>
> >>
> >> Le 04/11/2017 à 13:28, Stefan Seelmann a écrit :
> >>> On 11/04/2017 12:50 PM, Emmanuel Lécharny wrote:
> >>>> Hi guys,
> >>>>
> >>>>
> >>>> I'm (slowly) reviewing the way we use cache in ApacheDS, as we need to
> >>>> use one in Mavibot. Currently, we have a CacheService that is managing
> >>>> the caches, hidding a bit of their initialization and such things.
> >>>>
> >>>> I'm not sure it's really well implemented :
> >>>>
> >>>> - it does not abstract the cache system we use (it's dependent on
> >>>> ehcache atm)
> >>>>
> >>>> - it just provide a way to add a cache, remove it or get it
> >>>>
> >>>> - it depends on a configuration file on disk
> >>>>
> >>>>
> >>>> The third part is really annoying, especially for those who want to
> >>>> embed the system.
> >>>>
> >>>>
> >>>> I do think we have all we need in teh ApacheDS configuration, ie the
> >>>> cache size. We don't persist anything on disk, we don't use any
> specific
> >>>> feature related to the cache system we use.
> >>>>
> >>>>
> >>>> Here is what I suggest we do :
> >>>>
> >>>> - make the CacheService cache agnostic : it should work with ehcahce
> or
> >>>> any other cache system we might want to use
> >>>>
> >>>> - mahe the Cache instance we return be an abstraction over the cache
> >>>> returned by the underlying cache system
> >>>>
> >>>> - get rid of the configuration file
> >>>>
> >>>>
> >>>> I don't think it would take long, it's quite isolated in the code (and
> >>>> that is the only good aspect of the cache service).
> >>>>
> >>>>
> >>>> If ayone of you have some better idea, or proposal, please feel free
> to
> >>>> express yourselves :-)
> >>> Sound good, do that change.
> >>>
> >>> The only concerns I have that
> >>> a) we are in the middle of svn->git migration and
> >>> b) the "value" branch which already lives since March 2016, which
> >>> contains changes not in trunks
> >>>
> >>> I really think we should do that first, finish the git migration and
> >>> merge back the "value" branches, so we have one clear main development
> >>> line, so other contributors are not confused.
> >>
> >> I don't disagree :-)
> >>
> >> As I said before, I have pending changes in the value branch that I
> >> would like to commit before the commit, but considering the litle time I
> >> have to do it properly, it's probably a good timing to commit what I
> >> have, regardless of its status, do the migration, then fix the branch
> >> later.
> >>
> >> Let me do that.
> >>
> >> Thanks for the feedback, Stefan.
> >>
> >> --
> >> Emmanuel Lecharny
> >>
> >> Symas.com
> >> directory.apache.org
> >>
> >> --
> > Regards,
> > Cordialement,
> > Emmanuel Lécharny
> > www.iktek.com
> >
>
> --
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com

Re: ApacheDS cache changes

[Stefan Seelmann <ma...@stefan-seelmann.de>]

On 11/05/2017 12:17 PM, Emmanuel Lecharny wrote:
> Never mind. I don’t have to commit everything now, I can do that after the
> git conversion.
> 
> Apacheds trunk is clean, please fell free to proceed !

Ok, thanks Emmanuel, and apolgize for my rude words yesterday :/

> Le sam. 4 nov. 2017 à 15:31, Emmanuel Lécharny <el...@gmail.com> a
> écrit :
> 
>>
>>
>> Le 04/11/2017 à 13:28, Stefan Seelmann a écrit :
>>> On 11/04/2017 12:50 PM, Emmanuel Lécharny wrote:
>>>> Hi guys,
>>>>
>>>>
>>>> I'm (slowly) reviewing the way we use cache in ApacheDS, as we need to
>>>> use one in Mavibot. Currently, we have a CacheService that is managing
>>>> the caches, hidding a bit of their initialization and such things.
>>>>
>>>> I'm not sure it's really well implemented :
>>>>
>>>> - it does not abstract the cache system we use (it's dependent on
>>>> ehcache atm)
>>>>
>>>> - it just provide a way to add a cache, remove it or get it
>>>>
>>>> - it depends on a configuration file on disk
>>>>
>>>>
>>>> The third part is really annoying, especially for those who want to
>>>> embed the system.
>>>>
>>>>
>>>> I do think we have all we need in teh ApacheDS configuration, ie the
>>>> cache size. We don't persist anything on disk, we don't use any specific
>>>> feature related to the cache system we use.
>>>>
>>>>
>>>> Here is what I suggest we do :
>>>>
>>>> - make the CacheService cache agnostic : it should work with ehcahce or
>>>> any other cache system we might want to use
>>>>
>>>> - mahe the Cache instance we return be an abstraction over the cache
>>>> returned by the underlying cache system
>>>>
>>>> - get rid of the configuration file
>>>>
>>>>
>>>> I don't think it would take long, it's quite isolated in the code (and
>>>> that is the only good aspect of the cache service).
>>>>
>>>>
>>>> If ayone of you have some better idea, or proposal, please feel free to
>>>> express yourselves :-)
>>> Sound good, do that change.
>>>
>>> The only concerns I have that
>>> a) we are in the middle of svn->git migration and
>>> b) the "value" branch which already lives since March 2016, which
>>> contains changes not in trunks
>>>
>>> I really think we should do that first, finish the git migration and
>>> merge back the "value" branches, so we have one clear main development
>>> line, so other contributors are not confused.
>>
>> I don't disagree :-)
>>
>> As I said before, I have pending changes in the value branch that I
>> would like to commit before the commit, but considering the litle time I
>> have to do it properly, it's probably a good timing to commit what I
>> have, regardless of its status, do the migration, then fix the branch
>> later.
>>
>> Let me do that.
>>
>> Thanks for the feedback, Stefan.
>>
>> --
>> Emmanuel Lecharny
>>
>> Symas.com
>> directory.apache.org
>>
>> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
> 

Re: ApacheDS cache changes

[Emmanuel Lecharny <el...@apache.org>]

Never mind. I don’t have to commit everything now, I can do that after the
git conversion.

Apacheds trunk is clean, please fell free to proceed !

Le sam. 4 nov. 2017 à 15:31, Emmanuel Lécharny <el...@gmail.com> a
écrit :

>
>
> Le 04/11/2017 à 13:28, Stefan Seelmann a écrit :
> > On 11/04/2017 12:50 PM, Emmanuel Lécharny wrote:
> >> Hi guys,
> >>
> >>
> >> I'm (slowly) reviewing the way we use cache in ApacheDS, as we need to
> >> use one in Mavibot. Currently, we have a CacheService that is managing
> >> the caches, hidding a bit of their initialization and such things.
> >>
> >> I'm not sure it's really well implemented :
> >>
> >> - it does not abstract the cache system we use (it's dependent on
> >> ehcache atm)
> >>
> >> - it just provide a way to add a cache, remove it or get it
> >>
> >> - it depends on a configuration file on disk
> >>
> >>
> >> The third part is really annoying, especially for those who want to
> >> embed the system.
> >>
> >>
> >> I do think we have all we need in teh ApacheDS configuration, ie the
> >> cache size. We don't persist anything on disk, we don't use any specific
> >> feature related to the cache system we use.
> >>
> >>
> >> Here is what I suggest we do :
> >>
> >> - make the CacheService cache agnostic : it should work with ehcahce or
> >> any other cache system we might want to use
> >>
> >> - mahe the Cache instance we return be an abstraction over the cache
> >> returned by the underlying cache system
> >>
> >> - get rid of the configuration file
> >>
> >>
> >> I don't think it would take long, it's quite isolated in the code (and
> >> that is the only good aspect of the cache service).
> >>
> >>
> >> If ayone of you have some better idea, or proposal, please feel free to
> >> express yourselves :-)
> > Sound good, do that change.
> >
> > The only concerns I have that
> > a) we are in the middle of svn->git migration and
> > b) the "value" branch which already lives since March 2016, which
> > contains changes not in trunks
> >
> > I really think we should do that first, finish the git migration and
> > merge back the "value" branches, so we have one clear main development
> > line, so other contributors are not confused.
>
> I don't disagree :-)
>
> As I said before, I have pending changes in the value branch that I
> would like to commit before the commit, but considering the litle time I
> have to do it properly, it's probably a good timing to commit what I
> have, regardless of its status, do the migration, then fix the branch
> later.
>
> Let me do that.
>
> Thanks for the feedback, Stefan.
>
> --
> Emmanuel Lecharny
>
> Symas.com
> directory.apache.org
>
> --
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com

Re: ApacheDS cache changes

[Emmanuel Lécharny <el...@gmail.com>]

Le 04/11/2017 à 13:28, Stefan Seelmann a écrit :
> On 11/04/2017 12:50 PM, Emmanuel Lécharny wrote:
>> Hi guys,
>>
>>
>> I'm (slowly) reviewing the way we use cache in ApacheDS, as we need to
>> use one in Mavibot. Currently, we have a CacheService that is managing
>> the caches, hidding a bit of their initialization and such things.
>>
>> I'm not sure it's really well implemented :
>>
>> - it does not abstract the cache system we use (it's dependent on
>> ehcache atm)
>>
>> - it just provide a way to add a cache, remove it or get it
>>
>> - it depends on a configuration file on disk
>>
>>
>> The third part is really annoying, especially for those who want to
>> embed the system.
>>
>>
>> I do think we have all we need in teh ApacheDS configuration, ie the
>> cache size. We don't persist anything on disk, we don't use any specific
>> feature related to the cache system we use.
>>
>>
>> Here is what I suggest we do :
>>
>> - make the CacheService cache agnostic : it should work with ehcahce or
>> any other cache system we might want to use
>>
>> - mahe the Cache instance we return be an abstraction over the cache
>> returned by the underlying cache system
>>
>> - get rid of the configuration file
>>
>>
>> I don't think it would take long, it's quite isolated in the code (and
>> that is the only good aspect of the cache service).
>>
>>
>> If ayone of you have some better idea, or proposal, please feel free to
>> express yourselves :-)
> Sound good, do that change.
>
> The only concerns I have that
> a) we are in the middle of svn->git migration and
> b) the "value" branch which already lives since March 2016, which
> contains changes not in trunks
>
> I really think we should do that first, finish the git migration and
> merge back the "value" branches, so we have one clear main development
> line, so other contributors are not confused.

I don't disagree :-)

As I said before, I have pending changes in the value branch that I
would like to commit before the commit, but considering the litle time I
have to do it properly, it's probably a good timing to commit what I
have, regardless of its status, do the migration, then fix the branch later.

Let me do that.

Thanks for the feedback, Stefan.

-- 
Emmanuel Lecharny

Symas.com
directory.apache.org

Re: ApacheDS cache changes

[Stefan Seelmann <ma...@stefan-seelmann.de>]

On 11/04/2017 12:50 PM, Emmanuel Lécharny wrote:
> Hi guys,
> 
> 
> I'm (slowly) reviewing the way we use cache in ApacheDS, as we need to
> use one in Mavibot. Currently, we have a CacheService that is managing
> the caches, hidding a bit of their initialization and such things.
> 
> I'm not sure it's really well implemented :
> 
> - it does not abstract the cache system we use (it's dependent on
> ehcache atm)
> 
> - it just provide a way to add a cache, remove it or get it
> 
> - it depends on a configuration file on disk
> 
> 
> The third part is really annoying, especially for those who want to
> embed the system.
> 
> 
> I do think we have all we need in teh ApacheDS configuration, ie the
> cache size. We don't persist anything on disk, we don't use any specific
> feature related to the cache system we use.
> 
> 
> Here is what I suggest we do :
> 
> - make the CacheService cache agnostic : it should work with ehcahce or
> any other cache system we might want to use
> 
> - mahe the Cache instance we return be an abstraction over the cache
> returned by the underlying cache system
> 
> - get rid of the configuration file
> 
> 
> I don't think it would take long, it's quite isolated in the code (and
> that is the only good aspect of the cache service).
> 
> 
> If ayone of you have some better idea, or proposal, please feel free to
> express yourselves :-)

Sound good, do that change.

The only concerns I have that
a) we are in the middle of svn->git migration and
b) the "value" branch which already lives since March 2016, which
contains changes not in trunks

I really think we should do that first, finish the git migration and
merge back the "value" branches, so we have one clear main development
line, so other contributors are not confused.

Kind Regards,
Stefan