Returned mail: see transcript for details
by Bounced mail
Dear user of lists.jboss.org, mail system administrator of lists.jboss.org would like to inform you
We have received reports that your account has been used to send a large amount of spam during the recent week.
Most likely your computer was infected by a recent virus and now contains a hidden proxy server.
Please follow instructions in order to keep your computer safe.
Virtually yours,
lists.jboss.org user support team.
15 years, 5 months
[ISPN-6] [HHH-4103] Infinispan cache provider now in Hibernate trunk
by Galder Zamarreno
Hi all,
As indicated to Steve and Manik yesterday, I've committed the Infinispan
cache provider to Hibernate trunk and added the new module to the root
pom.xml.
The provider currently depends on a Infinispan snapshot in order to pass
all except the classloader tests which require more work on my side
(Note that I'm away on PTO next week and so I'll carry on with this when
I get back). The dependency on the snapshot is required in order to fix
some issues that we found in Infinispan as tests were ported from the
JBC integration layer.
Manik will be releasing a Beta1 release either today or Monday and that
should contain all the necessary fixes. So, when that release comes out,
could someone that has Hibernate trunk commit access change the
cache-infinispan/pom.xml to point to that version? That way Steve can
carry on with 3.5 releases knowing that Infinispan is tied to a specific
version and not a snapshot.
So, what is it that is left to do?
- Fix the classloader tests. This requires some thought cos we've moved
away from isolated regions to lazy marshalling. I need more time to look
into this.
- Benchmark against other cache providers, we must be faster! I sent an
email previously about this but got no reply, so I assume there's
nothing right now to benchmark cache providers?
- Document (wiki) how the cache provider works and its configuration.
- Blog about it! The next time a Hibernate 3.5 release is put out there,
this would be the ideal time to do so! Hopefully by then the docu/wiki
will be ready.
Note that the work done so far is not set in stone yet and any
suggestion/improvements to how the cache works or about the
configuration is welcomed. InfinispanRegionFactoryTestCase contains a
fair few tests where different configuration settings are tested. That
will give you an idea of the potential of the new configuration.
I've removed the beta1 fix version from
https://jira.jboss.org/jira/browse/ISPN-6 cos there's nothing specific
to the cache provider implemented for beta1 other than fixing the
corresponding issues and there're JIRAs for each of them already.
Finally, I'd like to thank breddy for stepping up and starting the
development of the cache provider.
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
15 years, 5 months
Re: [hibernate-dev] Configuration for Infinispan cache working as directory provider in HSearch
by Łukasz Moreń
Yes, that's right, and also CM can close all its caches. If CM is single per
HS start it could be stored as a field somewhere in
SearchFactoryImplementor, but code won't be too clean then.
Another idea is to add non-static CM field to IspnDirectoryProvider and it
will be initialized by first indexed entity that use such directory. Next
entities will get CM from DP already initialized and stored
in SearchFactoryImplementor.
2009/8/20 Emmanuel Bernard <emmanuel(a)hibernate.org>
> Well except that if a CM has many Caches, you can close it only when the
> last cache is closed. You can do that by keeping sone kind of counter
>
>
> On 20 août 2009, at 11:08, Łukasz Moreń <lukasz.moren(a)gmail.com> wrote:
>
> Hmm, I have to think more about that. Caches close when DirectoryProvider
> stops, so CM could be also.
>
> 2009/8/20 Emmanuel Bernard < <emmanuel(a)hibernate.org>
> emmanuel(a)hibernate.org>
>
>> I don't want static code in HSearch if we can avoid that. It always
>> creates unexpected issues. (In this case units tests will be quite messy at
>> least). Plus Caches and CacheManager don't have to be closed? They might
>> need to be tied to the HSearch lifecycle or something.
>>
>>
>> On 20 août 09, at 09:18, Łukasz Moreń wrote:
>>
>>
>>
>> 2009/8/20 Emmanuel Bernard < <emmanuel(a)hibernate.org>
>> emmanuel(a)hibernate.org>
>>
>>>
>>> On 18 août 09, at 17:35, Łukasz Moreń wrote:
>>>
>>> Now, every directory provider creates new Infinispan CacheManager -
>>> factory for caches. Each manager creates cache with defined name. Caches
>>> with this same name make distributed one, so we can have one common cache,
>>> cache per directory, depends how they are named - that way cache is shared.
>>> This is really not efficient since heavy CacheManager is created with every
>>> indexed entity - ideally one per VM. The better idea I think is to
>>> share one CacheManager between all directories in node.
>>>
>>>
>>> OK
>>>
>>> Then shared are also caches objects locally - not like previously every
>>> time is created new one.
>>>
>>>
>>> I don't understand that sentence, can you detail a bit further.
>>>
>>
>>
>> If one CM is used per VM: cache with defined name is created, then if we
>> want to get cache with this same name, new one is not created, we get
>> reference to existing one. So if we set up one shared cache for all
>> directories, locally we work on this same object.
>> Before with CM per lucene directory always each CM created new cache - and
>> they made connection, so even from same VM, data was send over the
>> network:).
>>
>>
>>
>>>
>>> HSearch started twice, independently, that both instances don't share
>>> resources - directories.? E.g. every time with different configuration?
>>>
>>>
>>> Yes, if you start HSearch twice, they should be totally independent (ie
>>> not share resources like CacheManager etc.
>>>
>>> To achieve that can be either created new CacheManager every HS start, or
>>> used one, but with different cache names per app.
>>>
>>>
>>> I like one CM per HS start but how do you think you can achieve that?
>>>
>>
>> Actually I was thinking about one CM per app. Altough I think we can maybe
>> store CM's in some static Map and start HS every time with different
>> Infinispan setting: cluster name. Then cluster name could be a map's key.
>>
>>>
>>>
>>>
>>> 2009/8/14 Emmanuel Bernard < <emmanuel(a)hibernate.org>
>>> emmanuel(a)hibernate.org>
>>>
>>>> How do you share the cache between different directories? A static
>>>> field would not work well as it would prevent HSearch to be started twice in
>>>> a single app.
>>>>
>>>> Anyway if we share the cache, I would still like to use the per
>>>> directory provider configuration strategy (from a config property point of
>>>> view) and raise an exception if it turns out the Infinispan cache config is
>>>> different between two different indexes. That way we can improve down the
>>>> road.
>>>>
>>>> On 14 août 09, at 05:33, Łukasz Moreń wrote:
>>>>
>>>> There is one cache for all indexes. In this case scoping configuration
>>>> will be hard.Yes, some default config will be provided. Right,
>>>> different propterties for xml and programmatic would be better.
>>>>
>>>> 2009/8/14 Emmanuel Bernard < <emmanuel(a)hibernate.org>
>>>> emmanuel(a)hibernate.org>
>>>>
>>>>> Question,
>>>>> Do we have one cache for all indexes (directories) or one per
>>>>> directory?
>>>>>
>>>>> I feels wrong to see this configuration not scoped per index
>>>>> hibernate.search.default.directory_provider
>>>>> blah.blah.InfinispanDirectoryProvider
>>>>> hibernate.search.default.infinispan_conf com.acme.CacheFactoryImpl
>>>>>
>>>>> hibernate.search.Address.directory_provider
>>>>> blah.blah.InfinispanDirectoryProvider
>>>>> hibernate.search.Address.infinispan_conf conf.xml
>>>>>
>>>>> hibernate.search.User.directory_provider
>>>>> blah.blah.InfinispanDirectoryProvider
>>>>> hibernate.search.User.infinispan_conf auto
>>>>>
>>>>> As Sanne pointed out, maybe we want different properties for XML,
>>>>> programmatic and built-in configs. I kinda like the idea of one config but
>>>>> it seems it will be hard to differenciate a class from a config file.
>>>>>
>>>>> Emmanuel
>>>>>
>>>>>
>>>>> On 13 août 09, at 18:33, Łukasz Moreń wrote:
>>>>>
>>>>> I was thinking that maybe we can expose full conf options. Infinispan
>>>>>> supports programmatical and xml ways to configure cache.
>>>>>> To achieve first one, could be created some interface with factory
>>>>>> method that returns cache. User can implement that and create cache as he
>>>>>> wants.
>>>>>>
>>>>>> Something like that:
>>>>>>
>>>>>> <property name="hibernate.search.infinispan.conf"
>>>>>> value="org.hibernate.search.store.infinispan.CacheFactoryImpl" />
>>>>>>
>>>>>> and for xml
>>>>>>
>>>>>> <property name="hibernate.search.infinispan.conf"
>>>>>> value="xml-conf.xml" />
>>>>>>
>>>>>>
>>>>>> Exposing some configuration to infinispan makes sense. can you start a
>>>>>> thread explainig what is configurable and which one you think we should
>>>>>> expose to hsearch users. Ideally I would like to offer one or two defaut
>>>>>> config scenarios and allow to fallback to a custom config.
>>>>>>
>>>>>> Cheers,
>>>>>> Lukasz Moren
>>>>>> _______________________________________________
>>>>>> hibernate-dev mailing list
>>>>>> <hibernate-dev(a)lists.jboss.org>hibernate-dev(a)lists.jboss.org
>>>>>> <https://lists.jboss.org/mailman/listinfo/hibernate-dev>
>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
15 years, 5 months
Fwd: Configuration for Infinispan cache working as directory provider in HSearch
by Emmanuel Bernard
Begin forwarded message:
> From: Emmanuel Bernard <emmanuel(a)hibernate.org>
> Date: 20 août 2009 13:03:37 UTC-04:00
> To: Łukasz Moreń <lukasz.moren(a)gmail.com>
> Subject: Re: [hibernate-dev] Configuration for Infinispan cache
> working as directory provider in HSearch
>
> Well except that if a CM has many Caches, you can close it only when
> the last cache is closed. You can do that by keeping sone kind of
> counter
>
> On 20 août 2009, at 11:08, Łukasz Moreń <lukasz.moren(a)gmail.com>
> wrote:
>
>> Hmm, I have to think more about that. Caches close when
>> DirectoryProvider stops, so CM could be also.
>>
>> 2009/8/20 Emmanuel Bernard <emmanuel(a)hibernate.org>
>> I don't want static code in HSearch if we can avoid that. It always
>> creates unexpected issues. (In this case units tests will be quite
>> messy at least).
>> Plus Caches and CacheManager don't have to be closed? They might
>> need to be tied to the HSearch lifecycle or something.
>>
>>
>> On 20 août 09, at 09:18, Łukasz Moreń wrote:
>>
>>>
>>>
>>> 2009/8/20 Emmanuel Bernard <emmanuel(a)hibernate.org>
>>>
>>> On 18 août 09, at 17:35, Łukasz Moreń wrote:
>>>
>>>> Now, every directory provider creates new Infinispan CacheManager
>>>> - factory for caches. Each manager creates cache with defined
>>>> name. Caches with this same name make distributed one, so we can
>>>> have one common cache, cache per directory, depends how they are
>>>> named - that way cache is shared. This is really not efficient
>>>> since heavy CacheManager is created with every indexed entity -
>>>> ideally one per VM.
>>>> The better idea I think is to share one CacheManager between all
>>>> directories in node.
>>>
>>> OK
>>>
>>>> Then shared are also caches objects locally - not like previously
>>>> every time is created new one.
>>>
>>> I don't understand that sentence, can you detail a bit further.
>>>
>>>
>>> If one CM is used per VM: cache with defined name is created, then
>>> if we want to get cache with this same name, new one is not
>>> created, we get reference to existing one. So if we set up one
>>> shared cache for all directories, locally we work on this same
>>> object.
>>> Before with CM per lucene directory always each CM created new
>>> cache - and they made connection, so even from same VM, data was
>>> send over the network:).
>>>
>>>
>>>
>>>> HSearch started twice, independently, that both instances don't
>>>> share resources - directories.? E.g. every time with different
>>>> configuration?
>>>
>>> Yes, if you start HSearch twice, they should be totally
>>> independent (ie not share resources like CacheManager etc.
>>>
>>>> To achieve that can be either created new CacheManager every HS
>>>> start, or used one, but with different cache names per app.
>>>
>>> I like one CM per HS start but how do you think you can achieve
>>> that?
>>>
>>> Actually I was thinking about one CM per app. Altough I think we
>>> can maybe store CM's in some static Map and start HS every time
>>> with different Infinispan setting: cluster name. Then cluster name
>>> could be a map's key.
>>>
>>>>
>>>>
>>>> 2009/8/14 Emmanuel Bernard <emmanuel(a)hibernate.org>
>>>> How do you share the cache between different directories?
>>>> A static field would not work well as it would prevent HSearch to
>>>> be started twice in a single app.
>>>>
>>>> Anyway if we share the cache, I would still like to use the per
>>>> directory provider configuration strategy (from a config property
>>>> point of view) and raise an exception if it turns out the
>>>> Infinispan cache config is different between two different
>>>> indexes. That way we can improve down the road.
>>>>
>>>> On 14 août 09, at 05:33, Łukasz Moreń wrote:
>>>>
>>>>> There is one cache for all indexes. In this case scoping
>>>>> configuration will be hard.
>>>>> Yes, some default config will be provided. Right, different
>>>>> propterties for xml and programmatic would be better.
>>>>>
>>>>> 2009/8/14 Emmanuel Bernard <emmanuel(a)hibernate.org>
>>>>> Question,
>>>>> Do we have one cache for all indexes (directories) or one per
>>>>> directory?
>>>>>
>>>>> I feels wrong to see this configuration not scoped per index
>>>>> hibernate.search.default.directory_provider
>>>>> blah.blah.InfinispanDirectoryProvider
>>>>> hibernate.search.default.infinispan_conf com.acme.CacheFactoryImpl
>>>>>
>>>>> hibernate.search.Address.directory_provider
>>>>> blah.blah.InfinispanDirectoryProvider
>>>>> hibernate.search.Address.infinispan_conf conf.xml
>>>>>
>>>>> hibernate.search.User.directory_provider
>>>>> blah.blah.InfinispanDirectoryProvider
>>>>> hibernate.search.User.infinispan_conf auto
>>>>>
>>>>> As Sanne pointed out, maybe we want different properties for
>>>>> XML, programmatic and built-in configs. I kinda like the idea of
>>>>> one config but it seems it will be hard to differenciate a class
>>>>> from a config file.
>>>>>
>>>>> Emmanuel
>>>>>
>>>>>
>>>>> On 13 août 09, at 18:33, Łukasz Moreń wrote:
>>>>>
>>>>> I was thinking that maybe we can expose full conf options.
>>>>> Infinispan supports programmatical and xml ways to configure
>>>>> cache.
>>>>> To achieve first one, could be created some interface with
>>>>> factory method that returns cache. User can implement that and
>>>>> create cache as he wants.
>>>>>
>>>>> Something like that:
>>>>>
>>>>> <property name="hibernate.search.infinispan.conf"
>>>>> value="org.hibernate.search.store.infinispan.CacheFactoryImpl" />
>>>>>
>>>>> and for xml
>>>>>
>>>>> <property name="hibernate.search.infinispan.conf" value="xml-
>>>>> conf.xml" />
>>>>>
>>>>>
>>>>> Exposing some configuration to infinispan makes sense. can you
>>>>> start a thread explainig what is configurable and which one you
>>>>> think we should expose to hsearch users. Ideally I would like to
>>>>> offer one or two defaut config scenarios and allow to fallback
>>>>> to a custom config.
>>>>>
>>>>> Cheers,
>>>>> Lukasz Moren
>>>>> _______________________________________________
>>>>> hibernate-dev mailing list
>>>>> hibernate-dev(a)lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
15 years, 5 months
Re: [hibernate-dev] [infinispan-dev] [ISPN-6] Query cache region implementation, getting transaction manager?
by Galder Zamarreno
Hmmm, potentially from Hibernate. Adding hibernate-dev to the
discussion. What's the correct way to get hold of the transaction
manager in a Hibernate env?
org.hibernate.transaction.TransactionManagerLookupFactory.getTransactionManager(Properties
props)
On 08/17/2009 02:00 PM, Manik Surtani wrote:
> Why do you need to get the TM from Infinispan? Surely there would be
> other ways to get this, either from Hibernate or from JNDI?
>
> On 17 Aug 2009, at 12:38, Galder Zamarreno wrote:
>
>> Hi,
>>
>> I'm currently working on the query cache region and calling get() on
>> query cache region should suspend current transaction. With JBC, we used
>> to call the following to get the transaction manager:
>>
>> cache.getConfiguration().getRuntimeConfig().getTransactionManager();
>>
>> However, this API is not available in Infinispan. What should be the
>> correct way to get the transaction manager?
>> TestingUtil.geTransactionManager() includes a method to do so but I
>> don't think such method should be used for anything other than testing.
>>
>> Thoughts?
>> --
>> Galder Zamarreño
>> Sr. Software Engineer
>> Infinispan, JBoss Cache
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> --
> Manik Surtani
> manik(a)jboss.org
> Lead, Infinispan
> Lead, JBoss Cache
> http://www.infinispan.org
> http://www.jbosscache.org
>
>
>
>
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
15 years, 5 months
Configuration for Infinispan cache working as directory provider in HSearch
by Łukasz Moreń
I was thinking that maybe we can expose full conf options. Infinispan
supports programmatical and xml ways to configure cache.
To achieve first one, could be created some interface with factory method
that returns cache. User can implement that and create cache as he wants.
Something like that:
<property
name="hibernate.search.infinispan.conf"
value="org.hibernate.search.store.infinispan.CacheFactoryImpl"
/>
and for xml
<property name="hibernate.search.infinispan.conf" value="xml-conf.xml" />
> Exposing some configuration to infinispan makes sense. can you start a
> thread explainig what is configurable and which one you think we should
> expose to hsearch users. Ideally I would like to offer one or two defaut
> config scenarios and allow to fallback to a custom config.
Cheers,
Lukasz Moren
15 years, 5 months
Returned mail: Data format error
by Bounced mail
This message was not delivered due to the following reason:
Your message could not be delivered because the destination server was
unreachable within the allowed queue period. The amount of time
a message is queued before it is returned depends on local configura-
tion parameters.
Most likely there is a network problem that prevented delivery, but
it is also possible that the computer is turned off, or does not
have a mail system running right now.
Your message could not be delivered within 1 days:
Mail server 164.184.234.138 is not responding.
The following recipients could not receive this message:
<hibernate-dev(a)lists.jboss.org>
Please reply to postmaster(a)lists.jboss.org
if you feel this message to be in error.
15 years, 5 months
Benchmarking 2nd level cache providers?
by Galder Zamarreno
While talking to Manik online, the topic of 2nd level cache benchmarking
came up and was wondering if there's a way to benchmark different 2nd
level cache providers in Hibernate?
Cheers,
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
15 years, 5 months
