[
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 markU
[
http://issues.apache.org/jira/browse/DERBY-418?page=comments#action_12431170 ]
Mayuresh Nirhali commented on DERBY-418:
I have run derbyall on latest trunk with v5 patch, and found 2 failures as
below,
derbyall/derbynetmats/derbynetma
[
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_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 (yo
[
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_12430497 ]
Knut Anders Hatlen commented on DERBY-418:
--
Two more comments, and I'll stop complaining. :)
1. No need for a try/catch when the catch block only rethrows
[
http://issues.apache.org/jira/browse/DERBY-418?page=comments#action_12430420 ]
Knut Anders Hatlen commented on DERBY-418:
--
+} catch(StandardException e) {
+throw StandardException.plainWrapException(
[
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) {
+St
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.
Howev
[
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_12429721 ]
Daniel John Debrunner commented on DERBY-418:
-
Any change must not ignore exceptions thrrown during an activation.close().
} catch(Stand
[
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 autoco
[
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
s
[
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 t
[
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 GenericLangu
> 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
Knut Anders Hatlen wrote:
> "Andreas Korneliussen (JIRA)" 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 t
"Andreas Korneliussen (JIRA)" 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 multithreaded program wh
[
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 th
[
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_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 fina
[
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 in
[
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 guara
[
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 fi
[
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 other
[
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 activation
[
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_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 so
[
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 act
[
http://issues.apache.org/jira/browse/DERBY-418?page=comments#action_12427844 ]
Mayuresh Nirhali commented on DERBY-418:
In the reproducible testbase, autoCommit is set to FALSE, and more important,
the resultSet returned by select quer
[
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 CursorAc
[
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 o
32 matches
Mail list logo
