date:20080403


[ 
https://issues.apache.org/jira/browse/DERBY-3591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12585000#action_12585000
 ] 

Knut Anders Hatlen commented on DERBY-3591:
---

This may be the same bug as DERBY-2141, which is fixed in Derby 10.3.1.4.

 Cleanup action starting Failed Statement is: null  Less severe exception 
 raised during cleanup (ignored) An exception was thrown during transaction 
 abort.
 --

 Key: DERBY-3591
 URL: https://issues.apache.org/jira/browse/DERBY-3591
 Project: Derby
  Issue Type: Bug
  Components: Test
Affects Versions: 10.2.1.6
 Environment: windows server 2003
 jdk 1.6
Reporter: juveinfo
   Original Estimate: 24h
  Remaining Estimate: 24h

 when my use derby to deploy my project, derby.log display following error, 
 please help me, what's wrong about my derby,Thank's very much.
 Apache Derby Network Server - 10.2.1.6 - (452058) started and ready to accept 
 connections on port 11006 at 2008-03-27 14:29:39.323 GMT 
 
 2008-03-27 14:30:24.774 GMT:
  Booting Derby version The Apache Software Foundation - Apache Derby - 
 10.2.1.6 - (452058): instance c013800d-0118-f0a4-dccf-d51cf446
 on database directory C:\Program Files\test
 Database Class Loader started - derby.database.classpath=''
 2008-04-01 14:07:11.699 GMT Thread[DRDAConnThread_3,5,main] (XID = 26484558), 
 (SESSIONID = 2), (DATABASE = test), (DRDAID = 
 GA001444.G74E-809239351414880243{3}), Cleanup action starting
 2008-04-01 14:07:11.699 GMT Thread[DRDAConnThread_3,5,main] (XID = 26484558), 
 (SESSIONID = 2), (DATABASE = test), (DRDAID = 
 GA001444.G74E-809239351414880243{3}), Failed Statement is: null
 java.lang.NullPointerException
   at 
 org.apache.derby.impl.store.raw.data.BaseContainerHandle.close(Unknown Source)
   at 
 org.apache.derby.impl.store.raw.data.BaseContainerHandle.update(Unknown 
 Source)
   at java.util.Observable.notifyObservers(Unknown Source)
   at 
 org.apache.derby.iapi.store.raw.xact.RawTransaction.notifyObservers(Unknown 
 Source)
   at org.apache.derby.impl.store.raw.xact.Xact.doComplete(Unknown Source)
   at org.apache.derby.impl.store.raw.xact.Xact.preComplete(Unknown Source)
   at org.apache.derby.impl.store.raw.xact.Xact.prepareCommit(Unknown 
 Source)
   at org.apache.derby.impl.store.raw.xact.Xact.commit(Unknown Source)
   at org.apache.derby.impl.store.raw.xact.Xact.commit(Unknown Source)
   at org.apache.derby.impl.store.access.RAMTransaction.commit(Unknown 
 Source)
   at 
 org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.doCommit(Unknown
  Source)
   at 
 org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.userCommit(Unknown
  Source)
   at org.apache.derby.impl.jdbc.TransactionResourceImpl.commit(Unknown 
 Source)
   at org.apache.derby.impl.jdbc.EmbedConnection.commit(Unknown Source)
   at org.apache.derby.impl.drda.Database.commit(Unknown Source)
   at org.apache.derby.impl.drda.DRDAConnThread.processCommands(Unknown 
 Source)
   at org.apache.derby.impl.drda.DRDAConnThread.run(Unknown Source)
   BEGIN SHUTDOWN ERROR STACK -
 ERROR XSTB0: An exception was thrown during transaction abort.
   at org.apache.derby.iapi.error.StandardException.newException(Unknown 
 Source)
   at org.apache.derby.impl.store.raw.xact.Xact.preComplete(Unknown Source)
   at org.apache.derby.impl.store.raw.xact.Xact.abort(Unknown Source)
   at org.apache.derby.impl.store.access.RAMTransaction.abort(Unknown 
 Source)
   at 
 org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.doRollback(Unknown
  Source)
   at 
 org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.internalRollback(Unknown
  Source)
   at 
 org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.cleanupOnError(Unknown
  Source)
   at 
 org.apache.derby.iapi.services.context.ContextManager.cleanupOnError(Unknown 
 Source)
   at 
 org.apache.derby.impl.jdbc.TransactionResourceImpl.cleanupOnError(Unknown 
 Source)
   at 
 org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(Unknown 
 Source)
   at org.apache.derby.impl.jdbc.EmbedConnection.handleException(Unknown 
 Source)
   at org.apache.derby.impl.jdbc.EmbedConnection.commit(Unknown Source)
   at org.apache.derby.impl.drda.Database.commit(Unknown Source)
   at org.apache.derby.impl.drda.DRDAConnThread.processCommands(Unknown 
 Source)
   at org.apache.derby.impl.drda.DRDAConnThread.run(Unknown Source)
   END SHUTDOWN ERROR STACK -
 2008-04-01 14:07:12.184

[jira] Resolved: (DERBY-3130) Reduce memory footprint of StoredRecordHeader


 [ 
https://issues.apache.org/jira/browse/DERBY-3130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Knut Anders Hatlen resolved DERBY-3130.
---

   Resolution: Fixed
Fix Version/s: 10.4.1.0

Committed to 10.4 with revision 644209.

 Reduce memory footprint of StoredRecordHeader
 -

 Key: DERBY-3130
 URL: https://issues.apache.org/jira/browse/DERBY-3130
 Project: Derby
  Issue Type: Improvement
  Components: Store
Affects Versions: 10.4.0.0
Reporter: Knut Anders Hatlen
Assignee: Knut Anders Hatlen
Priority: Minor
 Fix For: 10.4.1.0, 10.5.0.0

 Attachments: d3130-1a.diff, SmallRecordsTest.java, srh.diff


 Derby's page cache often has a memory footprint that is much larger than 
 pageSize*pageCacheSize. One large contributor to the footprint is the array 
 of StoredPageHeader objects in BasePage. The memory consumed by these objects 
 can be as large as, and sometimes even larger than, the byte arrays 
 containing the raw page data. (See for instance 
 http://www.nabble.com/How-much-derby-need-memory--tf3307655.html.) Reducing 
 the size of the StoredPageHeader objects could therefore reduce Derby's 
 memory footprint significantly, especially if the page cache is large and 
 contains many pages from tables with small records or from indices.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (DERBY-3582) IndexOutOfBoundsError in ClockPolicy.moveHand


 [ 
https://issues.apache.org/jira/browse/DERBY-3582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Knut Anders Hatlen resolved DERBY-3582.
---

   Resolution: Fixed
Fix Version/s: 10.4.1.0

Committed to 10.4 with revision 644211.

 IndexOutOfBoundsError in ClockPolicy.moveHand
 -

 Key: DERBY-3582
 URL: https://issues.apache.org/jira/browse/DERBY-3582
 Project: Derby
  Issue Type: Bug
  Components: Services
Affects Versions: 10.5.0.0
 Environment: Dual CPU 2.4 GHz Opteron (x86)
 Sun Solaris 10u2
 java version 1.6.0_04-p
 Java(TM) SE Runtime Environment (build 1.6.0_04-p-b03)
 Java HotSpot(TM) Client VM (build 11.0-b09, mixed mode)
 Derby trunk version: 10.5.0.0 alpha - (642119M)
Reporter: Kristian Waagan
Assignee: Knut Anders Hatlen
Priority: Minor
 Fix For: 10.4.1.0, 10.5.0.0

 Attachments: d3582-1a.diff


 An IndexOutOfBoundsException was thrown during suites.All when testing a 
 patch for DERBY-3576.
 I have only seen it once, and I was unable to reproduce. I'm logging the 
 issue to track it and preserve the stack trace.
 See the environment field for version information.
 I think only the first error is important, the rest (except the management 
 test) is due to the first one.
 Time: 6,901.837
 There were 5 errors:
 1) 
 testFiringConstraintOrder(org.apache.derbyTesting.functionTests.tests.lang.TriggerTest)java.sql.SQLException:
  Java exception: 'Index: 0, Size: 0: java.lang.IndexOutOfBoundsException'.
   at 
 org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(SQLExceptionFactory40.java:95)
   at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Util.java:87)
   at org.apache.derby.impl.jdbc.Util.javaException(Util.java:244)
   at 
 org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(TransactionResourceImpl.java:403)
   at 
 org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(TransactionResourceImpl.java:346)
   at 
 org.apache.derby.impl.jdbc.EmbedConnection.handleException(EmbedConnection.java:2083)
   at 
 org.apache.derby.impl.jdbc.ConnectionChild.handleException(ConnectionChild.java:81)
   at 
 org.apache.derby.impl.jdbc.EmbedDatabaseMetaData.getPreparedQueryUsingSystemTables(EmbedDatabaseMetaData.java:3498)
   at 
 org.apache.derby.impl.jdbc.EmbedDatabaseMetaData.getPreparedQuery(EmbedDatabaseMetaData.java:3541)
   at 
 org.apache.derby.impl.jdbc.EmbedDatabaseMetaData.getPreparedQuery(EmbedDatabaseMetaData.java:3566)
   at 
 org.apache.derby.impl.jdbc.EmbedDatabaseMetaData.doGetProcs(EmbedDatabaseMetaData.java:1506)
   at 
 org.apache.derby.impl.jdbc.EmbedDatabaseMetaData.getProcedures(EmbedDatabaseMetaData.java:1447)
   at org.apache.derbyTesting.junit.JDBC.dropSchema(JDBC.java:259)
   at 
 org.apache.derbyTesting.functionTests.tests.lang.TriggerTest.tearDown(TriggerTest.java:103)
   at 
 org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:103)
   at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
   at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
   at junit.extensions.TestSetup.run(TestSetup.java:25)
   at 
 org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
 Caused by: java.sql.SQLException: Java exception: 'Index: 0, Size: 0: 
 java.lang.IndexOutOfBoundsException'.
   at 
 org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(SQLExceptionFactory.java:45)
   at 
 org.apache.derby.impl.jdbc.SQLExceptionFactory40.wrapArgsForTransportAcrossDRDA(SQLExceptionFactory40.java:119)
   at 
 org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(SQLExceptionFactory40.java:70)
   ... 35 more
 Caused by: java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
   at java.util.ArrayList.RangeCheck(ArrayList.java:547)
   at java.util.ArrayList.get(ArrayList.java:322)
   at 
 org.apache.derby.impl.services.cache.ClockPolicy.moveHand(ClockPolicy.java:364)
   at 
 org.apache.derby.impl.services.cache.ClockPolicy.rotateClock(ClockPolicy.java:404)
   at 
 org.apache.derby.impl.services.cache.ClockPolicy.insertEntry(ClockPolicy.java:176)
   at 
 org.apache.derby.impl.services.cache.ConcurrentCache.insertIntoFreeSlot(ConcurrentCache.java:208)
   at 
 org.apache.derby.impl.services.cache.ConcurrentCache.find(ConcurrentCache.java:284)
   at 
 org.apache.derby.impl.sql.catalog.DataDictionaryImpl.getSPSDescriptor(DataDictionaryImpl.java:3529)
   at 
 org.apache.derby.impl.jdbc.EmbedDatabaseMetaData.prepareSPS(EmbedDatabaseMetaData.java:3632)
   at 
 org.apache.derby.impl.jdbc.EmbedDatabaseMetaData.getPreparedQueryUsingSystemTables(EmbedDatabaseMetaData.java:3493)
   ... 28 more
 2)

Re: Problems with ant genchanges

2008-04-03 Thread Dyre . Tjeldvoll

Rick Hillegas [EMAIL PROTECTED] writes:

 [EMAIL PROTECTED] wrote:
 I can't seem to get the ant genchanges target to produce a meaningful
 CHANGES.html. I think I'm feeding it the same fixedBugsList.xml that I
 used for the release notes, but the resulting CHANGES.html only contains
 six issues. (fixedBugsList.xml contains more than 100...)

 Any ideas...?

   
 Hi Dyre,

 I'm afraid I can't be very helpful here. I don't know how to generate
 an xml report from a JIRA filter anymore. I thought that I would get
 an XML report by clicking on XML in the Issue Navigator box after
 running the filter. That, however, merely generated an xhtml version
 of the report and not the version containing the tags expected by the
 ChangesFileGenerator program. How are you generating an XML report?

I do use the XML link. I choose the 'Save link as ...' option in
my browser. The content looks like this:

!--  RSS generated by JIRA (Enterprise Edition, Version: 3.12.2-#300) at Wed 
Apr 02 01:42:48 PDT 2008 --
!-- If you wish to do custom client-side styling of RSS, uncomment this:
?xml-stylesheet 
href=https://issues.apache.org:443/jira/styles/jiraxml2html.xsl; 
type=text/xsl?
--
rss version=0.92 
channel
titleDerby 10.4 Fixed Bugs (ASF JIRA)/title

linkhttps://issues.apache.org:443/jira/secure/IssueNavigator.jspa?requestId=12312521/link
descriptionAn XML representation of a search request/description
languageen-uk/language
item
title[DERBY-3538] NullPointerException during execution for query with LEFT 
OUTER JOIN whose inner table selects all constants./title
linkhttps://issues.apache.org:443/jira/browse/DERBY-3538/link

descriptionFor a query having a LEFT OUTER JOIN such that 
the right, or amp;quot;inneramp;quot;, table is a SELECT subquery whose 
result column list consists entirely of constants, Derby may throw an 
execution-time NPE while trying to apply the join predicate.  I say 
amp;quot;mayamp;quot; because it depends on which join strategy the optimizer 
chooses.
lt;br/gt;

lt;br/gt;
Using optimizer overrides I was able to reproduce this problem against trunk 
with the following (admittedly nonsense) query:
lt;br/gt;

lt;br/gt;
amp;nbsp;amp;nbsp;create table t1 (i int, j int);
lt;br/gt;
amp;nbsp;amp;nbsp;insert into t1 values (-1, -2), (-2, -4), (-3, -9);
lt;br/gt;

lt;br/gt;
amp;nbsp;amp;nbsp;select * from
lt;br/gt;
amp;nbsp;amp;nbsp;amp;nbsp;amp;nbsp;t1 left outer join
lt;br/gt;
amp;nbsp;amp;nbsp;amp;nbsp;amp;nbsp;(select -1 a, 1 b from t1) x0 
--DERBY-PROPERTIES joinStrategy=NESTEDLOOP
lt;br/gt;
amp;nbsp;amp;nbsp;amp;nbsp;on x0.a = t1.i;
lt;br/gt;

lt;br/gt;
I  |J  |A  |B
lt;br/gt;
---
lt;br/gt;
-1 |-2 |-1 |1
lt;br/gt;
-1 |-2 |-1 |1
lt;br/gt;
-1 |-2 |-1 |1
lt;br/gt;
ERROR 38000: The exception apos;java.lang.NullPointerExceptionapos; was 
thrown while evaluating an expression.
lt;br/gt;
ERROR XJ001: Java exception: apos;: java.lang.NullPointerExceptionapos;.
lt;br/gt;

lt;br/gt;
Running the same query also failed with the same NPE on 10.0.2.1, even though 
optimizer overrides donapos;t exist there.  So Iapos;m marking all known 
releases to be affected by this issue.
lt;br/gt;

lt;br/gt;
Note: while this particular query may not make much sense, I have seen a user 
with a very large, auto-generated query that, when executed, fails due to this 
problem.  So it is worth investigating.../description
environment/environment
key id=12391406DERBY-3538/key
summaryNullPointerException during execution for query with LEFT 
OUTER JOIN whose inner table selects all constants./summary
type id=1 
iconUrl=https://issues.apache.org:443/jira/images/icons/bug.gif;Bug/type

priority id=4 
iconUrl=https://issues.apache.org:443/jira/images/icons/priority_minor.gif;Minor/priority

status id=5 
iconUrl=https://issues.apache.org:443/jira/images/icons/status_resolved.gif;Resolved/status
resolution id=1Fixed/resolution


assignee username=armyA B/assignee

reporter username=armyA B/reporter

createdThu, 13 Mar 2008 22:26:07 -0700 (PDT)/created
updatedTue, 25 Mar 2008 02:18:00 -0700 (PDT)/updated

version10.0.2.0/version
version10.0.2.1/version
version10.1.1.0/version
version10.1.2.1/version
version10.1.3.1/version
version10.2.1.6/version
version10.2.2.0/version
version10.3.1.4/version
version10.3.2.1/version

fixVersion10.1.3.2/fixVersion
fixVersion10.2.2.1/fixVersion
fixVersion10.3.2.2/fixVersion

[jira] Commented: (DERBY-3354) Select from large lob table with embedded gives OutOfMemoryError

[
https://issues.apache.org/jira/browse/DERBY-3354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12585005#action_12585005
]

Øystein Grøvlen commented on DERBY-3354:

If I understand correctly, the idea behind using a WeakHashMap is that if this
is the only reference, it should not prevent the referred object from being
garbage-collected.
In other words, as long as a user thread or the network server through
locators, refers to the object, it will not be garbage-collected, but if such
references does not exist, the object will be garbage-collected.This is an
interesting idea.

My question is whether it is OK that free is not called on the LOB objects that
are garbage-collected this way. Are you certain that all associated resources
(e.g., temp files) will be released? Maybe some finalizer clean-up will also
be needed?

Other comments/questions:
* It seems getLocator will create a new locator on every call. I think there
should be just a single locator per object. Otherwise, I think the clean-up
will be difficult.
* free: Willl removeLOBMapping handle correctly the cases where a locator
has not been set?
* typo: Refrence

Select from large lob table with embedded gives OutOfMemoryError

Key: DERBY-3354
URL: https://issues.apache.org/jira/browse/DERBY-3354
Project: Derby
Issue Type: Bug
Components: SQL
Affects Versions: 10.3.1.4, 10.3.2.1, 10.4.0.0
Reporter: Kathey Marsden
Assignee: Anurag Shekhar
Attachments: derby-3354.diff, derby-3354_preview.diff, LocLeak.java

Retrieving from a large table with lobs gives an OutOfMemoryException, even
if free() is explictly called on the lob. I believe this is because
EmbedConnection.addLobMapping is called for every lob creation but is never
cleared until commit or rollback, even if the lob is freed.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DERBY-3354) Select from large lob table with embedded gives OutOfMemoryError

2008-04-03 Thread Anurag Shekhar (JIRA)

[
https://issues.apache.org/jira/browse/DERBY-3354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12585015#action_12585015
]

Anurag Shekhar commented on DERBY-3354:
---

Thanks Øystein for look at the patch.

If there is no free called (or release on internal clob) the temporary file
will not be cleaned. But the temporary file
system is cleaned every time db boots up. I was under impression that disk
operations are not allowed from
finalize. Probably I was wrong. I will check and if its not restricted I will
add finalizer for EmbedClob and
EmbedBlob.

Other comments/questions:
* It seems getLocator will create a new locator on every call. I think there
should be just a single locator per object. Otherwise, I think the clean-up
will be difficult.

I will be checking it to check if the locator is 0 before calling addMapping.

* free: Willl removeLOBMapping handle correctly the cases where a locator has
not been set?
HashMap ignore remove call if key is not found in the Map So there is no
problem If we call
remove with invalid key.

* typo: Refrence
I will fix this,

Select from large lob table with embedded gives OutOfMemoryError

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DERBY-3561) testStartStopManagementFromApplication(org.apache.derbyTesting.functionTests.tests.management.ManagementMBeanTest)junit.framework.AssertionFailedError: expected:2 but

2008-04-03 Thread John H. Embretsen (JIRA)


[ 
https://issues.apache.org/jira/browse/DERBY-3561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12585040#action_12585040
 ] 

John H. Embretsen commented on DERBY-3561:
--

Thanks, Knut. Further test stabilization or perhaps even product changes should 
be considered if this or similar issues reappear often, but I think this is 
sufficient for 10.4.1 at least.

Vemund: We could certainly consider doing something about checking that 
preconditions are satisfied at test start. Though if preconditions are not as 
expected and we throw an exception then we would still get the same noise in 
the test results (for a while, at least). To be able to handle varying 
preconditions, a bit more logic would have to be added to the test code and/or 
setup (and I think that is too risky to do for 10.4 at this moment).

 testStartStopManagementFromApplication(org.apache.derbyTesting.functionTests.tests.management.ManagementMBeanTest)junit.framework.AssertionFailedError:
  expected:2 but was:5
 

 Key: DERBY-3561
 URL: https://issues.apache.org/jira/browse/DERBY-3561
 Project: Derby
  Issue Type: Bug
  Components: JMX, Regression Test Failure, Test
Affects Versions: 10.4.1.0, 10.5.0.0
Reporter: Mike Matrigali
Assignee: John H. Embretsen
 Attachments: d3561_testPolicyFix.diff, Derby3561ReproStandalone.java, 
 Derby3561ReproSuite_notForCommit.diff


 The following test has been failing consistently in the tinderbox runs since 
 about build 636714, unfortunately the run right before this build  failed so
 it may be from that one. 
 first tinderbox failure I could find:
 http://dbtg.thresher.com/derby/test/tinderbox_trunk16/jvm1.6/testing/testlog/SunOS-5.10_i86pc-i386/636714-org.apache.derbyTesting.functionTests.suites.All_diff.txt
 most recent as of this report:
 http://dbtg.thresher.com/derby/test/tinderbox_trunk16/jvm1.6/testing/testlog/SunOS-5.10_i86pc-i386/639156-org.apache.derbyTesting.functionTests.suites.All_diff.txt
 There was 1 failure:
 1) 
 testStartStopManagementFromApplication(org.apache.derbyTesting.functionTests.tests.management.ManagementMBeanTest)junit.framework.AssertionFailedError:
  expected:2 but was:5
   at 
 org.apache.derbyTesting.functionTests.tests.management.ManagementMBeanTest.startStopManagement(ManagementMBeanTest.java:86)
   at 
 org.apache.derbyTesting.functionTests.tests.management.ManagementMBeanTest.testStartStopManagementFromApplication(ManagementMBeanTest.java:56)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at 
 org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:101)
   at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
   at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
   at junit.extensions.TestSetup.run(TestSetup.java:25)
   at 
 org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
   at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
   at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
   at junit.extensions.TestSetup.run(TestSetup.java:25)
   at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
   at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
   at junit.extensions.TestSetup.run(TestSetup.java:25)
   at 
 org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (DERBY-3561) testStartStopManagementFromApplication(org.apache.derbyTesting.functionTests.tests.management.ManagementMBeanTest)junit.framework.AssertionFailedError: expected:2 but wa


 [ 
https://issues.apache.org/jira/browse/DERBY-3561?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Knut Anders Hatlen updated DERBY-3561:
--

Derby Info:   (was: [Patch Available])

I don't know enough about this issue to say if it is the best way to fix it, 
but I checked in the patch to reduce the noise from the test.

Committed to trunk with revision 644248.
Committed to 10.4 with revision 644250.

 testStartStopManagementFromApplication(org.apache.derbyTesting.functionTests.tests.management.ManagementMBeanTest)junit.framework.AssertionFailedError:
  expected:2 but was:5
 

 Key: DERBY-3561
 URL: https://issues.apache.org/jira/browse/DERBY-3561
 Project: Derby
  Issue Type: Bug
  Components: JMX, Regression Test Failure, Test
Affects Versions: 10.4.1.0, 10.5.0.0
Reporter: Mike Matrigali
Assignee: John H. Embretsen
 Attachments: d3561_testPolicyFix.diff, Derby3561ReproStandalone.java, 
 Derby3561ReproSuite_notForCommit.diff


 The following test has been failing consistently in the tinderbox runs since 
 about build 636714, unfortunately the run right before this build  failed so
 it may be from that one. 
 first tinderbox failure I could find:
 http://dbtg.thresher.com/derby/test/tinderbox_trunk16/jvm1.6/testing/testlog/SunOS-5.10_i86pc-i386/636714-org.apache.derbyTesting.functionTests.suites.All_diff.txt
 most recent as of this report:
 http://dbtg.thresher.com/derby/test/tinderbox_trunk16/jvm1.6/testing/testlog/SunOS-5.10_i86pc-i386/639156-org.apache.derbyTesting.functionTests.suites.All_diff.txt
 There was 1 failure:
 1) 
 testStartStopManagementFromApplication(org.apache.derbyTesting.functionTests.tests.management.ManagementMBeanTest)junit.framework.AssertionFailedError:
  expected:2 but was:5
   at 
 org.apache.derbyTesting.functionTests.tests.management.ManagementMBeanTest.startStopManagement(ManagementMBeanTest.java:86)
   at 
 org.apache.derbyTesting.functionTests.tests.management.ManagementMBeanTest.testStartStopManagementFromApplication(ManagementMBeanTest.java:56)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at 
 org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:101)
   at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
   at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
   at junit.extensions.TestSetup.run(TestSetup.java:25)
   at 
 org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
   at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
   at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
   at junit.extensions.TestSetup.run(TestSetup.java:25)
   at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
   at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
   at junit.extensions.TestSetup.run(TestSetup.java:25)
   at 
 org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DERBY-3561) testStartStopManagementFromApplication(org.apache.derbyTesting.functionTests.tests.management.ManagementMBeanTest)junit.framework.AssertionFailedError: expected:2 but


[ 
https://issues.apache.org/jira/browse/DERBY-3561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12585035#action_12585035
 ] 

Vemund Østgaard commented on DERBY-3561:


Good job tracking down the root cause for this, John.

I think your patch is a sensible way to get the tests to pass.

On a side note, if tests have certain preconditions to be able to behave as 
intended, it might be sensible to check for these at the start of the test. So, 
the test that has been failing could check that there are in fact 0 MBeans 
registered at the start of the test, and just throw an exception if there 
aren't, since this is obviously a precondition the way the test is written.



 testStartStopManagementFromApplication(org.apache.derbyTesting.functionTests.tests.management.ManagementMBeanTest)junit.framework.AssertionFailedError:
  expected:2 but was:5
 

 Key: DERBY-3561
 URL: https://issues.apache.org/jira/browse/DERBY-3561
 Project: Derby
  Issue Type: Bug
  Components: JMX, Regression Test Failure, Test
Affects Versions: 10.4.1.0, 10.5.0.0
Reporter: Mike Matrigali
Assignee: John H. Embretsen
 Attachments: d3561_testPolicyFix.diff, Derby3561ReproStandalone.java, 
 Derby3561ReproSuite_notForCommit.diff


 The following test has been failing consistently in the tinderbox runs since 
 about build 636714, unfortunately the run right before this build  failed so
 it may be from that one. 
 first tinderbox failure I could find:
 http://dbtg.thresher.com/derby/test/tinderbox_trunk16/jvm1.6/testing/testlog/SunOS-5.10_i86pc-i386/636714-org.apache.derbyTesting.functionTests.suites.All_diff.txt
 most recent as of this report:
 http://dbtg.thresher.com/derby/test/tinderbox_trunk16/jvm1.6/testing/testlog/SunOS-5.10_i86pc-i386/639156-org.apache.derbyTesting.functionTests.suites.All_diff.txt
 There was 1 failure:
 1) 
 testStartStopManagementFromApplication(org.apache.derbyTesting.functionTests.tests.management.ManagementMBeanTest)junit.framework.AssertionFailedError:
  expected:2 but was:5
   at 
 org.apache.derbyTesting.functionTests.tests.management.ManagementMBeanTest.startStopManagement(ManagementMBeanTest.java:86)
   at 
 org.apache.derbyTesting.functionTests.tests.management.ManagementMBeanTest.testStartStopManagementFromApplication(ManagementMBeanTest.java:56)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at 
 org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:101)
   at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
   at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
   at junit.extensions.TestSetup.run(TestSetup.java:25)
   at 
 org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
   at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
   at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
   at junit.extensions.TestSetup.run(TestSetup.java:25)
   at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
   at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
   at junit.extensions.TestSetup.run(TestSetup.java:25)
   at 
 org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DERBY-3354) Select from large lob table with embedded gives OutOfMemoryError


[ 
https://issues.apache.org/jira/browse/DERBY-3354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12585049#action_12585049
 ] 

Øystein Grøvlen commented on DERBY-3354:


I do think that it is a good idea to put disk operations in a finalizer, but it 
should be possible to record work that needs to be done (e.g., at transaction 
commit).   I do not think delaying clean-up of files until db reboot is 
acceptable since a server may be running for months without a reboot.



 Select from large lob table with embedded gives OutOfMemoryError
 

 Key: DERBY-3354
 URL: https://issues.apache.org/jira/browse/DERBY-3354
 Project: Derby
  Issue Type: Bug
  Components: SQL
Affects Versions: 10.3.1.4, 10.3.2.1, 10.4.0.0
Reporter: Kathey Marsden
Assignee: Anurag Shekhar
 Attachments: derby-3354.diff, derby-3354_preview.diff, LocLeak.java


 Retrieving from a large table with lobs gives an OutOfMemoryException, even 
 if free() is explictly called on the lob.   I believe this is because 
 EmbedConnection.addLobMapping is called for every lob creation but is never 
 cleared until commit or rollback, even if the lob is freed.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (DERBY-3561) testStartStopManagementFromApplication(org.apache.derbyTesting.functionTests.tests.management.ManagementMBeanTest)junit.framework.AssertionFailedError: expected:2 but w

2008-04-03 Thread John H. Embretsen (JIRA)


 [ 
https://issues.apache.org/jira/browse/DERBY-3561?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John H. Embretsen resolved DERBY-3561.
--

   Resolution: Fixed
Fix Version/s: 10.5.0.0
   10.4.1.0

Marking this issue as fixed, as a fix has been committed to both trunk and 10.4 
branch. I intend to close the issue after a couple of days if the failure 
disappears from daily test reports - further comments/suggestions are still 
welcome, though. 
Should probably create a new issue for making the ManagementMBeanTest more 
robust.

 testStartStopManagementFromApplication(org.apache.derbyTesting.functionTests.tests.management.ManagementMBeanTest)junit.framework.AssertionFailedError:
  expected:2 but was:5
 

 Key: DERBY-3561
 URL: https://issues.apache.org/jira/browse/DERBY-3561
 Project: Derby
  Issue Type: Bug
  Components: JMX, Regression Test Failure, Test
Affects Versions: 10.4.1.0, 10.5.0.0
Reporter: Mike Matrigali
Assignee: John H. Embretsen
 Fix For: 10.4.1.0, 10.5.0.0

 Attachments: d3561_testPolicyFix.diff, Derby3561ReproStandalone.java, 
 Derby3561ReproSuite_notForCommit.diff


 The following test has been failing consistently in the tinderbox runs since 
 about build 636714, unfortunately the run right before this build  failed so
 it may be from that one. 
 first tinderbox failure I could find:
 http://dbtg.thresher.com/derby/test/tinderbox_trunk16/jvm1.6/testing/testlog/SunOS-5.10_i86pc-i386/636714-org.apache.derbyTesting.functionTests.suites.All_diff.txt
 most recent as of this report:
 http://dbtg.thresher.com/derby/test/tinderbox_trunk16/jvm1.6/testing/testlog/SunOS-5.10_i86pc-i386/639156-org.apache.derbyTesting.functionTests.suites.All_diff.txt
 There was 1 failure:
 1) 
 testStartStopManagementFromApplication(org.apache.derbyTesting.functionTests.tests.management.ManagementMBeanTest)junit.framework.AssertionFailedError:
  expected:2 but was:5
   at 
 org.apache.derbyTesting.functionTests.tests.management.ManagementMBeanTest.startStopManagement(ManagementMBeanTest.java:86)
   at 
 org.apache.derbyTesting.functionTests.tests.management.ManagementMBeanTest.testStartStopManagementFromApplication(ManagementMBeanTest.java:56)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at 
 org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:101)
   at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
   at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
   at junit.extensions.TestSetup.run(TestSetup.java:25)
   at 
 org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
   at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
   at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
   at junit.extensions.TestSetup.run(TestSetup.java:25)
   at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
   at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
   at junit.extensions.TestSetup.run(TestSetup.java:25)
   at 
 org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Assigned: (DERBY-3589) AllocPage.createPage() doesn't initialize minimumRecordSize correctly


 [ 
https://issues.apache.org/jira/browse/DERBY-3589?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Knut Anders Hatlen reassigned DERBY-3589:
-

Assignee: Knut Anders Hatlen

 AllocPage.createPage() doesn't initialize minimumRecordSize correctly
 -

 Key: DERBY-3589
 URL: https://issues.apache.org/jira/browse/DERBY-3589
 Project: Derby
  Issue Type: Bug
  Components: Store
Affects Versions: 10.3.1.4, 10.4.1.0
Reporter: Knut Anders Hatlen
Assignee: Knut Anders Hatlen
Priority: Minor

 AllocPage.createPage() will initialize minimumRecordSize to the same
 value as borrowedSpace. See this code taken from AllocPage.java:
 ---
   protected void createPage(PageKey newIdentity, int[] args) 
throws StandardException
   {
   super.createPage(newIdentity, args);
   // args[0] is the format id
   // args[1] is whether to sync the page to disk or not
   // args[2] is the pagesize (used by StoredPage)
   // args[3] is the spareSize (used by StoredPage)
   // args[4] is the number of bytes to reserve for container 
 header
   // args[5] is the minimumRecordSize
   // NOTE: the arg list here must match the one in FileContainer
   int pageSize = args[2];
   int minimumRecordSize = args[5];
   borrowedSpace = args[4];
 ---
 Here it correctly takes args[5] and puts into the local variable
 minimumRecordSize. However, that variable hides a field with the same
 name, and that field is set to args[4] in the call to
 super.createPage() at the first line in the method. The local variable
 is never used.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DERBY-3589) AllocPage.createPage() doesn't initialize minimumRecordSize correctly


[ 
https://issues.apache.org/jira/browse/DERBY-3589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12585051#action_12585051
 ] 

Knut Anders Hatlen commented on DERBY-3589:
---

I wonder if it would be better if createPage() took a struct class instead of 
an array. With named fields we avoid the problem that one array element is 
interpreted differently by AllocPage.createPage() and StoredPage.createPage(). 
I think this would also solve DERBY-3116.

 AllocPage.createPage() doesn't initialize minimumRecordSize correctly
 -

 Key: DERBY-3589
 URL: https://issues.apache.org/jira/browse/DERBY-3589
 Project: Derby
  Issue Type: Bug
  Components: Store
Affects Versions: 10.3.1.4, 10.4.1.0
Reporter: Knut Anders Hatlen
Priority: Minor

 AllocPage.createPage() will initialize minimumRecordSize to the same
 value as borrowedSpace. See this code taken from AllocPage.java:
 ---
   protected void createPage(PageKey newIdentity, int[] args) 
throws StandardException
   {
   super.createPage(newIdentity, args);
   // args[0] is the format id
   // args[1] is whether to sync the page to disk or not
   // args[2] is the pagesize (used by StoredPage)
   // args[3] is the spareSize (used by StoredPage)
   // args[4] is the number of bytes to reserve for container 
 header
   // args[5] is the minimumRecordSize
   // NOTE: the arg list here must match the one in FileContainer
   int pageSize = args[2];
   int minimumRecordSize = args[5];
   borrowedSpace = args[4];
 ---
 Here it correctly takes args[5] and puts into the local variable
 minimumRecordSize. However, that variable hides a field with the same
 name, and that field is set to args[4] in the call to
 super.createPage() at the first line in the method. The local variable
 is never used.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (DERBY-3200) Developer's Guide: Add examples showing use of SQL authorization with user authentication

2008-04-03 Thread Dag H. Wanvik (JIRA)


 [ 
https://issues.apache.org/jira/browse/DERBY-3200?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dag H. Wanvik updated DERBY-3200:
-

Attachment: auth2.log

Sorry not to reply to this one earlier, Kim. Have been away for some time.

You need to reboot the database after setting the property 
derby.database.sqlAuthorization,
for the change to take effect. It is a static property.

When I did that I got the results shown in auth2.log (attached).



 Developer's Guide: Add examples showing use of SQL authorization with user 
 authentication
 -

 Key: DERBY-3200
 URL: https://issues.apache.org/jira/browse/DERBY-3200
 Project: Derby
  Issue Type: Improvement
  Components: Documentation
Reporter: Kim Haase
Assignee: Kim Haase
Priority: Minor
 Attachments: auth2.log, AuthExampleClientSQLAuth1.java, 
 AuthExampleClientSQLAuth2.java, AuthExampleEmbeddedSQLAuth.java, 
 rdevcsecuresqlauthembeddedex.dita


 This is the followup to DERBY-1823 that Francois Orsini suggested.
 I've been experimenting and reading the Developer's Guide section on SQL 
 authorization (User authorizations, cdevcsecure36595).
 It appears that the only use of SQL authorization mode is to restrict user 
 access, not to expand it.
 For example, if you set the default connection mode to noAccess, a user with 
 fullAccess can't grant any privileges to a user with noAccess. And presumably 
 if the default connection mode is readOnlyAccess, a user with fullAccess 
 can't grant any privileges beyond SELECT, which the user has anyway.
 Only if the default connection mode is fullAccess is SQL authorization mode 
 meaningful. That means that a fullAccess user can use GRANT to restrict 
 another user's privileges on a particular database that the user owns.
 I'm running into a problem at the end, though. At the beginning of the 
 program, as nobody in particular, I was able to create several users, some of 
 them with full access. But at the end of the program, it seems that even a 
 user with full access isn't allowed to turn off those database properties:
 Message:  User 'MARY' does not have execute permission on PROCEDURE 
 'SYSCS_UTIL'.'SYSCS_SET_DATABASE_PROPERTY'.
 This seems a bit extreme. I know that with SQL authorization on, the ability 
 to read from or write to database objects is further restricted to the owner 
 of the database objects. But the ability to execute built-in system 
 procedures? Can I log in as SYSCS_UTIL? How? 
 I realize that having access to SYSCS_SET_DATABASE_PROPERTY would allow me to 
 in effect delete myself -- but that's essentially what I do at the end of the 
 program that sets derby.connection.requireAuthentication but not 
 derby.database.sqlAuthorization. 
 The documentation does say that once you have turned on SQL authorization, 
 you can't turn it off. But it doesn't say that you can't turn anything else 
 off, either!
 I'll attach the program I've been using. Most of the stacktraces are 
 expected, but I'm stumped by that last one.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DERBY-3200) Developer's Guide: Add examples showing use of SQL authorization with user authentication

2008-04-03 Thread Dag H. Wanvik (JIRA)


[ 
https://issues.apache.org/jira/browse/DERBY-3200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12585056#action_12585056
 ] 

Dag H. Wanvik commented on DERBY-3200:
--

Btw, you may want to reattach your code samples with ASF license granted.
Not important here, but good rule.


 Developer's Guide: Add examples showing use of SQL authorization with user 
 authentication
 -

 Key: DERBY-3200
 URL: https://issues.apache.org/jira/browse/DERBY-3200
 Project: Derby
  Issue Type: Improvement
  Components: Documentation
Reporter: Kim Haase
Assignee: Kim Haase
Priority: Minor
 Attachments: auth2.log, AuthExampleClientSQLAuth1.java, 
 AuthExampleClientSQLAuth2.java, AuthExampleEmbeddedSQLAuth.java, 
 rdevcsecuresqlauthembeddedex.dita


 This is the followup to DERBY-1823 that Francois Orsini suggested.
 I've been experimenting and reading the Developer's Guide section on SQL 
 authorization (User authorizations, cdevcsecure36595).
 It appears that the only use of SQL authorization mode is to restrict user 
 access, not to expand it.
 For example, if you set the default connection mode to noAccess, a user with 
 fullAccess can't grant any privileges to a user with noAccess. And presumably 
 if the default connection mode is readOnlyAccess, a user with fullAccess 
 can't grant any privileges beyond SELECT, which the user has anyway.
 Only if the default connection mode is fullAccess is SQL authorization mode 
 meaningful. That means that a fullAccess user can use GRANT to restrict 
 another user's privileges on a particular database that the user owns.
 I'm running into a problem at the end, though. At the beginning of the 
 program, as nobody in particular, I was able to create several users, some of 
 them with full access. But at the end of the program, it seems that even a 
 user with full access isn't allowed to turn off those database properties:
 Message:  User 'MARY' does not have execute permission on PROCEDURE 
 'SYSCS_UTIL'.'SYSCS_SET_DATABASE_PROPERTY'.
 This seems a bit extreme. I know that with SQL authorization on, the ability 
 to read from or write to database objects is further restricted to the owner 
 of the database objects. But the ability to execute built-in system 
 procedures? Can I log in as SYSCS_UTIL? How? 
 I realize that having access to SYSCS_SET_DATABASE_PROPERTY would allow me to 
 in effect delete myself -- but that's essentially what I do at the end of the 
 program that sets derby.connection.requireAuthentication but not 
 derby.database.sqlAuthorization. 
 The documentation does say that once you have turned on SQL authorization, 
 you can't turn it off. But it doesn't say that you can't turn anything else 
 off, either!
 I'll attach the program I've been using. Most of the stacktraces are 
 expected, but I'm stumped by that last one.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (DERBY-3585) Document user authentication support for network server shutdown

2008-04-03 Thread Martin Zaun (JIRA)


 [ 
https://issues.apache.org/jira/browse/DERBY-3585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Martin Zaun updated DERBY-3585:
---

Attachment: DERBY-3585-0.zip
DERBY-3585-0.diff
DERBY-3585-0.stat


Please find attached for review and comments the documentation update
(dita diffs and html) for the network server shutdown authentication.

Having looked into the documentation source for the first time, the
formatting, the usage of the dita-tags in the individual sections, and
the applied level of detail appeared at times somewhat incoherent to me
(in the admin guide, for instance, comparing the network server start with
the shutdown section).

I tried to fit my additions into the existing structure, language, and
formatting, but most certainly there's plenty of chance for improvement by
a native speaker and a dita expert.  For instance, I'm not sure if the
codeblock lines have gotten too long with the newly appended ... [-user
username] [-password password] options.

Summary of changes:

1) adminguide/tadminconfigshuttingdownthenetworkserver.dita
   - removed obsolete statements that user must explicitely shut down open
 databases before shutting down the server when user authentication is
 enabled
   + added that server can be shutdown by invoking script, jar, or class
   + added new user/password command-line options

2) adminguide/tadminconfig815333.dita
   + added jar file invokation usage for server shutdown
   + added username/password command-line options

3) tadminconfig815357.dita
   + added username/password constructor arguments

4) adminguide/derbyadmin.ditamap
   adminguide/tadminnetservusrauth.dita
   + added a new section/toc entry Running the Network Server with User
 Authentication under Derby Network Server advanced topics; this
 adds a cross-reference to Working with user authentication in the
 Derby Developer's Guide, which I strongly felt missing.  Without this
 section (or task?), there's only scattered information in the admin
 guide on how to enable user authentication.  For instance, there's a
 note burried in Basic Network Server security policy; however,
 enabling user authentication is independent from running with a
 security manager.  Also, having user authentication show up under
 the generated links Related concepts/tasks might be very helpful
 (even if the user will only find a cross-reference to the devguide
 there).

5) adminguide/tadminconfig813694.dita
   + added new constructors with user/password arguments

6) adminguide/radminappsclientxmp.dita
   + added cross-reference to devguide's section on user authentication
 neccessary to understand the examples and context

7) adminguide/tadminconfig814963.dita
   - decided not to add new constructor examples here, since they're
 described in their own section

8) adminguide/cadminssl.dita
   - decided not to address any potential confusion about Derby's user
 authentication and authentication with SSL/TLS, which are separate;
 we've already identified this as a topic for future refinement and
 changes (single login with certificate-based identity).

9) devguide/cdevcsecure36127.dita
   - ok, no changes needed

10) devguide/tdevdvlp20349.dita
   - found a flatly wrong statement but did NOT correct here since
 unrelated to server shutdown authentication:
 You cannot explicitly request that the JVM unload a class, but you
 can ensure that the EmbeddedDriver class is unloaded by using a
 System.gc() to force it to garbage collect classes that are no longer
 needed. Running with -nogc or -noclassgc definitely prevents the class
 from being unloaded and makes you unable to restart Derby in the same
 JVM.

 System.gc() is only a suggestion to the Runtime to garbage-collect, it
 cannot be enforced, and there's no guarantee whatsoever that GC has
 run and any classes been unloaded.  Likewise it's most probably not
 guarantueed that -nogc or -noclassgc definitely (!) prevent a class
 from being unloaded (a JVM may ignore these options...)

11) refderby, getstartderby, tuningderby, derbytools
- ok, no changes needed


 Document user authentication support for network server shutdown
 

 Key: DERBY-3585
 URL: https://issues.apache.org/jira/browse/DERBY-3585
 Project: Derby
  Issue Type: Sub-task
  Components: Documentation
Reporter: Martin Zaun
Assignee: Martin Zaun
 Fix For: 10.4.0.0

 Attachments: DERBY-3585-0.diff, DERBY-3585-0.stat, DERBY-3585-0.zip, 
 releaseNote.html, releaseNote.html, releaseNote.html, releaseNote.html


 As part of the System Privileges work in DERBY-2109, the support of user 
 authentication for network server shutdown was

[jira] Commented: (DERBY-3561) testStartStopManagementFromApplication(org.apache.derbyTesting.functionTests.tests.management.ManagementMBeanTest)junit.framework.AssertionFailedError: expected:2 but


[ 
https://issues.apache.org/jira/browse/DERBY-3561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12585066#action_12585066
 ] 

Vemund Østgaard commented on DERBY-3561:


Yes, my thoughts on preconditions was mostly in general for all tests. It makes 
it a bit easier to track down issues if preconditions are verified at the start 
of a test. It won't remove noise, but for a test that fails maybe just once in 
a while and is difficult to reproduce it would give insight into whether the 
problem is related to something that happened before or during the test.

I think it requires some thought when deciding if a test should throw an 
exception if something is not as expected at the start of the test, or silently 
adapt to the change in behavior. It is important not to mask what potentially 
is a bug, but at the same time you don't want unnecessary noise.

 testStartStopManagementFromApplication(org.apache.derbyTesting.functionTests.tests.management.ManagementMBeanTest)junit.framework.AssertionFailedError:
  expected:2 but was:5
 

 Key: DERBY-3561
 URL: https://issues.apache.org/jira/browse/DERBY-3561
 Project: Derby
  Issue Type: Bug
  Components: JMX, Regression Test Failure, Test
Affects Versions: 10.4.1.0, 10.5.0.0
Reporter: Mike Matrigali
Assignee: John H. Embretsen
 Fix For: 10.4.1.0, 10.5.0.0

 Attachments: d3561_testPolicyFix.diff, Derby3561ReproStandalone.java, 
 Derby3561ReproSuite_notForCommit.diff


 The following test has been failing consistently in the tinderbox runs since 
 about build 636714, unfortunately the run right before this build  failed so
 it may be from that one. 
 first tinderbox failure I could find:
 http://dbtg.thresher.com/derby/test/tinderbox_trunk16/jvm1.6/testing/testlog/SunOS-5.10_i86pc-i386/636714-org.apache.derbyTesting.functionTests.suites.All_diff.txt
 most recent as of this report:
 http://dbtg.thresher.com/derby/test/tinderbox_trunk16/jvm1.6/testing/testlog/SunOS-5.10_i86pc-i386/639156-org.apache.derbyTesting.functionTests.suites.All_diff.txt
 There was 1 failure:
 1) 
 testStartStopManagementFromApplication(org.apache.derbyTesting.functionTests.tests.management.ManagementMBeanTest)junit.framework.AssertionFailedError:
  expected:2 but was:5
   at 
 org.apache.derbyTesting.functionTests.tests.management.ManagementMBeanTest.startStopManagement(ManagementMBeanTest.java:86)
   at 
 org.apache.derbyTesting.functionTests.tests.management.ManagementMBeanTest.testStartStopManagementFromApplication(ManagementMBeanTest.java:56)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at 
 org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:101)
   at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
   at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
   at junit.extensions.TestSetup.run(TestSetup.java:25)
   at 
 org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
   at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
   at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
   at junit.extensions.TestSetup.run(TestSetup.java:25)
   at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
   at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
   at junit.extensions.TestSetup.run(TestSetup.java:25)
   at 
 org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (DERBY-3585) Document user authentication support for network server shutdown

2008-04-03 Thread Martin Zaun (JIRA)


 [ 
https://issues.apache.org/jira/browse/DERBY-3585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Martin Zaun updated DERBY-3585:
---

Derby Info: [Patch Available, Release Note Needed]  (was: [Release Note 
Needed])

Admin Guide patch available for review/comments/edits.

 Document user authentication support for network server shutdown
 

 Key: DERBY-3585
 URL: https://issues.apache.org/jira/browse/DERBY-3585
 Project: Derby
  Issue Type: Sub-task
  Components: Documentation
Reporter: Martin Zaun
Assignee: Martin Zaun
 Fix For: 10.4.0.0

 Attachments: DERBY-3585-0.diff, DERBY-3585-0.stat, DERBY-3585-0.zip, 
 releaseNote.html, releaseNote.html, releaseNote.html, releaseNote.html


 As part of the System Privileges work in DERBY-2109, the support of user 
 authentication for network server shutdown was discussed, implemented, and 
 committed (revision 632502).
 In order to address a security issue (missing user authentication for 
 shutdown), this feature introduces a few incompatibilities with the usage of 
 NetworkServerControl, which need to be documented.
 This JIRA is to provide for the user documentation and the release notes 
 describing the usage changes and incompatibilities.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DERBY-3489) Error message XRE04 does not include the right port number.

[
https://issues.apache.org/jira/browse/DERBY-3489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12585073#action_12585073
]

Øystein Grøvlen commented on DERBY-3489:

Thanks for the patch, Narayanan. It basically looks. I have only a
few comments:

- SlaveController#boot: Need to check for port being null. Check
what happens if you do startSlave without specifying port.
(Evidently the test suite does not test that. Such a test would be
good).

- ReplicationMessageReceive constructor: Parameter dbname is no
longer used

- ReplicationMessageReceive: Import of UnknownHostException no longer
necessary.

- MessageId: Does not seem to contain any significant change.

Error message XRE04 does not include the right port number.
---

Key: DERBY-3489
URL: https://issues.apache.org/jira/browse/DERBY-3489
Project: Derby
Issue Type: Bug
Components: Replication
Affects Versions: 10.4.0.0
Reporter: Øystein Grøvlen
Assignee: V.Narayanan
Attachments: Derby3489_1.diff, Derby3489_1.stat, Derby3489_2.diff,
Derby3489_2.stat

If the master is not able to connect to the slave, the error messages does
not include the right port number:
ij connect
'jdbc:derby:masterDB;user=oystein;password=pass;startMaster=true;slaveHost=localhost;slavePort=9901';
ERROR XRE04: Could not establish a connection to the peer of the replicated
database 'masterDB' on address 'localhost:-1'.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DERBY-3589) AllocPage.createPage() doesn't initialize minimumRecordSize correctly


[ 
https://issues.apache.org/jira/browse/DERBY-3589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12585070#action_12585070
 ] 

Knut Anders Hatlen commented on DERBY-3589:
---

I was too quick there. This change alone wouldn't solve DERBY-3116, since that 
issue is about a field being initialized too late, not about being initialized 
to the wrong value.

 AllocPage.createPage() doesn't initialize minimumRecordSize correctly
 -

 Key: DERBY-3589
 URL: https://issues.apache.org/jira/browse/DERBY-3589
 Project: Derby
  Issue Type: Bug
  Components: Store
Affects Versions: 10.3.1.4, 10.4.1.0
Reporter: Knut Anders Hatlen
Assignee: Knut Anders Hatlen
Priority: Minor

 AllocPage.createPage() will initialize minimumRecordSize to the same
 value as borrowedSpace. See this code taken from AllocPage.java:
 ---
   protected void createPage(PageKey newIdentity, int[] args) 
throws StandardException
   {
   super.createPage(newIdentity, args);
   // args[0] is the format id
   // args[1] is whether to sync the page to disk or not
   // args[2] is the pagesize (used by StoredPage)
   // args[3] is the spareSize (used by StoredPage)
   // args[4] is the number of bytes to reserve for container 
 header
   // args[5] is the minimumRecordSize
   // NOTE: the arg list here must match the one in FileContainer
   int pageSize = args[2];
   int minimumRecordSize = args[5];
   borrowedSpace = args[4];
 ---
 Here it correctly takes args[5] and puts into the local variable
 minimumRecordSize. However, that variable hides a field with the same
 name, and that field is set to args[4] in the call to
 super.createPage() at the first line in the method. The local variable
 is never used.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Issue Comment Edited: (DERBY-3489) Error message XRE04 does not include the right port number.

[
https://issues.apache.org/jira/browse/DERBY-3489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12585073#action_12585073
]

oysteing edited comment on DERBY-3489 at 4/3/08 5:32 AM:

Thanks for the patch, Narayanan. It basically looks good. I have only a
few comments:

- SlaveController#boot: Need to check for port being null. Check
what happens if you do startSlave without specifying port.
(Evidently the test suite does not test that. Such a test would be
good).

- ReplicationMessageReceive constructor: Parameter dbname is no
longer used

- ReplicationMessageReceive: Import of UnknownHostException no longer
necessary.

- MessageId: Does not seem to contain any significant change.

was (Author: oysteing):
Thanks for the patch, Narayanan. It basically looks. I have only a
few comments:

- SlaveController#boot: Need to check for port being null. Check
what happens if you do startSlave without specifying port.
(Evidently the test suite does not test that. Such a test would be
good).

- ReplicationMessageReceive constructor: Parameter dbname is no
longer used

- ReplicationMessageReceive: Import of UnknownHostException no longer
necessary.

- MessageId: Does not seem to contain any significant change.

Error message XRE04 does not include the right port number.
---

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DERBY-3200) Developer's Guide: Add examples showing use of SQL authorization with user authentication

2008-04-03 Thread Dag H. Wanvik (JIRA)

[
https://issues.apache.org/jira/browse/DERBY-3200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12585079#action_12585079
]

Dag H. Wanvik commented on DERBY-3200:
--

Some comments on the initial description section.

For example, if you set the default connection mode to noAccess, a
user with fullAccess can't grant any privileges to a user with
noAccess.

I guess he could, but it would be of little use, since the noAccess
would override the privilege.

And presumably if the default connection mode is readOnlyAccess, a
user with fullAccess can't grant any privileges beyond SELECT,

Again, the full access user could grant update privilege but it would
be of no use, since the grantee and only read (connection level
authorization overrides again).

which the user has anyway.

No, that is not the case: when sqlAuthorization mode is active, a user
only has access to her own tables by default (and read access to
system tables it seems).

Cf section How user authorization properties work together in the
dev guide:

(quote)

- The access mode specified for the
derby.database.defaultConnectionMode property overrides the
permissions that are granted by the owner of a database object. For
example, if a user is granted INSERT privileges on a table but the
user only has read-only connection authorization, the user cannot
insert data into the table.

I interpret this overrides as further restricts.

Only if the default connection mode is fullAccess is SQL authorization
mode meaningful.

No, even for connections with readOnly connection access, the
GRANT/REVOKE machinery can be used to further limit access (but not to
broaden it beyond readOnly).

That means that a fullAccess user can use GRANT to restrict another
user's privileges on a particular database that the user owns.

GRANT/REVOKE provides more fine graned access control that connection
level authorization. The way I think of this is that, when both are
used, the more limiting access provided by each authorization
mechanism (connection or sqlAUthorization) rules the day in any
particular case.

Hope this makes sense :) It is a bit confusing, so making running
examples to check understanding is very useful here. Sorry if I
misconstrued something.

Developer's Guide: Add examples showing use of SQL authorization with user
authentication
-

Key: DERBY-3200
URL: https://issues.apache.org/jira/browse/DERBY-3200
Project: Derby
Issue Type: Improvement
Components: Documentation
Reporter: Kim Haase
Assignee: Kim Haase
Priority: Minor
Attachments: auth2.log, AuthExampleClientSQLAuth1.java,
AuthExampleClientSQLAuth2.java, AuthExampleEmbeddedSQLAuth.java,
rdevcsecuresqlauthembeddedex.dita

This is the followup to DERBY-1823 that Francois Orsini suggested.
I've been experimenting and reading the Developer's Guide section on SQL
authorization (User authorizations, cdevcsecure36595).
It appears that the only use of SQL authorization mode is to restrict user
access, not to expand it.
For example, if you set the default connection mode to noAccess, a user with
fullAccess can't grant any privileges to a user with noAccess. And presumably
if the default connection mode is readOnlyAccess, a user with fullAccess
can't grant any privileges beyond SELECT, which the user has anyway.
Only if the default connection mode is fullAccess is SQL authorization mode
meaningful. That means that a fullAccess user can use GRANT to restrict
another user's privileges on a particular database that the user owns.
I'm running into a problem at the end, though. At the beginning of the
program, as nobody in particular, I was able to create several users, some of
them with full access. But at the end of the program, it seems that even a
user with full access isn't allowed to turn off those database properties:
Message: User 'MARY' does not have execute permission on PROCEDURE
'SYSCS_UTIL'.'SYSCS_SET_DATABASE_PROPERTY'.
This seems a bit extreme. I know that with SQL authorization on, the ability
to read from or write to database objects is further restricted to the owner
of the database objects. But the ability to execute built-in system
procedures? Can I log in as SYSCS_UTIL? How?
I realize that having access to SYSCS_SET_DATABASE_PROPERTY would allow me to
in effect delete myself -- but that's essentially what I do at the end of the
program that sets derby.connection.requireAuthentication but not
derby.database.sqlAuthorization.
The documentation does say that once you have turned on SQL authorization,
you can't turn it off. But it doesn't say that you can't turn anything else
off, either!
I'll attach the program I've been using. Most of

[jira] Updated: (DERBY-3509) The replication log shipper is not notified when a new replication transmitter is instantiated in MC#handleException.


 [ 
https://issues.apache.org/jira/browse/DERBY-3509?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Øystein Grøvlen updated DERBY-3509:
---

   Derby Info:   (was: [Patch Available])
Fix Version/s: 10.5.0.0

Thanks, Narayanan. Patch looks good.  Committed to trunk at revision 644291.

 The replication log shipper is not notified when a new replication 
 transmitter is instantiated in MC#handleException.
 -

 Key: DERBY-3509
 URL: https://issues.apache.org/jira/browse/DERBY-3509
 Project: Derby
  Issue Type: Bug
  Components: Newcomer, Replication
Affects Versions: 10.4.0.0
Reporter: Jørgen Løland
Assignee: V.Narayanan
Priority: Minor
 Fix For: 10.5.0.0

 Attachments: Derby3509_1.diff, Derby3509_1.stat


 In MasterController#handleException, a new ReplicationMessageTransmit object 
 is created if the exception is IOException. However, the logShipper is not 
 notified that the new transmitter should be used. A possible solution would 
 be to add a setTransmitter method to AsynchronousLogShipper. Note that the 
 logShipper may contain state information that cannot be discarded, so it 
 cannot be reinstantiated.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: [VOTE] Thomas Nielsen as a Derby committer

2008-04-03 Thread Lance Andersen


+1 (not sure if i voted earlier or not)
On Apr 2, 2008, at 11:06 PM, Jean T. Anderson wrote:


Bryan Pendleton wrote:

I propose that Thomas Nielsen shall be a Derby committer.

+1


-jean

[jira] Updated: (DERBY-3589) AllocPage.createPage() doesn't initialize minimumRecordSize correctly


 [ 
https://issues.apache.org/jira/browse/DERBY-3589?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Knut Anders Hatlen updated DERBY-3589:
--

Attachment: d3589-1a.stat
d3589-1a.diff

Attached is a patch that changes the signature of CachedPage.createPage() so 
that it takes a PageCreationArgs object instead of an int array. The 
PageCreationArgs object contains the same information as the array, only that 
it has named fields and thereby fixes the problem with minimumRecordSize being 
taken from the wrong array element.

I have started the full regression test suite.

 AllocPage.createPage() doesn't initialize minimumRecordSize correctly
 -

 Key: DERBY-3589
 URL: https://issues.apache.org/jira/browse/DERBY-3589
 Project: Derby
  Issue Type: Bug
  Components: Store
Affects Versions: 10.3.1.4, 10.4.1.0
Reporter: Knut Anders Hatlen
Assignee: Knut Anders Hatlen
Priority: Minor
 Attachments: d3589-1a.diff, d3589-1a.stat


 AllocPage.createPage() will initialize minimumRecordSize to the same
 value as borrowedSpace. See this code taken from AllocPage.java:
 ---
   protected void createPage(PageKey newIdentity, int[] args) 
throws StandardException
   {
   super.createPage(newIdentity, args);
   // args[0] is the format id
   // args[1] is whether to sync the page to disk or not
   // args[2] is the pagesize (used by StoredPage)
   // args[3] is the spareSize (used by StoredPage)
   // args[4] is the number of bytes to reserve for container 
 header
   // args[5] is the minimumRecordSize
   // NOTE: the arg list here must match the one in FileContainer
   int pageSize = args[2];
   int minimumRecordSize = args[5];
   borrowedSpace = args[4];
 ---
 Here it correctly takes args[5] and puts into the local variable
 minimumRecordSize. However, that variable hides a field with the same
 name, and that field is set to args[4] in the call to
 super.createPage() at the first line in the method. The local variable
 is never used.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Closed: (DERBY-3577) Add a stored procedure for releasing a list of LOB locators


 [ 
https://issues.apache.org/jira/browse/DERBY-3577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kristian Waagan closed DERBY-3577.
--

Resolution: Won't Fix

See parent task for explanation.
In short, we'll go for the best optimization in the next version to avoid 
compatibility problems.

 Add a stored procedure for releasing a list of LOB locators
 ---

 Key: DERBY-3577
 URL: https://issues.apache.org/jira/browse/DERBY-3577
 Project: Derby
  Issue Type: Sub-task
  Components: Network Client, Network Server
Affects Versions: 10.4.0.0, 10.5.0.0
Reporter: Kristian Waagan
Assignee: Kristian Waagan
Priority: Minor

 Implement a stored procedure for releasing a list of LOB locators.
 The reason for implementing it is that it is more effective than invoking a 
 stored procedure for each individual LOB locator.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Closed: (DERBY-3575) Optimize client side LOB release mechanism by reducing the number of round-trips

[
https://issues.apache.org/jira/browse/DERBY-3575?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Kristian Waagan closed DERBY-3575.
--

Resolution: Won't Fix

Closing as Won't Fix.
I hope to contribute on the piggy-backing solution for the next release.

Optimize client side LOB release mechanism by reducing the number of
round-trips

Key: DERBY-3575
URL: https://issues.apache.org/jira/browse/DERBY-3575
Project: Derby
Issue Type: Improvement
Components: Network Client
Affects Versions: 10.4.0.0, 10.5.0.0
Reporter: Kristian Waagan
Assignee: Kristian Waagan
Priority: Minor

The current mechanism for freeing LOB locators from the client driver, is to
invoke a stored procedure for each LOB locator every time the result set
position is changed. This can potentially result in a number of round-trips
to the server.
The mechanism can easily be optimized by adding a stored procedure that takes
a list of LOB locators and frees them all. The level of optimization can be
tweaked by changing the timing of the stored procedure invocation, and this
must also be balanced with regards to resource consumption on the server. The
more LOB locators we collect on the client before we send the release
request, the more memory is bound to LOB resources on the server.
Possible release points:
* on each result set positioning
* when a threshold value is reached
* on result set close
* when Blob/Clob.free is called (problematic, as the Blob/Clob is detached
from the result set)
There are some compatibility issues to consider, and the client driver will
most likely have to implement both the naive and the optimized mechanism. For
this reason, it might be good if the release mechanism can be tightly
encapsulated (for instance within LOBStateTracker).
Note that piggy-backing the locators would be the most effective solution,
but it is likely that implementing it requires more time and thus I'm
reluctant to do so this close to the release. I'm saying this because we do
need a fix to go into 10.4.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DERBY-3567) AsynchronousLogShipper#forceFlush should time out

[
https://issues.apache.org/jira/browse/DERBY-3567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12585125#action_12585125
]

Øystein Grøvlen commented on DERBY-3567:

I think forceFlush also needs to consider the stopShipping flag. If the flag is
set, the log shipper thread may exit its loop without notifying the waiting
thread. This will cause an unecessary delay of a waiting user thread.

AsynchronousLogShipper#forceFlush should time out
-

Key: DERBY-3567
URL: https://issues.apache.org/jira/browse/DERBY-3567
Project: Derby
Issue Type: Bug
Components: Replication
Affects Versions: 10.4.0.0, 10.5.0.0
Reporter: Jørgen Løland
Assignee: Jørgen Løland
Attachments: derby-3567-1a.diff, derby-3567-1a.stat,
derby-3567-1b.diff

If the network connection to the slave is lost,
ObjectOutputStream#writeObject may be blocked for 2 minutes before failing
(not configurable TCP property).
Currently, ALS#forceFlush sends a chunk of log to the slave using the client
thread. The client thread cannot be blocked for 2 minutes before giving up.
Rather, it should notify the log shipper that it has to send log immediately,
and then wait for a short while (until notified or e.g. maximum 5 seconds).
If the log shipper has not been able to empty some space in the log buffer by
then, replication should be stopped.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Subscription: Derby: JIRA issues with patch available

2008-04-03 Thread jira

Issue Subscription
Filter: Derby: JIRA issues with patch available (11 issues)
Subscriber: derby-dev


Key Summary
DERBY-3567  AsynchronousLogShipper#forceFlush should time out
https://issues.apache.org/jira/browse/DERBY-3567
DERBY-3489  Error message XRE04 does not include the right port number.
https://issues.apache.org/jira/browse/DERBY-3489
DERBY-3585  Document user authentication support for network server shutdown
https://issues.apache.org/jira/browse/DERBY-3585
DERBY-3581  Changing certain properties on client DataSource objects causes 
existing connections to reflect the new values
https://issues.apache.org/jira/browse/DERBY-3581
DERBY-3445  Make it easier to use the EMMA tool to measure the code coverage of 
the Derby testing
https://issues.apache.org/jira/browse/DERBY-3445
DERBY-3543  NetworkServerControl with options but no command does not give 
usage message
https://issues.apache.org/jira/browse/DERBY-3543
DERBY-3162  Create a framework for replication tests
https://issues.apache.org/jira/browse/DERBY-3162
DERBY-2953  Dump the information about rollbacks of the global transaction 
(introduced in DERBY-2220 and DERBY-2432) to derby.log
https://issues.apache.org/jira/browse/DERBY-2953
DERBY-2871  XATransactionTest gets XaException: Error executing a 
XAResource.commit(), server returned XAER_PROTO.
https://issues.apache.org/jira/browse/DERBY-2871
DERBY-3409  Remove JDBC 2.0-specific topics from Reference Manual and merge 
implementation notes as needed
https://issues.apache.org/jira/browse/DERBY-3409
DERBY-3227  Remove final from all getConnection() methods in EmbeddedDataSource
https://issues.apache.org/jira/browse/DERBY-3227

[jira] Updated: (DERBY-3326) Introduce a caching logical connection and logical prepared statement in the client driver


 [ 
https://issues.apache.org/jira/browse/DERBY-3326?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kristian Waagan updated DERBY-3326:
---

Attachment: derby-3326-9a-temp_table_test.diff

'derby-3326-9a-temp_table_test.diff' adds a test in 
jdbcapi.StatementPoolingTest that tests that temporary tables are deleted and 
not visible across logical connections.
Also set the createDatabase to create on the data source for some of the tests, 
so they can be run individually and not fail if the database hasn't been 
created yet.

Committed to trunk with revision 644360 and to the 10.4 branch with revision 
644373.

 Introduce a caching logical connection and logical prepared statement in the 
 client driver
 --

 Key: DERBY-3326
 URL: https://issues.apache.org/jira/browse/DERBY-3326
 Project: Derby
  Issue Type: Sub-task
  Components: JDBC, Network Client
Affects Versions: 10.4.0.0
Reporter: Kristian Waagan
Assignee: Kristian Waagan
 Fix For: 10.4.0.0

 Attachments: derby-3326-1a_cpds_testing_preparation.diff, 
 derby-3326-1a_cpds_testing_preparation.stat, 
 derby-3326-1b_cpds_testing_preparation.diff, 
 derby-3326-2a-method_rename.diff, derby-3326-3a-new_classes.diff, 
 derby-3326-3a-new_classes.stat, derby-3326-3b-new_classes.diff, 
 derby-3326-3b-new_classes.stat, derby-3326-3c-new_classes.diff, 
 derby-3326-4a-cpdsc_shutEngine.diff, 
 derby-3326-5a-enable_logicalstmtentity_pptest.diff, 
 derby-3326-6a-npe_fix_synch_CLC.diff, derby-3326-6b-npe_fix_synch_CLC.diff, 
 derby-3326-7a-prepare_column_indexes_names_fix.diff, 
 derby-3326-8a-use_session_data_caching.diff, 
 derby-3326-9a-temp_table_test.diff


 A logical connection with statement caching capabilities is required to 
 support JDBC prepared statement pooling. Further, a logical prepared 
 statement object is also needed.
 The logical prepared statements will be generated by the logical connection's 
 'prepareStatement'-method.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Regression Test Report - Daily 643947 - Sun DBTG

2008-04-03 Thread Henri . Vandescheur

[Auto-generated mail]

*Daily* 643947/2008-04-02 18:01:11 MEST

Failed  TestsOK  Skip  Duration   Suite
---
*Jvm: 1.6*
 lin
0274274 083.93% derbyall
F:1,E:097779776 0   1332.81% suitesAll
 sles
1274273 075.14% derbyall
F:2,E:097769774 0   913.68% suitesAll
 sol
0274274 077.02% derbyall
F:1,E:097779776 0   1423.32% suitesAll
 solN+1
0274274 098.69% derbyall
F:1,E:097779776 0   174.57% suitesAll
 sparc
1274273 067.90% derbyall
F:1,E:097779776 0   368.76% suitesAll
 vista
0274274 094.83% derbyall
F:1,E:086128611 064.81% suitesAll
 vista-64
0274274 0   100.27% derbyall
F:1,E:086128611 0   101.78% suitesAll
 w2003
1274273 091.43% derbyall
F:1,E:086128611 0   130.88% suitesAll
  Details in  
http://dbtg.thresher.com/derby/test/Daily/jvm1.6/testing/Limited/testSummary-643947.html
 
  Attempted failure analysis in
  
http://dbtg.thresher.com/derby/test/Daily/jvm1.6/FailReports/643947_bySig.html 

*Jvm: 1.5*
 lin
0275275 081.18% derbyall
F:1,E:080578056 0   1029.65% suitesAll
 sles
0275275 073.15% derbyall
F:1,E:080578056 0   588.15% suitesAll
 sol
0275275 080.65% derbyall
F:1,E:080578056 0   884.93% suitesAll
 solN+1
0275275 090.03% derbyall
F:1,E:080578056 0   816.87% suitesAll
 sparc
0275275 068.69% derbyall
F:1,E:080578056 0   729.91% suitesAll
 vista
0275275 072.54% derbyall
F:1,E:068926891 0   415.91% suitesAll
 w2003
0275275 075.44% derbyall
F:1,E:868926883 0   236.44% suitesAll
  Details in  
http://dbtg.thresher.com/derby/test/Daily/jvm1.5/testing/Limited/testSummary-643947.html
 
  Attempted failure analysis in
  
http://dbtg.thresher.com/derby/test/Daily/jvm1.5/FailReports/643947_bySig.html 

*Jvm: 1.4*
 lin
0272272 281.65% derbyall
079057905 0   917.21% suitesAll
 sles
0272272 273.67% derbyall
079057905 0   544.20% suitesAll
 sol
0272272 277.77% derbyall
079057905 0   702.16% suitesAll
 solN+1
0272272 289.98% derbyall
079057905 0   759.92% suitesAll
 sparc
0272272 268.45% derbyall
079057905 0   724.17% suitesAll
 vista
0272272 271.87% derbyall
067406740 0   401.69% suitesAll
 w2003
0272272 276.18% derbyall
F:0,E:867446736 0   225.67% suitesAll
  Details in  
http://dbtg.thresher.com/derby/test/Daily/jvm1.4/testing/Limited/testSummary-643947.html
 
  Attempted failure analysis in
  
http://dbtg.thresher.com/derby/test/Daily/jvm1.4/FailReports/643947_bySig.html 

---

Changes in  http://dbtg.thresher.com/derby/test/Daily/UpdateInfo/643947.txt 

( All results in http://dbtg.thresher.com/derby/test/ )

[jira] Resolved: (DERBY-3326) Introduce a caching logical connection and logical prepared statement in the client driver


 [ 
https://issues.apache.org/jira/browse/DERBY-3326?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kristian Waagan resolved DERBY-3326.


Resolution: Fixed

Resolving the issue.
There is still a minor issue regarding the prepare calls taking an int and a 
string array. The assert will trigger in sane builds, whereas in insane builds 
enabling statement caching will give you the same behavior as without caching.

 Introduce a caching logical connection and logical prepared statement in the 
 client driver
 --

 Key: DERBY-3326
 URL: https://issues.apache.org/jira/browse/DERBY-3326
 Project: Derby
  Issue Type: Sub-task
  Components: JDBC, Network Client
Affects Versions: 10.4.0.0
Reporter: Kristian Waagan
Assignee: Kristian Waagan
 Fix For: 10.4.0.0

 Attachments: derby-3326-1a_cpds_testing_preparation.diff, 
 derby-3326-1a_cpds_testing_preparation.stat, 
 derby-3326-1b_cpds_testing_preparation.diff, 
 derby-3326-2a-method_rename.diff, derby-3326-3a-new_classes.diff, 
 derby-3326-3a-new_classes.stat, derby-3326-3b-new_classes.diff, 
 derby-3326-3b-new_classes.stat, derby-3326-3c-new_classes.diff, 
 derby-3326-4a-cpdsc_shutEngine.diff, 
 derby-3326-5a-enable_logicalstmtentity_pptest.diff, 
 derby-3326-6a-npe_fix_synch_CLC.diff, derby-3326-6b-npe_fix_synch_CLC.diff, 
 derby-3326-7a-prepare_column_indexes_names_fix.diff, 
 derby-3326-8a-use_session_data_caching.diff, 
 derby-3326-9a-temp_table_test.diff


 A logical connection with statement caching capabilities is required to 
 support JDBC prepared statement pooling. Further, a logical prepared 
 statement object is also needed.
 The logical prepared statements will be generated by the logical connection's 
 'prepareStatement'-method.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DERBY-3545) NullPointerException in TableFunctionTest.noSpecialCollation and specialCollation


[ 
https://issues.apache.org/jira/browse/DERBY-3545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12585157#action_12585157
 ] 

Kathey Marsden commented on DERBY-3545:
---

I see this problem as well on linux with both IBM 1.5 and IBM 1.6 jvms.


 NullPointerException in TableFunctionTest.noSpecialCollation and 
 specialCollation
 -

 Key: DERBY-3545
 URL: https://issues.apache.org/jira/browse/DERBY-3545
 Project: Derby
  Issue Type: Bug
  Components: Regression Test Failure
Affects Versions: 10.4.1.0, 10.5.0.0
 Environment: IBM 1.5 - linux - insane jars
Reporter: Daniel John Debrunner
 Attachments: 
 TEST-org.apache.derbyTesting.functionTests.tests.lang.TableFunctionTest.xml


 Running the tests through ant.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Closed: (DERBY-3566) Alter column set data type not allowed in soft upgrade with unique constraint


 [ 
https://issues.apache.org/jira/browse/DERBY-3566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kathey Marsden closed DERBY-3566.
-

   Resolution: Fixed
Fix Version/s: 10.5.0.0
   10.4.1.0

committed to trunk and 10.4


 Alter column set data type not allowed in soft upgrade with unique constraint
 -

 Key: DERBY-3566
 URL: https://issues.apache.org/jira/browse/DERBY-3566
 Project: Derby
  Issue Type: Bug
  Components: SQL
Affects Versions: 10.4.0.0
Reporter: Kathey Marsden
Assignee: Anurag Shekhar
Priority: Minor
 Fix For: 10.4.1.0, 10.5.0.0

 Attachments: derby-3566_v1.diff


 In 10.3 I can do this:
 ij create table t0 (i int not null, v varchar(1) not null, constraint  uq 
 unique(v,i));
 0 rows inserted/updated/deleted
 ij alter table t0 alter v set data type varchar(2);
 0 rows inserted/updated/deleted
 ij
 In 10.4 soft upgrade mode I cannot:
 ij create table t0 (i int not null, v varchar(1) not null, constraint  uq 
 unique(v,i));
 0 rows inserted/updated/deleted
 ij alter table t0 alter v set data type varchar(2);
 ERROR 42Z20: Column 'V' cannot be made nullable. It is part of a primary key 
 or unique constraint, which cannot have any
 nullable columns.
 ij

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Problems with ant genchanges

2008-04-03 Thread Dyre . Tjeldvoll

Myrna van Lunteren [EMAIL PROTECTED] writes:

 I wanted only those issues that were not already fixed in an already
 released version...I think the tool automatically picked the last
 released version (in my case, 10.2.2.0), but because of the two
 versions off the 10.2 branch, there were a number of issues that had
 been backported earlier, and were actually fixed in 10.2.1.6;  hence
 that release shows up as to be excluded in the ChangesFileGenerator.

 I think you'd want everything that's marked fixed 10.4.0.0, and
 10.4.1.0, except if it's marked also fixed in 10.3.1.4, 10.3.1.5
 (which issues would've gotten included into 10.3.2.1), or 10.3.2.1
 which was also a released version, for those would likely be things
 that have gotten backported after the initial release off the 10.3
 branch. Issues that got marked fixed in 10.3.2.2 (in addition to
 10.4.0) would be ok to pick up. I think that's all the versions?

 The ChangesFileGenerator should get modified...

 I hope this makes sense...

Yes, I think I see what you mean. The problem is that neither the
ReleaseNoteGenerator or the ChangesGenerator will filter out those
issues already fixed in an update release (without special patching),
and there doesn't seem to be a way to search for 'fixVersion == 10.4.*
 !(fixVersion == 10.3.2.1 || fixVersion == 10.3.1.4) in Jira. (You
can't negate a field predicate).

I guess it would be possible to modify the generators to use table
functions and SQL to get the correct set of Jira issues. But for the upcoming
release candidate I'm just going to patch this by hand.

-- 
dt

[jira] Commented: (DERBY-3581) Changing certain properties on client DataSource objects causes existing connections to reflect the new values

[
https://issues.apache.org/jira/browse/DERBY-3581?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12585177#action_12585177
]

Kristian Waagan commented on DERBY-3581:

In the issue description, I wrote the following:
- Kristian wrote:
Further, I also suspect the concept of a deferred reset has been introduced
because of the feature/bug described by this Jira issue. A deferred reset seems
to be a mechanism to avoid a round-trip to validate the newly changed
DataSource properties (typically user, password and security mechanism).
I will look into removing code related to deferred resets as well. If you have
historic information about these parts of the driver, I would appreciate if you
share it with the community if possible.
-

After reading some sections in the DRDA spec, I think that statement is wrong.
Sending what is called the deferred reset sequence in the driver (EXCSAT,
ACCSEC, SECCHK and ACCRDB), is specified by the DRDA spec. It says the source
server *can* send it if it wants to reuse the connection for another
application or transaction, but I haven't found a place where it says it has to
send it.
I thought about sending only SECCHK and ACCRDB to reduce the work, but this is
not allowed by the DRDA spec (but I think it is allowed by the network server).

My current conclusion is that the deferred reset code still has to be used and
cannot be removed. The code related to picking up changes in the data source
can however still be removed.
Implementing an alternative reset protocol might be possible, but that would
be 10.5 or maybe even 11. I'm sure a more efficient scheme can be implemented,
but it is not clear to me what the solution space looks like bounded by the
DRDA spec.

BTW; derbyall ran cleanly for the 1a patch.

Changing certain properties on client DataSource objects causes existing
connections to reflect the new values
--

Key: DERBY-3581
URL: https://issues.apache.org/jira/browse/DERBY-3581
Project: Derby
Issue Type: Bug
Components: JDBC, Network Client
Affects Versions: 10.3.2.1, 10.4.0.0, 10.5.0.0
Reporter: Kristian Waagan
Assignee: Kristian Waagan
Attachments: derby-3581-1a-remove_user_password_iteration1.diff

The client driver has code propagating changes made to the DataSource to
existing connections created by that DataSource.
There is some discussion of this in the thread
http://www.nabble.com/ConnectionPoolDataSource-properties-td15740457.html,
and there is also an example of what can happen due to this feature.
Besides from being a bug with the potential to cause strange errors in
deployment, the issue also makes the client driver code harder to read and
understand.
As far as I can see, there is also some related code in other parts of the
client driver, for instance for fully resetting statements. There is
mention of dynamic versus static sections in the comments (this one from
am.Statement):
// If a dataSource is passed into resetClientConnection(), then we will
assume
// properties on the dataSource may have changed, and we will need to go
through
// the open-statement list on the connection and do a full reset on all
statements,
// including preparedStatement's and callableStatement's. This is
because property
// change may influence the section we allocate for the
preparedStatement, and
// also the cursor attributes, i.e. setCursorSensitivity().
// If no dataSource is passed into resetClientConnection(), then we will
do the
// minimum reset required for preparedStatement's and callableStatement's.
Note that the reset code for statements is also invoked when
ClientPooledConnection.getConnection() is invoked. I do not understand why we
should reset statements when we get a new logical connection.
Further, I also suspect the concept of a deferred reset has been introduced
because of the feature/bug described by this Jira issue. A deferred reset
seems to be a mechanism to avoid a round-trip to validate the newly changed
DataSource properties (typically user, password and security mechanism).
I will look into removing code related to deferred resets as well. If you
have historic information about these parts of the driver, I would appreciate
if you share it with the community if possible.
Just to be clear, it is my opinion that changed DataSource properties should
take effect when one of the following methods is invoked:
* DataSource.getConnection()
* ConnectionPoolDataSource.getPooledConnection()
* XADataSource.getXAConnection()
All of the methods above returns a physical connection. Properties like user
name and password are associated with the

[VOTE] Jørgen Løland as a committer

Please vote on whether we should make Jørgen Løland a Derby committer. 
The polls close at 5:00 pm San Francisco time on Thursday April 10.


Jørgen has contributed significantly to adding replication functionality 
to Derby. Although he readily seeks and cheerfully incorporates 
community feedback, his work does not need supervision by other 
committers. In addition, Jørgen fields questions on the user lists and 
his interactions with the broader community are respectful, thoughtful, 
and thorough.


Regards,
-Rick

[jira] Created: (DERBY-3592) The Java 5 javadoc tool generates a spurious output line when digesting the doctitle element for the public api

The Java 5 javadoc tool generates a spurious output line when digesting the 
doctitle element for the public api
---

 Key: DERBY-3592
 URL: https://issues.apache.org/jira/browse/DERBY-3592
 Project: Derby
  Issue Type: Bug
  Components: Javadoc
Affects Versions: 10.4.1.0
Reporter: Rick Hillegas
Assignee: Rick Hillegas


The Java 5 javadoc tool seems to have a bug. This bug seems to be fixed in Java 
6. The issue is discussed in the following email thread: 
http://www.nabble.com/some-comments-on-the-10.4-beta-distribution-td16408536.html#a16408536
 which puts forward the following theory:

The exact same javadoc directive is used to build the jdbc3 and jdbc4 public 
apis. The spurious line turns up in the jdbc3 javadoc but not the jdbc4 
javadoc. The jdbc3 javadoc is built with the Java 5 javadoc tool and the jdbc4 
javadoc is built with the Java 6 javadoc tool. I think that the Java 5 javadoc 
tool may have a bug that was corrected in Java 6.

What we're trying to do in this doctitle element is a bit tricky. We are 
trying to generate javadoc whose overview page has a title consisting of the 
Derby logo followed by some useful text. The doctitle element does not allow 
nested image elements, and we appear to have hacked around this by stuffing the 
image and text into a CDATA section. That CDATA section survives the Java 6 
javadoc tool but is munged by the Java 5 javadoc tool.

I can get rid of the spurious line at the cost of removing the Derby logo. That 
is, I get rid of the CDATA section and just put text inside the doctitle 
element like so:

Doctitle Apache Derby ${major}.${minor} API Documentation/Doctitle 

I miss the pretty logo, but I think that the output without the logo looks 
better than the output with both the logo and the spurious line.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[VOTE] V. Narayanan as a committer

Please vote on whether we should make V. Narayanan a Derby committer. 
The polls close at 5:00 pm San Francisco time on Thursday April 10.


For several years, Narayanan has contributed valuable features and fixes 
to Derby, starting with JDBC4 and continuing through recent work on 
Derby replication. Narayanan eagerly seeks the community's advice and 
thoroughly responds to feedback. He also fields issues on the user 
list--there his responses are detailed and respectful. With commit 
privilege he will be even more effective.


Regards,
-Rick

[jira] Updated: (DERBY-3540) Document the JMX management and monitoring functionality

2008-04-03 Thread Kim Haase (JIRA)

[
https://issues.apache.org/jira/browse/DERBY-3540?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Kim Haase updated DERBY-3540:
-

Attachment: tadminconfigsysteminformation.html
cadminconfig86869.html
DERBY-3540-1.diff

Here is a draft of a paragraph that I've put into the introductory topics
Obtaining system information and Managing the Derby Network Server in the
Admin Guide. I'm attaching DERBY-3540-1.diff and the two files,
tadminconfigsysteminformation.html and cadminconfig86869.html.

Is this okay, or do we need to add some more basic information in this
paragraph?

If it's okay, I can put it in some other places, though I'm not sure if there
are any other appropriate places at this point. Does JMX apply only to Network
Server mode, not embedded mode? Embedded mode is mostly discussed in the
Developer's Guide, though there's not an obvious place to put JMX info there.

Thanks very much. The wiki information is great and should be very helpful when
I have time to transfer it to the docs.

Document the JMX management and monitoring functionality

Key: DERBY-3540
URL: https://issues.apache.org/jira/browse/DERBY-3540
Project: Derby
Issue Type: Improvement
Components: Documentation, JMX
Affects Versions: 10.4.0.0
Reporter: John H. Embretsen
Assignee: Kim Haase
Attachments: cadminconfig86869.html, DERBY-3540-1.diff,
tadminconfigsysteminformation.html

Brand new management and monitoring capabilities using JMX were starting to
be added to Derby in the first calendar quarter of 2008. This issue tracks
efforts documenting this functionality.
A JMX MM functional specification document (funcSpec.html) is attached to
DERBY-1387. More information may be available on the wiki -
http://wiki.apache.org/db-derby/DerbyJMX - and in JMX-related Javadocs
(published API) (packages org.apache.derby.mbeans and
org.apache.derby.mbeans.drda).

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (DERBY-3592) The Java 5 javadoc tool generates a spurious output line when digesting the doctitle element for the public api


 [ 
https://issues.apache.org/jira/browse/DERBY-3592?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rick Hillegas updated DERBY-3592:
-

Attachment: derby-3592-01-removeImgTag.diff

Attaching derby-3592-01-removeImgTag.diff. This removes the derby logo from the 
doctitle of the public api and eliminates the spurious line in the jdbc3 
javadoc. Committed at subversion revision 644417.

 The Java 5 javadoc tool generates a spurious output line when digesting the 
 doctitle element for the public api
 ---

 Key: DERBY-3592
 URL: https://issues.apache.org/jira/browse/DERBY-3592
 Project: Derby
  Issue Type: Bug
  Components: Javadoc
Affects Versions: 10.4.1.0
Reporter: Rick Hillegas
Assignee: Rick Hillegas
 Attachments: derby-3592-01-removeImgTag.diff


 The Java 5 javadoc tool seems to have a bug. This bug seems to be fixed in 
 Java 6. The issue is discussed in the following email thread: 
 http://www.nabble.com/some-comments-on-the-10.4-beta-distribution-td16408536.html#a16408536
  which puts forward the following theory:
 The exact same javadoc directive is used to build the jdbc3 and jdbc4 public 
 apis. The spurious line turns up in the jdbc3 javadoc but not the jdbc4 
 javadoc. The jdbc3 javadoc is built with the Java 5 javadoc tool and the 
 jdbc4 javadoc is built with the Java 6 javadoc tool. I think that the Java 5 
 javadoc tool may have a bug that was corrected in Java 6.
 What we're trying to do in this doctitle element is a bit tricky. We are 
 trying to generate javadoc whose overview page has a title consisting of the 
 Derby logo followed by some useful text. The doctitle element does not 
 allow nested image elements, and we appear to have hacked around this by 
 stuffing the image and text into a CDATA section. That CDATA section survives 
 the Java 6 javadoc tool but is munged by the Java 5 javadoc tool.
 I can get rid of the spurious line at the cost of removing the Derby logo. 
 That is, I get rid of the CDATA section and just put text inside the 
 doctitle element like so:
 Doctitle Apache Derby ${major}.${minor} API Documentation/Doctitle 
 I miss the pretty logo, but I think that the output without the logo looks 
 better than the output with both the logo and the spurious line.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Closed: (DERBY-3592) The Java 5 javadoc tool generates a spurious output line when digesting the doctitle element for the public api

[
https://issues.apache.org/jira/browse/DERBY-3592?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Rick Hillegas closed DERBY-3592.

Resolution: Fixed

The Java 5 javadoc tool generates a spurious output line when digesting the
doctitle element for the public api
---

Key: DERBY-3592
URL: https://issues.apache.org/jira/browse/DERBY-3592
Project: Derby
Issue Type: Bug
Components: Javadoc
Affects Versions: 10.4.1.0
Reporter: Rick Hillegas
Assignee: Rick Hillegas
Attachments: derby-3592-01-removeImgTag.diff

The Java 5 javadoc tool seems to have a bug. This bug seems to be fixed in
Java 6. The issue is discussed in the following email thread:
http://www.nabble.com/some-comments-on-the-10.4-beta-distribution-td16408536.html#a16408536
which puts forward the following theory:
The exact same javadoc directive is used to build the jdbc3 and jdbc4 public
apis. The spurious line turns up in the jdbc3 javadoc but not the jdbc4
javadoc. The jdbc3 javadoc is built with the Java 5 javadoc tool and the
jdbc4 javadoc is built with the Java 6 javadoc tool. I think that the Java 5
javadoc tool may have a bug that was corrected in Java 6.
What we're trying to do in this doctitle element is a bit tricky. We are
trying to generate javadoc whose overview page has a title consisting of the
Derby logo followed by some useful text. The doctitle element does not
allow nested image elements, and we appear to have hacked around this by
stuffing the image and text into a CDATA section. That CDATA section survives
the Java 6 javadoc tool but is munged by the Java 5 javadoc tool.
I can get rid of the spurious line at the cost of removing the Derby logo.
That is, I get rid of the CDATA section and just put text inside the
doctitle element like so:
Doctitle Apache Derby ${major}.${minor} API Documentation/Doctitle
I miss the pretty logo, but I think that the output without the logo looks
better than the output with both the logo and the spurious line.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DERBY-3592) The Java 5 javadoc tool generates a spurious output line when digesting the doctitle element for the public api

[
https://issues.apache.org/jira/browse/DERBY-3592?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12585204#action_12585204
]

Rick Hillegas commented on DERBY-3592:
--

Merged 644417 from trunk to 10.4 branch at subversion revision 644419.

The Java 5 javadoc tool generates a spurious output line when digesting the
doctitle element for the public api
---

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (DERBY-3540) Document the JMX management and monitoring functionality

2008-04-03 Thread Kim Haase (JIRA)


 [ 
https://issues.apache.org/jira/browse/DERBY-3540?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kim Haase updated DERBY-3540:
-

Derby Info: [Patch Available]

 Document the JMX management and monitoring functionality
 

 Key: DERBY-3540
 URL: https://issues.apache.org/jira/browse/DERBY-3540
 Project: Derby
  Issue Type: Improvement
  Components: Documentation, JMX
Affects Versions: 10.4.0.0
Reporter: John H. Embretsen
Assignee: Kim Haase
 Attachments: cadminconfig86869.html, DERBY-3540-1.diff, 
 tadminconfigsysteminformation.html


 Brand new management and monitoring capabilities using JMX were starting to 
 be added to Derby in the first calendar quarter of 2008. This issue tracks 
 efforts documenting this functionality.
 A JMX MM functional specification document (funcSpec.html) is attached to 
 DERBY-1387. More information may be available on the wiki - 
 http://wiki.apache.org/db-derby/DerbyJMX - and in JMX-related Javadocs 
 (published API) (packages org.apache.derby.mbeans and 
 org.apache.derby.mbeans.drda).

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DERBY-3320) Database creation and boot should fail if collation=TERRITORY_BASED and the selected locale is not supported

2008-04-03 Thread Mamta A. Satoor (JIRA)


[ 
https://issues.apache.org/jira/browse/DERBY-3320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12585205#action_12585205
 ] 

Mamta A. Satoor commented on DERBY-3320:


I am researching into how support for a Collator can be removed from a JVM. 
What I am hoping to accomplish is create a territory based database with say 
Norwegian locale. Then shutdown the database and remove the support for 
Norwegian locale from the JVM in such a way that the Collator object for 
Nrowegian local can not be instantiated for that JVM. Then boot the database 
again and issue a SQL which requires collation operation and that SQL should 
fail because Collator could not be found for Norwegian. If anyone has any ideas 
on removal of Collator, please post a comment here.

 Database creation and boot should fail if collation=TERRITORY_BASED and the 
 selected locale is not supported
 

 Key: DERBY-3320
 URL: https://issues.apache.org/jira/browse/DERBY-3320
 Project: Derby
  Issue Type: Bug
Affects Versions: 10.4.0.0
 Environment: Java ME:
 Product: phoneME Advanced (phoneme_advanced_mr2-b34)
 Profile: Foundation Profile Specification 1.1
 Linux 2.4.21-40.ELsmp #1 SMP Thu Feb 2 22:14:12 EST 2006 i686 athlon i386 
 GNU/Linux
Reporter: Vemund Østgaard
Assignee: Mamta A. Satoor
 Attachments: DERBY_3320_Collator_Support_Check_diff_v2.txt, 
 DERBY_3320_Collator_Support_Check_stat_v2.txt, 
 DERBY_3320_not_ready_for_commit_diff_v1.txt, 
 DERBY_3320_not_ready_for_commit_stat_v1.txt, DERBY_3320_Repro.java


 A problem I've discovered when testing with the phoneME advanced platform is 
 that the collationtests expect other locales than Locale.US to be available 
 on the platform that is used for the test, and for phoneME advanced (when 
 compiled as foundation profile) only Locale.US is available. From the jdk1.6 
 javadoc of Collator.getAvailableLocales() I see that only Locale.US is 
 strictly required:
 public static Locale[] getAvailableLocales()
 Returns an array of all locales for which the getInstance methods of this 
 class can return localized instances. The returned array represents the union 
 of locales supported by the Java runtime and by installed CollatorProvider 
 implementations. It must contain at least a Locale instance equal to 
 Locale.US.
 Returns:
 An array of locales for which localized Collator instances are 
 available.
 This led me to thinking about how Derby should behave if created/booted with 
 collation=TERRITORY_BASED and territory=some unsupported locale. I'm not 
 sure what the consequences could be if the database is first created on a 
 platform that supports whatever locale is set and later booted with one that 
 doesn't, or created on a platform missing support and later booted with one 
 that has. In any case I think it may confuse a user needlessly to see the 
 database boot successfully with his collation setting and later behave in a 
 way he does not expect.
 Opinions voiced on the derby-dev list are that both database creation and 
 boot should fail if collation=TERRITORY_BASED and the selected locale is not 
 supported.
 If a change like this is implemented, the collationtests should be changed to 
 verify correct behavior also if they are executed in an environment were some 
 of the tested locales are not supported.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Reopened: (DERBY-3592) The Java 5 javadoc tool generates a spurious output line when digesting the doctitle element for the public api

2008-04-03 Thread Daniel John Debrunner (JIRA)

[
https://issues.apache.org/jira/browse/DERBY-3592?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Daniel John Debrunner reopened DERBY-3592:
--

I'm not sure this is a valid approach without some more investigation.

The nightly builds of the javadoc do not seem to have any problem for the jdbc
3 pages so could this not be a problem specific to the environment used to
create the beta?

Or is is a bug on some specific jdk release?

I added the logo and never saw any problems with generation of the pages.

The Java 5 javadoc tool generates a spurious output line when digesting the
doctitle element for the public api
---

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: [VOTE] V. Narayanan as a committer

2008-04-03 Thread Bryan Pendleton

Please vote on whether we should make V. Narayanan a Derby committer. 


+1

bryan

Re: [VOTE] Jørgen Løland as a committ er

2008-04-03 Thread Bryan Pendleton

Please vote on whether we should make Jørgen Løland a Derby committer. 


+1

bryan

Re: [VOTE] Jørgen Løland as a committ er

2008-04-03 Thread Dyre Tjeldvoll


Rick Hillegas wrote:
Please vote on whether we should make Jørgen Løland a Derby committer. 
The polls close at 5:00 pm San Francisco time on Thursday April 10.


+1

Dyre

[jira] Commented: (DERBY-3569) Incorrect encoding of derby_tests.policy file on Z/OS

2008-04-03 Thread Myrna van Lunteren (JIRA)


[ 
https://issues.apache.org/jira/browse/DERBY-3569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12585238#action_12585238
 ] 

Myrna van Lunteren commented on DERBY-3569:
---

The encoding of the derby_test.policy file appears to be no different from the 
encoding of other files...Nor do I think it has changed from earlier releases. 
There might be something wrong in how the file gets read.

It would be helpful if the following info could be added:
- exact derby build 
- example of stack trace when the error occurs
- any tests that pass?
- encoding used (I think zseries recognizes chcp, my old notes say chcp -q 
gives you current setting).
- also useful might be the value of java properties file.encoding, and 
sun.io.unicode.encoding, or any other encoding/codepage properties set by 
default in the environment


 Incorrect encoding of derby_tests.policy file on Z/OS
 -

 Key: DERBY-3569
 URL: https://issues.apache.org/jira/browse/DERBY-3569
 Project: Derby
  Issue Type: Bug
  Components: Test
Affects Versions: 10.4.1.0
Reporter: Manjula Kutty
Priority: Minor

 While running the tests on Z/OS most of the tests failed with invalid 
 authentication. I could run the tests by unjarring the derbyTesting.jar and 
 then FTPying the derby_tests.policy file in the ascii mode. and then 
 rejarring again.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: [VOTE] V. Narayanan as a committer

2008-04-03 Thread Dyre Tjeldvoll


Rick Hillegas wrote:
Please vote on whether we should make V. Narayanan a Derby committer. 
The polls close at 5:00 pm San Francisco time on Thursday April 10.


For several years, Narayanan has contributed valuable features and fixes 
to Derby, starting with JDBC4 and continuing through recent work on 
Derby replication. Narayanan eagerly seeks the community's advice and 
thoroughly responds to feedback. He also fields issues on the user 
list--there his responses are detailed and respectful. With commit 
privilege he will be even more effective.


Hear, hear, +10!

Dyre

Re: [VOTE] V. Narayanan as a committer

2008-04-03 Thread Oystein Grovlen


Rick Hillegas wrote:
Please vote on whether we should make V. Narayanan a Derby committer. 
The polls close at 5:00 pm San Francisco time on Thursday April 10.


For several years, Narayanan has contributed valuable features and fixes 
to Derby, starting with JDBC4 and continuing through recent work on 
Derby replication. Narayanan eagerly seeks the community's advice and 
thoroughly responds to feedback. He also fields issues on the user 
list--there his responses are detailed and respectful. With commit 
privilege he will be even more effective.


+1

--
Øystein

Re: [VOTE] V. Narayanan as a committer

2008-04-03 Thread Kristian Waagan


Rick Hillegas wrote:
Please vote on whether we should make V. Narayanan a Derby committer. 


+1


--
Kristian

Re: [VOTE] Jørgen Løland as a committ er

2008-04-03 Thread Kristian Waagan


Rick Hillegas wrote:
Please vote on whether we should make Jørgen Løland a Derby committer. 


+1


--
Kristian

Re: [VOTE] Jørgen Løland as a committ er

2008-04-03 Thread Oystein Grovlen


Rick Hillegas wrote:
Please vote on whether we should make Jørgen Løland a Derby committer. 
The polls close at 5:00 pm San Francisco time on Thursday April 10.


Jørgen has contributed significantly to adding replication functionality 
to Derby. Although he readily seeks and cheerfully incorporates 
community feedback, his work does not need supervision by other 
committers. In addition, Jørgen fields questions on the user lists and 
his interactions with the broader community are respectful, thoughtful, 
and thorough.


+1

--
Øystein

Re: [VOTE] V. Narayanan as a committer

2008-04-03 Thread Lance J. Andersen


+1

Dyre Tjeldvoll wrote:

Rick Hillegas wrote:
Please vote on whether we should make V. Narayanan a Derby committer. 
The polls close at 5:00 pm San Francisco time on Thursday April 10.


For several years, Narayanan has contributed valuable features and 
fixes to Derby, starting with JDBC4 and continuing through recent 
work on Derby replication. Narayanan eagerly seeks the community's 
advice and thoroughly responds to feedback. He also fields issues on 
the user list--there his responses are detailed and respectful. With 
commit privilege he will be even more effective.


Hear, hear, +10!

Dyre

[jira] Commented: (DERBY-3110) server hangs after trace on command fails


[ 
https://issues.apache.org/jira/browse/DERBY-3110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12585265#action_12585265
 ] 

Kathey Marsden commented on DERBY-3110:
---

I am thinking this may be a problem with synchronization with Derby rather than 
a problem with the JVM. The thread dump shows a ping thread waiting for 
response from the server and ClientThread waiting to accept connections.  If I 
try to ping the server once the hang occurs my client hangs, as though, the 
ClientThread is accepting connections, but not designating a thread to pick 
them up.


 server hangs after trace on command fails
 -

 Key: DERBY-3110
 URL: https://issues.apache.org/jira/browse/DERBY-3110
 Project: Derby
  Issue Type: Bug
  Components: Network Server
Affects Versions: 10.3.1.4
Reporter: Sebb
Assignee: Kathey Marsden
 Fix For: 10.3.2.1, 10.4.0.0

 Attachments: derby-3110_diff.txt, derby-3110_diff2.txt, 
 derby-3110_stat.txt, derby-3110_stat2.txt, derby-3110_test_diff.txt


 Tried turning on trace:
 networkservercontrol  trace on
 Invalid reply from network server: Insufficient data.
 The server process shows the following stack trace:
 access denied (java.io.FilePermission Server58.trace write)
 java.security.AccessControlException: access denied (java.io.FilePermission 
 Server58.trace write)
 at 
 java.security.AccessControlContext.checkPermission(AccessControlContext.java:269)
 at 
 java.security.AccessController.checkPermission(AccessController.java:401)
 at java.lang.SecurityManager.checkPermission(SecurityManager.java:524)
 at java.lang.SecurityManager.checkWrite(SecurityManager.java:954)
 at java.io.FileOutputStream.init(FileOutputStream.java:169)
 at java.io.FileOutputStream.init(FileOutputStream.java:70)
 at java.io.FileWriter.init(FileWriter.java:46)
 at org.apache.derby.impl.drda.DssTrace.startComBufferTrace(Unknown 
 Source)
 at org.apache.derby.impl.drda.Session.initTrace(Unknown Source)
 at org.apache.derby.impl.drda.Session.setTraceOn(Unknown Source)
 at 
 org.apache.derby.impl.drda.NetworkServerControlImpl.setTrace(Unknown Source)
 at 
 org.apache.derby.impl.drda.NetworkServerControlImpl.processCommands(Unknown 
 Source)
 at 
 org.apache.derby.impl.drda.DRDAConnThread.sessionInitialState(Unknown Source)
 at org.apache.derby.impl.drda.DRDAConnThread.run(Unknown Source)
 The server now does not respond to ping or shutdown, and has to be killed.
 See also DERBY-3103

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: [VOTE] V. Narayanan as a committer

2008-04-03 Thread Martin Zaun



+1

Rick Hillegas wrote:
Please vote on whether we should make V. Narayanan a Derby committer. 
The polls close at 5:00 pm San Francisco time on Thursday April 10.


For several years, Narayanan has contributed valuable features and fixes 
to Derby, starting with JDBC4 and continuing through recent work on 
Derby replication. Narayanan eagerly seeks the community's advice and 
thoroughly responds to feedback. He also fields issues on the user 
list--there his responses are detailed and respectful. With commit 
privilege he will be even more effective.


Regards,
-Rick

Re: [VOTE] Jørgen Løland as a committ er

2008-04-03 Thread Martin Zaun


+1

Rick Hillegas wrote:
Please vote on whether we should make Jørgen Løland a Derby committer. 
The polls close at 5:00 pm San Francisco time on Thursday April 10.


Jørgen has contributed significantly to adding replication functionality 
to Derby. Although he readily seeks and cheerfully incorporates 
community feedback, his work does not need supervision by other 
committers. In addition, Jørgen fields questions on the user lists and 
his interactions with the broader community are respectful, thoughtful, 
and thorough.


Regards,
-Rick

[jira] Assigned: (DERBY-3590) Hang in suites.All on Linux with IBM 1.6


 [ 
https://issues.apache.org/jira/browse/DERBY-3590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kathey Marsden reassigned DERBY-3590:
-

Assignee: Kathey Marsden

 Hang in suites.All  on Linux with IBM 1.6
 -

 Key: DERBY-3590
 URL: https://issues.apache.org/jira/browse/DERBY-3590
 Project: Derby
  Issue Type: Bug
  Components: Network Server
Affects Versions: 10.5.0.0
 Environment: SUSE LInux with java version:
 java version 1.6.0
 Java(TM) SE Runtime Environment (build pxi3260sr1-20080307_01)
 IBM J9 VM (build 2.4, J2RE 1.6.0 IBM J9 2.4 Linux x86-32 
 jvmxi3260-20080305_17755 (JIT enabled, AOT enabled)
 J9VM - 20080305_017755_lHdSMr
 JIT  - r9_20080304_1821
 GC   - 20080305_AB)
 JCL  - 20080301_01
Reporter: Kathey Marsden
Assignee: Kathey Marsden
 Attachments: javacore.zip


 With IBM 1.6 suites.All will hang after finishing testUpdatePurgedTuple1  
 with the following message in the derby.log
 Could not listen on port 1527 on host 127.0.0.1:
  java.net.BindException: Address already in use
 An exception was thrown during network server startup. 
 DRDA_ListenPort.S:Could not listen on port 1527 on host 127.0.0.1:
  java.net.BindException: Address already in use
 java.lang.reflect.InvocationTargetException
 at sun.reflect.GeneratedMethodAccessor14.invoke(Unknown Source)
 at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 at java.lang.reflect.Method.invoke(Method.java:599)
 at org.apache.derby.iapi.jdbc.DRDAServerStarter.run(Unknown Source)
 at java.lang.Thread.run(Thread.java:735)
 Caused by: java.lang.Exception: DRDA_ListenPort.S:Could not listen on port 
 1527 on host 127.0.0.1:
  java.net.BindException: Address already in use
 at 
 org.apache.derby.impl.drda.NetworkServerControlImpl.consolePropertyMessageWork(Unknown
  Source)
 at 
 org.apache.derby.impl.drda.NetworkServerControlImpl.consolePropertyMessage(Unknown
  Source)
 at 
 org.apache.derby.impl.drda.NetworkServerControlImpl.blockingStart(Unknown 
 Source)
 ... 5 more
 The server seems to be partially  up.   Any attempt to ping it will hang  I 
 will attach the javacore with the thread dump.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DERBY-3590) Hang in suites.All on Linux with IBM 1.6


[ 
https://issues.apache.org/jira/browse/DERBY-3590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12585267#action_12585267
 ] 

Kathey Marsden commented on DERBY-3590:
---

Sorry accidentally put this comment on DERBY-3110 the first time.
I am thinking this may be a problem with synchronization with Derby rather than 
a problem with the JVM. The thread dump shows a ping thread waiting for 
response from the server and ClientThread waiting to accept connections.  If I 
try to ping the server once the hang occurs my client hangs, as though, the 
ClientThread is accepting connections, but not designating a thread to pick 
them up.



 Hang in suites.All  on Linux with IBM 1.6
 -

 Key: DERBY-3590
 URL: https://issues.apache.org/jira/browse/DERBY-3590
 Project: Derby
  Issue Type: Bug
  Components: Network Server
Affects Versions: 10.5.0.0
 Environment: SUSE LInux with java version:
 java version 1.6.0
 Java(TM) SE Runtime Environment (build pxi3260sr1-20080307_01)
 IBM J9 VM (build 2.4, J2RE 1.6.0 IBM J9 2.4 Linux x86-32 
 jvmxi3260-20080305_17755 (JIT enabled, AOT enabled)
 J9VM - 20080305_017755_lHdSMr
 JIT  - r9_20080304_1821
 GC   - 20080305_AB)
 JCL  - 20080301_01
Reporter: Kathey Marsden
 Attachments: javacore.zip


 With IBM 1.6 suites.All will hang after finishing testUpdatePurgedTuple1  
 with the following message in the derby.log
 Could not listen on port 1527 on host 127.0.0.1:
  java.net.BindException: Address already in use
 An exception was thrown during network server startup. 
 DRDA_ListenPort.S:Could not listen on port 1527 on host 127.0.0.1:
  java.net.BindException: Address already in use
 java.lang.reflect.InvocationTargetException
 at sun.reflect.GeneratedMethodAccessor14.invoke(Unknown Source)
 at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 at java.lang.reflect.Method.invoke(Method.java:599)
 at org.apache.derby.iapi.jdbc.DRDAServerStarter.run(Unknown Source)
 at java.lang.Thread.run(Thread.java:735)
 Caused by: java.lang.Exception: DRDA_ListenPort.S:Could not listen on port 
 1527 on host 127.0.0.1:
  java.net.BindException: Address already in use
 at 
 org.apache.derby.impl.drda.NetworkServerControlImpl.consolePropertyMessageWork(Unknown
  Source)
 at 
 org.apache.derby.impl.drda.NetworkServerControlImpl.consolePropertyMessage(Unknown
  Source)
 at 
 org.apache.derby.impl.drda.NetworkServerControlImpl.blockingStart(Unknown 
 Source)
 ... 5 more
 The server seems to be partially  up.   Any attempt to ping it will hang  I 
 will attach the javacore with the thread dump.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (DERBY-3110) server hangs after trace on command fails


 [ 
https://issues.apache.org/jira/browse/DERBY-3110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kathey Marsden updated DERBY-3110:
--

Comment: was deleted

 server hangs after trace on command fails
 -

 Key: DERBY-3110
 URL: https://issues.apache.org/jira/browse/DERBY-3110
 Project: Derby
  Issue Type: Bug
  Components: Network Server
Affects Versions: 10.3.1.4
Reporter: Sebb
Assignee: Kathey Marsden
 Fix For: 10.3.2.1, 10.4.0.0

 Attachments: derby-3110_diff.txt, derby-3110_diff2.txt, 
 derby-3110_stat.txt, derby-3110_stat2.txt, derby-3110_test_diff.txt


 Tried turning on trace:
 networkservercontrol  trace on
 Invalid reply from network server: Insufficient data.
 The server process shows the following stack trace:
 access denied (java.io.FilePermission Server58.trace write)
 java.security.AccessControlException: access denied (java.io.FilePermission 
 Server58.trace write)
 at 
 java.security.AccessControlContext.checkPermission(AccessControlContext.java:269)
 at 
 java.security.AccessController.checkPermission(AccessController.java:401)
 at java.lang.SecurityManager.checkPermission(SecurityManager.java:524)
 at java.lang.SecurityManager.checkWrite(SecurityManager.java:954)
 at java.io.FileOutputStream.init(FileOutputStream.java:169)
 at java.io.FileOutputStream.init(FileOutputStream.java:70)
 at java.io.FileWriter.init(FileWriter.java:46)
 at org.apache.derby.impl.drda.DssTrace.startComBufferTrace(Unknown 
 Source)
 at org.apache.derby.impl.drda.Session.initTrace(Unknown Source)
 at org.apache.derby.impl.drda.Session.setTraceOn(Unknown Source)
 at 
 org.apache.derby.impl.drda.NetworkServerControlImpl.setTrace(Unknown Source)
 at 
 org.apache.derby.impl.drda.NetworkServerControlImpl.processCommands(Unknown 
 Source)
 at 
 org.apache.derby.impl.drda.DRDAConnThread.sessionInitialState(Unknown Source)
 at org.apache.derby.impl.drda.DRDAConnThread.run(Unknown Source)
 The server now does not respond to ping or shutdown, and has to be killed.
 See also DERBY-3103

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: [VOTE] Jørgen Løland as a committer

2008-04-03 Thread Knut Anders Hatlen

Rick Hillegas [EMAIL PROTECTED] writes:

 Please vote on whether we should make Jørgen Løland a Derby
 committer. The polls close at 5:00 pm San Francisco time on Thursday
 April 10.

+1

-- 
Knut Anders

Re: [VOTE] V. Narayanan as a committer

2008-04-03 Thread Knut Anders Hatlen

Rick Hillegas [EMAIL PROTECTED] writes:

 Please vote on whether we should make V. Narayanan a Derby
 committer. The polls close at 5:00 pm San Francisco time on Thursday
 April 10.

+1

-- 
Knut Anders

[jira] Updated: (DERBY-3589) AllocPage.createPage() doesn't initialize minimumRecordSize correctly


 [ 
https://issues.apache.org/jira/browse/DERBY-3589?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Knut Anders Hatlen updated DERBY-3589:
--

Derby Info: [Patch Available]

Derbyall and suites.All ran cleanly.

 AllocPage.createPage() doesn't initialize minimumRecordSize correctly
 -

 Key: DERBY-3589
 URL: https://issues.apache.org/jira/browse/DERBY-3589
 Project: Derby
  Issue Type: Bug
  Components: Store
Affects Versions: 10.3.1.4, 10.4.1.0
Reporter: Knut Anders Hatlen
Assignee: Knut Anders Hatlen
Priority: Minor
 Attachments: d3589-1a.diff, d3589-1a.stat


 AllocPage.createPage() will initialize minimumRecordSize to the same
 value as borrowedSpace. See this code taken from AllocPage.java:
 ---
   protected void createPage(PageKey newIdentity, int[] args) 
throws StandardException
   {
   super.createPage(newIdentity, args);
   // args[0] is the format id
   // args[1] is whether to sync the page to disk or not
   // args[2] is the pagesize (used by StoredPage)
   // args[3] is the spareSize (used by StoredPage)
   // args[4] is the number of bytes to reserve for container 
 header
   // args[5] is the minimumRecordSize
   // NOTE: the arg list here must match the one in FileContainer
   int pageSize = args[2];
   int minimumRecordSize = args[5];
   borrowedSpace = args[4];
 ---
 Here it correctly takes args[5] and puts into the local variable
 minimumRecordSize. However, that variable hides a field with the same
 name, and that field is set to args[4] in the call to
 super.createPage() at the first line in the method. The local variable
 is never used.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (DERBY-3354) Select from large lob table with embedded gives OutOfMemoryError

2008-04-03 Thread Anurag Shekhar (JIRA)

[
https://issues.apache.org/jira/browse/DERBY-3354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Anurag Shekhar updated DERBY-3354:
--

Attachment: derby-3354_v1.diff

Description of derby-3354_v1.diff
This patch introduces a new WeakHashMap in EmbedConnection. EmbedBlob and
EmbedClob objects references are stored in this
map (objects as key and null as value). Adding entry to locater map is
differed till the first call of getLocater.
This ensures that there is entry of LOB objects in locater map if they are
invoked in embedded mode.
As the keys of WeakHashMap doesn't prevents the objects from being
garbage collected, once the lob objects are unreferenced lob objects will
be garbage collected releasing the memory.

During commit/rollback or Connection.close, free is invoked on all the lob
objects from WeakHashMap and the map is cleared.

Modified files
java/engine/org/apache/derby/impl/jdbc/EmbedConnection.java
Added a new attribute lobRefrences of type WeakHashMap.
Added a new method addLOBReference to make an entry in new
hash map.
Modified clearLOBMapping to use lobRefrences to fetch and invoke free on lob
objects instead of lobHashMap.

java/engine/org/apache/derby/impl/jdbc/EmbedBlob.java
java/engine/org/apache/derby/impl/jdbc/EmbedClob.java

Modified constructs to call connection.lobRefrences instead of
conn.addLOBMapping.
Modified getLocater method to check if the locater value is non zero
before returning and if its zero calling conn.addLOBMapping to make
entry of lob objects and getting locater value.
Calling removeLOBMapping in free method.

Cleanup of temporary file is already being taken care by the finalizer of
LOBStreamControl so I haven't added any new cleanup code for
finalizer.

lang and jdbcapi junit tests running clean with this patch applied. I am
running rest of the test suite and will update the results of the same.

Select from large lob table with embedded gives OutOfMemoryError

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DERBY-3354) Select from large lob table with embedded gives OutOfMemoryError

[
https://issues.apache.org/jira/browse/DERBY-3354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12585299#action_12585299
]

Kristian Waagan commented on DERBY-3354:

I haven't validated the approach, but it seems reasonable. I applied the patch
and compiled Derby.

Some *very minor* things you can consider changing:
1) Typos: refrences - references (5 occurrences)
2) Use of a space between the method call / declaration and the following
parenthesis is not consistent.
3) Trailing whitespace at diff lines 28, 107 and 148.
4) You could change the comment for the weak hash map to JavaDoc.

Nice and small change :)
Is this the final patch, or are the more coming up?

Select from large lob table with embedded gives OutOfMemoryError

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: [VOTE] V. Narayanan as a committer

2008-04-03 Thread Henri van de Scheur


Rick Hillegas wrote:
Please vote on whether we should make V. Narayanan a Derby committer. 
The polls close at 5:00 pm San Francisco time on Thursday April 10.

+1

Henri

Re: [VOTE] Jørgen Løland as a committ er

2008-04-03 Thread Henri van de Scheur


+1

Rick Hillegas wrote:
Please vote on whether we should make Jørgen Løland a Derby committer. 
The polls close at 5:00 pm San Francisco time on Thursday April 10.

[jira] Assigned: (DERBY-3592) The Java 5 javadoc tool generates a spurious output line when digesting the doctitle element for the public api

[
https://issues.apache.org/jira/browse/DERBY-3592?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Rick Hillegas reassigned DERBY-3592:

Assignee: (was: Rick Hillegas)

I am unassigning myself from this issue. I think the current behavior is better
than the behavior in the beta. But if someone else would like to improve on
this, they are welcome to.

The Java 5 javadoc tool generates a spurious output line when digesting the
doctitle element for the public api
---

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: [VOTE] Jørgen Løland as a committ er


Rick Hillegas wrote:
Please vote on whether we should make Jørgen Løland a Derby committer. 
The polls close at 5:00 pm San Francisco time on Thursday April 10.


Jørgen has contributed significantly to adding replication 
functionality to Derby. Although he readily seeks and cheerfully 
incorporates community feedback, his work does not need supervision by 
other committers. In addition, Jørgen fields questions on the user 
lists and his interactions with the broader community are respectful, 
thoughtful, and thorough.


Regards,
-Rick

+1

Re: [VOTE] V. Narayanan as a committer


Rick Hillegas wrote:
Please vote on whether we should make V. Narayanan a Derby committer. 
The polls close at 5:00 pm San Francisco time on Thursday April 10.


For several years, Narayanan has contributed valuable features and 
fixes to Derby, starting with JDBC4 and continuing through recent work 
on Derby replication. Narayanan eagerly seeks the community's advice 
and thoroughly responds to feedback. He also fields issues on the user 
list--there his responses are detailed and respectful. With commit 
privilege he will be even more effective.


Regards,
-Rick

+1

[jira] Created: (DERBY-3593) ErrorCode 30000 when quering a select with 'having' clause and named tables with aliases for selected fields

2008-04-03 Thread Bruno Medeiros (JIRA)

ErrorCode 3 when quering a select with 'having' clause and named tables 
with aliases for selected fields


 Key: DERBY-3593
 URL: https://issues.apache.org/jira/browse/DERBY-3593
 Project: Derby
  Issue Type: Bug
Affects Versions: 10.2.2.1, 10.3.2.2
 Environment: WinVista 32bits, Running a java 1.4 application 
Aplication 
Reporter: Bruno Medeiros
Priority: Critical


When I run a query like this:
-
select 
v.indicador_id as col_1, 
'someString' as col_2, 
sum(v.valor) as col_3
from 
VALUES v
where v.valor is null 
and v.indicador_id = 13
group by v.indicador_id
having sum(v.valor)  3
--
I got a error:
Error: Column 'V.COL_1' is either not in any table in the FROM list or appears 
within a join specification and is outside the scope of the join specification 
or appears in a HAVING clause and is not in the GROUP BY list. If this is a 
CREATE or ALTER TABLE  statement then 'V.COL_1' is not a column in the target 
table.
SQLState:  42X04
ErrorCode: 3


if i gave no name to the table 'VALUES' or remove the aliases 'col_1' and 
'col_3' of the corresponding selected fields, the query runs ok. The alias for 
the constant column, 'col_2', don't affect the query.
The query also runs ok if i remove the 'having' clause.
Queries that work:

select 
v.indicador_id , 
'jujuba' as col_2, 
sum(v.valor) 
from 
VALUES v
where v.valor is null 
and v.indicador_id = 13
group by v.indicador_id
having sum(v.valor)  3

select 
indicador_id as col_1, 
'jujuba' as col_2, 
sum(valor) as col_3
from 
VALUES
where valor is null 
and indicador_id = 13
group by indicador_id
having sum(valor)  3

select 
v.indicador_id as col_1, 
'jujuba' as col_2, 
sum(v.valor) as col_3
from 
VALUES v
where v.valor is null 
and v.indicador_id = 13
group by v.indicador_id


I think there's a problem when derby is trying to match the selected fields 
with the grouped ones, because 'V.COL_1', as it appears in the error message, 
doesn't exist in any place of my query. The correct would be 'V.indicador' or 
'COL_1'.

Thanks in advance,

Bruno Medeiros

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: [VOTE] Jørgen Løland as a committer

2008-04-03 Thread Dag H. Wanvik

Rick Hillegas [EMAIL PROTECTED] writes:

 Please vote on whether we should make Jørgen Løland a Derby
 committer. The polls close at 5:00 pm San Francisco time on Thursday
 April 10.

+1

Dag


 Jørgen has contributed significantly to adding replication
 functionality to Derby. Although he readily seeks and cheerfully
 incorporates community feedback, his work does not need supervision by
 other committers. In addition, Jørgen fields questions on the user
 lists and his interactions with the broader community are respectful,
 thoughtful, and thorough.

 Regards,
 -Rick

Re: [VOTE] V. Narayanan as a committer

2008-04-03 Thread Dag H. Wanvik

Rick Hillegas [EMAIL PROTECTED] writes:

 Please vote on whether we should make V. Narayanan a Derby
 committer. The polls close at 5:00 pm San Francisco time on Thursday
 April 10.

+1

Dag


 For several years, Narayanan has contributed valuable features and
 fixes to Derby, starting with JDBC4 and continuing through recent work
 on Derby replication. Narayanan eagerly seeks the community's advice
 and thoroughly responds to feedback. He also fields issues on the user
 list--there his responses are detailed and respectful. With commit
 privilege he will be even more effective.

 Regards,
 -Rick

[jira] Commented: (DERBY-3585) Document user authentication support for network server shutdown


[ 
https://issues.apache.org/jira/browse/DERBY-3585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12585341#action_12585341
 ] 

Rick Hillegas commented on DERBY-3585:
--

Thanks, Martin. I made some minor wording changes and committed the Admin Guide 
patch at subversion revision 644555.

 Document user authentication support for network server shutdown
 

 Key: DERBY-3585
 URL: https://issues.apache.org/jira/browse/DERBY-3585
 Project: Derby
  Issue Type: Sub-task
  Components: Documentation
Reporter: Martin Zaun
Assignee: Martin Zaun
 Fix For: 10.4.0.0

 Attachments: DERBY-3585-0.diff, DERBY-3585-0.stat, DERBY-3585-0.zip, 
 releaseNote.html, releaseNote.html, releaseNote.html, releaseNote.html


 As part of the System Privileges work in DERBY-2109, the support of user 
 authentication for network server shutdown was discussed, implemented, and 
 committed (revision 632502).
 In order to address a security issue (missing user authentication for 
 shutdown), this feature introduces a few incompatibilities with the usage of 
 NetworkServerControl, which need to be documented.
 This JIRA is to provide for the user documentation and the release notes 
 describing the usage changes and incompatibilities.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DERBY-3585) Document user authentication support for network server shutdown