« Return to Thread: Compass, Lucene and Grails Searchable Plugin

Re: Compass, Lucene and Grails Searchable Plugin

by teck-terracotta :: Rate this Message:

Some parts of this message have been removed. Learn more about Nabble's security policy.

Everything Nitin mentions is spot on…just a few more notes to add:

The purpose of the classloader name is to give loader instances a common identity across VMs. For every clustered object in terracotta, we record the identity of the classloader that defined it’s class. That identity is used to resolve a loader instance when the object is referenced on another VM. The terracotta client that resides in each VM maintains a map of loader name to loader instance (the registerGlobalLoader() call lets you add entries to the map).

The whole reason I’m detailing this is that you might need to assign more meaningful/complex names to the grails loader(s) than the static string in the example code below. If there is more than one grails loader, then more than likely the name will need to be more specific.

Other notes:

- There are two terracotta types referenced in the example code – the fully qualified names of those classes are com/tc/object/loaders/NamedClassLoader and com/tc/object/bytecode/hook/impl/ClassProcessorHelper

- Both of those types can be found in tc.jar (or for terracotta versions 2.5.1+, there is a specific terracotta-api-xxx.jar that should be used)

- You do not need to include any of these jars at runtime, they are only needed for compilation. At runtime these types are present in the bootstrap classloader (via the “dso-boot” jar) so including them in CLASSPATH or in web app is not a good idea

From: tc-users-bounces@... [mailto:tc-users-bounces@...] On Behalf Of Nitin Jain
Sent: Monday, January 28, 2008 10:24 AM
To: tc-users@...
Subject: Re: [tc-users] Compass, Lucene and Grails Searchable Plugin

Hi Mike,

Before an object can be shared by Terracotta, the ClassLoader that loaded object’s class has to be known to Terracotta. For core java and supported frameworks/container we take care of registering relevant classloaders with Terracotta.

The approach for Grails is

1) Identify the place where Grails classloader is created.

2) Register it with terracotta like this (this is to done where ClassLoader is created)

      ((NamedClassLoader) loader).__tc_setClassLoaderName("Grail Classloader"); //should follow some naming convention for assigning the name

       ClassProcessorHelper.registerGlobalLoader((NamedClassLoader) loader);

Initially try with direct code modification. If everything works well, we can convert this info a config module that will inject the proper byte code at runtime so as to avoid any code tweaking.

Thanks,

Nitin

From: tc-users-bounces@... [mailto:tc-users-bounces@...] On Behalf Of Mike Brevoort
Sent: Tuesday, January 22, 2008 7:19 PM
To: tc-users@...
Subject: Re: [tc-users] Compass, Lucene and Grails Searchable Plugin

Tim,

Thanks for that! It did get me passed my problem... and onto my next one :) I promise if I get this working I'll write it up and publish it.

Here's a snippet of the exception I'm getting now. This one might be a little tougher I'm assuming. Grails implements it's own classloader, I searched around to try and find a way to register a classloader somehow in Terracotta but I didn't find anything specific and it looks like it may not be that straightforward. Hopefully you'll prove me wrong though :)

Any ideas?
Thanks,
Mike

        ... 254 more
2008-01-22 20:08:00.757::WARN: Nested in org.springframework.beans.factory.BeanCreationException: Error creating bean w
ith name 'compassGps': Cannot resolve reference to bean 'compass' while setting bean property 'compass'; nested exceptio
n is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'compass': FactoryBean threw
exception on object creation; nested exception is java.lang.IllegalStateException: Classloader name not set, instances
defined from this loader not supported in Terracotta (loader: org.codehaus.groovy.grails.cli.support.GrailsRootLoader):
java.lang.IllegalStateException: Classloader name not set, instances defined from this loader not supported in Terracott
a (loader: org.codehaus.groovy.grails.cli.support.GrailsRootLoader)
        at java.lang.ClassLoader.__tc_getClassLoaderName (ClassLoader.java)
        at com.tc.object.loaders.StandardClassProvider.getName(StandardClassProvider.java:67)
        at com.tc.object.loaders.StandardClassProvider.getLoaderDescriptionFor(StandardClassProvider.java :79)
        at com.tc.object.loaders.StandardClassProvider.getLoaderDescriptionFor(StandardClassProvider.java:74)
        at com.tc.object.TCClassFactoryImpl.getOrCreate(TCClassFactoryImpl.java:53)
        at com.tc.object.ClientObjectManagerImpl.getPortableObjects (ClientObjectManagerImpl.java:211)
        at com.tc.object.Traverser.addReferencedObjects(Traverser.java:37)
        at com.tc.object.Traverser.traverse(Traverser.java:82)
        at com.tc.object.ClientObjectManagerImpl.addToManagedFromRoot (ClientObjectManagerImpl.java:890)
        at com.tc.object.ClientObjectManagerImpl.create(ClientObjectManagerImpl.java:273)
        at com.tc.object.ClientObjectManagerImpl.lookupOrCreateIfNecesary(ClientObjectManagerImpl.java :337)
        at com.tc.object.ClientObjectManagerImpl.lookupOrCreate(ClientObjectManagerImpl.java:310)
        at com.tc.object.tx.ClientTransactionManagerImpl.logicalInvoke(ClientTransactionManagerImpl.java:725)
        at com.tc.object.TCObjectLogical.logicalInvoke(TCObjectLogical.java:20)
        at com.tc.object.bytecode.ManagerImpl.logicalInvoke(ManagerImpl.java:218)
        at com.tc.object.bytecode.ManagerUtil.logicalInvoke (ManagerUtil.java:259)
        at java.util.HashMap.put(Unknown Source)
        at org.compass.core.lucene.engine.store.RAMLuceneSearchEngineStore.__tc_wrapped_doOpenDirectoryBySubIndex(RAMLuc
eneSearchEngineStore.java :42)
        at org.compass.core.lucene.engine.store.RAMLuceneSearchEngineStore.doOpenDirectoryBySubIndex(RAMLuceneSearchEngi
neStore.java)
        at org.compass.core.lucene.engine.store.AbstractLuceneSearchEngineStore.openDirectoryBySubIndex (AbstractLuceneSe
archEngineStore.java:196)
        at org.compass.core.lucene.engine.store.AbstractLuceneSearchEngineStore.getDirectoryBySubIndex(AbstractLuceneSea
rchEngineStore.java:178)
        at org.compass.core.lucene.engine.store.LuceneStoreTemplate.executeForSubIndex (LuceneStoreTemplate.java:36)
        at org.compass.core.lucene.engine.store.AbstractLuceneSearchEngineStore.createIndex(AbstractLuceneSearchEngineSt
ore.java:208)
        at org.compass.core.lucene.engine.store.AbstractLuceneSearchEngineStore.verifyIndex (AbstractLuceneSearchEngineSt

On Jan 22, 2008 7:57 PM, Tim Eck <teck@...> wrote:

Hi Mike,

Let me say up front that I don't know anything about compass – I just browsed some of their code (I looked at trunk of their svn repo).

So if "org.compass.core.lucene.engine.store.RAMLuceneSearchEngineStore.ramIndexes" is a root, then this lock snippet should get past that exception:

<named-lock>

<method-expression>* org.compass.core.lucene.engine.store.RAMLuceneSearchEngineStore.*(..)</method-expression>

<lock-level>write</lock-level>

<lock-name>theLockName</lock-name>

</named-lock>

That will apply the named lock to all methods of that class. In reality, you only need to apply the lock to those methods that read or write the shared object.

It's not obvious, but you'll also need to <include> that class

<class-expression>org.compass.core.lucene.engine.store.RAMLuceneSearchEngineStore</class-expression>

</include>

All this said, this approach with named locks is rather blunt, but it is useful for experimenting.

Hope this helps

-tim

From: tc-users-bounces@... [mailto:tc-users-bounces@...] On Behalf Of Mike Brevoort
Sent: Tuesday, January 22, 2008 7:30 AM
To: tc-users@...
Subject: [tc-users] Compass, Lucene and Grails Searchable Plugin

Hi,

I'm trying to get Terracotta working to cluster my Lucene RAMDirectory index while using the Compass/Lucene Grails plugin. I've dug into compass to find that it manages the RAMDirectory objects in this class: org.compass.core.lucene.engine

.store.RAMLuceneSearchEngineStore and manages each subindex RAMDirectory in a java.util.HashMap called ramIndexes.

I've been trying to set org.compass.core.lucene.engine.store.RAMLuceneSearchEngineStore.ramIndexes as a root in Terracotta (I'm a rookie here!), but no matter what I do I can't get past the UnlockedSharedObjectException exception. I've tried using coarse named locks though I'm not sure if I'm setting it up directory. I thought I'd ask here first...

Is it possible to have this as a root and have Terracotta manage it if the code around it is not synchronized and the data structure (HashMap) is not synchronized? If so can you point me to how to configure it? I've tried already on my own for five hours to get it working but just can't get past it.

Thanks!
Mike

com.tc.object.tx.UnlockedSharedObjectException:
*******************************************************************************
Attempt to access a shared object outside the scope of a shared lock.
All access to shared objects must be within the scope of one or more shared locks defined in your Terracotta configurati
on.
Please alter the locks section of your Terracotta configuration so that this access is auto-locked or protected by a nam
ed lock.

For more information on this issue, please visit our Troubleshooting Guide at:
http://terracotta.org/kit/troubleshooting

Caused by Thread: main in VM(0)
Shared Object Type: java.util.HashMap
*******************************************************************************

_______________________________________________
tc-users mailing list
tc-users@...
http://lists.terracotta.org/mailman/listinfo/tc-users

« Return to Thread: Compass, Lucene and Grails Searchable Plugin