Java DB testing and reporting infrastructure.
Success nightly 10.9 (rev 1451271)
No errors or failures.
Test report: http://download.java.net/javadesktop/derby/javadb-5573401-report/
Java DB testing and reporting infrastructure.
Success nightly trunk (rev 1451262)
No errors or failures.
Test report: http://download.java.net/javadesktop/derby/javadb-5573400-report/
Java DB testing and reporting infrastructure.
Success nightly 10.9 (rev 1451271)
No errors or failures.
Test report: http://download.java.net/javadesktop/derby/javadb-5573401-report/
If we decide to make this part of the product, I would recommend using
the new optional tools feature rather than adding yet another syscs_diag
procedure. New optional tools are easier to add than new system
procedures. Something like the following would work:
-- this installs optimizer
[
https://issues.apache.org/jira/browse/DERBY-6094?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rick Hillegas updated DERBY-6094:
-
Attachment: LoginTimeoutTest.java
Attaching a new version of LoginTimeoutTest, correcting a bug
On 2/28/2013 9:11 AM, Mike Matrigali wrote:
In BackingStoreHashTableFromScan I see.
this.max_inmemory_rowcnt = max_inmemory_rowcnt;
if( max_inmemory_rowcnt 0)
max_inmemory_size = Long.MAX_VALUE;
else
max_inmemory_size =
The goal was to use larger memory if it was available. At the time Java
did not provide much access to this info, so only totalMemory() was
available to use. I think this translated to current allocated memory.
So if you start the jvm with a lot of memory (even if you are not using
it), then
[
https://issues.apache.org/jira/browse/DERBY-6094?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rick Hillegas updated DERBY-6094:
-
Attachment: LoginTimeoutTest.java
Attaching a new version of LoginTimeoutTest. This version
Java DB testing and reporting infrastructure.
Error continuous trunk (rev 1451683)
1 errors.
Test report: http://download.java.net/javadesktop/derby/javadb-5573474-report/
