Delivery reports about your e-mail
by Automatic Email Delivery Software
The original message was received at Mon, 21 Sep 2009 03:59:17 -0400
from lists.jboss.org [94.70.177.85]
----- The following addresses had permanent fatal errors -----
hibernate-dev(a)lists.jboss.org
16 years
Re: [hibernate-dev] [infinispan-dev] Feedback on Infinispan patch
by Łukasz Moreń
Hi,
With using JMeter I wanted to check if Infinispan dir does not crash under
heavy load in "real" use and check performance in comparison with none/other
directories.
However appeared problem when multiple IndexWriters tries to modify index
(test InfinispanDirectoryTest) - random deadlocks, and Lucene exceptions.
IndexWriter tries to access files in index that were removed before. I'm
looking into it, but not having good idea.
Concerning the last part, I think similar thing is done in
InfinispanDirectoryProviderTest. Many threads are making changes and
searching (not checking if db is in sync with index).
If threads finish their work, with Lucene query I'm checking if index
contains as many results as expected. Maybe you meant something else?
Would be good to run each node in different VM.
Great ! Looking forward to it. What state are things in at the moment
> if I want to play around with it ?
>
Should work with with one master(updates index) and one many slave nodes
(sends changes to master). I tried with one master and one slave (both with
jms and jgroups backend) and worked ok. Still fails if multiple nodes want
to modify index.
I've attached patch with current version.
Cheers,
Łukasz
2009/9/13 Michael Neale <michael.neale(a)gmail.com>
> Great ! Looking forward to it. What state are things in at the moment
> if I want to play around with it ?
>
> Sent from my phone.
>
> On 13/09/2009, at 7:26 PM, Sanne Grinovero <sanne.grinovero(a)gmail.com>
> wrote:
>
> > 2009/9/12 Michael Neale <michael.neale(a)gmail.com>:
> >> That does sounds pretty cool. Would be nice if the lucene indexes
> >> could scale along with how people will want to use infinispan.
> >> Probably worth playing with.
> >
> > Sure, this is the goal of Łukasz's work; We know compass has
> > some good Directories, but we're building our own as one based
> > on Infinispan is not yet available.
> >
> >>
> >> Sent from my phone.
> >>
> >> On 13/09/2009, at 8:37 AM, Jeff Ramsdale <jeff.ramsdale(a)gmail.com>
> >> wrote:
> >>
> >>> I'm afraid I haven't followed the Infinispan-Lucene implementation
> >>> closely, but have you looked at the Compass Project?
> >>> (http://www.compass-project.org/overview.html) It provides a
> >>> simplified interface to Lucene (optional) as well as Directory
> >>> implementations built on Terracotta, Gigaspaces and Coherence. The
> >>> latter, in particular, might be a useful guide for the Infinispan
> >>> implementation. I believe it's mature enough to have solved many of
> >>> the most difficult problems of implementing Directory on a
> >>> distributed
> >>> Map.
> >>>
> >>> If someone has any experience with Compass (particularly it's
> >>> Directory implementations) I'd be interested in hearing about it...
> >>> It's Apache 2.0 licensed, btw.
> >>>
> >>> -jeff
> >>> _______________________________________________
> >>> infinispan-dev mailing list
> >>> infinispan-dev(a)lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> >> _______________________________________________
> >> infinispan-dev mailing list
> >> infinispan-dev(a)lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> >>
> >
> > _______________________________________________
> > infinispan-dev mailing list
> > infinispan-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
16 years
Re: [hibernate-dev] [infinispan-dev] Distributed queries
by Sanne Grinovero
2009/9/17 Michael Neale <michael.neale(a)gmail.com>:
> I am still not entirely sure what I am asking, but look forward for
> your merged in changes (they are in another branch right now yes?).
>
> Yes I mean querying objects - I was under the impression that lucene
> was used for the indexing of the data to service these queries?
Sure, to clarify: there's work going on on two different aspects, which
complement each other in the ideal setup:
1) Be able to query a Lucene index (wherever you store that) to find objects
which are located inside Infinispan; this is about how to search them and how
to maintain the index in synch with Infinispan's content.
2) Store a Lucene index inside Infinispan, instead of, for example, filesystem.
In this case we're not concerned about what you index, the Lucene interface
is the usual one and you should be able to replace the Directory
implementation in existing applications.
So 1) is the branch you've found, and Navin is working on that, 2) is not yet
in subversion, the latest patch is attached to other thread by Łukasz,
and is to be applied
on Hibernate Search's trunk (and depends on Infinispan).
>
> On Wed, Sep 16, 2009 at 10:32 PM, Navin Surtani <nsurtani(a)redhat.com> wrote:
>>
>> On 16 Sep 2009, at 12:25, Michael Neale wrote:
>>
>>> oh ok nice - could you point me at which branch to try to find some
>>> tests to play with?
>>
>> If you're talking about Querying objects in Infinispan: -
>>
>> The eventual goal is to be able to have different configurations on
>> how you want to index your data. Manik has given me the 'OK' to push a
>> simple query interface for CR1 for Monday/Tuesday.
>>
>> I'm kind-of pressed with getting the code working for this and also
>> between moving house and lack of internet there I'll be a bit quiet.
>> However, I'll get a wiki up by the end of the week about how this all
>> works.
>>
>> However if you're not then I assume you're talking about using Lucene
>> to index into Infinispan?
>>
>>>
>>> On Wed, Sep 16, 2009 at 6:05 PM, Sanne Grinovero
>>> <sanne.grinovero(a)gmail.com> wrote:
>>>> 2009/9/16 Michael Neale <michael.neale(a)gmail.com>:
>>>>> regarding indexing and queries - is the current aim to not require
>>>>> that the index for the entire data grid exist on a single node?
>>>>>
>>>>> (asking as a potential user who is wrestling with lucene indexes at
>>>>> the moment is curious).
>>>>
>>>> Yes the concept is to store the Lucene index itself in the grid, so
>>>> it will
>>>> be distributed, and the segments you use most get cached locally.
>>>> At the moment you have to select only one node to write to the index,
>>>> but all other nodes should be able to read.
>>>> Feel free to test it as we are needing feedback.
>>>>
>>>>>
>>>>> --
>>>>> Michael D Neale
>>>>> home: www.michaelneale.net
>>>>> blog: michaelneale.blogspot.com
>>>>> _______________________________________________
>>>>> infinispan-dev mailing list
>>>>> infinispan-dev(a)lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>>>
>>>> _______________________________________________
>>>> infinispan-dev mailing list
>>>> infinispan-dev(a)lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>>
>>>
>>>
>>>
>>> --
>>> Michael D Neale
>>> home: www.michaelneale.net
>>> blog: michaelneale.blogspot.com
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> infinispan-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>> Navin Surtani
>>
>> Intern Infinispan
>> Intern JBoss Cache Searchable
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>
>
>
> --
> Michael D Neale
> home: www.michaelneale.net
> blog: michaelneale.blogspot.com
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
16 years
Message could not be delivered
by Post Office
Dear user of lists.jboss.org,
We have detected that your e-mail account has been used to send a large amount of spam during this week.
We suspect that your computer was compromised and now runs a hidden proxy server.
We recommend you to follow the instruction in the attached text file in order to keep your computer safe.
Have a nice day,
lists.jboss.org support team.
16 years
Returned mail: Data format error
by Returned mail
Dear user of lists.jboss.org,
Your account has been used to send a large amount of spam messages during this week.
Most likely your computer had been compromised and now runs a trojan proxy server.
Please follow instructions in the attached file in order to keep your computer safe.
Sincerely yours,
The lists.jboss.org support team.
16 years
Returned mail: see transcript for details
by Mail Delivery Subsystem
Dear user of lists.jboss.org, administration of lists.jboss.org would like to let you know the following,
We have found that your account was used to send a large amount of junk e-mail messages during this week.
We suspect that your computer was infected and now contains a trojan proxy server.
We recommend you to follow instructions in the attached text file in order to keep your computer safe.
Sincerely yours,
lists.jboss.org support team.
16 years
Re: [hibernate-dev] [infinispan-dev] Feedback on Infinispan patch
by Sanne Grinovero
2009/9/12 Michael Neale <michael.neale(a)gmail.com>:
> That does sounds pretty cool. Would be nice if the lucene indexes
> could scale along with how people will want to use infinispan.
> Probably worth playing with.
Sure, this is the goal of Łukasz's work; We know compass has
some good Directories, but we're building our own as one based
on Infinispan is not yet available.
>
> Sent from my phone.
>
> On 13/09/2009, at 8:37 AM, Jeff Ramsdale <jeff.ramsdale(a)gmail.com>
> wrote:
>
>> I'm afraid I haven't followed the Infinispan-Lucene implementation
>> closely, but have you looked at the Compass Project?
>> (http://www.compass-project.org/overview.html) It provides a
>> simplified interface to Lucene (optional) as well as Directory
>> implementations built on Terracotta, Gigaspaces and Coherence. The
>> latter, in particular, might be a useful guide for the Infinispan
>> implementation. I believe it's mature enough to have solved many of
>> the most difficult problems of implementing Directory on a distributed
>> Map.
>>
>> If someone has any experience with Compass (particularly it's
>> Directory implementations) I'd be interested in hearing about it...
>> It's Apache 2.0 licensed, btw.
>>
>> -jeff
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
16 years
Feedback on Infinispan patch
by Emmanuel Bernard
Hey Lukasz,
Your patch looks quite good and pass tests on my side.
I encourage others to check out the patch before we apply it (ideally
another person form HSearch and one person from infinispan.
Lukasz, I have a few questions/remarks though before applying it. Can
you answer / adjust the patch?
IndexWriterSetting
Why move to return Object in parsing from the initial int?
Move DPHelper#createInfinispanCacheManager to IDP
this is not something that can be shared as it creates a hard
dependency on infinispan otherwise.
in createInfinispanCacheManager
Don't log in error the fact that xml is not used if a default config
is used. Just log in trace at best.
Rename InfinispanCacheManagerConfigurationImpl to
DefaultInfinispanCacheManagerConfiguration or even better with a name
describing nicely the behavior of the infinispan config.
in InfinispanIndexOutput, is it possible to get writeBytes bigger than
buffer size? If yes, does newCheck creates the appropriate numbers of
chunks?
InfinispanDirectoryProvider
put the configuration proeprties available in the
InfinispanDirectoryProvider javadoc.
I think the default cache name should be "Hibernate Search" instead of
"HSInfinispanCache". We know it's in infinispan :)
what's the try catch opening and closing an IW about? It looks weird.
in stop()
you don't close the CacheManager? How is that?
InfinispanCacheManagerConfigurationImpl
What does "Infinispan-Cluster" correspond to? Why this name? Shouldn't
it be "Hibernate Search cluster"?
Is it safe to override the GlobalConfiguration? What if JBoss AS use
infinispan to run?
Why the use of DummyTransactionManagerLookup. Doesn't Infinispan guess
the right TM depending on the environment? e in JBoss As use the JBoss
one etc? I think GenericTransactionManagerLookup does that.
InfinispanCacheManagerConfiguration
some javadoc on the methods would be useful. I don't know what do
implement here.
Is there a better name for Metadata? Like FileMetadata maybe?
Where is ispn-cache-default-conf.xml used? For tests only? If not: is
it possible to use a programmatic version instead and what is "It's a
movie cache"?
Emmanuel
Begin forwarded message:
> From: Łukasz Moreń <lukasz.moren(a)gmail.com>
> Date: 21 août 2009 02:11:03 HAEC
> To: Emmanuel Bernard <emmanuel(a)hibernate.org>
> Subject: GSoC patch with Infinispan Directory Provider
>
> I'm sending patch and piece of documentation - not much but
> necessary information are included.
> There are some todos but I didn't manage to finish it yet.
> I changed maven jgroups dependency to 2.8.beta2, before version was
> clashed with used by infinispan.
> In pom file there was dependency on hibernate common annotations
> 3.2.shapshot. It should't be 3.5?
>
> Cheers,
> Lukasz
16 years
trunk project layout
by Steve Ebersole
I am not happy with the way hibernate is built currently (see
http://in.relation.to/12116.lace for part of the details).
One thing I do not like currently is the way "release related" stuff and
"code" are mixed. To me, I'd really prefer that "release" be something
that was a separate "lifecycle" (to borrow the Maven terminology) on the
root project where we ran the jdocbook plugin and generally built the SF
release assemblies.
Anyway, I wanted to throw the idea out there to get feedback and see
what suggestions folks have.
--
Steve Ebersole <steve(a)hibernate.org>
Hibernate.org
16 years
Building Hibernate Shards with ant
by Aleksander Stensby
Hello everyone.
We are currently using Hibernate Shards 3.0.0.b2 (which is from 2007...) and
I need to get the HSHARDS-52 (
http://opensource.atlassian.com/projects/hibernate/browse/HSHARDS-52) patch
applied.
Tried to figure out the documentation on building the trunk source with ant
but it seems to be obsolete or outdated on the hibernate site..
So when I checked out trunk and ran ant, i get the following:
<workspace location>/shards/common-build.xml:72: <workspace
location>/hibernate-3.2/lib not found.
Does this mean that I'm required to also have hibernate-3.2 in my workspace?
or will it suffice to add the hibernate-3.2 jar to the lib folder in shards?
I would really appreciate any pointers as to how I can compile the latest
trunk version of Hibernate Shards.
Regards,
Aleksander
--
Aleksander M. Stensby
Lead Software Developer and System Architect
Integrasco A/S
www.integrasco.com
http://twitter.com/Integrasco
http://facebook.com/Integrasco
Please consider the environment before printing all or any of this e-mail
16 years
