jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From KÖLL Claus <C.KO...@TIROL.GV.AT>
Subject AW: Caching problem with shared deployment
Date Wed, 18 Apr 2007 10:39:20 GMT
Hi,
we are using websphere 5.1 with jackrabbit ...no problems after some fixes :-)
This is my ra.xml what i used to install the jca adapter.

BR
claus

-----Ursprüngliche Nachricht-----
Von: Hatherly, Adam (GE Money) [mailto:Adam.Hatherly@ge.com] 
Gesendet: Mittwoch, 18. April 2007 12:18
An: users@jackrabbit.apache.org
Betreff: RE: Caching problem with shared deployment

Hi,

I am using Websphere 5.1 which only supports connectors version 1.0, so I started with the
example 1.0 ra.xml from the jackrabbit source distribution.
The problem I got when I deployed that was I got the error:

[18/04/07 10:09:14:641 BST] 776311ba ConnectionFac E J2CA0104E: Authentication mechanism preference
BasicPassword is not supported by the resource adapter for connection factory or datasource
Jackrabbit.
[18/04/07 10:09:14:829 BST] 776311ba ConnectionFac A J2CA0014I: An exception occurred while
building the reference for JNDI deployment of Jackrabbit : java.lang.Exception: RA does not
support BasicPassword

So, after lots of trial and error I added this section to the ra.xml:

<authentication-mechanism>
    <authentication-mechanism-type>SimpleCredentials</authentication-mechanism-type>
    <credential-interface>javax.jcr.SimpleCredentials</credential-interface>
</authentication-mechanism>

Which solved that problem, although I don't know if that just works by accident rather than
by design...
>From that point on however, I had the transaction problem mentioned below.

I then changed the ra.xml to have:

<transaction-support>NoTransaction</transaction-support>
rather than 
<transaction-support>XATransaction</transaction-support>

And that seems to have solved all my problems.
My question is - what is the implications of changing the transaction-support element, and
why is it set to XATransaction in the example ra.xml files distributed with Jackrabbit?
I'm sure there must be a good reason for it....

Adam.


-----Original Message-----
From: dominique.pfister@gmail.com [mailto:dominique.pfister@gmail.com]On
Behalf Of Dominique Pfister
Sent: 18 April 2007 09:10
To: users@jackrabbit.apache.org
Subject: Re: Caching problem with shared deployment


Hi Adam,

IMO, using jackrabbit as a resource adapter in WebSphere is the better
approach. Can you tell me, what your ra.xml used in your deployment
looks like?

I suppose that WebSphere is asking for this "LocalTransaction" without
ever actually using it, and therefore returning a "dummy" object may
overcome your problem.

Kind regards
Dominique

On 4/17/07, Hatherly, Adam (GE Money) <Adam.Hatherly@ge.com> wrote:
> 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