jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hatherly, Adam \(GE Money\)" <Adam.Hathe...@ge.com>
Subject RE: Caching problem with shared deployment
Date Tue, 17 Apr 2007 14:40:47 GMT
Sounds like a good idea - I will have a look at raising one shortly.

Unfortunately my websphere problems has not gone away, although I think I am getting closer
to a solution.

I suspect that deploying as a "Resource Environment Provider" was resulting in multiple versions
of Jackrabbir running after all, which is what was causing the problem. I have managed to
get it to deploy as a proper resource adapter now after a bit of tweaking in the ra.xml, but
I am getting the following error whenever I try to log in to the repository from my web app:


[17/04/07 15:32:58:887 BST] 57053d6b LocalTransact E J2CA0077E: An exception was caught while
trying to obtain a javax.resource.cci.LocalTransaction from a ManagedConnection for resource
jcr/local. The exception is: java.lang.UnsupportedOperationException: Local transaction is
not supported


I can't find anywhere that I can set the transaction handling to overcome this problem - any
ideas?

Once I have it all working maybe I could document the process for WebSphere to help other
people who might want to run on this platform?

Adam.


-----Original Message-----
From: David Nuescheler [mailto:david.nuescheler@gmail.com]
Sent: 16 April 2007 15:31
To: users@jackrabbit.apache.org
Subject: Re: Caching problem with shared deployment


Hi Adam,

thanks for sending the report.

The workspace template portion of the "repository.xml" is copied into
workspace.xml
of each workspace upon creation of the workspace. So each workspace gets its
own configuration, this allows to independently configure the workspaces.
I think this is why you did not see any changes after modifying the
repository.xml
since your workspace.xml still had the old values and after the deletion of the
workspace it was recreated from the template.
I think we could put a comment into the repository.xml stating that this section
is copied into the workspace.xml and where to find them.

I think a number of people ran into similar issues before. Maybe this would be
worth a JIRA issue, just to clarify. What do you think?

regards,
david

On 4/16/07, Hatherly, Adam (GE Money) <Adam.Hatherly@ge.com> wrote:
> Apologies - I restarted everything, killed all Websphere processes, deleted the repository
directory and started again and it appears to be working now.
> If I get any more problems I will let you know - thanks again for all your help!
>
> Adam.
>
> -----Original Message-----
> From: Hatherly, Adam (GE Money)
> Sent: 16 April 2007 14:00
> To: 'users@jackrabbit.apache.org'
> Subject: RE: Caching problem with shared deployment
>
>
> Marcel,
>
> I am still getting the problem.
> Do I need to provide a different workspace name for the two web apps? If not then won't
they be sharing the same local file system path anyway? Currently when I login I specify the
workspace name as null. Also, if I use a different workspace I guess I will need to specify
the correspondence somehow - are there any example of this you could point me to?
>
> Apologies if this is a bit of a newbie question - I am still getting up to speed with
Jackrabbit.
>
> Adam.
>
>
> -----Original Message-----
> From: Marcel Reutegger [mailto:marcel.reutegger@gmx.net]
> Sent: 16 April 2007 13:19
> To: users@jackrabbit.apache.org
> Subject: Re: Caching problem with shared deployment
>
>
> Hi Adam,
>
> your workspaces are configured to use the same local file system.
>
> Hatherly, Adam (GE Money) wrote:
> > Thanks for your speedy response - I am indeed running as a model 2 deployment -
my repository config is:
> >
> > <?xml version="1.0" encoding="ISO-8859-1"?>
> > <Repository>
> >     <FileSystem class="org.apache.jackrabbit.core.fs.local.LocalFileSystem">
> >         <param name="path" value="c:/repository/repository"/>
> >     </FileSystem>
> >     <Security appName="Jackrabbit">
> >         <AccessManager class="org.apache.jackrabbit.core.security.SimpleAccessManager"/>
> >         <LoginModule class="org.apache.jackrabbit.core.security.SimpleLoginModule">
> >                 <param name="anonymousId" value="anonymous"/>
> >         </LoginModule>
> >     </Security>
> >     <Workspaces rootPath="c:/repository/workspaces" defaultWorkspace="default"
/>
> >     <Workspace name="${wsp.name}">
> >         <FileSystem class="org.apache.jackrabbit.core.fs.local.LocalFileSystem">
> >             <param name="path" value="c:/repository"/>
>
> <param name="path" value="${wsp.home}"/>
>
> will work.
>
> regards
>   marcel
>
> >         </FileSystem>
> >         <PersistenceManager class="org.apache.jackrabbit.core.persistence.db.DerbyPersistenceManager">
> >             <param name="url" value="jdbc:derby:${wsp.home}/db;create=true"/>
> >             <param name="schemaObjectPrefix" value="${wsp.name}_"/>
> >         </PersistenceManager>
> >         <SearchIndex class="org.apache.jackrabbit.core.query.lucene.SearchIndex">
> >             <param name="path" value="${wsp.home}/index"/>
> >             <param name="useCompoundFile" value="true"/>
> >             <param name="minMergeDocs" value="100"/>
> >             <param name="volatileIdleTime" value="3"/>
> >             <param name="maxMergeDocs" value="100000"/>
> >             <param name="mergeFactor" value="10"/>
> >             <param name="bufferSize" value="10"/>
> >             <param name="cacheSize" value="1000"/>
> >             <param name="forceConsistencyCheck" value="false"/>
> >             <param name="autoRepair" value="true"/>
> >             <param name="analyzer" value="org.apache.lucene.analysis.standard.StandardAnalyzer"/>
> >         </SearchIndex>
> >     </Workspace>
> >     <Versioning rootPath="c:/repository/versions">
> >         <FileSystem class="org.apache.jackrabbit.core.fs.local.LocalFileSystem">
> >             <param name="path" value="c:/repository/versions"/>
> >         </FileSystem>
> >         <PersistenceManager class="org.apache.jackrabbit.core.persistence.db.DerbyPersistenceManager">
> >              <param name="url" value="jdbc:derby:${rep.home}/version/db;create=true"/>
> >              <param name="schemaObjectPrefix" value="version_"/>
> >         </PersistenceManager>
> >     </Versioning>
> > </Repository>
> >
> > And I have set it up as a "Resource Environment Provider" in Websphere 5.1, configured
in a similar way as mentioned on this post: http://epesh.blog-city.com/jackrabbit_and_glassfish_v2.htm
> >
> > To initialise the repository I use the code:
> >
> > InitialContext ctx = new InitialContext();
> > _repository = (Repository) ctx.lookup("java:comp/env/jcr/repository");
> > SimpleCredentials cred = new SimpleCredentials("user","password".toCharArray());
> > Session session = _repository.login(cred, null);
> > Workspace workspace = session.getWorkspace();
> >
> > I did look at configuring the repository as a "Resource Adapter" rather than a "Resource
Environment Provider" but couldn't get it to work in Websphere.
> >
> > Adam.
> >
> >
> > -----Original Message-----
> > From: David Nuescheler [mailto:david.nuescheler@gmail.com]
> > Sent: 16 April 2007 11:55
> > To: users@jackrabbit.apache.org
> > Subject: Re: Caching problem with shared deployment
> >
> >
> > hi adam,
> >
> > it sounds like you might be running two jackrabbit instances against the
> > same backing store, which is something that jackrabbit is not designed to do.
> > i would recommend to connect from branding editor application through rmi
> > to the "web site"-app or run the repository as a resource in websphere.
> > http://jackrabbit.apache.org/doc/deploy.html
> >
> > if you already are running model (2) or model(3) then i think we would
> > have to look at your repository.xml file(s) and also see how you create the
> > repository itself. maybe you could attach the code that you use to get a hold
> > of the repository object?
> >
> > since lucene is not used for a getNode(key) call, i think it is unlikely to
> > have something to do with lucene.
> >
> > regards,
> > david
> >
> > On 4/16/07, Hatherly, Adam (GE Money) <Adam.Hatherly@ge.com> wrote:
> >> Hi - I have a small problem you may be able to help me with.
> >>
> >> I am using Jackrabbit to apply "branding" to a web page dynamically, and to
that end I have deployed two separate web apps to a server - one which is the actual web site,
and a second which is the "branding" editor that allows me to update image elements in the
jackrabbit repository to alter branding on the page.
> >>
> >> My problem occurs if I delete an element and then recreate it using the same
path. When I do that, the change is reflected correctly within the "editor" web app, but when
the normal web app tries to retrieve the element I get this error:
> >>
> >> /89/25/ebd281b64edfb93b597753c5e716/%7b%7ddata.0.bin: the specified resource
does not exist: /home/wasadmin/repository/workspaces/default/blobs/89/25/ebd281b64edfb93b597753c5e716/%7b%7ddata.0.bin
does not denote an existing file
> >>
> >> I am retrieving the node from the repository using:
> >>
> >> Node rootNode = session.getRootNode();
> >> Node node = rootNode.getNode(key);
> >>
> >> Where key is the path of the node I want.
> >>
> >> I can only assume it is related to some in-memory indexing/caching within lucene,
as a server restart fixes the problem. Do you know of any way I can overcome the problem so
I don't need a restart every time I change or delete/recreate a node?
> >>
> >> Thanks,
> >> Adam.
> >>
> >>
> >
>

Mime
View raw message