jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Buchmann (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (JCR-3205) Missing support for lock timeout and ownerHint in jcr-server
Date Fri, 20 Jan 2012 13:54:39 GMT

    [ https://issues.apache.org/jira/browse/JCR-3205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13189812#comment-13189812
] 

David Buchmann commented on JCR-3205:
-------------------------------------

thanks, the timeout is now taken into account by the server and works fine!


what still confuses me is the reply by the server for infinite timeout (before and after this
fix):

<D:timeout>Second-2147483</D:timeout>

this number is
2^21+50331

which seems pretty random to me. coincidally, this number is exactly 2^31 - 1  (2147483647)
without the last 3 digits. can it be that there are some weird string operations happening
on server side?
                
> Missing support for lock timeout and ownerHint in jcr-server
> ------------------------------------------------------------
>
>                 Key: JCR-3205
>                 URL: https://issues.apache.org/jira/browse/JCR-3205
>             Project: Jackrabbit Content Repository
>          Issue Type: Bug
>          Components: jackrabbit-jcr-server, locks
>    Affects Versions: 2.3.6
>            Reporter: David Buchmann
>            Assignee: angela
>             Fix For: 2.3.7
>
>         Attachments: tcpdump.log
>
>
> trying to set the lock timeout when creating a lock seems not to work over the davex
transport. the timeout is always 2147483.
> this was my test code:
> import javax.jcr.*;
> import javax.jcr.lock.*;
> import org.apache.jackrabbit.jcr2spi.RepositoryImpl;
> import org.apache.jackrabbit.jcr2spi.config.RepositoryConfig;
> String url = "http://localhost:8080/server/";
> String workspace = "tests";
> RepositoryConfig config = new RepositoryConfigImplTest(repoUrl);
> Repository repo = RepositoryImpl.create(config);
> Credentials sc = new SimpleCredentials("admin","admin".toCharArray());
> Session s = repo.login(sc,workspace);
> Node t;
> if (s.getRootNode().hasNode("test")) {
>     t = s.getRootNode().getNode("test");
> } else {
>     t = s.getRootNode().addNode("test", "nt:unstructured");
> }
> t.addMixin("mix:lockable");
> s.save();
> LockManager m = s.getWorkspace().getLockManager();
> Lock l = m.lock(t.getPath(), false, true, 10, "me");
> System.out.println(l.getSecondsRemaining());
> and the output is 2147483
> the relevant communication fragment is below, i attach the full trace in case i miss
something.
> LOCK /server/tests/jcr%3aroot/test HTTP/1.1
> Timeout: Second-10
> Depth: 0
> Link: <urn:uuid0c740bb9-042a-4ef2-b019-1a6c52784c29>; rel="http://www.day.com/jcr/webdav/1.0/session-id"
> Authorization: Basic YWRtaW46YWRtaW4=
> User-Agent: Jakarta Commons-HttpClient/3.0
> Host: localhost:8080
> Content-Length: 254
> Content-Type: text/xml; charset=UTF-8
> <?xml version="1.0" encoding="UTF-8" standalone="no"?><D:lockinfo xmlns:D="DAV:"><D:lockscope><dcr:exclusive-session-scoped
xmlns:dcr="http://www.day.com/jcr/webdav/1.0"/></D:lockscope><D:locktype><D:write/></D:locktype><D:owner>me</D:owner></D:lockinfo>
> HTTP/1.1 200 OK
> Content-Type: text/xml; charset=utf-8
> Content-Length: 450
> Lock-Token: <aa724c28-3c24-41e8-a3b4-9fc129adf732>
> Server: Jetty(6.1.x)
> <?xml version="1.0" encoding="UTF-8" standalone="no"?><D:prop xmlns:D="DAV:"><D:lockdiscovery><D:activelock><D:lockscope><dcr:exclusive-session-scoped
xmlns:dcr="http://www.day.com/jcr/webdav/1.0"/></D:lockscope><D:locktype><D:write/></D:locktype><D:depth>0</D:depth><D:timeout>Second-2147483</D:timeout><D:owner>admin</D:owner><D:locktoken><D:href>aa724c28-3c24-41e8-a3b4-9fc129adf732</D:href></D:locktoken></D:activelock></D:lockdiscovery></D:prop>
> by the way: if i do not explicitly logout before the program exits, the lock is also
not released even though it is session based. should the session not trigger a logout on destruction?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message