Two options: 1) CHM + Reaper thread (we have something like this in msc) 2) copy infinispan's LIRS map Sent from my iPhone On Sep 5, 2011, at 1:07 PM, Darran Lofthouse <darran.lofthouse(a)jboss.com&gt; wrote: > I have a couple of tasks that are going to need some form of cache with > items to be removed after after a specified timeout, for the API I just > need something that implements the Map interface or similar. > > I don't really want to be bringing in additional dependencies but wanted > to check do we have anything similar already in AS7 so I am not > re-inventing this for the sake of it. > > Regards, > Darran Lofthouse. > _______________________________________________ > jboss-as7-dev mailing list > jboss-as7-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev _______________________________________________ jboss-as7-dev mailing list jboss-as7-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

On 6 September 2011 03:05, Jason Greene&lt;jgreene(a)redhat.com&gt; wrote: > Two options: > > 1) CHM + Reaper thread (we have something like this in msc) > > 2) copy infinispan's LIRS map Infinispan's LIRS is not easy to extract out, you'll have to make significant changes

; maybe you could depend on Infinispan core?

Depending on your needs it might not suite you: LIRS provides a bounded container, so it might drop some values even if the timeout was not reached.

>> >> 2) copy infinispan's LIRS map > > > > Infinispan's LIRS is not easy to extract out, you'll have to make > > significant changes Last I looked it was a small handful of classes. Not a big deal. I think Jesper used it in ironjacamar. The security subsytem directly linked against it. That' something I have been meaning to open a JIRA on, since this is technically not a public API it's likely better to copy.

On 09/06/2011 08:38 AM, Jason T. Greene wrote: >>> >>  2) copy infinispan's LIRS map >> > >> >  Infinispan's LIRS is not easy to extract out, you'll have to make >> >  significant changes > Last I looked it was a small handful of classes. Not a big deal. I think > Jesper used it in ironjacamar. The security subsytem directly linked > against it. That' something I have been meaning to open a JIRA on, since > this is technically not a public API it's likely better to copy. > For the Auth Cache in the Security subsystem, we have 2 use cases: a) Timed Cache. b) Timed Cache with cluster distribution. The former is default usage while the latter is something the user configures. For the cluster aware cache, we brought in direct dependence on Infinispan cache. Jason, we support your insistence on  a smaller infinispan dependence.

On 9/6/11 9:58 AM, Sanne Grinovero wrote: > On 6 September 2011 16:28, Anil Saldhana&lt;Anil.Saldhana(a)redhat.com&gt; wrote: >> On 09/06/2011 08:38 AM, Jason T. Greene wrote: >>>>>>> 2) copy infinispan's LIRS map >>>>> >>>>> Infinispan's LIRS is not easy to extract out, you'll have to make >>>>> significant changes >>> Last I looked it was a small handful of classes. Not a big deal. I think >>> Jesper used it in ironjacamar. The security subsytem directly linked >>> against it. That' something I have been meaning to open a JIRA on, since >>> this is technically not a public API it's likely better to copy. >>> >> For the Auth Cache in the Security subsystem, we have 2 use cases: >> a) Timed Cache. >> b) Timed Cache with cluster distribution. >> >> The former is default usage while the latter is something the user >> configures. >> >> For the cluster aware cache, we brought in direct dependence on >> Infinispan cache. >> >> Jason, we support your insistence on a smaller infinispan dependence. > > +1 from another Infinispan consumer&& developer. > > If you could explain why you don't want to depend on it I'll call > attention on this at the Infinispan meeting, to be held in two weeks, > and see if we can do something in useful time. > If the main reason is bootup time in standalone mode, right now the > testsuite performs a dozen tests per second, to give a rough idea of > where we stand now, but we can work on it more if that's the main > factor. > I don't think we ever spent any effort to optimize the boot time, so > there might be some low hanging fruits. When we were working on 7, code which used infinispan (even without the slow jaxb XML parsing) had to eat close to 500 ms initialization time. I didn't look too deeply into it, but infinispan does reflective analysis and injection which isnt free. Basically at the end of the day, when all we need is a map, there is no reason to expect any initialization time that is not comparable to any other map implemementation (CHM etc).

On 6 September 2011 17:17, Jason T. Greene&lt;jason.greene(a)redhat.com&gt; wrote: > On 9/6/11 9:58 AM, Sanne Grinovero wrote: >> >> On 6 September 2011 16:28, Anil Saldhana&lt;Anil.Saldhana(a)redhat.com&gt; wrote: >>> >>> On 09/06/2011 08:38 AM, Jason T. Greene wrote: >>>>>>>> >>>>>>>> 2) copy infinispan's LIRS map >>>>>> >>>>>> Infinispan's LIRS is not easy to extract out, you'll have to make >>>>>> significant changes >>>> >>>> Last I looked it was a small handful of classes. Not a big deal. I think >>>> Jesper used it in ironjacamar. The security subsytem directly linked >>>> against it. That' something I have been meaning to open a JIRA on, since >>>> this is technically not a public API it's likely better to copy. >>>> >>> For the Auth Cache in the Security subsystem, we have 2 use cases: >>> a) Timed Cache. >>> b) Timed Cache with cluster distribution. >>> >>> The former is default usage while the latter is something the user >>> configures. >>> >>> For the cluster aware cache, we brought in direct dependence on >>> Infinispan cache. >>> >>> Jason, we support your insistence on a smaller infinispan dependence. >> >> +1 from another Infinispan consumer&& developer. >> >> If you could explain why you don't want to depend on it I'll call >> attention on this at the Infinispan meeting, to be held in two weeks, >> and see if we can do something in useful time. >> If the main reason is bootup time in standalone mode, right now the >> testsuite performs a dozen tests per second, to give a rough idea of >> where we stand now, but we can work on it more if that's the main >> factor. >> I don't think we ever spent any effort to optimize the boot time, so >> there might be some low hanging fruits. > > When we were working on 7, code which used infinispan (even without the slow > jaxb XML parsing) had to eat close to 500 ms initialization time. I didn't > look too deeply into it, but infinispan does reflective analysis and > injection which isnt free. > > Basically at the end of the day, when all we need is a map, there is no > reason to expect any initialization time that is not comparable to any other > map implemementation (CHM etc). Right I see your point, for internal usage you could avoid XML parsing and rely on the programmatic configuration, which should be much faster,

but reflection and injection are unlikely to be removed soon. I hope we will bring it significantly under 500 ms (I guess it is already) but obviously it won't ever be as simple as a CHM. If one day you'll have more reasons to need it you could start a local CacheManager early in the boot process to be reused across all internal caching needs.

> > Depending on your needs it might not suite you: LIRS provides a > bounded container, so it might drop some values even if the timeout > was not reached. Thanks Sanne, that is probably not going to meet what I need - one thing I am looking at is better tracking of failed authentication attempts so I wouldn't want someone to be able to force an item out by causing additional entries to be added.

On 09/06/2011 02:50 PM, Sanne Grinovero wrote: >>> >>> Depending on your needs it might not suite you: LIRS provides a >>> bounded container, so it might drop some values even if the timeout >>> was not reached. >> >> Thanks Sanne, that is probably not going to meet what I need - one thing I >> am looking at is better tracking of failed authentication attempts so I >> wouldn't want someone to be able to force an item out by causing additional >> entries to be added. >> > > I really don't know about your plans, but having a limit in the amount > of entries the cache will be able to hold is generally a good idea. Yes in that case I would probably look at an option to just stop accepting remote connection attempts if it appears the server is really under attack - I will start a separate discussion on how people believe that should behave.

On 09/06/2011 02:50 PM, Sanne Grinovero wrote: >>> >>> Depending on your needs it might not suite you: LIRS provides a >>> bounded container, so it might drop some values even if the timeout >>> was not reached. >> >> Thanks Sanne, that is probably not going to meet what I need - one thing I >> am looking at is better tracking of failed authentication attempts so I >> wouldn't want someone to be able to force an item out by causing additional >> entries to be added. >> > > I really don't know about your plans, but having a limit in the amount > of entries the cache will be able to hold is generally a good idea. Yes in that case I would probably look at an option to just stop accepting remote connection attempts if it appears the server is really under attack - I will start a separate discussion on how people believe that should behave. > A malicious user could otherwise find a pattern to fill the memory of > the AS by sending the appropriate (failing) authentication attempts, > maybe from multiple users. > > Sanne _______________________________________________ jboss-as7-dev mailing list jboss-as7-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev