[
http://issues.apache.org/jira/browse/DERBY-418?page=comments#action_12431510 ]
Knut Anders Hatlen commented on DERBY-418:
--
Derbyall ran cleanly. However, when running the repro for DERBY-1142 (without
rs.close()), I noticed that
[
http://issues.apache.org/jira/browse/DERBY-418?page=comments#action_12431148 ]
Knut Anders Hatlen commented on DERBY-418:
--
Thanks Mayuresh. I think the patch looks good. If there are no more comments, I
will run some tests and commit
[
http://issues.apache.org/jira/browse/DERBY-418?page=comments#action_12430512 ]
Daniel John Debrunner commented on DERBY-418:
-
I think your loop that closes activations needs to include similar logic to
htis, from cleanupOnError
[
http://issues.apache.org/jira/browse/DERBY-418?page=comments#action_12430517 ]
Knut Anders Hatlen commented on DERBY-418:
--
Thank you for addressing my comments, Mayuresh!
I think you misunderstood what I meant with the indentation
Mayuresh Nirhali [EMAIL PROTECTED] writes:
Hi Knut,
Thanks for the review and trying out my changes.
Could you tell me with what memory size did you run the repros ??
I see the OOME for -Xmx16m and do not see it for 64m.
You're right. I used 64 MB, and it did fail eventually.
However, I
[
http://issues.apache.org/jira/browse/DERBY-418?page=comments#action_12430028 ]
Daniel John Debrunner commented on DERBY-418:
-
The change ignores the exception:
+} catch(StandardException e) {
+
[
http://issues.apache.org/jira/browse/DERBY-418?page=comments#action_12429668 ]
Mayuresh Nirhali commented on DERBY-418:
I tried the approach suggested by Dan in DERBY-1142, and my version of change
looks like as below,
In
[
http://issues.apache.org/jira/browse/DERBY-418?page=comments#action_12429674 ]
Knut Anders Hatlen commented on DERBY-418:
--
Hi Mayuresh,
I'm afraid your fix has some unwanted consequences. First of all, the
OutOfMemoryError is still
[
http://issues.apache.org/jira/browse/DERBY-418?page=comments#action_12429709 ]
Mayuresh Nirhali commented on DERBY-418:
Thanks Knut for pointing that out.
I did not mean to provide a patch for this JIRA, but just wanted to try out a
[
http://issues.apache.org/jira/browse/DERBY-418?page=comments#action_12429712 ]
Knut Anders Hatlen commented on DERBY-418:
--
Did you try to declare BaseActivation.inUse as volatile?
outofmemory error when running large query in
[
http://issues.apache.org/jira/browse/DERBY-418?page=comments#action_12429721 ]
Daniel John Debrunner commented on DERBY-418:
-
Any change must not ignore exceptions thrrown during an activation.close().
}
[
http://issues.apache.org/jira/browse/DERBY-418?page=comments#action_12429725 ]
Knut Anders Hatlen commented on DERBY-418:
--
Mayuresh, with your latest changes, I don't see the memory leak any more
(neither DERBY-418 nor DERBY-1142).
[
http://issues.apache.org/jira/browse/DERBY-418?page=comments#action_12429361 ]
Andreas Korneliussen commented on DERBY-418:
I think that the lack of synchronization when calling
singleUseActivation.markUnused() may cause that
[
http://issues.apache.org/jira/browse/DERBY-418?page=comments#action_12429386 ]
Andreas Korneliussen commented on DERBY-418:
The finalizer thread is as pr javadoc guaranteed to not hold any user-visible
synchronization locks when
[
http://issues.apache.org/jira/browse/DERBY-418?page=comments#action_12429430 ]
Daniel John Debrunner commented on DERBY-418:
-
I don't think there is any guarantee about the order of finalization, therefore
it is impossible to
[
http://issues.apache.org/jira/browse/DERBY-418?page=comments#action_12429438 ]
Andreas Korneliussen commented on DERBY-418:
I am not sure what you mean.
Could you give an example ?
I agree that it is possible to get a deadlock
[
http://issues.apache.org/jira/browse/DERBY-418?page=comments#action_12429442 ]
Daniel John Debrunner commented on DERBY-418:
-
The alternate way to phrase it is:
Can you guarantee no deadlocks from using synchronization in the
[
http://issues.apache.org/jira/browse/DERBY-418?page=comments#action_12429473 ]
Andreas Korneliussen commented on DERBY-418:
Assuming the Derby embedded JDBC driver is thread-safe, it should be safe for a
result set to call its own
[
http://issues.apache.org/jira/browse/DERBY-418?page=comments#action_12429483 ]
Daniel John Debrunner commented on DERBY-418:
-
I'd assumed that you were going to go in at a lower level than
ResultSet.close(). ResultSet.close() is
Andreas Korneliussen (JIRA) derby-dev@db.apache.org writes:
Assuming the Derby embedded JDBC driver is thread-safe, it should be
safe for a result set to call its own close() method in its
finalizer. If you get a dead-lock in the finalizer, it proves that
it is also possible to write a
Knut Anders Hatlen wrote:
Andreas Korneliussen (JIRA) derby-dev@db.apache.org writes:
Assuming the Derby embedded JDBC driver is thread-safe, it should be
safe for a result set to call its own close() method in its
finalizer. If you get a dead-lock in the finalizer, it proves that
it is
Not sure of the guarantee of the unsynchronized field being set. Are you
saying that field will never be seen as set, or that the setting may not be
seen for some time?
It may be seen, however it may also never be seen.
Andreas
[
http://issues.apache.org/jira/browse/DERBY-418?page=comments#action_12429259 ]
Mayuresh Nirhali commented on DERBY-418:
I tried modifying the finalize method of embedResultSet to close
singleuseActivation and that seems to have worked
[
http://issues.apache.org/jira/browse/DERBY-418?page=comments#action_12429264 ]
Daniel John Debrunner commented on DERBY-418:
-
Closing the activation directly in the finalize method will lead to problems.
The close of the
[
http://issues.apache.org/jira/browse/DERBY-418?page=comments#action_12427891 ]
Mayuresh Nirhali commented on DERBY-418:
Thanks to Andreas and Oystein for pointing out another possibilty that when the
statement objects are GC'd, the
[
http://issues.apache.org/jira/browse/DERBY-418?page=comments#action_12427899 ]
Daniel John Debrunner commented on DERBY-418:
-
I think this is the same case as described in DERBY-1142, comment towards end
has a couple of possible
[
http://issues.apache.org/jira/browse/DERBY-418?page=comments#action_12427480 ]
Mayuresh Nirhali commented on DERBY-418:
I used the JHAT (jdk1.6) to dump the java heap and observed that large number
of generated objects of type
[
http://issues.apache.org/jira/browse/DERBY-418?page=comments#action_12422407 ]
Mayuresh Nirhali commented on DERBY-418:
I was able to reproduce this issue on my Sol10 x86 jdk1.5 platform.
I ran with following option,
-verbosegc (java
28 matches
Mail list logo
