Data store garbage collection: inUse not correctly synchronized
---
Key: JCR-1414
URL: https://issues.apache.org/jira/browse/JCR-1414
Project: Jackrabbit
Issue Type: Bug
Hi,
I think it would be good to log at least the driver and database name
and version.
Regards,
Thomas
On Mon, Feb 25, 2008 at 12:06 AM, Alexander Klimetschek
[EMAIL PROTECTED] wrote:
Hi all,
while merging changes done to the Oracle bundle PM back to the 1.3
branch
hi alex,
On Mon, Feb 25, 2008 at 12:06 AM, Alexander Klimetschek
[EMAIL PROTECTED] wrote:
Hi all,
while merging changes done to the Oracle bundle PM back to the 1.3
branch (https://issues.apache.org/jira/browse/JCR-1400, backporting
https://issues.apache.org/jira/browse/JCR-940)
I face
I think the idea of adding getChildInfos to NodeInfo was to cut down on
individual calls to the SPI. In a call to getItemInfos an implementation
may choose to return any number of ItemInfos in one single batch. By
making the ChildInfos directly available for those nodes having its
child nodes in
Michael Dürig wrote:
I think the idea of adding getChildInfos to NodeInfo was to cut down on
individual calls to the SPI. In a call to getItemInfos an implementation
may choose to return any number of ItemInfos in one single batch. By
The problem, as far as I understand, is that the saving is
Hi,
My objective is to standardize the access (read/write or both) to data
content in data sources like a database (MySQL) and any other content
repository that is not JSR 170 compliant like Open CMS, live link or
share point. By standardizing access I mean that the client program will
no longer
Hi,
My objective is to standardize the access (read/write or both) to data
content in data sources like a database (MySQL) and any other content
repository that is not JSR 170 compliant like Open CMS, live link or
share point. By standardizing access I mean that the client program will
Hi Thomas,
while backporting the DB auto-reconnect issue I have lots of
conflicts, so I have to fully understand the code to resolve it ;-).
So here's my question:
In the ConnectionRecoveryManager there are various methods (eg.
executeStmt) that have a trial-loop which tries 2 times
Hi,
In the ConnectionRecoveryManager there are various methods (eg.
executeStmt) that have a trial-loop which tries 2 times before giving
up. IIUC, this is for the case when a connection is broken and needs
to be reestablished.
I don't think it is really required to try twice. It is more
[
https://issues.apache.org/jira/browse/JCR-1334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12572081#action_12572081
]
Marcel Reutegger commented on JCR-1334:
---
The second RWLock probably belongs to the
Am 25.02.2008 um 14:23 schrieb Thomas Mueller:
I don't think it is really required to try twice. It is more like: OK
we have a loop already, why don't we add one iteration for security...
There is also an option to repeat forever (this is good for testing; I
don't think it makes sense in most
Julian Reschke wrote:
Returning ItemInfos in a batch is not going to happen for the children
of a large collection. After all, the SPI impl has no idea whether the
caller wants to see them.
You have a point there.
I think with NodeInfo.getChildInfos() we should be able to efficiently
i.e. RepositoryService.getChildInfos() returns NodeInfos instead of
ChildInfos.
I'd favour such a solution. We might even want to further generalize it to
RepositoryService.getNodeInfos(SessionInfo sessionInfo, NodeId[] nodeId)
returning an Iterator of NodeInfo. Or am I missing something
Michael Dürig wrote:
i.e. RepositoryService.getChildInfos() returns NodeInfos instead of
ChildInfos.
I'd favour such a solution. We might even want to further generalize it to
RepositoryService.getNodeInfos(SessionInfo sessionInfo, NodeId[] nodeId)
returning an Iterator of NodeInfo. Or am
RepositoryService.getNodeInfos(SessionInfo sessionInfo, NodeId[] nodeId)
returning an Iterator of NodeInfo. Or am I missing something here?
+1 for getting many NodeInfos in one call.
However -- is your proposal for the calls passed in as parameter, or for
their child nodes?
I missed
Michael Dürig wrote:
I missed something... the nodeId's are not available to jcr2spi (that
is what getChildInfos was/is for). So +1 for Marcel's original
suggestion for adding RepositoryService.getChildInfos().
...the one for which Marcel already agreed it doesn't help for the
problem we are
Michael Dürig wrote:
RepositoryService.getNodeInfos(SessionInfo sessionInfo, NodeId[] nodeId)
returning an Iterator of NodeInfo. Or am I missing something here?
+1 for getting many NodeInfos in one call.
However -- is your proposal for the calls passed in as parameter, or
for their child
...we may want to rename it to getNodeInfos() then :-)
Actually I'd prefer something along the line of getChildNodeInfos() to
be more explicit and to clearly differentiate it from getNodeInfo().
Michael
BR, Julian
Michael Dürig wrote:
...we may want to rename it to getNodeInfos() then :-)
Actually I'd prefer something along the line of getChildNodeInfos() to
be more explicit and to clearly differentiate it from getNodeInfo().
Now we're talking :-)
Let's change
public IteratorChildInfo
[
https://issues.apache.org/jira/browse/JCR-1400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Klimetschek updated JCR-1400:
---
Attachment: jackrabbit-core.jcr-940.patch
Patch for the 1.3 branch.
Also includes
Hi,
I am wondering how to do proper logging in jackrabbit test cases. At
first I used System.out.println() during test case debugging, but now
I want to improve that and switch to log (o.a.j.test.LogPrintWriter)
provided by the test base class o.a.j.test.JUnitTest.
Problem is, I cannot
[
https://issues.apache.org/jira/browse/JCR-1412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12572182#action_12572182
]
Jukka Zitting commented on JCR-1412:
Instead of adding builder classes I'd rather just
[
https://issues.apache.org/jira/browse/JCR-1412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12572187#action_12572187
]
Alexander Klimetschek commented on JCR-1412:
Yes, for a final new feature applied
Hi,
As mentioned before, we have a need to backport some 1.4 improvements
to the 1.3 maintenance branch. As you've probably noticed already,
Alexander Saar from Day is currently working on those backports and
we're planning to produce an official 1.3.4 maintenance release once
those backports are
[
https://issues.apache.org/jira/browse/JCR-1412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jukka Zitting updated JCR-1412:
---
Priority: Minor (was: Major)
Summary: [Patch] Java-based test configuration of Jackrabbit (no
Hi,
On Mon, Feb 25, 2008 at 9:14 PM, Alexander Klimetschek [EMAIL PROTECTED]
wrote:
I am wondering how to do proper logging in jackrabbit test cases.
What's the reason for logging in test cases? If you're writing a
complex test case where you need logging to follow the control flow,
then
Hi,
On Mon, Feb 25, 2008 at 9:35 PM, Jukka Zitting [EMAIL PROTECTED] wrote:
[...] Alexander Saar from Day is currently working [...]
Sorry, s/Saar/Klimetschek/
BR,
Jukka Zitting
[
https://issues.apache.org/jira/browse/JCR-1412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12572258#action_12572258
]
Alexander Klimetschek commented on JCR-1412:
You are right. I plan to provide a
Clustering configuration documentation for syncDelay doesn't match
--
Key: JCR-1415
URL: https://issues.apache.org/jira/browse/JCR-1415
Project: Jackrabbit
Issue Type: Bug
Am 25.02.2008 um 21:02 schrieb Jukka Zitting:
What's the reason for logging in test cases?
Why do other test cases in Jackrabbit use the logging? Why is there a
logger in the JUnitTest base class?
If you're writing a
complex test case where you need logging to follow the control flow,
Hi,
On Tue, Feb 26, 2008 at 12:02 AM, Alexander Klimetschek
[EMAIL PROTECTED] wrote:
Am 25.02.2008 um 21:02 schrieb Jukka Zitting:
What's the reason for logging in test cases?
Why do other test cases in Jackrabbit use the logging? Why is there a
logger in the JUnitTest base class?
The
[
https://issues.apache.org/jira/browse/JCR-1416?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dave Brosius updated JCR-1416:
--
Attachment: tostring_on_string.patch
[PATCH] No need to call toString on a String
[PATCH] No need to call toString on a String
Key: JCR-1416
URL: https://issues.apache.org/jira/browse/JCR-1416
Project: Jackrabbit
Issue Type: Improvement
Components:
[PATCH] remove code stutter
---
Key: JCR-1417
URL: https://issues.apache.org/jira/browse/JCR-1417
Project: Jackrabbit
Issue Type: Improvement
Components: jackrabbit-jcr2spi
Affects Versions: core 1.4.1
[
https://issues.apache.org/jira/browse/JCR-1417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dave Brosius updated JCR-1417:
--
Attachment: remove_stutter.patch
[PATCH] remove code stutter
---
Michael Dürig wrote:
i.e. RepositoryService.getChildInfos() returns NodeInfos instead of
ChildInfos.
I'd favour such a solution. We might even want to further generalize it to
RepositoryService.getNodeInfos(SessionInfo sessionInfo, NodeId[] nodeId)
i don't see the benefit of either of
36 matches
Mail list logo
