Infinispan tx, config and multithreading
by Emmanuel Bernard
Ok I understand better now.
Do your tests in JBoss AS with it's decent transaction manager
(infinispan should have a config for it)
For unit testing, force the indexing process in hibernate to use a
single thread (I ghnk it's possible ask Sanne of you don't know how).
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.
Emmanuel
On 12 août 2009, at 11:58, Łukasz Moreń <lukasz.moren(a)gmail.com>
wrote:
> Sorry, but my wifi does not work well today. I will try to explain
> it more clear.
>
> I'm using DummyTransactionManager available for Infinispan.
> It associates transaction with the calling thread.
>
> Steps to update index:
>
> 1. index writer acquires lock - begin of transaction
>
> 2. if it is necessary, index writer delegates new threads to do
> merge work.
> Those merge threads do not see changes made so far from begin of
> transaction,
> and are looking for segments which are not yet in index.
> Changes will be visible when AD.3 is completed.
> For tests i tried to commit transaction when merge starts and then
> everything worked well. But then i need to start it again.
>
> 3. index writer releases lock - transaction is commited, all changes
> made in this transaction are visible for other threads.
>
> Maybe using some other transaction manager could help?
>
> What about Infinispan cache configuration? Some configuration
> mechanism should be exposed to the user,
> or we can hardcoded one in InfinispanDirectoryProvider is enough?
>
>
>
>
> 2009/8/12 Emmanuel Bernard <emmanuel(a)hibernate.org>
> why?
> Emmanuel Bernard
> Pending
> you there?
> Emmanuel Bernard
> Pending
> Ok please describe in details what is going on. From what you are
> describing the tx cannot see all segments which looks like an
> infinispan bug to me.
> Pending
>
> As a back up you can try wo transaction and see if that works
> Emmanuel Bernard
> Pending
> technically the lucene index should cope with that
> Emmanuel Bernard
> 11:16
> but I like this approach less
>
>
>
> Let's try and chat by email IF I'm not online, I need to run on some
> errands today.
>
15 years, 5 months
Re: [hibernate-dev] [infinispan-dev] Infinispan tx, config and multithreading
by Emmanuel Bernard
It's a bit complex but the Lucene IndexWriter works better if you can
inject what has to be indexed in a multi threaded way because
analyzing the data before writing it to the index can be heavy.
The IW does rely on what is called a Directory (implemented by
Infinispan in this case).
On 13 août 09, at 17:25, Jason T. Greene wrote:
> Any reason you cant do a transaction per thread? That would be the
> most efficient.
>
> Łukasz Moreń wrote:
>> Newly created threads were not associated with any transaction, so I
>> suppose it was a problem. Sharing transaction between threads seems
>> to
>> be a good solution.
>> Thanks for help!
>> 2009/8/13, Jason T. Greene <jason.greene(a)redhat.com>:
>>> Correct. Also there could be read races as well, so if you are
>>> going to
>>> share a tx between threads, i would use some shared lock to
>>> gaurantee
>>> that only one thread can use it at a time. BTW this means you have
>>> to
>>> properly suspend/resume the TX via the TM API as well.
>>>
>>> Emmanuel Bernard wrote:
>>>> Modifying a transaction means applying muations (like SQL INSERT /
>>>> UPDATE / DELETE) to the transactional resource?
>>>>
>>>> On 13 août 09, at 15:07, Jason T. Greene wrote:
>>>>
>>>>> When using transactions, the context is bound to the
>>>>> transaction, and
>>>>> you can move a transaction between threads. However, you should
>>>>> only
>>>>> be modifying a transaction with one thread at a time.
>>>>>
>>>>> Emmanuel Bernard wrote:
>>>>>> Could it be that you are not using the same transaction between
>>>>>> different threads (ie you physically start different ones or
>>>>>> different "Infinispan contexts")?
>>>>>> Infini guys, do you support transactional operation spanning
>>>>>> several
>>>>>> concurrent threads?
>>>>>> On 13 août 09, at 14:04, Łukasz Moreń wrote:
>>>>>>> I've tried with JBoss AS transaction manager and
>>>>>>> JBossStandaloneTM.
>>>>>>> The result is this same in all cases - error during merge.
>>>>>>>
>>>>>>> 2009/8/12, Emmanuel Bernard <emmanuel(a)hibernate.org>:
>>>>>>>> Ok I understand better now.
>>>>>>>> Do your tests in JBoss AS with it's decent transaction manager
>>>>>>>> (infinispan should have a config for it)
>>>>>>>> For unit testing, force the indexing process in hibernate to
>>>>>>>> use a
>>>>>>>> single thread (I ghnk it's possible ask Sanne of you don't
>>>>>>>> know how).
>>>>>>>>
>>>>>>>> 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.
>>>>>>>>
>>>>>>>> Emmanuel
>>>>>>>>
>>>>>>>> On 12 août 2009, at 11:58, Łukasz Moreń
>>>>>>>> <lukasz.moren(a)gmail.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Sorry, but my wifi does not work well today. I will try to
>>>>>>>>> explain
>>>>>>>>> it more clear.
>>>>>>>>>
>>>>>>>>> I'm using DummyTransactionManager available for Infinispan.
>>>>>>>>> It associates transaction with the calling thread.
>>>>>>>>>
>>>>>>>>> Steps to update index:
>>>>>>>>>
>>>>>>>>> 1. index writer acquires lock - begin of transaction
>>>>>>>>>
>>>>>>>>> 2. if it is necessary, index writer delegates new threads to
>>>>>>>>> do
>>>>>>>>> merge work.
>>>>>>>>> Those merge threads do not see changes made so far from
>>>>>>>>> begin of
>>>>>>>>> transaction,
>>>>>>>>> and are looking for segments which are not yet in index.
>>>>>>>>> Changes will be visible when AD.3 is completed.
>>>>>>>>> For tests i tried to commit transaction when merge starts
>>>>>>>>> and then
>>>>>>>>> everything worked well. But then i need to start it again.
>>>>>>>>>
>>>>>>>>> 3. index writer releases lock - transaction is commited, all
>>>>>>>>> changes
>>>>>>>>> made in this transaction are visible for other threads.
>>>>>>>>>
>>>>>>>>> Maybe using some other transaction manager could help?
>>>>>>>>>
>>>>>>>>> What about Infinispan cache configuration? Some configuration
>>>>>>>>> mechanism should be exposed to the user,
>>>>>>>>> or we can hardcoded one in InfinispanDirectoryProvider is
>>>>>>>>> enough?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 2009/8/12 Emmanuel Bernard <emmanuel(a)hibernate.org>
>>>>>>>>> why?
>>>>>>>>> Emmanuel Bernard
>>>>>>>>> Pending
>>>>>>>>> you there?
>>>>>>>>> Emmanuel Bernard
>>>>>>>>> Pending
>>>>>>>>> Ok please describe in details what is going on. From what
>>>>>>>>> you are
>>>>>>>>> describing the tx cannot see all segments which looks like an
>>>>>>>>> infinispan bug to me.
>>>>>>>>> Pending
>>>>>>>>>
>>>>>>>>> As a back up you can try wo transaction and see if that works
>>>>>>>>> Emmanuel Bernard
>>>>>>>>> Pending
>>>>>>>>> technically the lucene index should cope with that
>>>>>>>>> Emmanuel Bernard
>>>>>>>>> 11:16
>>>>>>>>> but I like this approach less
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Let's try and chat by email IF I'm not online, I need to run
>>>>>>>>> on some
>>>>>>>>> errands today.
>>>>>>>>>
>>>>>> _______________________________________________
>>>>>> infinispan-dev mailing list
>>>>>> infinispan-dev(a)lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>>>
>>>>> --
>>>>> Jason T. Greene
>>>>> JBoss, a division of Red Hat
>>>
>>> --
>>> Jason T. Greene
>>> JBoss, a division of Red Hat
>>>
>
>
> --
> Jason T. Greene
> JBoss, a division of Red Hat
15 years, 5 months
Re: [hibernate-dev] [infinispan-dev] Infinispan tx, config and multithreading
by Emmanuel Bernard
Modifying a transaction means applying muations (like SQL INSERT /
UPDATE / DELETE) to the transactional resource?
On 13 août 09, at 15:07, Jason T. Greene wrote:
> When using transactions, the context is bound to the transaction,
> and you can move a transaction between threads. However, you should
> only be modifying a transaction with one thread at a time.
>
> Emmanuel Bernard wrote:
>> Could it be that you are not using the same transaction between
>> different threads (ie you physically start different ones or
>> different "Infinispan contexts")?
>> Infini guys, do you support transactional operation spanning
>> several concurrent threads?
>> On 13 août 09, at 14:04, Łukasz Moreń wrote:
>>> I've tried with JBoss AS transaction manager and JBossStandaloneTM.
>>> The result is this same in all cases - error during merge.
>>>
>>> 2009/8/12, Emmanuel Bernard <emmanuel(a)hibernate.org>:
>>>> Ok I understand better now.
>>>> Do your tests in JBoss AS with it's decent transaction manager
>>>> (infinispan should have a config for it)
>>>> For unit testing, force the indexing process in hibernate to use a
>>>> single thread (I ghnk it's possible ask Sanne of you don't know
>>>> how).
>>>>
>>>> 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.
>>>>
>>>> Emmanuel
>>>>
>>>> On 12 août 2009, at 11:58, Łukasz Moreń <lukasz.moren(a)gmail.com>
>>>> wrote:
>>>>
>>>>> Sorry, but my wifi does not work well today. I will try to explain
>>>>> it more clear.
>>>>>
>>>>> I'm using DummyTransactionManager available for Infinispan.
>>>>> It associates transaction with the calling thread.
>>>>>
>>>>> Steps to update index:
>>>>>
>>>>> 1. index writer acquires lock - begin of transaction
>>>>>
>>>>> 2. if it is necessary, index writer delegates new threads to do
>>>>> merge work.
>>>>> Those merge threads do not see changes made so far from begin of
>>>>> transaction,
>>>>> and are looking for segments which are not yet in index.
>>>>> Changes will be visible when AD.3 is completed.
>>>>> For tests i tried to commit transaction when merge starts and then
>>>>> everything worked well. But then i need to start it again.
>>>>>
>>>>> 3. index writer releases lock - transaction is commited, all
>>>>> changes
>>>>> made in this transaction are visible for other threads.
>>>>>
>>>>> Maybe using some other transaction manager could help?
>>>>>
>>>>> What about Infinispan cache configuration? Some configuration
>>>>> mechanism should be exposed to the user,
>>>>> or we can hardcoded one in InfinispanDirectoryProvider is enough?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> 2009/8/12 Emmanuel Bernard <emmanuel(a)hibernate.org>
>>>>> why?
>>>>> Emmanuel Bernard
>>>>> Pending
>>>>> you there?
>>>>> Emmanuel Bernard
>>>>> Pending
>>>>> Ok please describe in details what is going on. From what you are
>>>>> describing the tx cannot see all segments which looks like an
>>>>> infinispan bug to me.
>>>>> Pending
>>>>>
>>>>> As a back up you can try wo transaction and see if that works
>>>>> Emmanuel Bernard
>>>>> Pending
>>>>> technically the lucene index should cope with that
>>>>> Emmanuel Bernard
>>>>> 11:16
>>>>> but I like this approach less
>>>>>
>>>>>
>>>>>
>>>>> Let's try and chat by email IF I'm not online, I need to run on
>>>>> some
>>>>> errands today.
>>>>>
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
> --
> Jason T. Greene
> JBoss, a division of Red Hat
15 years, 5 months
GSoC 2009 project at Hibernate Search status
by Łukasz Moreń
Hello,
The deadline for Google Summer of Code 2009 projects is coming soon. Here is
status of my work during GSoC on Hibernate Search:
[+] Hibernate Search backend based on JGroups. I finished it about month ago
and sent patch to hibernate-dev list.
[+] Infinispan Directory to store Lucene indexes
I'm working on that. Currently I'm testing it with many readers and many
Infinispan caches, where index is replicated.It works quite ok,
just with problem with index merging.
There are some things left to do like: "master" node selection, Infinispan
cache configuration available to user, ... , but also some days
are left so I hope to manage with that.
Cheers,
Lukasz Moren
15 years, 5 months
Returned mail: see transcript for details
by The Post Office
j���J�����"�o���f�V3� NN���������*����!��|M^���C"7��F�Y�/$(a��W4�M��a#O>�~m�|��h�j��t�q���0V����W�nA��Q��`�iK\�Q���Z�a�3-()m,�
��}�����5�}SD��i%c���15�H���f��Z������������r��&��{��������
Ky���h���M��ymJ-�2g�����R~*���v���11�I4�r�k�vy�q���&}��v��
����]��v
l���
��n���|o�a�q�U%90��|�����s/G 3�{t��f�Nw�G��i!�Z8O�!�V��'�L��W���[���]��a��]��H`�NB%SR<Z�l������3����p$���n��B���7������h�0[�2�o��{�L����N3�9.��cq�_(f��/���Ph*��#PI�i�fd��m
���u1sV���[he���k����q����m�����t��RS�$�$��>i��'�����e'������F�{�]V(�$���g��h��1��Rx~|�C�Os��34Iu5\��k�lL[��xw���A���^}��p�P1��o�2��v��m�Fy]�A
Wa�g�Hc���g,�v<b�b| ����f��$����w�-��
2����
`^�h�O��9J����**u��^�Y��c�[�
�X[;?���NsW�l�������h����!����FR��2
cr���%�|�P�:��r��`~y���2`k���w^5z�x�I��g������6v0��4V�
j�uU�Z�H
)�K�M�v�ES�z�
blf��'��P�R����rT/��f��CA� (X��Z*}��]����si�2����kH���#_��-�3�)�dq'7U�VK����&�)�B���4
v�W��|��U����u��.9*��bJ�5�7���:(����QHW���G�c#*/�55_�� ��j���
r��������K_��Mi5r��T5��!�T��X6{�Rd��u0Vq��xL�����W�#U�Hr��?��V,�u��#�oz��_���{3��mgc�|�c�������?�����r��'�2\��h����Nd���������3��H����\[�
�I1�u3V/\����c�&W�}�6������t�r�snF�/��LGE]-�l�C�
�S����w�v�A���v�1�r�Wr^�x�_"*y.|�����/����9��U#a��
��I�� �b���!���;�p
YB}-�o���N��F�7�Z
��B�A�d�(����I]�'�^Y'��)�f?�P�O��1�����N,�� �^�,�E� �gs���^����M����X�W�[
e��9Mx6V��<AE�>M��G7����6"�L�&[.8��DI��I�}�K���� *������,06��U{U�)2oBU|�f��E�EWH�$
9%�:��LO�%���.���U���3��wB�:F�`���H ���M�~�M�T��u�b����g����$��3HA���r&�F���rg�*��m����k�D?g�,}S��|��D�t�>�Qh��mO)
#<�M��y��V8�epX�{B�s�6��
15 years, 5 months
Returned mail: Data format error
by MAILER-DAEMON
The original message was received at Thu, 13 Aug 2009 08:57:36 +0530
from [14.10.191.28]
----- The following addresses had permanent fatal errors -----
<hibernate-dev(a)lists.jboss.org>
----- Transcript of session follows -----
... while talking to 24.47.184.110:
>>> DATA
<<< 400-aturner; %MAIL-E-OPENOUT, error opening !AS as output
<<< 400-aturner; -RMS-E-CRE, ACP file create failed
<<< 400-aturner; -SYSTEM-F-EXDISKQUOTA, disk quota exceeded
<<< 400
15 years, 5 months
Re: [hibernate-dev] [infinispan-dev] [ISPN-6] (Infinispan cache provider for Hibernate) Remaining TODOs, notes and questions
by Manik Surtani
On 4 Aug 2009, at 09:37, 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
hibernate.cache.infinispan.cfg ?
- why do we need 'region' in there, non-intuitive to end-users?
- I'd rather use infinispan rather than ispn.
>
> 2. Need a equivalent version of this region factory where cache
> manager
> is retrieved from JNDI. Suggsted property name:
> hibernate.cache.region.ispn4.manager
s/region.ispn4/infinispan
>
> 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
s/region.ispn4/infinispan
>
> 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
>
s/region.ispn4/infinispan
> 6. Add more unit tests!
>
> 7. Document in wiki.
Good stuff, thanks for taking this on!
- Manik
>
> 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
> _______________________________________________
> 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
15 years, 6 months
If Unable to compile core, try this
by Emmanuel Bernard
If you see the following when compiling core/core
mvn clean install or mvn -e clean install
=> do
rm -fR ~/.m2/repository/org/hibernate/
rm -fR ~/.m2/repository/org/jboss/maven/
That does the trick for me.
-------
[INFO] [compiler:compile]
[INFO] Nothing to compile - all classes are up to date
[INFO] [injection:bytecode {execution: default}]
[INFO] Adding project compile classpath element : /Users/manu/projects/
trunk/core/core/target/classes
[INFO] Adding project compile classpath element : /Users/manu/.m2/
repository/antlr/antlr/2.7.6/antlr-2.7.6.jar
[INFO] Adding project compile classpath element : /Users/manu/.m2/
repository/commons-collections/commons-collections/3.1/commons-
collections-3.1.jar
[INFO] Adding project compile classpath element : /Users/manu/.m2/
repository/dom4j/dom4j/1.6.1/dom4j-1.6.1.jar
[INFO] Adding project compile classpath element : /Users/manu/.m2/
repository/xml-apis/xml-apis/1.0.b2/xml-apis-1.0.b2.jar
[INFO] Adding project compile classpath element : /Users/manu/.m2/
repository/javassist/javassist/3.9.0.GA/javassist-3.9.0.GA.jar
[INFO] Adding project compile classpath element : /Users/manu/.m2/
repository/cglib/cglib/2.2/cglib-2.2.jar
[INFO] Adding project compile classpath element : /Users/manu/.m2/
repository/asm/asm/3.1/asm-3.1.jar
[INFO] Adding project compile classpath element : /Users/manu/.m2/
repository/javax/transaction/jta/1.1/jta-1.1.jar
[INFO] Adding project compile classpath element : /Users/manu/.m2/
repository/javax/security/jaas/1.0.01/jaas-1.0.01.jar
[INFO] Adding project compile classpath element : /Users/manu/.m2/
repository/javax/security/jacc/1.0/jacc-1.0.jar
[INFO] Adding project compile classpath element : /Users/manu/.m2/
repository/ant/ant/1.6.5/ant-1.6.5.jar
[INFO] Adding project compile classpath element : /Users/manu/.m2/
repository/org/slf4j/slf4j-api/1.5.8/slf4j-api-1.5.8.jar
[INFO]
------------------------------------------------------------------------
[ERROR] BUILD ERROR
[INFO]
------------------------------------------------------------------------
[INFO] Unable to resolve class file path
[INFO]
------------------------------------------------------------------------
[INFO] Trace
org.apache.maven.lifecycle.LifecycleExecutionException: Unable to
resolve class file path
at
org
.apache
.maven
.lifecycle
.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:
584)
at
org
.apache
.maven
.lifecycle
.DefaultLifecycleExecutor
.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:500)
at
org
.apache
.maven
.lifecycle
.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:479)
at
org
.apache
.maven
.lifecycle
.DefaultLifecycleExecutor
.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:331)
at
org
.apache
.maven
.lifecycle
.DefaultLifecycleExecutor
.executeTaskSegments(DefaultLifecycleExecutor.java:292)
at
org
.apache
.maven
.lifecycle
.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:301)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun
.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:
39)
at
sun
.reflect
.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:
25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:
430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
Caused by: org.apache.maven.plugin.MojoExecutionException: Unable to
resolve class file path
at org.jboss.maven.plugins.injection.BytecodeInjectionMojo
$BaseInjectionTarget.<init>(BytecodeInjectionMojo.java:127)
at org.jboss.maven.plugins.injection.BytecodeInjectionMojo
$MethodBodyReturnReplacementTarget.<init>(BytecodeInjectionMojo.java:
185)
at org.jboss.maven.plugins.injection.BytecodeInjectionMojo
$MethodBodyReturnReplacementTarget.<init>(BytecodeInjectionMojo.java:
181)
at
org
.jboss
.maven
.plugins
.injection
.BytecodeInjectionMojo
.generateBytecodeInjectionTarget(BytecodeInjectionMojo.java:96)
at
org
.jboss
.maven
.plugins
.injection
.BytecodeInjectionMojo.generateDescriptor(BytecodeInjectionMojo.java:86)
at
org
.jboss
.maven
.plugins
.injection
.BytecodeInjectionMojo
.getInjectionDescriptors(BytecodeInjectionMojo.java:78)
at
org
.jboss
.maven
.plugins
.injection.AbstractInjectionMojo.execute(AbstractInjectionMojo.java:45)
at
org
.apache
.maven
.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:453)
at
org
.apache
.maven
.lifecycle
.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:
559)
... 16 more
Caused by: java.lang.NullPointerException
at org.jboss.maven.plugins.injection.BytecodeInjectionMojo
$BaseInjectionTarget.<init>(BytecodeInjectionMojo.java:123)
... 24 more
15 years, 6 months
Preferred branch for patches
by Rob Hasselbaum
Hi,
I'm working on my first patch for Hibernate Core and Annotations and I'm
wondering what branch to use as the baseline. Trunk would seem to make
sense, but the trunk version of Core won't build for me right now. (Should
it?) In contrast, the "hibernate-3.3.2.GA" tag builds just fine.
Thanks,
-Rob
15 years, 6 months
Election of Hibernate Search "master" indexer on top of Infinispan
by Sanne Grinovero
Hello,
from what I recall of latest updates about the creation of an
Infinispan-backed Hibernate Search DirectoryProvider
to store Lucene's indexes, you're going to focus on having one
"Master" indexer which will take care of all the writing
to the index.
So Infinispan will take care of safely replicating the index to slave
nodes, but IMHO we should also consider the way the "Master" is being
selected; from my understanding the master node has to be configured
differently, this is not going to make it safer and
is a pain to manage in a cloud environment.
AFAIK the JBoss Cache has some code to "elect" a master node for buddy
replication, would it be possible to expose the same
logic in Infinispan's API to make sure to auto-discover and auto-elect
the "Hibernate Search Master Node" ?
Something like "whoever is the owner of this marker token is the
master"? Would that make sense?
Sanne
15 years, 6 months
