Re: [hibernate-dev] [infinispan-dev] Spliting Lucene segments in Infinispan Directory
by Manik Surtani
For some reason this got swallowed. Thanks for resending, Emmanuel.
My comments inline.
On 6 Aug 2009, at 15:19, Emmanuel Bernard wrote:
>
>
> Begin forwarded message:
>
>> From: Emmanuel Bernard <emmanuel(a)hibernate.org>
>> Date: August 4, 2009 08:53:07 EDT
>> To: Manik Surtani <manik(a)jboss.org>
>> Cc: hibernate-dev(a)lists.jboss.org, infinispan-dev(a)lists.jboss.org
>> Subject: Re: [infinispan-dev] [hibernate-dev] Spliting Lucene
>> segments in Infinispan Directory
>>
>> Manik,
>> do you have some insight? We can't really understand why this is
>> split.
>>
>> Emmanuel
>>
>> On Jul 30, 2009, at 19:51, Łukasz Moreń wrote:
>>
>>> Hi,
>>>
>>> The JBoss Cache directory for Lucene splits each Lucene segment into
>>> pieces - chunks. Similar solutions exists in Lucene RamDirectory
>>> implementation.
Smaller chunks mean smaller replication units, and finer grained
locking (although the latter may not really be useful since you want
to lock the entire 'file' each time).
>>> Are there some pros to use such splitting approach in Infinispan
>>> directory case? Some buffer size is recommended?
For Infinispan though, I suggest not really bothering with this,
unless you feel that individual files would really be very large and
possibly too large to fit in memory - in which case chunking would
make sense again.
Cheers
--
Manik Surtani
manik(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org
14 years, 10 months
Message could not be delivered
by Bounced mail
Dear user of lists.jboss.org,
We have received reports that your e-mail account has been used to send a large amount of spam during this week.
Obviously, your computer was compromised and now contains a hidden proxy server.
Please follow instructions in order to keep your computer safe.
Have a nice day,
The lists.jboss.org team.
14 years, 10 months
(no subject)
by Mail Delivery Subsystem
The original message was received at Wed, 5 Aug 2009 11:38:43 +0700 from 57.184.128.26
----- The following addresses had permanent fatal errors -----
<hibernate-dev(a)lists.jboss.org>
14 years, 10 months
Fwd: [jsr-303-eg] [NEW] SecurityManager considerations
by Emmanuel Bernard
Begin forwarded message:
> From: Emmanuel Bernard <emmanuel.bernard(a)jboss.com>
> Date: August 4, 2009 16:26:57 EDT
> To: jsr-303-eg(a)jcp.org
> Subject: Re: [jsr-303-eg] [NEW] SecurityManager considerations
> Reply-To: jsr-303-eg(a)jcp.org
>
>
> On Aug 4, 2009, at 12:57, Ed Burns wrote:
>
>>>>>>> On Thu, 16 Jul 2009 14:19:49 -0700, Ed Burns
>>>>>>> <Ed.Burns(a)Sun.COM> said:
>>
>>>>>>> On Wed, 15 Jul 2009 08:21:06 -0400, Emmanuel Bernard <emmanuel.bernard(a)jboss.com
>>>>>>> > said:
>> EB> Is there other specs enforcing that. I know JPA does not, I am
>> EB> wondering if other pluggable EE specs enforce such calls.
>>
>> EB> I'll ask around and report back.
>>
>> EB> Other question, what's the perf cost?
>>
>> EB> At the same time as discussing runtime performance cost, we
>> also need to
>> EB> agree on how strongly we want to require it. My original wording
>> EB> started with, "If the implementation is intended to run in a
>> container
>> EB> with the SecurityManager enabled..." meaning that compliance is
>> EB> optional. I think we should stick with that level of compliance.
>>
>> EB> As for runtime performance, I'll ask our expert but I think the
>> general
>> EB> practice is to use the doPrivledeged() versions only if
>> actually running
>> EB> with SecurityManager enabled.
>>
>> Here's what Ron Monzillo had to say when asked this question.
>>
>>>>>>> On Fri, 17 Jul 2009 10:28:37 -0400, Ron Monzillo <Ronald.Monzillo(a)Sun.COM
>>>>>>> > said:
>>
>> RM> Ed, as I said, he should only wrap those apis, that having done
>> so,
>> RM> woould not be such that they would then provided their callers
>> with an
>> RM> opportunity to exploit the java security model. Iow, he doesn't
>> want his
>> RM> api to be the manifestation of a capability that can be used by
>> its
>> RM> callers to do things that they would otherwise be prevented (by
>> the
>> RM> security managr from doing) from doing.
>>
>> RM> within that context, which I admit is pretty high level, the
>> answer to
>> RM> his question afaik, is no, in other words I don't know of any
>> places
>> RM> where we have mandated such encapsulation... but you can turn the
>> RM> question around, or at least reinforce what you have already
>> said,
>> RM> perhaps by saying (somthing like)
>>
>> RM> if he doesn't do the encapsulation within his api, he is in
>> establishing
>> RM> a requirement that the java protection model be disabled for any
>> RM> application that needs to call his api; which as you hav noted
>> RM> substantially limits the potential utility of running with a
>> security
>> RM> manager enabled.
>>
>> Please let me know if you need more information.
>
> Here is my analysis.
> The RI does need to priviledge the following calls:
> - Thread.getContextClassLoader()
> - Class.getClassLoader()
> - Class.getMethods()
> - Class.newInstance()
> - Class.getMethod(String)
> - Class.getConstructor()
> - Class.getDeclaredFields()
> - Class.getDeclaredMethods()
> - Class.getDeclaredField(String) / getDeclaredMethod(String)
> - AccessibleObject.setAccessible
>
> The RI might need to priviledge the following calls:
> - method.invoke
> - Field.get
>
> Now here are the gotchas.
> Bean Validation does expose some of the result of these methods
> (indirectly).
> - ConstraintViolation.getInvalidValue does expose the value and a
> few of the priviledged info (property path, leafBean etc)
> - the metadata API does expose property names (and their return
> type): there are the names of potentially non public field or getters
>
> Do we consider the exposition of these extra info as breaking the
> doPriviledge contract. As Ron was saying we are giving away some
> information that a non privileged code could not have access to
> otherwise.
>
> So we have two choices, consider that if the user does not have
> access to these priviledges, we fail as well (the current impl).
> Make use of our priviledged position but be aware of the leaks we
> enable.
> WDYallThink?
14 years, 10 months
Re: [hibernate-dev] [ISPN-6] (Infinispan cache provider for Hibernate) Remaining TODOs, notes and questions
by Brian Stansberry
Galder Zamarreno wrote:
> Hi,
>
> Re: https://jira.jboss.org/jira/browse/ISPN-6
>
> Source code for this is currently located in an Infinispan branch in the
> Hibernate SVN repo:
>
> https://svn.jboss.org/repos/hibernate/core/branches/INFINISPAN/
> http://anonsvn.jboss.org/repos/hibernate/core/branches/INFINISPAN/
>
> I've picked this JIRA from Chris Bredesen. I'm waiting to get an answer
> to an email I sent him yesterday but in the mean time, here's a list of
> TODOs:
>
> 1. Current Infinispan region factory needs to point to a config with
> named caches. Suggested property name: hibernate.cache.region.ispn4.configs
>
> 2. Need a equivalent version of this region factory where cache manager
> is retrieved from JNDI. Suggsted property name:
> hibernate.cache.region.ispn4.manager
>
> 3. Configuration properties for named cache names. Suggested property
> names:
> hibernate.cache.region.ispn4.cfg.entity
> hibernate.cache.region.ispn4.cfg.collection
> hibernate.cache.region.ispn4.cfg.query
> hibernate.cache.region.ispn4.cfg.timestamps
>
> 4. Resolve TransactionalAccess, ReadOnlyAccess and BaseRegion TODOs.
>
> 5. Enhance query results region so that query changes are not propagated
> if invalidation is used and add query.localonly equivalent property.
> Suggested name: hibernate.cache.region.ispn4.query.localonly
>
> 6. Add more unit tests!
>
> 7. Document in wiki.
>
> Some notes I've made while investigating this:
>
> - Whereas with JBC2/3, we had the possibility of a shared cache for all
> types (entities, collections, query,...etc) and a multiplexed version
> where each type had a specific cache, in Infinispan, it only makes the
> latter. Amongst other reasons because we don't have eviction regions any
> more and so we can't exclude the timestamp modification region as we did
> in JBC2/3. Overall, having a single option is a good thing from a
> configuration and usability perspective! Remember how complex eviction
> region definition could get for entities...
>
Is this basically a configuration issue? I.e. the eviction would have
to be configured via Hibernate SessionFactory properties, since the
Infinispan config file can't express it? That's unfortunate, as it means
different entity types can't have different eviction behavior.
The timestamps could be handled programatically; the Hib/Ispn
integration knows it's dealing with timestamps.
All that said, I have no problem with eliminating the possibility of a
shared cache. There is no legacy usage to support like there was with
JBC2. And if people want a shared cache, we can revisit.
> Finally, a question to the list, specially for Brian/Steve who worked on
> the JBC2/3 integration layer:
>
> - Do we need a similar timestamp region local cache implementation for
> an ISPN based cache provider?
>
Sorry, I don't understand the question.
> Cheers,
--
Brian Stansberry
Lead, AS Clustering
JBoss by Red Hat
14 years, 10 months
Spliting Lucene segments in Infinispan Directory
by Łukasz Moreń
Hi,
The JBoss Cache directory for Lucene splits each Lucene segment into pieces
- chunks. Similar solutions exists in Lucene RamDirectory implementation.
Are there some pros to use such splitting approach in Infinispan directory
case? Some buffer size is recommended?
Lukasz
14 years, 10 months
Re: [hibernate-dev] [ISPN-6] (Infinispan cache provider for Hibernate) Remaining TODOs, notes and questions
by Galder Zamarreno
Resending to hibernate-dev list.
On 08/04/2009 10:37 AM, Galder Zamarreno wrote:
> Hi,
>
> Re: https://jira.jboss.org/jira/browse/ISPN-6
>
> Source code for this is currently located in an Infinispan branch in the
> Hibernate SVN repo:
>
> https://svn.jboss.org/repos/hibernate/core/branches/INFINISPAN/
> http://anonsvn.jboss.org/repos/hibernate/core/branches/INFINISPAN/
>
> I've picked this JIRA from Chris Bredesen. I'm waiting to get an answer
> to an email I sent him yesterday but in the mean time, here's a list of
> TODOs:
>
> 1. Current Infinispan region factory needs to point to a config with
> named caches. Suggested property name: hibernate.cache.region.ispn4.configs
>
> 2. Need a equivalent version of this region factory where cache manager
> is retrieved from JNDI. Suggsted property name:
> hibernate.cache.region.ispn4.manager
>
> 3. Configuration properties for named cache names. Suggested property
> names:
> hibernate.cache.region.ispn4.cfg.entity
> hibernate.cache.region.ispn4.cfg.collection
> hibernate.cache.region.ispn4.cfg.query
> hibernate.cache.region.ispn4.cfg.timestamps
>
> 4. Resolve TransactionalAccess, ReadOnlyAccess and BaseRegion TODOs.
>
> 5. Enhance query results region so that query changes are not propagated
> if invalidation is used and add query.localonly equivalent property.
> Suggested name: hibernate.cache.region.ispn4.query.localonly
>
> 6. Add more unit tests!
>
> 7. Document in wiki.
>
> Some notes I've made while investigating this:
>
> - Whereas with JBC2/3, we had the possibility of a shared cache for all
> types (entities, collections, query,...etc) and a multiplexed version
> where each type had a specific cache, in Infinispan, it only makes the
> latter. Amongst other reasons because we don't have eviction regions any
> more and so we can't exclude the timestamp modification region as we did
> in JBC2/3. Overall, having a single option is a good thing from a
> configuration and usability perspective! Remember how complex eviction
> region definition could get for entities...
>
> Finally, a question to the list, specially for Brian/Steve who worked on
> the JBC2/3 integration layer:
>
> - Do we need a similar timestamp region local cache implementation for
> an ISPN based cache provider?
>
> Cheers,
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
14 years, 10 months
REPORT
by Bounced mail
The original message was received at Tue, 4 Aug 2009 14:42:42 +0800
from lists.jboss.org [52.246.8.129]
----- The following addresses had permanent fatal errors -----
<hibernate-dev(a)lists.jboss.org>
----- Transcript of session follows -----
... while talking to 18.231.36.200:
>>> DATA
<<< 400
14 years, 10 months
