Re: [jira] Commented: (DERBY-3523) sql states (X0Y63, X0Y63, X0Y63.S) related to nulls in unique constraints are associated with wrong message texts
Mike Matrigali wrote: > It does seem like the best case would be for the error message system to > somehow return a different error message for the same number if it is > in soft upgrade vs. hard upgrade. Does the error message system support > such a thing? Yes, it does. If you want multiple messages with the same SQL state, you need to add the "..<#>" information to the error state in SQLState.java. E.g, all these messages have SQL State 08004: - snip from SQLState.java String LOGIN_FAILED = "08004"; String NET_CONNECT_AUTH_FAILED = "08004.C.1"; String NET_DATABASE_NOT_FOUND = "08004.C.2"; String AUTH_DATABASE_CONNECTION_REFUSED = "08004.C.3"; String AUTH_SHUTDOWN_NOT_DB_OWNER = "08004.C.4"; String AUTH_ENCRYPT_NOT_DB_OWNER= "08004.C.5"; ... - snip --- If, e.g., both these messages '{0}' cannot be a column of a primary key or unique key because it can contain null values. '{0}' cannot be a column of a primary key because it can contain null values. ... should have the same 42831 error code, you would need something like this in the SQLState.java file: String LANG_DB2_ADD_UNIQUE_OR_PRIMARY_KEY_ON_NULL_COLS = "42831.S.1"; String LANG_DB2_ADD_PRIMARY_KEY_ON_NULL_COLS = "42831.S.2"; 'S' because 42831 is statement severity level (see class javadoc in SQLState.java), while 1 and 2 are used to tell the messages apart. messages.xml also needs to be updated, of course.
[jira] Commented: (DERBY-3322) Server guide refers to phantom property in template policy file for the Network Server
[ https://issues.apache.org/jira/browse/DERBY-3322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12577734#action_12577734 ] Andrew McIntyre commented on DERBY-3322: hi John, I'll take a look tomorrow and see if I can figure out why my automated copy is not updating the files. The copy process itself is not reporting any errors, but maybe there are permissions problems on people.apache.org that are preventing the files from being updated. > Server guide refers to phantom property in template policy file for the > Network Server > -- > > Key: DERBY-3322 > URL: https://issues.apache.org/jira/browse/DERBY-3322 > Project: Derby > Issue Type: Bug > Components: Documentation >Affects Versions: 10.3.1.4, 10.3.2.1 > Environment: N/A >Reporter: John H. Embretsen >Assignee: John H. Embretsen >Priority: Trivial > Fix For: 10.4.0.0 > > Attachments: d3322v01.diff, tadminnetservcustom.html > > > The Server and Administration guide contains a section about customizing the > Network Server's security policy, based on the template policy: > http://db.apache.org/derby/docs/dev/adminguide/tadminnetservcustom.html > This section mentions that the variable ${derby.security.host} should be > replaced with a suitable value. > > However, the template policy, at /demo/templates/server.policy (released > binaries) or java/drda/org/apache/derby/drda/template.policy (SVN codeline), > does not refer to any variable or property called ${derby.security.host}. > Instead, the policy file specifies the wildcard address, with appropriate > comments: > > // Accept connections from any host. Derby is listening to the host > // interface specified via the -h option to "NetworkServerControl > // start" on the command line, via the address parameter to the > // org.apache.derby.drda.NetworkServerControl constructor in the API > // or via the property derby.drda.host; the default is localhost. > // You may want to restrict allowed hosts, e.g. to hosts in a specific > // subdomain, e.g. "*.acme.com". > permission java.net.SocketPermission "*", "accept"; > > See also > http://www.nabble.com/Customizing-the-Network-Server%27s-security-policy-%28docs-vs.-reality%29-td14841290.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [jira] Commented: (DERBY-3523) sql states (X0Y63, X0Y63, X0Y63.S) related to nulls in unique constraints are associated with wrong message texts
Jørgen Løland wrote: Mike Matrigali wrote: > It does seem like the best case would be for the error message system to > somehow return a different error message for the same number if it is > in soft upgrade vs. hard upgrade. Does the error message system support > such a thing? Yes, it does. If you want multiple messages with the same SQL state, you need to add the "..<#>" information to the error state in SQLState.java. E.g, all these messages have SQL State 08004: - snip from SQLState.java String LOGIN_FAILED = "08004"; String NET_CONNECT_AUTH_FAILED = "08004.C.1"; String NET_DATABASE_NOT_FOUND = "08004.C.2"; String AUTH_DATABASE_CONNECTION_REFUSED = "08004.C.3"; String AUTH_SHUTDOWN_NOT_DB_OWNER = "08004.C.4"; String AUTH_ENCRYPT_NOT_DB_OWNER= "08004.C.5"; ... - snip --- If, e.g., both these messages '{0}' cannot be a column of a primary key or unique key because it can contain null values. '{0}' cannot be a column of a primary key because it can contain null values. ... should have the same 42831 error code, you would need something like this in the SQLState.java file: String LANG_DB2_ADD_UNIQUE_OR_PRIMARY_KEY_ON_NULL_COLS = "42831.S.1"; String LANG_DB2_ADD_PRIMARY_KEY_ON_NULL_COLS = "42831.S.2"; 'S' because 42831 is statement severity level (see class javadoc in SQLState.java), while 1 and 2 are used to tell the messages apart. messages.xml also needs to be updated, of course. But how will this help in printing different error messages in hard and soft upgrade? I thought this would be useful in grouping together the same family of messages, but can this act as a switch for messages that need to be printed in hard and soft upgrade? Narayanan
[jira] Commented: (DERBY-3523) sql states (X0Y63, X0Y63, X0Y63.S) related to nulls in unique constraints are associated with wrong message texts
[ https://issues.apache.org/jira/browse/DERBY-3523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12577750#action_12577750 ] Jørgen Løland commented on DERBY-3523: -- (Attaching mail thread) Narayanan wrote: > Jørgen Løland wrote: >> Mike Matrigali wrote: >> > It does seem like the best case would be for the error message >> system to >> > somehow return a different error message for the same number if it is >> > in soft upgrade vs. hard upgrade. Does the error message system >> support >> > such a thing? >> >> Yes, it does. If you want multiple messages with the same SQL state, >> you need to add the "..<#>" information to the error state >> in SQLState.java. E.g, all these messages have SQL State 08004: >> >> - snip from SQLState.java >> String LOGIN_FAILED = "08004"; >> String NET_CONNECT_AUTH_FAILED = "08004.C.1"; >> String NET_DATABASE_NOT_FOUND = "08004.C.2"; >> String AUTH_DATABASE_CONNECTION_REFUSED = "08004.C.3"; >> String AUTH_SHUTDOWN_NOT_DB_OWNER = "08004.C.4"; >> String AUTH_ENCRYPT_NOT_DB_OWNER= "08004.C.5"; >> ... >> - snip --- >> >> If, e.g., both these messages >> >> '{0}' cannot be a column of a primary key or unique key because it can >> contain null values. >> '{0}' cannot be a column of a primary key because it can contain null >> values. >> >> ... should have the same 42831 error code, you would need something >> like this in the SQLState.java file: >> >> String LANG_DB2_ADD_UNIQUE_OR_PRIMARY_KEY_ON_NULL_COLS = "42831.S.1"; >> String LANG_DB2_ADD_PRIMARY_KEY_ON_NULL_COLS = "42831.S.2"; >> >> 'S' because 42831 is statement severity level (see class javadoc in >> SQLState.java), while 1 and 2 are used to tell the messages apart. >> messages.xml also needs to be updated, of course. >> > But how will this help in printing different error messages in hard and > soft upgrade? I thought this would be useful > in grouping together the same family of messages, but can this act as a > switch for messages that need to be printed > in hard and soft upgrade? > > Narayanan > The code where these exceptions are thrown needs to explicitly use the correct exception. However, this is the same thing that must be done if fix suggestion 2 is chosen. I think suggestion 2 should be modified like this: 2b: Introduce new message without changing the state and use old messages only during soft upgrade run. > sql states (X0Y63, X0Y63, X0Y63.S) related to nulls in unique constraints are > associated with wrong message texts > -- > > Key: DERBY-3523 > URL: https://issues.apache.org/jira/browse/DERBY-3523 > Project: Derby > Issue Type: Bug >Affects Versions: 10.4.0.0, 10.5.0.0 >Reporter: Anurag Shekhar >Assignee: Anurag Shekhar > > There are three messages which after Derby-3330 checkin now giving wrong > information. These are > 42831:'{0}' cannot be a column of a primary key or unique key because it can > contain null values. > 42Z20:Column '{0}' cannot be made nullable. It is part of a primary key or > unique constraint, which cannot have any null able columns. > X0Y63.S:The command on table '{0}' failed because null data was found in the > primary key or unique constraint/index column(s). All columns in a primary or > unique index key must not be null. -- 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-3523) sql states (X0Y63, X0Y63, X0Y63.S) related to nulls in unique constraints are associated with wrong message texts
[ https://issues.apache.org/jira/browse/DERBY-3523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12577750#action_12577750 ] jorgenlo edited comment on DERBY-3523 at 3/12/08 1:17 AM: --- (Attaching mail thread) Narayanan wrote: > Jørgen Løland wrote: >> Mike Matrigali wrote: >> > It does seem like the best case would be for the error message >> system to >> > somehow return a different error message for the same number if it is >> > in soft upgrade vs. hard upgrade. Does the error message system >> support >> > such a thing? >> >> Yes, it does. If you want multiple messages with the same SQL state, >> you need to add the "..<#>" information to the error state >> in SQLState.java. E.g, all these messages have SQL State 08004: >> >> - snip from SQLState.java >> String LOGIN_FAILED = "08004"; >> String NET_CONNECT_AUTH_FAILED = "08004.C.1"; >> String NET_DATABASE_NOT_FOUND = "08004.C.2"; >> String AUTH_DATABASE_CONNECTION_REFUSED = "08004.C.3"; >> String AUTH_SHUTDOWN_NOT_DB_OWNER = "08004.C.4"; >> String AUTH_ENCRYPT_NOT_DB_OWNER= "08004.C.5"; >> ... >> - snip --- >> >> If, e.g., both these messages >> >> '{0}' cannot be a column of a primary key or unique key because it can >> contain null values. >> '{0}' cannot be a column of a primary key because it can contain null >> values. >> >> ... should have the same 42831 error code, you would need something >> like this in the SQLState.java file: >> >> String LANG_DB2_ADD_UNIQUE_OR_PRIMARY_KEY_ON_NULL_COLS = "42831.S.1"; >> String LANG_DB2_ADD_PRIMARY_KEY_ON_NULL_COLS = "42831.S.2"; >> >> 'S' because 42831 is statement severity level (see class javadoc in >> SQLState.java), while 1 and 2 are used to tell the messages apart. >> messages.xml also needs to be updated, of course. >> > But how will this help in printing different error messages in hard and > soft upgrade? I thought this would be useful > in grouping together the same family of messages, but can this act as a > switch for messages that need to be printed > in hard and soft upgrade? > > Narayanan > I misinterpreted Mike's question. The code where these exceptions are thrown needs to explicitly use the correct exception. However, this is the same thing that must be done if fix suggestion 2 is chosen. I think suggestion 2 should be modified like this: 2b: Introduce new message without changing the state and use old messages only during soft upgrade run. was (Author: jorgenlo): (Attaching mail thread) Narayanan wrote: > Jørgen Løland wrote: >> Mike Matrigali wrote: >> > It does seem like the best case would be for the error message >> system to >> > somehow return a different error message for the same number if it is >> > in soft upgrade vs. hard upgrade. Does the error message system >> support >> > such a thing? >> >> Yes, it does. If you want multiple messages with the same SQL state, >> you need to add the "..<#>" information to the error state >> in SQLState.java. E.g, all these messages have SQL State 08004: >> >> - snip from SQLState.java >> String LOGIN_FAILED = "08004"; >> String NET_CONNECT_AUTH_FAILED = "08004.C.1"; >> String NET_DATABASE_NOT_FOUND = "08004.C.2"; >> String AUTH_DATABASE_CONNECTION_REFUSED = "08004.C.3"; >> String AUTH_SHUTDOWN_NOT_DB_OWNER = "08004.C.4"; >> String AUTH_ENCRYPT_NOT_DB_OWNER= "08004.C.5"; >> ... >> - snip --- >> >> If, e.g., both these messages >> >> '{0}' cannot be a column of a primary key or unique key because it can >> contain null values. >> '{0}' cannot be a column of a primary key because it can contain null >> values. >> >> ... should have the same 42831 error code, you would need something >> like this in the SQLState.java file: >> >> String LANG_DB2_ADD_UNIQUE_OR_PRIMARY_KEY_ON_NULL_COLS = "42831.S.1"; >> String LANG_DB2_ADD_PRIMARY_KEY_ON_NULL_COLS = "42831.S.2"; >> >> 'S' because 42831 is statement severity level (see class javadoc in >> SQLState.java), while 1 and 2 are used to tell the messages apart. >> messages.xml also needs to be updated, of course. >> > But how will this help in printing different error messages in hard and > soft upgrade? I thought this would be useful > in grouping together the same family of messages, but can this act as a > switch for messages that need to be printed > in hard and soft upgrade? > > Narayanan > The code where these exceptions are thrown needs to explicitly use the correct exception. However, this is the same thing that must be done if fix suggestion 2 is chosen. I think suggestion 2 should be modified like this: 2b: Introduce new message without changing the state and use old messages only
[jira] Updated: (DERBY-2911) Implement a buffer manager using java.util.concurrent classes
[ https://issues.apache.org/jira/browse/DERBY-2911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Knut Anders Hatlen updated DERBY-2911: -- Derby Info: (was: [Patch Available]) Committed revision 636247. > Implement a buffer manager using java.util.concurrent classes > - > > Key: DERBY-2911 > URL: https://issues.apache.org/jira/browse/DERBY-2911 > Project: Derby > Issue Type: Improvement > Components: Performance, Services >Affects Versions: 10.4.0.0 >Reporter: Knut Anders Hatlen >Assignee: Knut Anders Hatlen >Priority: Minor > Attachments: cleaner.diff, cleaner.tar, d2911-1.diff, d2911-1.stat, > d2911-10.diff, d2911-10.stat, d2911-11.diff, d2911-12.diff, d2911-2.diff, > d2911-3.diff, d2911-4.diff, d2911-5.diff, d2911-6.diff, d2911-6.stat, > d2911-7.diff, d2911-7a.diff, d2911-9.diff, d2911-9.stat, d2911-enable.diff, > d2911-entry-javadoc.diff, d2911-unused.diff, d2911-unused.stat, > d2911perf.java, derby-2911-8.diff, derby-2911-8.stat, perftest.diff, > perftest.pdf, perftest.stat, perftest2.diff, perftest6.pdf, poisson_patch8.tar > > > There are indications that the buffer manager is a bottleneck for some types > of multi-user load. For instance, Anders Morken wrote this in a comment on > DERBY-1704: "With a separate table and index for each thread (to remove latch > contention and lock waits from the equation) we (...) found that > org.apache.derby.impl.services.cache.Clock.find()/release() caused about 5 > times more contention than the synchronization in LockSet.lockObject() and > LockSet.unlock(). That might be an indicator of where to apply the next push". > It would be interesting to see the scalability and performance of a buffer > manager which exploits the concurrency utilities added in Java SE 5. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [jira] Commented: (DERBY-3523) sql states (X0Y63, X0Y63, X0Y63.S) related to nulls in unique constraints are associated with wrong message texts
thanks every one for pitching. Let me try to summarize it Derby doesn;t directly supports choosing message based on the type of run (soft upgrade more or a regular mode), but it does allow associating multiple messages to a single sql state bye adding "." extension (sqlstate.1, sqltate.2 etc). From the code this can be used to throw correct error message after detecting the mode engine is running under (use existing sql states during soft upgrade and newer once during regular operation). The extensions of the sql state is dropped while setting the sql state to SQLException so user won't experience any difference during soft upgrade and will get newer message with same sql state during regular operation. anurag Jørgen Løland (JIRA) wrote: [ https://issues.apache.org/jira/browse/DERBY-3523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12577750#action_12577750 ] Jørgen Løland commented on DERBY-3523: -- (Attaching mail thread) Narayanan wrote: Jørgen Løland wrote: Mike Matrigali wrote: It does seem like the best case would be for the error message system to somehow return a different error message for the same number if it is in soft upgrade vs. hard upgrade. Does the error message system support such a thing? Yes, it does. If you want multiple messages with the same SQL state, you need to add the "..<#>" information to the error state in SQLState.java. E.g, all these messages have SQL State 08004: - snip from SQLState.java String LOGIN_FAILED = "08004"; String NET_CONNECT_AUTH_FAILED = "08004.C.1"; String NET_DATABASE_NOT_FOUND = "08004.C.2"; String AUTH_DATABASE_CONNECTION_REFUSED = "08004.C.3"; String AUTH_SHUTDOWN_NOT_DB_OWNER = "08004.C.4"; String AUTH_ENCRYPT_NOT_DB_OWNER= "08004.C.5"; ... - snip --- If, e.g., both these messages '{0}' cannot be a column of a primary key or unique key because it can contain null values. '{0}' cannot be a column of a primary key because it can contain null values. ... should have the same 42831 error code, you would need something like this in the SQLState.java file: String LANG_DB2_ADD_UNIQUE_OR_PRIMARY_KEY_ON_NULL_COLS = "42831.S.1"; String LANG_DB2_ADD_PRIMARY_KEY_ON_NULL_COLS = "42831.S.2"; 'S' because 42831 is statement severity level (see class javadoc in SQLState.java), while 1 and 2 are used to tell the messages apart. messages.xml also needs to be updated, of course. But how will this help in printing different error messages in hard and soft upgrade? I thought this would be useful in grouping together the same family of messages, but can this act as a switch for messages that need to be printed in hard and soft upgrade? Narayanan The code where these exceptions are thrown needs to explicitly use the correct exception. However, this is the same thing that must be done if fix suggestion 2 is chosen. I think suggestion 2 should be modified like this: 2b: Introduce new message without changing the state and use old messages only during soft upgrade run. sql states (X0Y63, X0Y63, X0Y63.S) related to nulls in unique constraints are associated with wrong message texts -- Key: DERBY-3523 URL: https://issues.apache.org/jira/browse/DERBY-3523 Project: Derby Issue Type: Bug Affects Versions: 10.4.0.0, 10.5.0.0 Reporter: Anurag Shekhar Assignee: Anurag Shekhar There are three messages which after Derby-3330 checkin now giving wrong information. These are 42831:'{0}' cannot be a column of a primary key or unique key because it can contain null values. 42Z20:Column '{0}' cannot be made nullable. It is part of a primary key or unique constraint, which cannot have any null able columns. X0Y63.S:The command on table '{0}' failed because null data was found in the primary key or unique constraint/index column(s). All columns in a primary or unique index key must not be null.
[jira] Updated: (DERBY-3508) Log receiver thread fails with NPE at failover when master has died
[ https://issues.apache.org/jira/browse/DERBY-3508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jørgen Løland updated DERBY-3508: - Attachment: derby-3508-1a.diff derby-3508-1a.stat The NPE was caused by the log receiver thread trying to get the port from a closed down ReplicationMessageReceive. Patch v1 fixes the problem. I don't know how to write a regression test for this bug since the exception is not thrown to the caller of failover and the command succeeds. All tests (except failures reported in tinderbox) passed, including the replication suite. Requesting review. > Log receiver thread fails with NPE at failover when master has died > --- > > Key: DERBY-3508 > URL: https://issues.apache.org/jira/browse/DERBY-3508 > Project: Derby > Issue Type: Bug > Components: Replication >Affects Versions: 10.4.0.0 >Reporter: Øystein Grøvlen >Assignee: Jørgen Løland >Priority: Minor > Attachments: derby-3508-1a.diff, derby-3508-1a.stat > > > Both master and slave embedded in ij. > I kill master and perform failover on slave. > The following is printed in ij: > ij> connect 'jdbc:derby:slaveDB;user=oystein;password=pass;failover=true'; > Exception in thread "derby.slave.logger-slaveDB" > java.lang.NullPointerException > at > org.apache.derby.impl.services.replication.slave.SlaveController.setupConnection(SlaveController.java:348) >at > org.apache.derby.impl.services.replication.slave.SlaveController.handleDisconnect(SlaveController.java:375) > at > org.apache.derby.impl.services.replication.slave.SlaveController.access$600(SlaveController.java:62) > at > org.apache.derby.impl.services.replication.slave.SlaveController$SlaveLogReceiverThread.run(SlaveController.java:504) > Note that failover works, and all seems well, so this is not a major issue. > derby.log is as follows: > BEGIN REPLICATION ERROR MESSAGE - > Lost connection with the replication master of database 'slaveDB'. > java.io.EOFException > at > java.io.ObjectInputStream$BlockDataInputStream.peekByte(ObjectInputStream.java:2552) > at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1297) > at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351) > at > org.apache.derby.impl.services.replication.net.SocketConnection.readMessage(SocketConnection.java:84) > at > org.apache.derby.impl.services.replication.net.ReplicationMessageReceive.readMessage(ReplicationMessageReceive.java:387) > at > org.apache.derby.impl.services.replication.slave.SlaveController$SlaveLogReceiverThread.run(SlaveController.java:477) > - END REPLICATION ERROR MESSAGE -- > Failover perfomed successfully for database 'slaveDB'. > Database Class Loader started - derby.database.classpath='' -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3508) Log receiver thread fails with NPE at failover when master has died
[ https://issues.apache.org/jira/browse/DERBY-3508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jørgen Løland updated DERBY-3508: - Derby Info: [Patch Available] > Log receiver thread fails with NPE at failover when master has died > --- > > Key: DERBY-3508 > URL: https://issues.apache.org/jira/browse/DERBY-3508 > Project: Derby > Issue Type: Bug > Components: Replication >Affects Versions: 10.4.0.0 >Reporter: Øystein Grøvlen >Assignee: Jørgen Løland >Priority: Minor > Attachments: derby-3508-1a.diff, derby-3508-1a.stat > > > Both master and slave embedded in ij. > I kill master and perform failover on slave. > The following is printed in ij: > ij> connect 'jdbc:derby:slaveDB;user=oystein;password=pass;failover=true'; > Exception in thread "derby.slave.logger-slaveDB" > java.lang.NullPointerException > at > org.apache.derby.impl.services.replication.slave.SlaveController.setupConnection(SlaveController.java:348) >at > org.apache.derby.impl.services.replication.slave.SlaveController.handleDisconnect(SlaveController.java:375) > at > org.apache.derby.impl.services.replication.slave.SlaveController.access$600(SlaveController.java:62) > at > org.apache.derby.impl.services.replication.slave.SlaveController$SlaveLogReceiverThread.run(SlaveController.java:504) > Note that failover works, and all seems well, so this is not a major issue. > derby.log is as follows: > BEGIN REPLICATION ERROR MESSAGE - > Lost connection with the replication master of database 'slaveDB'. > java.io.EOFException > at > java.io.ObjectInputStream$BlockDataInputStream.peekByte(ObjectInputStream.java:2552) > at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1297) > at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351) > at > org.apache.derby.impl.services.replication.net.SocketConnection.readMessage(SocketConnection.java:84) > at > org.apache.derby.impl.services.replication.net.ReplicationMessageReceive.readMessage(ReplicationMessageReceive.java:387) > at > org.apache.derby.impl.services.replication.slave.SlaveController$SlaveLogReceiverThread.run(SlaveController.java:477) > - END REPLICATION ERROR MESSAGE -- > Failover perfomed successfully for database 'slaveDB'. > Database Class Loader started - derby.database.classpath='' -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3523) sql states (X0Y63, X0Y63, X0Y63.S) related to nulls in unique constraints are associated with wrong message texts
[ https://issues.apache.org/jira/browse/DERBY-3523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12577761#action_12577761 ] V.Narayanan commented on DERBY-3523: Anurag says - thanks every one for pitching. Let me try to summarize it Derby doesn;t directly supports choosing message based on the type of run (soft upgrade more or a regular mode), but it does allow associating multiple messages to a single sql state bye adding "." extension (sqlstate.1, sqltate.2 etc). >From the code this can be used to throw correct error message after detecting the mode engine is running under (use existing sql states during soft upgrade and newer once during regular operation). The extensions of the sql state is dropped while setting the sql state to SQLException so user won't experience any difference during soft upgrade and will get newer message with same sql state during regular operation. > sql states (X0Y63, X0Y63, X0Y63.S) related to nulls in unique constraints are > associated with wrong message texts > -- > > Key: DERBY-3523 > URL: https://issues.apache.org/jira/browse/DERBY-3523 > Project: Derby > Issue Type: Bug >Affects Versions: 10.4.0.0, 10.5.0.0 >Reporter: Anurag Shekhar >Assignee: Anurag Shekhar > > There are three messages which after Derby-3330 checkin now giving wrong > information. These are > 42831:'{0}' cannot be a column of a primary key or unique key because it can > contain null values. > 42Z20:Column '{0}' cannot be made nullable. It is part of a primary key or > unique constraint, which cannot have any null able columns. > X0Y63.S:The command on table '{0}' failed because null data was found in the > primary key or unique constraint/index column(s). All columns in a primary or > unique index key must not be null. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [jira] Commented: (DERBY-3523) sql states (X0Y63, X0Y63, X0Y63.S) related to nulls in unique constraints are associated with wrong message texts
A general tip a reply to a mail generated by a JIRA comment, is appended to the issue if the 'to' in the email messages contain [EMAIL PROTECTED] I think our email clients automatically replace the 'to' field with derby-dev@db.apache.org Narayanan Anurag Shekhar wrote: thanks every one for pitching. Let me try to summarize it Derby doesn;t directly supports choosing message based on the type of run (soft upgrade more or a regular mode), but it does allow associating multiple messages to a single sql state bye adding "." extension (sqlstate.1, sqltate.2 etc). From the code this can be used to throw correct error message after detecting the mode engine is running under (use existing sql states during soft upgrade and newer once during regular operation). The extensions of the sql state is dropped while setting the sql state to SQLException so user won't experience any difference during soft upgrade and will get newer message with same sql state during regular operation. anurag Jørgen Løland (JIRA) wrote: [ https://issues.apache.org/jira/browse/DERBY-3523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12577750#action_12577750 ] Jørgen Løland commented on DERBY-3523: -- (Attaching mail thread) Narayanan wrote: Jørgen Løland wrote: Mike Matrigali wrote: It does seem like the best case would be for the error message system to somehow return a different error message for the same number if it is in soft upgrade vs. hard upgrade. Does the error message system support such a thing? Yes, it does. If you want multiple messages with the same SQL state, you need to add the "..<#>" information to the error state in SQLState.java. E.g, all these messages have SQL State 08004: - snip from SQLState.java String LOGIN_FAILED = "08004"; String NET_CONNECT_AUTH_FAILED = "08004.C.1"; String NET_DATABASE_NOT_FOUND = "08004.C.2"; String AUTH_DATABASE_CONNECTION_REFUSED = "08004.C.3"; String AUTH_SHUTDOWN_NOT_DB_OWNER = "08004.C.4"; String AUTH_ENCRYPT_NOT_DB_OWNER= "08004.C.5"; ... - snip --- If, e.g., both these messages '{0}' cannot be a column of a primary key or unique key because it can contain null values. '{0}' cannot be a column of a primary key because it can contain null values. ... should have the same 42831 error code, you would need something like this in the SQLState.java file: String LANG_DB2_ADD_UNIQUE_OR_PRIMARY_KEY_ON_NULL_COLS = "42831.S.1"; String LANG_DB2_ADD_PRIMARY_KEY_ON_NULL_COLS = "42831.S.2"; 'S' because 42831 is statement severity level (see class javadoc in SQLState.java), while 1 and 2 are used to tell the messages apart. messages.xml also needs to be updated, of course. But how will this help in printing different error messages in hard and soft upgrade? I thought this would be useful in grouping together the same family of messages, but can this act as a switch for messages that need to be printed in hard and soft upgrade? Narayanan The code where these exceptions are thrown needs to explicitly use the correct exception. However, this is the same thing that must be done if fix suggestion 2 is chosen. I think suggestion 2 should be modified like this: 2b: Introduce new message without changing the state and use old messages only during soft upgrade run. sql states (X0Y63, X0Y63, X0Y63.S) related to nulls in unique constraints are associated with wrong message texts -- Key: DERBY-3523 URL: https://issues.apache.org/jira/browse/DERBY-3523 Project: Derby Issue Type: Bug Affects Versions: 10.4.0.0, 10.5.0.0 Reporter: Anurag Shekhar Assignee: Anurag Shekhar There are three messages which after Derby-3330 checkin now giving wrong information. These are 42831:'{0}' cannot be a column of a primary key or unique key because it can contain null values. 42Z20:Column '{0}' cannot be made nullable. It is part of a primary key or unique constraint, which cannot have any null able columns. X0Y63.S:The command on table '{0}' failed because null data was found in the primary key or unique constraint/index column(s). All columns in a primary or unique index key must not be null.
[jira] Resolved: (DERBY-3521) Functionality for skipping testsuites on certain platforms fails for the new management testsuite on phoneME advanced
[ https://issues.apache.org/jira/browse/DERBY-3521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Knut Anders Hatlen resolved DERBY-3521. --- Resolution: Fixed Fix Version/s: 10.5.0.0 Derby Info: (was: [Patch Available]) Committed revision 636256. Should the fix also be merged into the 10.4 branch? > Functionality for skipping testsuites on certain platforms fails for the new > management testsuite on phoneME advanced > -- > > Key: DERBY-3521 > URL: https://issues.apache.org/jira/browse/DERBY-3521 > Project: Derby > Issue Type: Test > Components: Test > Environment: phoneME advanced platform >Reporter: Vemund Østgaard >Assignee: Vemund Østgaard > Fix For: 10.5.0.0 > > Attachments: 3521-fix-diff > > > It is not possible to run suites.All on phoneME advanced, junit will just > exit with an InvocationTargetException when trying to invoke the > suites.All.suite() method. Unwrapping the exception shows that the underlying > reason is a NoClassDefFoundError from the invoke() call in > AllPackages.addSuiteByReflection() when trying to load the new management > testsuite. > Now, this suite is compiled into 1.5 classfiles, so the Class.forName() call > before the invoke() is expected to fail with UnsupportedClassVersionError on > Java ME and Java SE 1.4. It does fail as expected when running with jdk 1.4, > but on phoneME advanced it does not, possibly a bug in phoneME advanced. > A fix/workaround in the testinfrastructure may be to catch > InvocationTargetException from the try block below, unwrap it and see if it > is an instance of LinkageError and if so skip the testsuite. This would make > it possible to run the tests on phoneME advanced. > private static Test addSuiteByReflection(String className) throws Exception >{ >try { >Class clz = Class.forName(className); > Method sm = clz.getMethod("suite", null); > return (Test) sm.invoke(null, null); >} catch (LinkageError e) { >return new TestSuite("SKIPPED: " + className + " - " + >e.getMessage()); >} >} -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3521) Functionality for skipping testsuites on certain platforms fails for the new management testsuite on phoneME advanced
[ https://issues.apache.org/jira/browse/DERBY-3521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1250#action_1250 ] Vemund Østgaard commented on DERBY-3521: It would be good to get it merged to 10.4, so I can test the RCs on phoneME advanced. > Functionality for skipping testsuites on certain platforms fails for the new > management testsuite on phoneME advanced > -- > > Key: DERBY-3521 > URL: https://issues.apache.org/jira/browse/DERBY-3521 > Project: Derby > Issue Type: Test > Components: Test > Environment: phoneME advanced platform >Reporter: Vemund Østgaard >Assignee: Vemund Østgaard > Fix For: 10.5.0.0 > > Attachments: 3521-fix-diff > > > It is not possible to run suites.All on phoneME advanced, junit will just > exit with an InvocationTargetException when trying to invoke the > suites.All.suite() method. Unwrapping the exception shows that the underlying > reason is a NoClassDefFoundError from the invoke() call in > AllPackages.addSuiteByReflection() when trying to load the new management > testsuite. > Now, this suite is compiled into 1.5 classfiles, so the Class.forName() call > before the invoke() is expected to fail with UnsupportedClassVersionError on > Java ME and Java SE 1.4. It does fail as expected when running with jdk 1.4, > but on phoneME advanced it does not, possibly a bug in phoneME advanced. > A fix/workaround in the testinfrastructure may be to catch > InvocationTargetException from the try block below, unwrap it and see if it > is an instance of LinkageError and if so skip the testsuite. This would make > it possible to run the tests on phoneME advanced. > private static Test addSuiteByReflection(String className) throws Exception >{ >try { >Class clz = Class.forName(className); > Method sm = clz.getMethod("suite", null); > return (Test) sm.invoke(null, null); >} catch (LinkageError e) { >return new TestSuite("SKIPPED: " + className + " - " + >e.getMessage()); >} >} -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (DERBY-3470) Replication: Master never gives up when slave dies.
[ https://issues.apache.org/jira/browse/DERBY-3470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jørgen Løland reassigned DERBY-3470: Assignee: Jørgen Løland > Replication: Master never gives up when slave dies. > --- > > Key: DERBY-3470 > URL: https://issues.apache.org/jira/browse/DERBY-3470 > Project: Derby > Issue Type: Bug > Components: Replication >Affects Versions: 10.4.0.0 >Reporter: Øystein Grøvlen >Assignee: Jørgen Løland > > After starting replication, I killed the slave process. The master continued > to write > Replication master role stopped for database 'masterDB'. > BEGIN REPLICATION ERROR MESSAGE - > Exception occurred during log shipping. > java.net.SocketException: Broken pipe > ... > over and over again. Soon my derby.log was several gigabytes. > In this scenario I inserted a lot of data, assuming that the > replication would stop when the database buffer became full, after > inserting more than 100 MB, the error messages still appeared. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
10.4 branch status
Thanks to everybody who enganged in a long and enlightening discussion about version numbers. I hope that I now have managed to check in the correct version number settings to the 10.4 branch: r635965 | dyre | 2008-03-11 16:08:07 +0100 (Tue, 11 Mar 2008) | 3 lines Changing the maint property on the 10.4 branch to 100, so that the branch will identify itself as 10.4.1.0 (beta). -- Dyre Tjeldvoll
[jira] Commented: (DERBY-3447) Shutdown on a database without stopping replication hangs
[ https://issues.apache.org/jira/browse/DERBY-3447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12577788#action_12577788 ] V.Narayanan commented on DERBY-3447: This shows that "derby.master.logger-mydb" prio=10 tid=0x08311800 nid=0x203b in Object.wait() [0xb5594000..0xb55950c0] java.lang.Thread.State: TIMED_WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on <0x8c0b6180> (a org.apache.derby.impl.store.replication.master.AsynchronousLogShipper) at org.apache.derby.impl.store.replication.master.AsynchronousLogShipper.run(AsynchronousLogShipper.java:203) - locked <0x8c0b6180> (a org.apache.derby.impl.store.replication.master.AsynchronousLogShipper) the log shipper thread is still running causing the hang in the master This shows that derby.slave.logger-mydb" prio=10 tid=0x0820f000 nid=0x203a runnable [0xb54ac000..0xb54acf40] java.lang.Thread.State: RUNNABLE at java.net.SocketInputStream.socketRead0(Native Method) at java.net.SocketInputStream.read(SocketInputStream.java:129) at java.net.SocketInputStream.read(SocketInputStream.java:182) at java.io.ObjectInputStream$PeekInputStream.peek(ObjectInputStream.java:2247) at java.io.ObjectInputStream$BlockDataInputStream.peek(ObjectInputStream.java:2540) at java.io.ObjectInputStream$BlockDataInputStream.peekByte(ObjectInputStream.java:2550) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1297) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351) at org.apache.derby.impl.store.replication.net.SocketConnection.readMessage(SocketConnection.java:84) at org.apache.derby.impl.store.replication.net.ReplicationMessageReceive.readMessage(ReplicationMessageReceive.java:387) at org.apache.derby.impl.store.replication.slave.SlaveController$SlaveLogReceiverThread.run(SlaveController.java:476) The SlaveLogReceiver thread is hanging on the read method of the socket it is listening on causing the hang on the slave. The questions I am searching for answers now is 1) Why is this happening only in the embedded mode? 2) How does turning authentication on affect this? > Shutdown on a database without stopping replication hangs > - > > Key: DERBY-3447 > URL: https://issues.apache.org/jira/browse/DERBY-3447 > Project: Derby > Issue Type: Bug > Components: Replication >Affects Versions: 10.4.0.0 >Reporter: V.Narayanan >Assignee: V.Narayanan > Attachments: Derby3447_v1.diff, Derby3447_v1.stat > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3521) Functionality for skipping testsuites on certain platforms fails for the new management testsuite on phoneME advanced
[ https://issues.apache.org/jira/browse/DERBY-3521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1259#action_1259 ] Knut Anders Hatlen commented on DERBY-3521: --- Merged to 10.4 and committed revision 636268. (JIRA is down, so I'll have to update the fix version later.) > Functionality for skipping testsuites on certain platforms fails for the new > management testsuite on phoneME advanced > -- > > Key: DERBY-3521 > URL: https://issues.apache.org/jira/browse/DERBY-3521 > Project: Derby > Issue Type: Test > Components: Test > Environment: phoneME advanced platform >Reporter: Vemund Østgaard >Assignee: Vemund Østgaard > Fix For: 10.5.0.0 > > Attachments: 3521-fix-diff > > > It is not possible to run suites.All on phoneME advanced, junit will just > exit with an InvocationTargetException when trying to invoke the > suites.All.suite() method. Unwrapping the exception shows that the underlying > reason is a NoClassDefFoundError from the invoke() call in > AllPackages.addSuiteByReflection() when trying to load the new management > testsuite. > Now, this suite is compiled into 1.5 classfiles, so the Class.forName() call > before the invoke() is expected to fail with UnsupportedClassVersionError on > Java ME and Java SE 1.4. It does fail as expected when running with jdk 1.4, > but on phoneME advanced it does not, possibly a bug in phoneME advanced. > A fix/workaround in the testinfrastructure may be to catch > InvocationTargetException from the try block below, unwrap it and see if it > is an instance of LinkageError and if so skip the testsuite. This would make > it possible to run the tests on phoneME advanced. > private static Test addSuiteByReflection(String className) throws Exception >{ >try { >Class clz = Class.forName(className); > Method sm = clz.getMethod("suite", null); > return (Test) sm.invoke(null, null); >} catch (LinkageError e) { >return new TestSuite("SKIPPED: " + className + " - " + >e.getMessage()); >} >} -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3447) Shutdown on a database without stopping replication hangs
[ https://issues.apache.org/jira/browse/DERBY-3447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] V.Narayanan updated DERBY-3447: --- Attachment: Derby3447_v2.stat Derby3447_v2.diff Fixed the earlier broken patch for the new trunk > Shutdown on a database without stopping replication hangs > - > > Key: DERBY-3447 > URL: https://issues.apache.org/jira/browse/DERBY-3447 > Project: Derby > Issue Type: Bug > Components: Replication >Affects Versions: 10.4.0.0 >Reporter: V.Narayanan >Assignee: V.Narayanan > Attachments: Derby3447_v1.diff, Derby3447_v1.stat, Derby3447_v2.diff, > Derby3447_v2.stat > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3521) Functionality for skipping testsuites on certain platforms fails for the new management testsuite on phoneME advanced
[ https://issues.apache.org/jira/browse/DERBY-3521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Knut Anders Hatlen updated DERBY-3521: -- Fix Version/s: 10.4.0.0 > Functionality for skipping testsuites on certain platforms fails for the new > management testsuite on phoneME advanced > -- > > Key: DERBY-3521 > URL: https://issues.apache.org/jira/browse/DERBY-3521 > Project: Derby > Issue Type: Test > Components: Test > Environment: phoneME advanced platform >Reporter: Vemund Østgaard >Assignee: Vemund Østgaard > Fix For: 10.4.0.0, 10.5.0.0 > > Attachments: 3521-fix-diff > > > It is not possible to run suites.All on phoneME advanced, junit will just > exit with an InvocationTargetException when trying to invoke the > suites.All.suite() method. Unwrapping the exception shows that the underlying > reason is a NoClassDefFoundError from the invoke() call in > AllPackages.addSuiteByReflection() when trying to load the new management > testsuite. > Now, this suite is compiled into 1.5 classfiles, so the Class.forName() call > before the invoke() is expected to fail with UnsupportedClassVersionError on > Java ME and Java SE 1.4. It does fail as expected when running with jdk 1.4, > but on phoneME advanced it does not, possibly a bug in phoneME advanced. > A fix/workaround in the testinfrastructure may be to catch > InvocationTargetException from the try block below, unwrap it and see if it > is an instance of LinkageError and if so skip the testsuite. This would make > it possible to run the tests on phoneME advanced. > private static Test addSuiteByReflection(String className) throws Exception >{ >try { >Class clz = Class.forName(className); > Method sm = clz.getMethod("suite", null); > return (Test) sm.invoke(null, null); >} catch (LinkageError e) { >return new TestSuite("SKIPPED: " + className + " - " + >e.getMessage()); >} >} -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3447) Shutdown on a database without stopping replication hangs
[ https://issues.apache.org/jira/browse/DERBY-3447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12577785#action_12577785 ] V.Narayanan commented on DERBY-3447: I am not able to reproduce this problem on the network client (surprises me, Maybe I did something wrong!!). But am able to reproduce this in the embedded mode. I did a jstack to find out what is hanging and found the following relevant - master "Attach Listener" daemon prio=10 tid=0x08312000 nid=0x2086 waiting on condition [0x..0x] java.lang.Thread.State: RUNNABLE "DestroyJavaVM" prio=10 tid=0x08059800 nid=0x2004 waiting on condition [0x..0xb7dfc090] java.lang.Thread.State: RUNNABLE "derby.master.logger-mydb" prio=10 tid=0x08311800 nid=0x203b in Object.wait() [0xb5594000..0xb55950c0] java.lang.Thread.State: TIMED_WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on <0x8c0b6180> (a org.apache.derby.impl.store.replication.master.AsynchronousLogShipper) at org.apache.derby.impl.store.replication.master.AsynchronousLogShipper.run(AsynchronousLogShipper.java:203) - locked <0x8c0b6180> (a org.apache.derby.impl.store.replication.master.AsynchronousLogShipper) "derby.rawStoreDaemon" daemon prio=10 tid=0x082b5c00 nid=0x2015 in Object.wait() [0xb5607000..0xb5608040] java.lang.Thread.State: TIMED_WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on <0x8c61f0a0> (a org.apache.derby.impl.services.daemon.BasicDaemon) at org.apache.derby.impl.services.daemon.BasicDaemon.rest(BasicDaemon.java:571) - locked <0x8c61f0a0> (a org.apache.derby.impl.services.daemon.BasicDaemon) at org.apache.derby.impl.services.daemon.BasicDaemon.run(BasicDaemon.java:388) at java.lang.Thread.run(Thread.java:619) "Timer-0" daemon prio=10 tid=0x08294000 nid=0x2014 in Object.wait() [0xb5666000..0xb5666fc0] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on <0x8c5d47b0> (a java.util.TaskQueue) at java.lang.Object.wait(Object.java:485) at java.util.TimerThread.mainLoop(Timer.java:483) - locked <0x8c5d47b0> (a java.util.TaskQueue) at java.util.TimerThread.run(Timer.java:462) "derby.antiGC" daemon prio=10 tid=0x08213c00 nid=0x2013 in Object.wait() [0xb56ba000..0xb56baf40] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on <0x8c5870a8> (a org.apache.derby.impl.services.monitor.AntiGC) at java.lang.Object.wait(Object.java:485) at org.apache.derby.impl.services.monitor.AntiGC.run(BaseMonitor.java:2196) - locked <0x8c5870a8> (a org.apache.derby.impl.services.monitor.AntiGC) at java.lang.Thread.run(Thread.java:619) "Low Memory Detector" daemon prio=10 tid=0x0808e000 nid=0x200a runnable [0x..0x] java.lang.Thread.State: RUNNABLE "CompilerThread0" daemon prio=10 tid=0x0808c400 nid=0x2009 waiting on condition [0x..0xb5a5b858] java.lang.Thread.State: RUNNABLE "Signal Dispatcher" daemon prio=10 tid=0x0808b000 nid=0x2008 runnable [0x..0xb5aace20] java.lang.Thread.State: RUNNABLE "Finalizer" daemon prio=10 tid=0x08082800 nid=0x2007 in Object.wait() [0xb5b3c000..0xb5b3d0c0] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on <0x8c551968> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:116) - locked <0x8c551968> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:132) at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:159) "Reference Handler" daemon prio=10 tid=0x08081800 nid=0x2006 in Object.wait() [0xb5b8d000..0xb5b8e040] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on <0x8c5519f8> (a java.lang.ref.Reference$Lock) at java.lang.Object.wait(Object.java:485) at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:116) - locked <0x8c5519f8> (a java.lang.ref.Reference$Lock) "VM Thread" prio=10 tid=0x0808 nid=0x2005 runnable "VM Periodic Task Thread" prio=10 tid=0x0808f800 nid=0x200b waiting on condition JNI global references: 690 --- Slave "Attach Listener" daemon prio=10 tid=0x0820ac00 nid=0x2092 runnable [0x
[jira] Commented: (DERBY-3513) NullPointerException in newBrokeredStatement in app server environment
[ https://issues.apache.org/jira/browse/DERBY-3513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12577799#action_12577799 ] Knut Anders Hatlen commented on DERBY-3513: --- Ops, sorry, I didn't notice that the affects version said 10.1.3.2. On 10.1 and 10.2, getJDBCLevel() returns 2 if we use Java 1.3, so removing the code wouldn't work. On trunk, I'd prefer that we removed the code. Will open a new issue so that we can fix that later. For now, I think it's OK to check in derby-3513_diff.txt. > NullPointerException in newBrokeredStatement in app server environment > -- > > Key: DERBY-3513 > URL: https://issues.apache.org/jira/browse/DERBY-3513 > Project: Derby > Issue Type: Bug > Components: JDBC >Affects Versions: 10.1.3.2 > Environment: Java Version:1.5.0 > Java Vendor: IBM Corporation > OS name: Linux > OS architecture: x86 > OS version: 2.6.9-55.ELsmp >Reporter: Kathey Marsden > Attachments: derby-3513_diff.txt > > > User reports in an app server environment an intermittent > NullPointerException > with the 10.1 trace: > R java.lang.NullPointerException > org.apache.derby.iapi.jdbc.BrokeredConnection.newBrokeredStatement(BrokeredConnection.java:448) > > ...org.apache.derby.jdbc.XAStatementControl.(XAStatementControl.java:62) > > ...org.apache.derby.jdbc.EmbedXAConnection.wrapStatement(EmbedXAConnection.java:827) > > org.apache.derby.iapi.jdbc.BrokeredConnection.createStatement(BrokeredConnection.java:296) > [snip user trace] > The code at line 448 is simply: > return new BrokeredStatement(statementControl, getJDBCLevel()); > so not much room for an NPE there. I added println statements to identify > the state values and where the NPE is actually occurring but that seemed to > make the > problem go away. It may be a JIT issue. > I gave them the fix for DERBY-2142 and that did not correct the problem. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3513) NullPointerException in newBrokeredStatement in app server environment
[ https://issues.apache.org/jira/browse/DERBY-3513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12577794#action_12577794 ] Knut Anders Hatlen commented on DERBY-3513: --- Wouldn't it be better to remove the jdbcLevel field from BrokeredStatement completely? Then we don't need the call to getJDBCLevel() in those methods at all. The only use of the jdbcLevel field I could find, was this statement in BrokeredStatement.createDuplicateStatement(): if (jdbcLevel == 2) newStatement = conn.createStatement(resultSetType, resultSetConcurrency); else newStatement = conn.createStatement(resultSetType, resultSetConcurrency, resultSetHoldability); Since BrokeredConnection.getJDBCLevel() never returns 2, it is not needed any more. > NullPointerException in newBrokeredStatement in app server environment > -- > > Key: DERBY-3513 > URL: https://issues.apache.org/jira/browse/DERBY-3513 > Project: Derby > Issue Type: Bug > Components: JDBC >Affects Versions: 10.1.3.2 > Environment: Java Version:1.5.0 > Java Vendor: IBM Corporation > OS name: Linux > OS architecture: x86 > OS version: 2.6.9-55.ELsmp >Reporter: Kathey Marsden > Attachments: derby-3513_diff.txt > > > User reports in an app server environment an intermittent > NullPointerException > with the 10.1 trace: > R java.lang.NullPointerException > org.apache.derby.iapi.jdbc.BrokeredConnection.newBrokeredStatement(BrokeredConnection.java:448) > > ...org.apache.derby.jdbc.XAStatementControl.(XAStatementControl.java:62) > > ...org.apache.derby.jdbc.EmbedXAConnection.wrapStatement(EmbedXAConnection.java:827) > > org.apache.derby.iapi.jdbc.BrokeredConnection.createStatement(BrokeredConnection.java:296) > [snip user trace] > The code at line 448 is simply: > return new BrokeredStatement(statementControl, getJDBCLevel()); > so not much room for an NPE there. I added println statements to identify > the state values and where the NPE is actually occurring but that seemed to > make the > problem go away. It may be a JIT issue. > I gave them the fix for DERBY-2142 and that did not correct the problem. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (DERBY-3525) Remove unneeded code to get JDBC level in BrokeredConnection and BrokeredStatement classes
Remove unneeded code to get JDBC level in BrokeredConnection and BrokeredStatement classes -- Key: DERBY-3525 URL: https://issues.apache.org/jira/browse/DERBY-3525 Project: Derby Issue Type: Improvement Components: JDBC, Network Client Affects Versions: 10.5.0.0 Reporter: Knut Anders Hatlen Priority: Minor BrokeredConnection has a method called getJDBCLevel() whose only purpose is to provide a value that can be stored in BrokeredStatement.jdbcLevel. This field is only used once, in BrokeredStatement.createDuplicateStatement(): if (jdbcLevel == 2) newStatement = conn.createStatement(resultSetType, resultSetConcurrency); else newStatement = conn.createStatement(resultSetType, resultSetConcurrency, resultSetHoldability); Since getJDBCLevel() only returns 2 if Java version 1.3 is used, and Derby doesn't support Java 1.3 any more, BrokeredConnection.getJDBCLevel() and BrokeredStatement.jdbcLevel could be removed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3513) NullPointerException in newBrokeredStatement in app server environment
[ https://issues.apache.org/jira/browse/DERBY-3513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12577801#action_12577801 ] Knut Anders Hatlen commented on DERBY-3513: --- Created DERBY-3525 to track the clean-up. > NullPointerException in newBrokeredStatement in app server environment > -- > > Key: DERBY-3513 > URL: https://issues.apache.org/jira/browse/DERBY-3513 > Project: Derby > Issue Type: Bug > Components: JDBC >Affects Versions: 10.1.3.2 > Environment: Java Version:1.5.0 > Java Vendor: IBM Corporation > OS name: Linux > OS architecture: x86 > OS version: 2.6.9-55.ELsmp >Reporter: Kathey Marsden > Attachments: derby-3513_diff.txt > > > User reports in an app server environment an intermittent > NullPointerException > with the 10.1 trace: > R java.lang.NullPointerException > org.apache.derby.iapi.jdbc.BrokeredConnection.newBrokeredStatement(BrokeredConnection.java:448) > > ...org.apache.derby.jdbc.XAStatementControl.(XAStatementControl.java:62) > > ...org.apache.derby.jdbc.EmbedXAConnection.wrapStatement(EmbedXAConnection.java:827) > > org.apache.derby.iapi.jdbc.BrokeredConnection.createStatement(BrokeredConnection.java:296) > [snip user trace] > The code at line 448 is simply: > return new BrokeredStatement(statementControl, getJDBCLevel()); > so not much room for an NPE there. I added println statements to identify > the state values and where the NPE is actually occurring but that seemed to > make the > problem go away. It may be a JIT issue. > I gave them the fix for DERBY-2142 and that did not correct the problem. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: 10.4 branch status
[EMAIL PROTECTED] writes: > Thanks to everybody who enganged in a long and enlightening discussion > about version numbers. I hope that I now have managed to > check in the correct version number settings to the 10.4 branch: > > > r635965 | dyre | 2008-03-11 16:08:07 +0100 (Tue, 11 Mar 2008) | 3 lines > > Changing the maint property on the 10.4 branch to 100, so that the branch > will identify itself as 10.4.1.0 (beta). > > Should we then also have a 10.4.1.0 version in JIRA? -- Knut Anders
[jira] Commented: (DERBY-3470) Replication: Master never gives up when slave dies.
[ https://issues.apache.org/jira/browse/DERBY-3470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12577800#action_12577800 ] Øystein Grøvlen commented on DERBY-3470: I suspect that this may have been fixed since I have not observed this the last few days. > Replication: Master never gives up when slave dies. > --- > > Key: DERBY-3470 > URL: https://issues.apache.org/jira/browse/DERBY-3470 > Project: Derby > Issue Type: Bug > Components: Replication >Affects Versions: 10.4.0.0 >Reporter: Øystein Grøvlen >Assignee: Jørgen Løland > > After starting replication, I killed the slave process. The master continued > to write > Replication master role stopped for database 'masterDB'. > BEGIN REPLICATION ERROR MESSAGE - > Exception occurred during log shipping. > java.net.SocketException: Broken pipe > ... > over and over again. Soon my derby.log was several gigabytes. > In this scenario I inserted a lot of data, assuming that the > replication would stop when the database buffer became full, after > inserting more than 100 MB, the error messages still appeared. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3525) Remove unneeded code to get JDBC level in BrokeredConnection and BrokeredStatement classes
[ https://issues.apache.org/jira/browse/DERBY-3525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12577804#action_12577804 ] Kristian Waagan commented on DERBY-3525: It is not clear to me why the component includes "Network Client". If it was not just a click too much, do you mind explaining how this affects the network client? > Remove unneeded code to get JDBC level in BrokeredConnection and > BrokeredStatement classes > -- > > Key: DERBY-3525 > URL: https://issues.apache.org/jira/browse/DERBY-3525 > Project: Derby > Issue Type: Improvement > Components: JDBC, Network Client >Affects Versions: 10.5.0.0 >Reporter: Knut Anders Hatlen >Priority: Minor > > BrokeredConnection has a method called getJDBCLevel() whose only purpose is > to provide a value that can be stored in BrokeredStatement.jdbcLevel. This > field is only used once, in BrokeredStatement.createDuplicateStatement(): > if (jdbcLevel == 2) > newStatement = conn.createStatement(resultSetType, > resultSetConcurrency); > else > newStatement = conn.createStatement(resultSetType, > resultSetConcurrency, > resultSetHoldability); > Since getJDBCLevel() only returns 2 if Java version 1.3 is used, and Derby > doesn't support Java 1.3 any more, BrokeredConnection.getJDBCLevel() and > BrokeredStatement.jdbcLevel could be removed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3319) Logical connections do not check if a transaction is active on close
[ https://issues.apache.org/jira/browse/DERBY-3319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Waagan updated DERBY-3319: --- Affects Version/s: 10.5.0.0 > Logical connections do not check if a transaction is active on close > > > Key: DERBY-3319 > URL: https://issues.apache.org/jira/browse/DERBY-3319 > Project: Derby > Issue Type: Bug > Components: JDBC, Network Client >Affects Versions: 10.3.2.1, 10.4.0.0, 10.5.0.0 > Environment: Embedded driver and client driver. >Reporter: Kristian Waagan > Attachments: LogicalConnectionCloseActiveTransactionBug.java > > > If you call close on a logical connection, for instance as obtained through a > PooledConnection, it does not check if there is an active transaction. > The close of the logical connection is allowed, and even the close of the > parent PooledConnection is allowed in the client driver. This can/will cause > resources to be left on the server, and later operations might fail > (typically with lock timeouts because the "closed" transaction is still > holding locks). > I do not know if gc will solve this eventually, but I would say the current > behavior of the client driver is wrong in any case. > There is difference in the behavior between the embedded and the client > driver, and there also seems to be a bug in the embedded driver. > The analysis above is a bit sketchy, so it might be required to look into the > issue a bit more... > I will attach a repro (JDBC usage should be verified as well, is it legal / > as intended?) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (DERBY-1911) rollback does not function with pooled connection
[ https://issues.apache.org/jira/browse/DERBY-1911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Waagan closed DERBY-1911. -- I'm taking the liberty of closing this issue. We haven't heard anything from the reporter in a long time, and the issue has been resolved as invalid. I wrote a little app to test the reported behavior, and as far as I can tell, Derby behaves correctly both with and without an explicit rollback after the exception. There is one exception, where the client driver does not check if there is an active transaction when the connection is closed. This has been logged earlier as DERBY-3319. > rollback does not function with pooled connection > - > > Key: DERBY-1911 > URL: https://issues.apache.org/jira/browse/DERBY-1911 > Project: Derby > Issue Type: Bug > Components: Network Server >Affects Versions: 10.1.3.1 > Environment: WIndows XP, Windows 2003, IBM Websphere Application > Server Community Edition 1.1, Sun JDK 1.5_08, IBM JDK 5.0 >Reporter: Huang GuangXia > > My scenario: The derby is running in a Network Server mode. > When using DriverManager to get connection, rollback works fine with > setAutoCommit(false) to the connection. > But rollback not do its work in the pooled connection scenario. > I configured a data source in Websphere Application Server Community Edition > 1.1 (WASCE for short hereafter), and get connection this way: > Context ctx = new InitialContext(); > DataSource ds = (DataSource)ctx.lookup("java:comp/env/jdbc/eim"); > conn = ds.getConnection(); > with this connection, I insert data into three tables. All the three tables > have primary key constraint, so no dup key can be inserted. > before execute insert statement, I do this: > conn.setAutoCommit(false); > and then execute three insert statements. > the third insertion failed because of duplicated key, so Exception caught, a > rollback is executed. > But the result is not right: the first and second insertion have not rolled > back!!! The inserted data still in table. > Any body can help me on this? > Can this problem be solved by change settings? > Thanks > HuangGX -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3525) Remove unneeded code to get JDBC level in BrokeredConnection and BrokeredStatement classes
[ https://issues.apache.org/jira/browse/DERBY-3525?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Knut Anders Hatlen updated DERBY-3525: -- Component/s: (was: Network Client) Thanks. Removed network client from components. > Remove unneeded code to get JDBC level in BrokeredConnection and > BrokeredStatement classes > -- > > Key: DERBY-3525 > URL: https://issues.apache.org/jira/browse/DERBY-3525 > Project: Derby > Issue Type: Improvement > Components: JDBC >Affects Versions: 10.5.0.0 >Reporter: Knut Anders Hatlen >Priority: Minor > > BrokeredConnection has a method called getJDBCLevel() whose only purpose is > to provide a value that can be stored in BrokeredStatement.jdbcLevel. This > field is only used once, in BrokeredStatement.createDuplicateStatement(): > if (jdbcLevel == 2) > newStatement = conn.createStatement(resultSetType, > resultSetConcurrency); > else > newStatement = conn.createStatement(resultSetType, > resultSetConcurrency, > resultSetHoldability); > Since getJDBCLevel() only returns 2 if Java version 1.3 is used, and Derby > doesn't support Java 1.3 any more, BrokeredConnection.getJDBCLevel() and > BrokeredStatement.jdbcLevel could be removed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3520) convert views.sql to junit
[ https://issues.apache.org/jira/browse/DERBY-3520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12577832#action_12577832 ] John H. Embretsen commented on DERBY-3520: -- The folowing committed code results in a Javadoc warning: + * @param sqlStates[] expected sql state. * @param st Statement object on which to execute. * @param query the query to compile and execute. */ -public static void assertStatementError(String sqlState, +public static void assertStatementError(String[] sqlStates, Statement st, String query) > convert views.sql to junit > -- > > Key: DERBY-3520 > URL: https://issues.apache.org/jira/browse/DERBY-3520 > Project: Derby > Issue Type: Task > Components: Test >Affects Versions: 10.5.0.0 >Reporter: Kathey Marsden >Assignee: Kathey Marsden >Priority: Minor > Attachments: derby-3520_diff.txt, derby-3520_diff.txt > > > With the latest IBM 1.6 jvm I am seeing an ordering diff in the errors in > drop table with views.sql so it would be good to convert to junit to avoid > having separate jvm masters. -- 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-3520) convert views.sql to junit
[ https://issues.apache.org/jira/browse/DERBY-3520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12577832#action_12577832 ] johnemb edited comment on DERBY-3520 at 3/12/08 5:42 AM: --- The following committed code results in a Javadoc warning: + * @param sqlStates[] expected sql state. * @param st Statement object on which to execute. * @param query the query to compile and execute. */ -public static void assertStatementError(String sqlState, +public static void assertStatementError(String[] sqlStates, Statement st, String query) /trunk/java/testing/org/apache/derbyTesting/junit/BaseJDBCTestCase.java:956: warning - @param argument "sqlStates[]" is not a parameter name. was (Author: johnemb): The folowing committed code results in a Javadoc warning: + * @param sqlStates[] expected sql state. * @param st Statement object on which to execute. * @param query the query to compile and execute. */ -public static void assertStatementError(String sqlState, +public static void assertStatementError(String[] sqlStates, Statement st, String query) > convert views.sql to junit > -- > > Key: DERBY-3520 > URL: https://issues.apache.org/jira/browse/DERBY-3520 > Project: Derby > Issue Type: Task > Components: Test >Affects Versions: 10.5.0.0 >Reporter: Kathey Marsden >Assignee: Kathey Marsden >Priority: Minor > Attachments: derby-3520_diff.txt, derby-3520_diff.txt > > > With the latest IBM 1.6 jvm I am seeing an ordering diff in the errors in > drop table with views.sql so it would be good to convert to junit to avoid > having separate jvm masters. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3385) Tests for JMX Management and Monitoring
[ https://issues.apache.org/jira/browse/DERBY-3385?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John H. Embretsen updated DERBY-3385: - Attachment: d3385_jdbcMBeanTest_02.diff Attached patch file d3385_jdbcMBeanTest_02.diff: M java/testing/org/apache/derbyTesting/functionTests/tests/management/MBeanTest.java M java/testing/org/apache/derbyTesting/functionTests/tests/management/JDBCMBeanTest.java M java/testing/org/apache/derbyTesting/junit/TestConfiguration.java M java/testing/org/apache/derbyTesting/junit/NetworkServerTestSetup.java M java/testing/org/apache/derbyTesting/junit/Utilities.java This patch modifies the JDBCMBeanTest so that the expected values for the MajorVersion and MinorVersion attributes are obtained from the embedded driver instead of the client driver. I wasn't sure how to do this, but I ended up decorating these two test fixtures a bit differently than the rest of the fixtures, by using a NetworkServerTestSetup which JDBCClient is set to embedded. The patch adds some logic in TestConfiguration.java and MBeanTest.java for handling this. The patch also moves the two generic utility methods for fetching sysinfo output from MBeanTest.java to org.apache.derbyTesting.junit.Utilities.java. In addition, the patch revises some Javadoc comments in NetworkServerTestSetup.java. When testing this patch I once ran into timeout issues similar to those reported in DERBY-3515 when running the management Suite on WinXP (single-CPU) - but I have not been able to reproduce this yet, and it was likely not related to this specific patch - so I'm asking for review/commit at this point. > Tests for JMX Management and Monitoring > --- > > Key: DERBY-3385 > URL: https://issues.apache.org/jira/browse/DERBY-3385 > Project: Derby > Issue Type: Sub-task > Components: JMX, Test >Reporter: John H. Embretsen >Assignee: John H. Embretsen > Attachments: d3385_ant-junit-all.diff, d3385_jdbcMBeanTest_01.diff, > d3385_jdbcMBeanTest_02.diff, d3385_versionMBeanTest_01.diff, > d3385_versionMBeanTest_02.diff, TestJMXp9.java > > > DERBY-1387 implements a new feature set in Derby: Java Management eXtentions > (JMX), i.e. standards-based management and monitoring capabilities. > As these are completely new features providing additional interfaces to a > running Derby system, a set of functional regression tests should be added. > The new tests should verify that Derby's public JMX API works as intended, > and should be able to detect regressions in this area in the future. There is > a functional specification (jmxFuncspec.html) attached to DERBY-1387 which > may be used as reference. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Regression Test Report - Daily 635600 - Sun DBTG
Platform 'linN+1' has become 'lin', meaning we no longer run on Red Hat AS 4 but from now on only on RHAS 5 (becoming 'lin'). Sorry, I should have informed about this before: this was activated last week. Henri [EMAIL PROTECTED] wrote: [Auto-generated mail] *Daily* 635600/2008-03-10 18:01:41 MET Failed TestsOK Skip Duration Suite --- *Jvm: 1.6* lin 0274274 081.63% derbyall 01045410454 0 1376.82% suitesAll linN+1 NA NA NANA derbyall NA NA NANA suitesAll sles 0274274 071.26% derbyall 01045410454 0 908.02% suitesAll sol 0274274 075.21% derbyall 01045410454 0 1629.17% suitesAll solN+1 0274274 098.58% derbyall 01045410454 0 175.80% suitesAll sparc 0274274 066.37% derbyall 01045410454 0 367.23% suitesAll vista 0274274 094.35% derbyall 093459345 067.95% suitesAll w2003 0274274 098.57% derbyall F:4,E:71618891169 041.46% suitesAll Details in http://dbtg.thresher.com/derby/test/Daily/jvm1.6/testing/Limited/testSummary-635600.html Attempted failure analysis in http://dbtg.thresher.com/derby/test/Daily/jvm1.6/FailReports/635600_bySig.html *Jvm: 1.5* lin 0275275 080.53% derbyall 087348734 0 1018.25% suitesAll linN+1 NA NA NANA derbyall NA NA NANA suitesAll sles 0275275 071.48% derbyall 087348734 0 572.72% suitesAll sol 0275275 079.34% derbyall 087348734 0 849.19% suitesAll solN+1 0275275 089.38% derbyall 087348734 0 810.32% suitesAll sparc 0275275 067.60% derbyall 087348734 0 706.49% suitesAll vista 0275275 072.17% derbyall 076257625 0 409.69% suitesAll w2003 0275275 075.76% derbyall 076257625 0 265.52% suitesAll Details in http://dbtg.thresher.com/derby/test/Daily/jvm1.5/testing/Limited/testSummary-635600.html Attempted failure analysis in http://dbtg.thresher.com/derby/test/Daily/jvm1.5/FailReports/635600_bySig.html *Jvm: 1.4* lin 0272272 281.64% derbyall 085828582 0 904.59% suitesAll linN+1 NA NA NANA derbyall NA NA NANA suitesAll sles 0272272 273.37% derbyall 085828582 0 529.96% suitesAll sol 0272272 278.49% derbyall 085828582 0 698.45% suitesAll solN+1 0272272 290.14% derbyall 085828582 0 752.08% suitesAll sparc 0272272 267.68% derbyall 085828582 0 712.83% suitesAll vista 0272272 271.46% derbyall 074737473 0 398.30% suitesAll w2003 0272272 276.43% derbyall 074777477 0 255.38% suitesAll Details in http://dbtg.thresher.com/derby/test/Daily/jvm1.4/testing/Limited/testSummary-635600.html Attempted failure analysis in http://dbtg.thresher.com/derby/test/Daily/jvm1.4/FailReports/635600_bySig.html --- Changes in http://dbtg.thresher.com/derby/test/Daily/UpdateInfo/635600.txt ( All results in http://dbtg.thresher.com/derby/test/ ) -- With regards, Henri van de Scheur, Database Technology Group, Sun Microsystems, Trondheim, Norway
[jira] Issue Comment Edited: (DERBY-3385) Tests for JMX Management and Monitoring
[ https://issues.apache.org/jira/browse/DERBY-3385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12577839#action_12577839 ] johnemb edited comment on DERBY-3385 at 3/12/08 6:12 AM: --- Attached patch file d3385_jdbcMBeanTest_02.diff: M java/testing/org/apache/derbyTesting/functionTests/tests/management/MBeanTest.java M java/testing/org/apache/derbyTesting/functionTests/tests/management/JDBCMBeanTest.java M java/testing/org/apache/derbyTesting/junit/TestConfiguration.java M java/testing/org/apache/derbyTesting/junit/NetworkServerTestSetup.java M java/testing/org/apache/derbyTesting/junit/Utilities.java This patch modifies the JDBCMBeanTest so that the expected values for the MajorVersion and MinorVersion attributes are obtained from the embedded driver instead of the client driver. I wasn't sure how to do this, but I ended up decorating these two test fixtures a bit differently than the rest of the fixtures, by using a ServerSetup which JDBCClient is set to embedded. The patch adds some logic in TestConfiguration.java and MBeanTest.java for handling this. The patch also moves the two generic utility methods for fetching sysinfo output from MBeanTest.java to org.apache.derbyTesting.junit.Utilities.java. In addition, the patch revises some Javadoc comments in NetworkServerTestSetup.java. When testing this patch I once ran into timeout issues similar to those reported in DERBY-3515 when running the management Suite on WinXP (single-CPU) - but I have not been able to reproduce this yet, and it was likely not related to this specific patch - so I'm asking for review/commit at this point. was (Author: johnemb): Attached patch file d3385_jdbcMBeanTest_02.diff: M java/testing/org/apache/derbyTesting/functionTests/tests/management/MBeanTest.java M java/testing/org/apache/derbyTesting/functionTests/tests/management/JDBCMBeanTest.java M java/testing/org/apache/derbyTesting/junit/TestConfiguration.java M java/testing/org/apache/derbyTesting/junit/NetworkServerTestSetup.java M java/testing/org/apache/derbyTesting/junit/Utilities.java This patch modifies the JDBCMBeanTest so that the expected values for the MajorVersion and MinorVersion attributes are obtained from the embedded driver instead of the client driver. I wasn't sure how to do this, but I ended up decorating these two test fixtures a bit differently than the rest of the fixtures, by using a NetworkServerTestSetup which JDBCClient is set to embedded. The patch adds some logic in TestConfiguration.java and MBeanTest.java for handling this. The patch also moves the two generic utility methods for fetching sysinfo output from MBeanTest.java to org.apache.derbyTesting.junit.Utilities.java. In addition, the patch revises some Javadoc comments in NetworkServerTestSetup.java. When testing this patch I once ran into timeout issues similar to those reported in DERBY-3515 when running the management Suite on WinXP (single-CPU) - but I have not been able to reproduce this yet, and it was likely not related to this specific patch - so I'm asking for review/commit at this point. > Tests for JMX Management and Monitoring > --- > > Key: DERBY-3385 > URL: https://issues.apache.org/jira/browse/DERBY-3385 > Project: Derby > Issue Type: Sub-task > Components: JMX, Test >Reporter: John H. Embretsen >Assignee: John H. Embretsen > Attachments: d3385_ant-junit-all.diff, d3385_jdbcMBeanTest_01.diff, > d3385_jdbcMBeanTest_02.diff, d3385_versionMBeanTest_01.diff, > d3385_versionMBeanTest_02.diff, TestJMXp9.java > > > DERBY-1387 implements a new feature set in Derby: Java Management eXtentions > (JMX), i.e. standards-based management and monitoring capabilities. > As these are completely new features providing additional interfaces to a > running Derby system, a set of functional regression tests should be added. > The new tests should verify that Derby's public JMX API works as intended, > and should be able to detect regressions in this area in the future. There is > a functional specification (jmxFuncspec.html) attached to DERBY-1387 which > may be used as reference. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3506) Add JMX testing with a security manager and JMX authentication.
[ https://issues.apache.org/jira/browse/DERBY-3506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12577851#action_12577851 ] Daniel John Debrunner commented on DERBY-3506: -- The existing MBean tests are run against the platform MBeanServer within the same vm and using remote JMX without jmx authentication against a derby network server spawned in a separate jvm. After revision 636323 both cases are running Derby & its jmx implementation under a security manager: platform mbean server - through standard use of security manager in the junit tests using derby_tests.policy remote jmx - through the start of the network server installing the basic security policy. > Add JMX testing with a security manager and JMX authentication. > --- > > Key: DERBY-3506 > URL: https://issues.apache.org/jira/browse/DERBY-3506 > Project: Derby > Issue Type: Sub-task > Components: JMX, Test >Reporter: Daniel John Debrunner >Assignee: Daniel John Debrunner >Priority: Minor > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Daily testing on branch 10.3 to be replaced by 10.4
From this evening on, daily testing on branch 10.3 will be stopped and replaced by daily testing on branch 10.4. Results will be reported under http://dbtg.thresher.com/derby/test/ -- With regards, Henri van de Scheur, Database Technology Group, Sun Microsystems, Trondheim, Norway
[jira] Created: (DERBY-3526) AsynchronousLogShipper#workToDo is blocked while the log shipper sends a log chunk
AsynchronousLogShipper#workToDo is blocked while the log shipper sends a log chunk -- Key: DERBY-3526 URL: https://issues.apache.org/jira/browse/DERBY-3526 Project: Derby Issue Type: Bug Affects Versions: 10.4.0.0, 10.5.0.0 Reporter: Jørgen Løland The replication log shipper thread synchronizes on 'this' both when shipping log records (shipALogChunk) and when it waits between log shipments. Transaction threads may try to wake up the log shipper because log has arrived that should be shipped (i.e., through the method workToDo). These threads should not have to wait for the monitor if the log shipper is currently busy shipping log. The solution is to have two monitors - one for log shipment and one for waiting between log shipment. This may seem like a minor issue, but if the TCP connection between master and slave is lost e.g. because a network cable has been unplugged, the log shipper will block for 2 minutes on ObjectOutputStream#writeObject. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-2911) Implement a buffer manager using java.util.concurrent classes
[ https://issues.apache.org/jira/browse/DERBY-2911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Knut Anders Hatlen updated DERBY-2911: -- Attachment: d2911-13.diff Attaching a patch (d2911-13) which addresses 2a and 4h. I have started the regression tests suite. 2a: Instead of inventing a new name for lockWhenIdentityIsSet(), I created a new method waitUntilIdentityIsSet() and let the callers first invoke lock() and then waitUntilIdentityIsSet(). I think that makes the code clearer. 4h: I created named constants for the numeric constants in rotateClock() and shrinkMe(). I didn't make any changes to trimMe(), since I'm wondering if it's best just to remove it. After this patch, I think it's only 4g (explain the heuristics in ClockPolicy.trimMe()) that hasn't been addressed. I believe that trimMe() in reality is dead code (supported by the fact that its predecessor Clock.trimToSize() is always a no-op in the regression tests according to the test coverage reports), and a better and more reliable solution for the problem it tries to solve, is to reduce the cache size. Unless someone comes up with a situation where Clock.trimToSize() and ClockPolicy.trimMe() provide valuable functionality, I'm inclined to remove the latter. > Implement a buffer manager using java.util.concurrent classes > - > > Key: DERBY-2911 > URL: https://issues.apache.org/jira/browse/DERBY-2911 > Project: Derby > Issue Type: Improvement > Components: Performance, Services >Affects Versions: 10.4.0.0 >Reporter: Knut Anders Hatlen >Assignee: Knut Anders Hatlen >Priority: Minor > Attachments: cleaner.diff, cleaner.tar, d2911-1.diff, d2911-1.stat, > d2911-10.diff, d2911-10.stat, d2911-11.diff, d2911-12.diff, d2911-13.diff, > d2911-2.diff, d2911-3.diff, d2911-4.diff, d2911-5.diff, d2911-6.diff, > d2911-6.stat, d2911-7.diff, d2911-7a.diff, d2911-9.diff, d2911-9.stat, > d2911-enable.diff, d2911-entry-javadoc.diff, d2911-unused.diff, > d2911-unused.stat, d2911perf.java, derby-2911-8.diff, derby-2911-8.stat, > perftest.diff, perftest.pdf, perftest.stat, perftest2.diff, perftest6.pdf, > poisson_patch8.tar > > > There are indications that the buffer manager is a bottleneck for some types > of multi-user load. For instance, Anders Morken wrote this in a comment on > DERBY-1704: "With a separate table and index for each thread (to remove latch > contention and lock waits from the equation) we (...) found that > org.apache.derby.impl.services.cache.Clock.find()/release() caused about 5 > times more contention than the synchronization in LockSet.lockObject() and > LockSet.unlock(). That might be an indicator of where to apply the next push". > It would be interesting to see the scalability and performance of a buffer > manager which exploits the concurrency utilities added in Java SE 5. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3447) Shutdown on a database without stopping replication hangs
[ https://issues.apache.org/jira/browse/DERBY-3447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12577863#action_12577863 ] Øystein Grøvlen commented on DERBY-3447: V.Narayanan (JIRA) wrote: > I am not able to reproduce this problem on the network client (surprises me, > Maybe I did something wrong!!). This may be ovious, but to be sure: Note that when embedded a quit in ij will stop the VM that contains the master. If client/server, the master is running in a separate VM. I not quite sure you will necessarily get the same code path by stopping a server. > Shutdown on a database without stopping replication hangs > - > > Key: DERBY-3447 > URL: https://issues.apache.org/jira/browse/DERBY-3447 > Project: Derby > Issue Type: Bug > Components: Replication >Affects Versions: 10.4.0.0 >Reporter: V.Narayanan >Assignee: V.Narayanan > Attachments: Derby3447_v1.diff, Derby3447_v1.stat, Derby3447_v2.diff, > Derby3447_v2.stat > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3385) Tests for JMX Management and Monitoring
[ https://issues.apache.org/jira/browse/DERBY-3385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12577864#action_12577864 ] Daniel John Debrunner commented on DERBY-3385: -- Does this method make sense? MBeanTest.decorateWithRemoteJmxAndEmbeddedJDBC In this case Derby's MBean will be running against the embedded jdbc driver on the remote machine, but the junit test will be running against the embedded driver in the test vm. I guess they are the same but that is an assumption, it could change in the future, maybe any improvements could be addressed then. > Tests for JMX Management and Monitoring > --- > > Key: DERBY-3385 > URL: https://issues.apache.org/jira/browse/DERBY-3385 > Project: Derby > Issue Type: Sub-task > Components: JMX, Test >Reporter: John H. Embretsen >Assignee: John H. Embretsen > Attachments: d3385_ant-junit-all.diff, d3385_jdbcMBeanTest_01.diff, > d3385_jdbcMBeanTest_02.diff, d3385_versionMBeanTest_01.diff, > d3385_versionMBeanTest_02.diff, TestJMXp9.java > > > DERBY-1387 implements a new feature set in Derby: Java Management eXtentions > (JMX), i.e. standards-based management and monitoring capabilities. > As these are completely new features providing additional interfaces to a > running Derby system, a set of functional regression tests should be added. > The new tests should verify that Derby's public JMX API works as intended, > and should be able to detect regressions in this area in the future. There is > a functional specification (jmxFuncspec.html) attached to DERBY-1387 which > may be used as reference. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3385) Tests for JMX Management and Monitoring
[ https://issues.apache.org/jira/browse/DERBY-3385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12577865#action_12577865 ] Daniel John Debrunner commented on DERBY-3385: -- Another thought is just use a really simple approach instead of hiding all of this through decorators: Driver d = new org.apache.derby.jdbc.EmbeddedDriver(); d.getMinorVersion(); d.getMajorVersion(); Sometimes simplicity & directness is better. > Tests for JMX Management and Monitoring > --- > > Key: DERBY-3385 > URL: https://issues.apache.org/jira/browse/DERBY-3385 > Project: Derby > Issue Type: Sub-task > Components: JMX, Test >Reporter: John H. Embretsen >Assignee: John H. Embretsen > Attachments: d3385_ant-junit-all.diff, d3385_jdbcMBeanTest_01.diff, > d3385_jdbcMBeanTest_02.diff, d3385_versionMBeanTest_01.diff, > d3385_versionMBeanTest_02.diff, TestJMXp9.java > > > DERBY-1387 implements a new feature set in Derby: Java Management eXtentions > (JMX), i.e. standards-based management and monitoring capabilities. > As these are completely new features providing additional interfaces to a > running Derby system, a set of functional regression tests should be added. > The new tests should verify that Derby's public JMX API works as intended, > and should be able to detect regressions in this area in the future. There is > a functional specification (jmxFuncspec.html) attached to DERBY-1387 which > may be used as reference. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (DERBY-3527) The slave will not notice that a network cable is unplugged and will therefore reject failover/stopSlave commands
The slave will not notice that a network cable is unplugged and will therefore reject failover/stopSlave commands - Key: DERBY-3527 URL: https://issues.apache.org/jira/browse/DERBY-3527 Project: Derby Issue Type: Bug Components: Replication Affects Versions: 10.4.0.0, 10.5.0.0 Reporter: Jørgen Løland If a network cable between the master and slave is unplugged (or a switch crashes etc), ObjectInputStream#readObject will not get an exception. Neither the socket nor the input stream can be queried for information on whether or not the connection is working. AFAIK, the only way to find out if the network is down is to send a message. The slave commands stopSlave and failover are rejected if the network connection is working. To be absolutely sure that the connection is working, we need to ping the master when these commands are requested. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3526) AsynchronousLogShipper#workToDo is blocked while the log shipper sends a log chunk
[ https://issues.apache.org/jira/browse/DERBY-3526?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jørgen Løland updated DERBY-3526: - Component/s: Replication > AsynchronousLogShipper#workToDo is blocked while the log shipper sends a log > chunk > -- > > Key: DERBY-3526 > URL: https://issues.apache.org/jira/browse/DERBY-3526 > Project: Derby > Issue Type: Bug > Components: Replication >Affects Versions: 10.4.0.0, 10.5.0.0 >Reporter: Jørgen Løland > > The replication log shipper thread synchronizes on 'this' both when shipping > log records (shipALogChunk) and when it waits between log shipments. > Transaction threads may try to wake up the log shipper because log has > arrived that should be shipped (i.e., through the method workToDo). These > threads should not have to wait for the monitor if the log shipper is > currently busy shipping log. The solution is to have two monitors - one for > log shipment and one for waiting between log shipment. > This may seem like a minor issue, but if the TCP connection between master > and slave is lost e.g. because a network cable has been unplugged, the log > shipper will block for 2 minutes on ObjectOutputStream#writeObject. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3385) Tests for JMX Management and Monitoring
[ https://issues.apache.org/jira/browse/DERBY-3385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12577868#action_12577868 ] John H. Embretsen commented on DERBY-3385: -- Ah, so I don't really need to use DatabaseMetaData Much better, I will create a new patch with this change (using the Driver interface directly). It still does not necessarily access the exact same embedded driver as the MBean implementation, but I have no idea how to access the embedded driver in a remote VM. It is better than using the client driver though, I guess. > Tests for JMX Management and Monitoring > --- > > Key: DERBY-3385 > URL: https://issues.apache.org/jira/browse/DERBY-3385 > Project: Derby > Issue Type: Sub-task > Components: JMX, Test >Reporter: John H. Embretsen >Assignee: John H. Embretsen > Attachments: d3385_ant-junit-all.diff, d3385_jdbcMBeanTest_01.diff, > d3385_jdbcMBeanTest_02.diff, d3385_versionMBeanTest_01.diff, > d3385_versionMBeanTest_02.diff, TestJMXp9.java > > > DERBY-1387 implements a new feature set in Derby: Java Management eXtentions > (JMX), i.e. standards-based management and monitoring capabilities. > As these are completely new features providing additional interfaces to a > running Derby system, a set of functional regression tests should be added. > The new tests should verify that Derby's public JMX API works as intended, > and should be able to detect regressions in this area in the future. There is > a functional specification (jmxFuncspec.html) attached to DERBY-1387 which > may be used as reference. -- 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
Issue Subscription Filter: Derby: JIRA issues with patch available (14 issues) Subscriber: derby-dev Key Summary DERBY-3447 Shutdown on a database without stopping replication hangs https://issues.apache.org/jira/browse/DERBY-3447 DERBY-3520 convert views.sql to junit https://issues.apache.org/jira/browse/DERBY-3520 DERBY-3508 Log receiver thread fails with NPE at failover when master has died https://issues.apache.org/jira/browse/DERBY-3508 DERBY-3382 Replication: Slave must inform master if DBs are out of sync. https://issues.apache.org/jira/browse/DERBY-3382 DERBY-3491 Change SystemPermission to be a two arguement permission with a name (object the permission is on) and an action. https://issues.apache.org/jira/browse/DERBY-3491 DERBY-3448 Allow the MailJdbc system test to run under junit. https://issues.apache.org/jira/browse/DERBY-3448 DERBY-3169 Add documentation for replication https://issues.apache.org/jira/browse/DERBY-3169 DERBY-3460 SQL roles: patch to mask off roles on 10.4 release branch https://issues.apache.org/jira/browse/DERBY-3460 DERBY-3327 SQL roles: Implement authorization stack (and SQL session context to hold it) https://issues.apache.org/jira/browse/DERBY-3327 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-3379 "No Current connection" on PooledConnection.getConnection() if pooled connection is reused during connectionClosed processing https://issues.apache.org/jira/browse/DERBY-3379 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-3227 Remove final from all getConnection() methods in EmbeddedDataSource https://issues.apache.org/jira/browse/DERBY-3227
[jira] Commented: (DERBY-3447) Shutdown on a database without stopping replication hangs
[ https://issues.apache.org/jira/browse/DERBY-3447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12577876#action_12577876 ] V.Narayanan commented on DERBY-3447: I understand that the code path will be different in the case of the client. But I am confused about its import. Are you trying to say that the problem of the log shipper thread clean-up not happening might still be there in the client but our current way of trying to reproduce the problem is not right? (or) Are you trying to say that this problem need not be looked from the client perspective at all (I think you don't mean this but just to be sure) I am trying to work with the embedded reproducible for now. But from your comment it looks like finding a solution in the embedded case might not necessarily mean that this problem has been solved in all cases? > Shutdown on a database without stopping replication hangs > - > > Key: DERBY-3447 > URL: https://issues.apache.org/jira/browse/DERBY-3447 > Project: Derby > Issue Type: Bug > Components: Replication >Affects Versions: 10.4.0.0 >Reporter: V.Narayanan >Assignee: V.Narayanan > Attachments: Derby3447_v1.diff, Derby3447_v1.stat, Derby3447_v2.diff, > Derby3447_v2.stat > > -- 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
[ https://issues.apache.org/jira/browse/DERBY-3320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12577882#action_12577882 ] Vemund Østgaard commented on DERBY-3320: I think it is sufficient as a first increment at least to check just Collator.getAvailableLocales(). I think you are correct in your earlier assessment that the locales returned by Collator.getAvailableLocales() is a subset of the locales returned by Locale.getAvailableLocales(), so if you find the locale in the first list it should also be in the second. > 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_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=. 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] Commented: (DERBY-3523) sql states (X0Y63, X0Y63, X0Y63.S) related to nulls in unique constraints are associated with wrong message texts
[ https://issues.apache.org/jira/browse/DERBY-3523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12577883#action_12577883 ] Anurag Shekhar commented on DERBY-3523: --- I am planning to introduce similar to the following String errorState = null; if (getLanguageConnectionContext().getDataDictionary() .checkVersion(DataDictionary.DD_VERSION_DERBY_10_4, null)) { errorState = SQLState.LANG_MODIFY_COLUMN_EXISTING_PRIMARY_KEY; } else { //soft upgrade mode errorState = SQLState.LANG_MODIFY_COLUMN_EXISTING_CONSTRAINT; } throw StandardException.newException(errorState, name); List of effected files java/engine/org/apache/derby/impl/sql/compile/sqlgrammar.jj java/engine/org/apache/derby/impl/sql/compile/TableElementList.java java/engine/org/apache/derby/impl/sql/compile/ModifyColumnNode.java java/engine/org/apache/derby/impl/sql/execute/AlterTableConstantAction.java java/shared/org/apache/derby/shared/common/reference/SQLState.java java/engine/org/apache/derby/loc/messages.xml In addition to these, out files of few harness tests will also need modifications. > sql states (X0Y63, X0Y63, X0Y63.S) related to nulls in unique constraints are > associated with wrong message texts > -- > > Key: DERBY-3523 > URL: https://issues.apache.org/jira/browse/DERBY-3523 > Project: Derby > Issue Type: Bug >Affects Versions: 10.4.0.0, 10.5.0.0 >Reporter: Anurag Shekhar >Assignee: Anurag Shekhar > > There are three messages which after Derby-3330 checkin now giving wrong > information. These are > 42831:'{0}' cannot be a column of a primary key or unique key because it can > contain null values. > 42Z20:Column '{0}' cannot be made nullable. It is part of a primary key or > unique constraint, which cannot have any null able columns. > X0Y63.S:The command on table '{0}' failed because null data was found in the > primary key or unique constraint/index column(s). All columns in a primary or > unique index key must not be null. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3385) Tests for JMX Management and Monitoring
[ https://issues.apache.org/jira/browse/DERBY-3385?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John H. Embretsen updated DERBY-3385: - Attachment: d3385_jdbcMBeanTest_03.diff Attached patch file d3385_jdbcMBeanTest_03.diff, to replace d3385_jdbcMBeanTest_02.diff: M java/testing/org/apache/derbyTesting/functionTests/tests/management/MBeanTest.java M java/testing/org/apache/derbyTesting/functionTests/tests/management/JDBCMBeanTest.java M java/testing/org/apache/derbyTesting/junit/NetworkServerTestSetup.java M java/testing/org/apache/derbyTesting/junit/Utilities.java This patch modifies the JDBCMBeanTest so that the expected values for the MajorVersion and MinorVersion attributes are obtained from the embedded driver instead of the client driver. The difference from patch 02 is that the expected values are retrieved directly from the embedded driver (assuming this is available in the classpath) instead of going through DatabaseMetaData and for that reason jumping through various hoops in order to get a JDBC connection using the embedded driver. As with patch 02, this patch also revises some javadoc comments in NetworkServerTestSetup, and moves the generic utility methods for getting sysinfo output, from MBeanTest to the Utilities class in org.apache.derbyTesting.junit. > Tests for JMX Management and Monitoring > --- > > Key: DERBY-3385 > URL: https://issues.apache.org/jira/browse/DERBY-3385 > Project: Derby > Issue Type: Sub-task > Components: JMX, Test >Reporter: John H. Embretsen >Assignee: John H. Embretsen > Attachments: d3385_ant-junit-all.diff, d3385_jdbcMBeanTest_01.diff, > d3385_jdbcMBeanTest_02.diff, d3385_jdbcMBeanTest_03.diff, > d3385_versionMBeanTest_01.diff, d3385_versionMBeanTest_02.diff, TestJMXp9.java > > > DERBY-1387 implements a new feature set in Derby: Java Management eXtentions > (JMX), i.e. standards-based management and monitoring capabilities. > As these are completely new features providing additional interfaces to a > running Derby system, a set of functional regression tests should be added. > The new tests should verify that Derby's public JMX API works as intended, > and should be able to detect regressions in this area in the future. There is > a functional specification (jmxFuncspec.html) attached to DERBY-1387 which > may be used as reference. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (DERBY-3513) NullPointerException in newBrokeredStatement in app server environment
[ https://issues.apache.org/jira/browse/DERBY-3513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden reassigned DERBY-3513: - Assignee: Kathey Marsden > NullPointerException in newBrokeredStatement in app server environment > -- > > Key: DERBY-3513 > URL: https://issues.apache.org/jira/browse/DERBY-3513 > Project: Derby > Issue Type: Bug > Components: JDBC >Affects Versions: 10.1.3.2 > Environment: Java Version:1.5.0 > Java Vendor: IBM Corporation > OS name: Linux > OS architecture: x86 > OS version: 2.6.9-55.ELsmp >Reporter: Kathey Marsden >Assignee: Kathey Marsden > Attachments: derby-3513_diff.txt > > > User reports in an app server environment an intermittent > NullPointerException > with the 10.1 trace: > R java.lang.NullPointerException > org.apache.derby.iapi.jdbc.BrokeredConnection.newBrokeredStatement(BrokeredConnection.java:448) > > ...org.apache.derby.jdbc.XAStatementControl.(XAStatementControl.java:62) > > ...org.apache.derby.jdbc.EmbedXAConnection.wrapStatement(EmbedXAConnection.java:827) > > org.apache.derby.iapi.jdbc.BrokeredConnection.createStatement(BrokeredConnection.java:296) > [snip user trace] > The code at line 448 is simply: > return new BrokeredStatement(statementControl, getJDBCLevel()); > so not much room for an NPE there. I added println statements to identify > the state values and where the NPE is actually occurring but that seemed to > make the > problem go away. It may be a JIT issue. > I gave them the fix for DERBY-2142 and that did not correct the problem. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3523) sql states (X0Y63, X0Y63, X0Y63.S) related to nulls in unique constraints are associated with wrong message texts
[ https://issues.apache.org/jira/browse/DERBY-3523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12577893#action_12577893 ] V.Narayanan commented on DERBY-3523: You could consider introducing a newException method in the StandardException class that would accept two SQLStates (one for hard, one for soft upgrade), the data dictionary version. This method would use the appropriate SQLState depending on whether hard upgrade or soft upgrade is being done for the mentioned data dictionary version. > sql states (X0Y63, X0Y63, X0Y63.S) related to nulls in unique constraints are > associated with wrong message texts > -- > > Key: DERBY-3523 > URL: https://issues.apache.org/jira/browse/DERBY-3523 > Project: Derby > Issue Type: Bug >Affects Versions: 10.4.0.0, 10.5.0.0 >Reporter: Anurag Shekhar >Assignee: Anurag Shekhar > > There are three messages which after Derby-3330 checkin now giving wrong > information. These are > 42831:'{0}' cannot be a column of a primary key or unique key because it can > contain null values. > 42Z20:Column '{0}' cannot be made nullable. It is part of a primary key or > unique constraint, which cannot have any null able columns. > X0Y63.S:The command on table '{0}' failed because null data was found in the > primary key or unique constraint/index column(s). All columns in a primary or > unique index key must not be null. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3513) NullPointerException in newBrokeredStatement in app server environment
[ https://issues.apache.org/jira/browse/DERBY-3513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12577906#action_12577906 ] Kathey Marsden commented on DERBY-3513: --- Thanks Knut, the cleanup (DERBY-3525) sounds like a good solution for 10.3+ > NullPointerException in newBrokeredStatement in app server environment > -- > > Key: DERBY-3513 > URL: https://issues.apache.org/jira/browse/DERBY-3513 > Project: Derby > Issue Type: Bug > Components: JDBC >Affects Versions: 10.1.3.2 > Environment: Java Version:1.5.0 > Java Vendor: IBM Corporation > OS name: Linux > OS architecture: x86 > OS version: 2.6.9-55.ELsmp >Reporter: Kathey Marsden >Assignee: Kathey Marsden > Attachments: derby-3513_diff.txt > > > User reports in an app server environment an intermittent > NullPointerException > with the 10.1 trace: > R java.lang.NullPointerException > org.apache.derby.iapi.jdbc.BrokeredConnection.newBrokeredStatement(BrokeredConnection.java:448) > > ...org.apache.derby.jdbc.XAStatementControl.(XAStatementControl.java:62) > > ...org.apache.derby.jdbc.EmbedXAConnection.wrapStatement(EmbedXAConnection.java:827) > > org.apache.derby.iapi.jdbc.BrokeredConnection.createStatement(BrokeredConnection.java:296) > [snip user trace] > The code at line 448 is simply: > return new BrokeredStatement(statementControl, getJDBCLevel()); > so not much room for an NPE there. I added println statements to identify > the state values and where the NPE is actually occurring but that seemed to > make the > problem go away. It may be a JIT issue. > I gave them the fix for DERBY-2142 and that did not correct the problem. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: 10.4 branch status
Knut Anders Hatlen <[EMAIL PROTECTED]> writes: > [EMAIL PROTECTED] writes: > >> Thanks to everybody who enganged in a long and enlightening discussion >> about version numbers. I hope that I now have managed to >> check in the correct version number settings to the 10.4 branch: >> >> >> r635965 | dyre | 2008-03-11 16:08:07 +0100 (Tue, 11 Mar 2008) | 3 lines >> >> Changing the maint property on the 10.4 branch to 100, so that the branch >> will identify itself as 10.4.1.0 (beta). >> >> > > Should we then also have a 10.4.1.0 version in JIRA? I guess so. The Wiki page says "Post to derby-dev requesting that a new version be added to JIRA for the next version of Derby" Until now I thought that meant add "10.5.0.0", and since that has already been done I didn't worry about it... I guess I assumed that this would be done when the release candidate was spun, but I guess we need to track bugs against the beta as well... -- dt
Regression Test Report - Daily 636007 - Sun DBTG
[Auto-generated mail] *Daily* 636007/2008-03-11 18:01:00 MET Failed TestsOK Skip Duration Suite --- *Jvm: 1.6* lin 1274273 083.18% derbyall 01045310453 0 1361.30% suitesAll linN+1 NA NA NANA derbyall NA NA NANA suitesAll sles 1274273 074.51% derbyall 01045310453 0 815.65% suitesAll sol 0274274 076.58% derbyall 01045310453 0 1625.77% suitesAll solN+1 0274274 098.34% derbyall 01045310453 0 182.17% suitesAll sparc 0274274 066.64% derbyall 01045310453 0 364.76% suitesAll vista 0274274 094.43% derbyall 093449344 067.49% suitesAll w2003 0274274 097.32% derbyall F:4,E:71518891170 041.05% suitesAll Details in http://dbtg.thresher.com/derby/test/Daily/jvm1.6/testing/Limited/testSummary-636007.html Attempted failure analysis in http://dbtg.thresher.com/derby/test/Daily/jvm1.6/FailReports/636007_bySig.html *Jvm: 1.5* lin 0275275 080.48% derbyall 087338733 0 1017.30% suitesAll linN+1 NA NA NANA derbyall NA NA NANA suitesAll sles 0275275 071.54% derbyall 087338733 0 573.44% suitesAll sol 0275275 078.82% derbyall 087338733 0 858.63% suitesAll solN+1 0275275 089.50% derbyall 087338733 0 809.62% suitesAll sparc 0275275 067.69% derbyall 087338733 0 705.38% suitesAll vista 0275275 071.74% derbyall 076247624 0 407.41% suitesAll w2003 1275274 073.39% derbyall 076247624 0 269.11% suitesAll Details in http://dbtg.thresher.com/derby/test/Daily/jvm1.5/testing/Limited/testSummary-636007.html Attempted failure analysis in http://dbtg.thresher.com/derby/test/Daily/jvm1.5/FailReports/636007_bySig.html *Jvm: 1.4* lin 0272272 281.64% derbyall 085818581 0 904.09% suitesAll linN+1 NA NA NANA derbyall NA NA NANA suitesAll sles 0272272 273.38% derbyall 085818581 0 527.84% suitesAll sol 0272272 278.46% derbyall 085818581 0 688.08% suitesAll solN+1 0272272 290.19% derbyall 085818581 0 772.69% suitesAll sparc 0272272 267.66% derbyall 085818581 0 713.57% suitesAll vista 0272272 272.14% derbyall 074727472 0 396.17% suitesAll w2003 0272272 276.38% derbyall 074767476 0 257.30% suitesAll Details in http://dbtg.thresher.com/derby/test/Daily/jvm1.4/testing/Limited/testSummary-636007.html Attempted failure analysis in http://dbtg.thresher.com/derby/test/Daily/jvm1.4/FailReports/636007_bySig.html --- Changes in http://dbtg.thresher.com/derby/test/Daily/UpdateInfo/636007.txt ( All results in http://dbtg.thresher.com/derby/test/ )
[jira] Closed: (DERBY-3520) convert views.sql to junit
[ https://issues.apache.org/jira/browse/DERBY-3520?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden closed DERBY-3520. - > convert views.sql to junit > -- > > Key: DERBY-3520 > URL: https://issues.apache.org/jira/browse/DERBY-3520 > Project: Derby > Issue Type: Task > Components: Test >Affects Versions: 10.5.0.0 >Reporter: Kathey Marsden >Assignee: Kathey Marsden >Priority: Minor > Fix For: 10.3.2.2, 10.4.0.0, 10.5.0.0 > > Attachments: derby-3520_diff.txt, derby-3520_diff.txt > > > With the latest IBM 1.6 jvm I am seeing an ordering diff in the errors in > drop table with views.sql so it would be good to convert to junit to avoid > having separate jvm masters. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3523) sql states (X0Y63, X0Y63, X0Y63.S) related to nulls in unique constraints are associated with wrong message texts
[ https://issues.apache.org/jira/browse/DERBY-3523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12577911#action_12577911 ] Anurag Shekhar commented on DERBY-3523: --- I don't think adding information about specific sql states StandardException is a good idea. Its not very frequently where error messages needs modification. I prefer keeping information about it in the respective classes only. These classes are anyway aware about the soft upgrade as they allow or disallow creation of unique constraint based on it. StanduardException does very specialized job of creating SQLException and filling it with SQLState and messages. IMO Its better if we don't add too many functionality to it. > sql states (X0Y63, X0Y63, X0Y63.S) related to nulls in unique constraints are > associated with wrong message texts > -- > > Key: DERBY-3523 > URL: https://issues.apache.org/jira/browse/DERBY-3523 > Project: Derby > Issue Type: Bug >Affects Versions: 10.4.0.0, 10.5.0.0 >Reporter: Anurag Shekhar >Assignee: Anurag Shekhar > > There are three messages which after Derby-3330 checkin now giving wrong > information. These are > 42831:'{0}' cannot be a column of a primary key or unique key because it can > contain null values. > 42Z20:Column '{0}' cannot be made nullable. It is part of a primary key or > unique constraint, which cannot have any null able columns. > X0Y63.S:The command on table '{0}' failed because null data was found in the > primary key or unique constraint/index column(s). All columns in a primary or > unique index key must not be null. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (DERBY-3520) convert views.sql to junit
[ https://issues.apache.org/jira/browse/DERBY-3520?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden resolved DERBY-3520. --- Resolution: Fixed Fix Version/s: 10.5.0.0 10.4.0.0 10.3.2.2 Actually fixed in 10.4.1.0, but we don't have a version for that yet in JIRA. > convert views.sql to junit > -- > > Key: DERBY-3520 > URL: https://issues.apache.org/jira/browse/DERBY-3520 > Project: Derby > Issue Type: Task > Components: Test >Affects Versions: 10.5.0.0 >Reporter: Kathey Marsden >Assignee: Kathey Marsden >Priority: Minor > Fix For: 10.3.2.2, 10.4.0.0, 10.5.0.0 > > Attachments: derby-3520_diff.txt, derby-3520_diff.txt > > > With the latest IBM 1.6 jvm I am seeing an ordering diff in the errors in > drop table with views.sql so it would be good to convert to junit to avoid > having separate jvm masters. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3385) Tests for JMX Management and Monitoring
[ https://issues.apache.org/jira/browse/DERBY-3385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12577922#action_12577922 ] Daniel John Debrunner commented on DERBY-3385: -- patch d3385_jdbcMBeanTest_03.diff applied revision 636417 - Thanks John. > Tests for JMX Management and Monitoring > --- > > Key: DERBY-3385 > URL: https://issues.apache.org/jira/browse/DERBY-3385 > Project: Derby > Issue Type: Sub-task > Components: JMX, Test >Reporter: John H. Embretsen >Assignee: John H. Embretsen > Attachments: d3385_ant-junit-all.diff, d3385_jdbcMBeanTest_01.diff, > d3385_jdbcMBeanTest_02.diff, d3385_jdbcMBeanTest_03.diff, > d3385_versionMBeanTest_01.diff, d3385_versionMBeanTest_02.diff, TestJMXp9.java > > > DERBY-1387 implements a new feature set in Derby: Java Management eXtentions > (JMX), i.e. standards-based management and monitoring capabilities. > As these are completely new features providing additional interfaces to a > running Derby system, a set of functional regression tests should be added. > The new tests should verify that Derby's public JMX API works as intended, > and should be able to detect regressions in this area in the future. There is > a functional specification (jmxFuncspec.html) attached to DERBY-1387 which > may be used as reference. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (DERBY-3515) 23 timeouts encountered while running management junit suite as part of full nightly runs.
[ https://issues.apache.org/jira/browse/DERBY-3515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Matrigali resolved DERBY-3515. --- Resolution: Cannot Reproduce Fix Version/s: 10.5.0.0 With latest build on trunk I can't duplicate this anymore. I ran full suite on laptop where I saw it twice before 9 times and did not reproduce and I ran it 8 times on another machine where I saw it once and did not see it reproduce. If anyone see's it feel free to reopen the issue. > 23 timeouts encountered while running management junit suite as part of full > nightly runs. > -- > > Key: DERBY-3515 > URL: https://issues.apache.org/jira/browse/DERBY-3515 > Project: Derby > Issue Type: Bug > Components: Regression Test Failure >Affects Versions: 10.4.0.0 > Environment: windows XP, laptop, ibm15 >Reporter: Mike Matrigali > Fix For: 10.5.0.0 > > Attachments: summary.out > > > While running full nightly test suite on a classes,SANE build got 23 failures > in management test suite as follows. Tried again in same codeline > just running the management test suite and it worked 50 times in a row. > Maybe issue is similar to DERBY-3514, where a previous test is leaving > a bad state and now that timeout has been reduced again to where it was known > to cause nightly test failures in some environments those issues > are resurfacing. I am trying another full suite run to see if it reproduces > in my environment, if others are seeing this issue, please add a comment. > I will attach full log of errors, but here is the first few: > There were 23 errors: > 1) > testDerbyRegisteredMBeansSimpleInfo(org.apache.derbyTesting.functionTests.tests.management.JMXTest)java.rmi.ConnectIOException: > Exception creating > connection to: 192.168.0.188; nested exception is: > java.net.SocketException: Operation timed out: connect:could be due to > invalid address > at sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:603) > at sun.rmi.transport.tcp.TCPChannel.createConnection(TCPChannel.java:204) > at sun.rmi.transport.tcp.TCPChannel.newConnection(TCPChannel.java:190) > at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:109) > at > javax.management.remote.rmi.RMIServerImpl_Stub.newClient(RMIServerImpl_Stub.java:52) > at > javax.management.remote.rmi.RMIConnector.getConnection(RMIConnector.java:2244) > at javax.management.remote.rmi.RMIConnector.connect(RMIConnector.java:286) > at > javax.management.remote.JMXConnectorFactory.connect(JMXConnectorFactory.java:263) > at > org.apache.derbyTesting.functionTests.tests.management.RemoteConnectionGetter.getMBeanServerConnection(RemoteConnectionGetter.java:49) > at > org.apache.derbyTesting.functionTests.tests.management.MBeanTest.getMBeanServerConnection(MBeanTest.java:177) > at > org.apache.derbyTesting.functionTests.tests.management.MBeanTest.getApplicationManagementMBean(MBeanTest.java:252) > at > org.apache.derbyTesting.functionTests.tests.management.MBeanTest.enableManagement(MBeanTest.java:201) > at > org.apache.derbyTesting.functionTests.tests.management.MBeanTest.setUp(MBeanTest.java:155) > at > org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:101) > at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) > at junit.extensions.TestSetup$1.protect(TestSetup.java:19) > at junit.extensions.TestSetup.run(TestSetup.java:23) > at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) > at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) > at junit.extensions.TestSetup$1.protect(TestSetup.java:19) > at junit.extensions.TestSetup.run(TestSetup.java:23) > at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) > at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) > at junit.extensions.TestSetup$1.protect(TestSetup.java:19) > at junit.extensions.TestSetup.run(TestSetup.java:23) > at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) > at junit.extensions.TestSetup$1.protect(TestSetup.java:19) > at junit.extensions.TestSetup.run(TestSetup.java:23) > Caused by: java.net.SocketException: Operation timed out: connect:could be > due to invalid address > at java.net.PlainSocketImpl.socketConnect(Native Method) > at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:372) > at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:233) > at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:220) > at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:385) > at java.net.Socket.connect(Socket.java:541) > at java.net.Socket.connect(Socket.java:491) >
[jira] Commented: (DERBY-3523) sql states (X0Y63, X0Y63, X0Y63.S) related to nulls in unique constraints are associated with wrong message texts
[ https://issues.apache.org/jira/browse/DERBY-3523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12577939#action_12577939 ] V.Narayanan commented on DERBY-3523: >I don't think adding information about specific sql states StandardException >is a good idea. Sorry about the ambiguity in the previous comment. I did not mean to ask you to push this specific SQLState creation into StandardException. If you were to following my suggestion you would have one method in StandardException whose "first three" parameters would probably be (String SQLState1, String SQLState2, ). In the simplest case You could choose the type of upgrade to be a boolean called hardupgrade, where it being, false - would indicate that SQLState1 is to be used true - would indicate that SQLState2 is to be used In the above case you would be retaining the logic for determining if it is a hard or a soft upgrade in the calling method. You could even decide on pushing the type of upgrade deciding logic into StandardException based on if you think it would be appropriate. Ofcourse I must say I do agree with "StanduardException does very specialized job of creating SQLException and filling it with SQLState and messages. IMO Its better if we don't add too many functionality to it." you have a strong case and your argument does leave me in a dilemna as to what would be most appropriate here. Sorry about the confusion, > sql states (X0Y63, X0Y63, X0Y63.S) related to nulls in unique constraints are > associated with wrong message texts > -- > > Key: DERBY-3523 > URL: https://issues.apache.org/jira/browse/DERBY-3523 > Project: Derby > Issue Type: Bug >Affects Versions: 10.4.0.0, 10.5.0.0 >Reporter: Anurag Shekhar >Assignee: Anurag Shekhar > > There are three messages which after Derby-3330 checkin now giving wrong > information. These are > 42831:'{0}' cannot be a column of a primary key or unique key because it can > contain null values. > 42Z20:Column '{0}' cannot be made nullable. It is part of a primary key or > unique constraint, which cannot have any null able columns. > X0Y63.S:The command on table '{0}' failed because null data was found in the > primary key or unique constraint/index column(s). All columns in a primary or > unique index key must not be null. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3494) Move the setup of NormalizeResultSetNode into the NormalizeResultSetNode
[ https://issues.apache.org/jira/browse/DERBY-3494?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-3494: -- Derby Info: [Patch Available] > Move the setup of NormalizeResultSetNode into the NormalizeResultSetNode > > > Key: DERBY-3494 > URL: https://issues.apache.org/jira/browse/DERBY-3494 > Project: Derby > Issue Type: Improvement > Components: SQL >Affects Versions: 10.4.0.0 >Reporter: Kathey Marsden >Priority: Minor > Attachments: d3494_npe_writeup.html, d3494_npe_writeup.html, > decompile.out, derby-3494_remove_genNormalizeResultSetNode_diff.txt, npe.sql > > > In DERBY-3310 Dan suggested ... > Setting up a NormalizeResultSetNode is spread over three locations, the class > itself (very little, it's almost acting like a C struct), > the genNormalizeResultSetNode method and then copyLengthsAndTypesToSource. A > good O-O implementation would have > the logic to create a NormalizeResultSetNode self-contained in > NormalizeResultSetNode. > Since the ResultColumnList of the original ResultSetNode correctly describes > the desired outcome, it's not clear to > me why NormalizeResultSetNode can't just refer to the same list and use it > for its processing. They may be some chance > that this would cause recursion at some point, where a NormalizeResultSetNode > would think it needed to be wrapped > in a NormalizeResultSetNode since the types of its columns and expression > don't match (i.e. when it is handled as a regular ResultSetNode). > I think moving the setup of a NormalizeResultSetNode into the class itself, > so that its inputs are just the ResultSetNode to wrap > would help clear up the code, especially if comments were added indicating > why certain actions were being taken. > I am separating this task out into a separate issue, so that it can be worked > on independently of DERBY-3310. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3494) Move the setup of NormalizeResultSetNode into the NormalizeResultSetNode
[ https://issues.apache.org/jira/browse/DERBY-3494?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-3494: -- Attachment: derby-3494_remove_genNormalizeResultSetNode_diff.txt Thank you so much Army for the detailed write up. After reading it a few dozen times I think I have a much better understanding of what is going on with the modification of the child result set. It seems necessary. I don't really see how we could acheive the goal of not modifying the result set we are wrapping with a NormalizeResultSetNode. Now that I understand the modification better I think I have also had a change of heart in the usefulness of moving it into NormalizeResultSetNode init. DistinctNode makes this modification in its init method and I think that it makes sense for NormalizeResultSetNode to do the same thing. I am attaching a patch deryby-3494_remove_genNormalizeResultSetNode_diff.txt which is the same as the patch I attached to derby-3310 except for some additional comments. I would like it to be considered for commit. > Move the setup of NormalizeResultSetNode into the NormalizeResultSetNode > > > Key: DERBY-3494 > URL: https://issues.apache.org/jira/browse/DERBY-3494 > Project: Derby > Issue Type: Improvement > Components: SQL >Affects Versions: 10.4.0.0 >Reporter: Kathey Marsden >Priority: Minor > Attachments: d3494_npe_writeup.html, d3494_npe_writeup.html, > decompile.out, derby-3494_remove_genNormalizeResultSetNode_diff.txt, npe.sql > > > In DERBY-3310 Dan suggested ... > Setting up a NormalizeResultSetNode is spread over three locations, the class > itself (very little, it's almost acting like a C struct), > the genNormalizeResultSetNode method and then copyLengthsAndTypesToSource. A > good O-O implementation would have > the logic to create a NormalizeResultSetNode self-contained in > NormalizeResultSetNode. > Since the ResultColumnList of the original ResultSetNode correctly describes > the desired outcome, it's not clear to > me why NormalizeResultSetNode can't just refer to the same list and use it > for its processing. They may be some chance > that this would cause recursion at some point, where a NormalizeResultSetNode > would think it needed to be wrapped > in a NormalizeResultSetNode since the types of its columns and expression > don't match (i.e. when it is handled as a regular ResultSetNode). > I think moving the setup of a NormalizeResultSetNode into the class itself, > so that its inputs are just the ResultSetNode to wrap > would help clear up the code, especially if comments were added indicating > why certain actions were being taken. > I am separating this task out into a separate issue, so that it can be worked > on independently of DERBY-3310. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3523) sql states (X0Y63, X0Y63, X0Y63.S) related to nulls in unique constraints are associated with wrong message texts
[ https://issues.apache.org/jira/browse/DERBY-3523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Matrigali updated DERBY-3523: -- thanks for everyone's input on this, I didn't realize we had this flexibility with the messages so now definitely don't think we should create new states for these messsages. Given the existing support seems like best solution would be to return same error number but different message. I will leave it to Anurag whether to inline the code that figures out which message, or to create a utility routine somewhere. > sql states (X0Y63, X0Y63, X0Y63.S) related to nulls in unique constraints are > associated with wrong message texts > -- > > Key: DERBY-3523 > URL: https://issues.apache.org/jira/browse/DERBY-3523 > Project: Derby > Issue Type: Bug >Affects Versions: 10.4.0.0, 10.5.0.0 >Reporter: Anurag Shekhar >Assignee: Anurag Shekhar > > There are three messages which after Derby-3330 checkin now giving wrong > information. These are > 42831:'{0}' cannot be a column of a primary key or unique key because it can > contain null values. > 42Z20:Column '{0}' cannot be made nullable. It is part of a primary key or > unique constraint, which cannot have any null able columns. > X0Y63.S:The command on table '{0}' failed because null data was found in the > primary key or unique constraint/index column(s). All columns in a primary or > unique index key must not be null. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Preparing to cut the 10.4 branch
[EMAIL PROTECTED] wrote: They all seem like bug fixes that would need to be merged to the new branch so unless I hear otherwise, I plan to cut the branch(es) from revision 635183. Can you confirm that 635183 was the revision base for the branch? Thanks, Dan.
[jira] Updated: (DERBY-3491) Change SystemPermission to be a two arguement permission with a name (object the permission is on) and an action.
[ https://issues.apache.org/jira/browse/DERBY-3491?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel John Debrunner updated DERBY-3491: - Derby Info: (was: [Patch Available]) Assignee: Daniel John Debrunner Patch applied revision 636435 with minor javadoc updates of "name" to "target-name" > Change SystemPermission to be a two arguement permission with a name (object > the permission is on) and an action. > - > > Key: DERBY-3491 > URL: https://issues.apache.org/jira/browse/DERBY-3491 > Project: Derby > Issue Type: Improvement > Components: Security >Reporter: Daniel John Debrunner >Assignee: Daniel John Debrunner > Attachments: d3491_v01_diff.txt > > > With the additional system permissions proposed in DERBY-3462 I wonder if it > makes sense to change the style of names & actions in SystemPermission. > Today a "shutdown" name is proposed and potential for future "shutdownEngine" > and "shutdownServer" with no actions. > DERBY-3462 is proposing names of jmxControl, serverControl, engineControl etc > also with no actions. > Looking at the standard Permission class it seems the name is meant to > represent an object that the permission applies to and action represent > actions on that object. > Thus it would seem to make more sense and be consistent with other > Permissions to have: > name=server action=control | monitor | shutdown > name=engine action=control | monitor | shutdown > name=jmx action=control -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (DERBY-3525) Remove unneeded code to get JDBC level in BrokeredConnection and BrokeredStatement classes
[ https://issues.apache.org/jira/browse/DERBY-3525?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden reassigned DERBY-3525: - Assignee: Kathey Marsden > Remove unneeded code to get JDBC level in BrokeredConnection and > BrokeredStatement classes > -- > > Key: DERBY-3525 > URL: https://issues.apache.org/jira/browse/DERBY-3525 > Project: Derby > Issue Type: Improvement > Components: JDBC >Affects Versions: 10.5.0.0 >Reporter: Knut Anders Hatlen >Assignee: Kathey Marsden >Priority: Minor > > BrokeredConnection has a method called getJDBCLevel() whose only purpose is > to provide a value that can be stored in BrokeredStatement.jdbcLevel. This > field is only used once, in BrokeredStatement.createDuplicateStatement(): > if (jdbcLevel == 2) > newStatement = conn.createStatement(resultSetType, > resultSetConcurrency); > else > newStatement = conn.createStatement(resultSetType, > resultSetConcurrency, > resultSetHoldability); > Since getJDBCLevel() only returns 2 if Java version 1.3 is used, and Derby > doesn't support Java 1.3 any more, BrokeredConnection.getJDBCLevel() and > BrokeredStatement.jdbcLevel could be removed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3525) Remove unneeded code to get JDBC level in BrokeredConnection and BrokeredStatement classes
[ https://issues.apache.org/jira/browse/DERBY-3525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12577956#action_12577956 ] Kathey Marsden commented on DERBY-3525: --- Should we just get rid of BrokeredConnection30 too? > Remove unneeded code to get JDBC level in BrokeredConnection and > BrokeredStatement classes > -- > > Key: DERBY-3525 > URL: https://issues.apache.org/jira/browse/DERBY-3525 > Project: Derby > Issue Type: Improvement > Components: JDBC >Affects Versions: 10.5.0.0 >Reporter: Knut Anders Hatlen >Assignee: Kathey Marsden >Priority: Minor > > BrokeredConnection has a method called getJDBCLevel() whose only purpose is > to provide a value that can be stored in BrokeredStatement.jdbcLevel. This > field is only used once, in BrokeredStatement.createDuplicateStatement(): > if (jdbcLevel == 2) > newStatement = conn.createStatement(resultSetType, > resultSetConcurrency); > else > newStatement = conn.createStatement(resultSetType, > resultSetConcurrency, > resultSetHoldability); > Since getJDBCLevel() only returns 2 if Java version 1.3 is used, and Derby > doesn't support Java 1.3 any more, BrokeredConnection.getJDBCLevel() and > BrokeredStatement.jdbcLevel could be removed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3525) Remove unneeded code to get JDBC level in BrokeredConnection and BrokeredStatement classes
[ https://issues.apache.org/jira/browse/DERBY-3525?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-3525: -- Attachment: derby-3525_diff.txt Attached is a patch for getting rid of jdbcLevel. It keeps BrokeredConnection30 for now. I ran the xa tests. I'll run the full suite. > Remove unneeded code to get JDBC level in BrokeredConnection and > BrokeredStatement classes > -- > > Key: DERBY-3525 > URL: https://issues.apache.org/jira/browse/DERBY-3525 > Project: Derby > Issue Type: Improvement > Components: JDBC >Affects Versions: 10.5.0.0 >Reporter: Knut Anders Hatlen >Assignee: Kathey Marsden >Priority: Minor > Attachments: derby-3525_diff.txt > > > BrokeredConnection has a method called getJDBCLevel() whose only purpose is > to provide a value that can be stored in BrokeredStatement.jdbcLevel. This > field is only used once, in BrokeredStatement.createDuplicateStatement(): > if (jdbcLevel == 2) > newStatement = conn.createStatement(resultSetType, > resultSetConcurrency); > else > newStatement = conn.createStatement(resultSetType, > resultSetConcurrency, > resultSetHoldability); > Since getJDBCLevel() only returns 2 if Java version 1.3 is used, and Derby > doesn't support Java 1.3 any more, BrokeredConnection.getJDBCLevel() and > BrokeredStatement.jdbcLevel could be removed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Latest javadoc not on web-site
The last update to the javadoc on the web-site seems to be 22-Feb-2008. http://db.apache.org/derby/javadoc/publishedapi/ I know there was an issue with javadoc creation, but I thought it was fixed. Where can I look to see what's failing, I couldn't quickly find any explanation of how this javadoc appears. Dan.
[jira] Updated: (DERBY-3310) ASSERT in MergeSort.checkColumnTypes() disallow legal type conversions
[ https://issues.apache.org/jira/browse/DERBY-3310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-3310: -- Attachment: derby-3310_diff.txt Attached is a revision of the try1 patch (derby-3310_diff.txt) that adds some comments to the changed method. Since Army confirmed that this change the right thing to do, I would like to commit this patch to get rid of this regression for 10.4. I welcome comments on the comments and the patch. Ultimately with DERBY-3494 I would like to try to roll this method into NormalizeResultSetNode, but for this fix I think it best not to combine it with code reorg. > ASSERT in MergeSort.checkColumnTypes() disallow legal type conversions > -- > > Key: DERBY-3310 > URL: https://issues.apache.org/jira/browse/DERBY-3310 > Project: Derby > Issue Type: Bug > Components: SQL >Affects Versions: 10.4.0.0 >Reporter: Dyre Tjeldvoll >Priority: Minor > Attachments: cast-repro.sql, d3310_writeup_1.html, > derby-3310_diff.txt, derby-3310_remove_genNormalizeResultSetNode_diff.txt, > derby-3310_try1_diff.txt, derby3310_rsn_cleanup_1.txt > > > The following code > CREATE TABLE U (SNAME VARCHAR(32000), TNAME VARCHAR(32000), C1 BIGINT); > -- This triggers an ASSERT (because 2 is INTEGER and not BIGINT) > INSERT INTO U(SNAME, TNAME, C1) SELECT DISTINCT SCHEMANAME, TABLENAME, 2 > FROM SYS.SYSTABLES T JOIN SYS.SYSSCHEMAS S ON T.SCHEMAID = S.SCHEMAID; > gives > ERROR XJ001: Java exception: 'ASSERT FAILED col1.getClass() (class > org.apache.derby.iapi.types.SQLInteger) expected to be the same as > col2.getClass() (class org.apache.derby.iapi.types.SQLLongint): > org.apache.derby.shared.common.sanity.AssertFailure'. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Latest javadoc not on web-site
Daniel John Debrunner wrote: The last update to the javadoc on the web-site seems to be 22-Feb-2008. http://db.apache.org/derby/javadoc/publishedapi/ I know there was an issue with javadoc creation, but I thought it was fixed. Where can I look to see what's failing, I couldn't quickly find any explanation of how this javadoc appears. John mentioned that the documentation on the web site did not seem to get updated after one of his doc fixes was checked in... Could these things be related? Don't remember the Jira number right now. Dyre
[jira] Updated: (DERBY-3310) ASSERT in MergeSort.checkColumnTypes() disallow legal type conversions
[ https://issues.apache.org/jira/browse/DERBY-3310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-3310: -- Derby Info: [Patch Available, Regression] (was: [Regression]) > ASSERT in MergeSort.checkColumnTypes() disallow legal type conversions > -- > > Key: DERBY-3310 > URL: https://issues.apache.org/jira/browse/DERBY-3310 > Project: Derby > Issue Type: Bug > Components: SQL >Affects Versions: 10.4.0.0 >Reporter: Dyre Tjeldvoll >Priority: Minor > Attachments: cast-repro.sql, d3310_writeup_1.html, > derby-3310_diff.txt, derby-3310_remove_genNormalizeResultSetNode_diff.txt, > derby-3310_try1_diff.txt, derby3310_rsn_cleanup_1.txt > > > The following code > CREATE TABLE U (SNAME VARCHAR(32000), TNAME VARCHAR(32000), C1 BIGINT); > -- This triggers an ASSERT (because 2 is INTEGER and not BIGINT) > INSERT INTO U(SNAME, TNAME, C1) SELECT DISTINCT SCHEMANAME, TABLENAME, 2 > FROM SYS.SYSTABLES T JOIN SYS.SYSSCHEMAS S ON T.SCHEMAID = S.SCHEMAID; > gives > ERROR XJ001: Java exception: 'ASSERT FAILED col1.getClass() (class > org.apache.derby.iapi.types.SQLInteger) expected to be the same as > col2.getClass() (class org.apache.derby.iapi.types.SQLLongint): > org.apache.derby.shared.common.sanity.AssertFailure'. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3310) ASSERT in MergeSort.checkColumnTypes() disallow legal type conversions
[ https://issues.apache.org/jira/browse/DERBY-3310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-3310: -- Attachment: derby-3310_diff.txt had an extraneous file in the diff > ASSERT in MergeSort.checkColumnTypes() disallow legal type conversions > -- > > Key: DERBY-3310 > URL: https://issues.apache.org/jira/browse/DERBY-3310 > Project: Derby > Issue Type: Bug > Components: SQL >Affects Versions: 10.4.0.0 >Reporter: Dyre Tjeldvoll >Priority: Minor > Attachments: cast-repro.sql, d3310_writeup_1.html, > derby-3310_diff.txt, derby-3310_diff.txt, > derby-3310_remove_genNormalizeResultSetNode_diff.txt, > derby-3310_try1_diff.txt, derby3310_rsn_cleanup_1.txt > > > The following code > CREATE TABLE U (SNAME VARCHAR(32000), TNAME VARCHAR(32000), C1 BIGINT); > -- This triggers an ASSERT (because 2 is INTEGER and not BIGINT) > INSERT INTO U(SNAME, TNAME, C1) SELECT DISTINCT SCHEMANAME, TABLENAME, 2 > FROM SYS.SYSTABLES T JOIN SYS.SYSSCHEMAS S ON T.SCHEMAID = S.SCHEMAID; > gives > ERROR XJ001: Java exception: 'ASSERT FAILED col1.getClass() (class > org.apache.derby.iapi.types.SQLInteger) expected to be the same as > col2.getClass() (class org.apache.derby.iapi.types.SQLLongint): > org.apache.derby.shared.common.sanity.AssertFailure'. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (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?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12577982#action_12577982 ] Daniel John Debrunner commented on DERBY-3445: -- When running junit-single, if the test fails the build is successful, it should fail. > Make it easier to use the EMMA tool to measure the code coverage of the Derby > testing > - > > Key: DERBY-3445 > URL: https://issues.apache.org/jira/browse/DERBY-3445 > Project: Derby > Issue Type: Improvement > Components: Build tools >Reporter: Vemund Østgaard >Assignee: Vemund Østgaard > Attachments: 3445-emma-clean-fix-diff, 3445-general-diff, > 3445-general-diffv2, 3445-singletest-codeline-jars-diff, > 3445-singletest-diff, 3445-SysinfoLocaleTest-diff, 3445-testspecific-diff, > 3445-testspecific-diffv2 > > > It is a bit tricky to use EMMA to measure code coverage for the derby testing. > Modifications must be made to the source both to avoid problems with the > SecurityManager and individual tests. It would be good if these modifcations > could be done once and for all so that it was easier for anyone to run the > tests with EMMA. > It would also be good to have ant tasks that would make it even easier to run > the tests with EMMA. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
HTML reports now available for any ant junit test run
I made a simple change to build.xml to separate out the junit HTML report generation from junitreport which always ran junit-all. The new target junit-html can be included as the last target in any junit ant run to produce an HTML report of all the tests run in that ant invocation. E.g. ant junit-clean junit-system-mini-codeline-jars junit-html The HTML report is much easier to read and find the issues than the XML files. For me the report transformation that Derby does always fails, see DERBY-2234 but the HTML report is generated correctly. Ie. it's readable but doesn't include the Derby post-report formatting. See: http://wiki.apache.org/db-derby/DerbyTopLevelJunitTests#head-208e7a618585ecea93f5cfb35d85e78dd71bca60 Dan.
Re: Latest javadoc not on web-site
On Wed, Mar 12, 2008 at 12:03 PM, Dyre Tjeldvoll <[EMAIL PROTECTED]> wrote: > > Daniel John Debrunner wrote: > > The last update to the javadoc on the web-site seems to be 22-Feb-2008. > > > > http://db.apache.org/derby/javadoc/publishedapi/ > > > > I know there was an issue with javadoc creation, but I thought it was > > fixed. > > > > Where can I look to see what's failing, I couldn't quickly find any > > explanation of how this javadoc appears. I've been copying the doc builds with a scheduled process on a machine of mine to people.apache.org using scp. It would be hard to share failure information publicly because it would mean copying it off the private machine, and if it's the copy process itself that is broken then that's not really possible. :-) I suppose an improvement here would be to have a scheduled process that check timestamps on the files on people and sends mail if they're out of date by a week. But a better solution would be for the DB project to get a Solaris Zone on zones.apache.org and then we could do the doc build and push to the website from there, and the process would be accessible and maintainable by all the Derby committers. Alas, DB has no zone. I've suggested that we get one before, as it would be useful for other things like automated build and push of the website. I don't have time to chase down the details of creating a zone right now, but I'll help out in some way if I can. An interested party should look here: http://www.apache.org/dev/solaris-zones.html I thought it used to require involvement from infra and a PMC vote, etc., but it looks like that has changed. It now looks like Jean, as PMC Chair, may have the necessary karma to just go create one, although she should probably still get the rest of the PMC and infrastructure involved first. > John mentioned that the documentation on the web site did not seem to > get updated after one of his doc fixes was checked in... Could these > things be related? Don't remember the Jira number right now. I'm not sure what was wrong with the javadoc copy, I've kicked off the javadoc copy by hand and it seems to be running fine. I'll keep an eye on it. I'm still investigating, but the doc copy looks like some sort of permissions problem due to a recent restore of people.a.o from backup. I'll send a followup mail once I have it figured out. andrew
Re: Latest javadoc not on web-site
Andrew McIntyre wrote: On Wed, Mar 12, 2008 at 12:03 PM, Dyre Tjeldvoll <[EMAIL PROTECTED]> wrote: Daniel John Debrunner wrote: > The last update to the javadoc on the web-site seems to be 22-Feb-2008. > > http://db.apache.org/derby/javadoc/publishedapi/ > > I know there was an issue with javadoc creation, but I thought it was > fixed. > > Where can I look to see what's failing, I couldn't quickly find any > explanation of how this javadoc appears. I've been copying the doc builds with a scheduled process on a machine of mine to people.apache.org using scp. It would be hard to share failure information publicly because it would mean copying it off the private machine, and if it's the copy process itself that is broken then that's not really possible. :-) I suppose an improvement here would be to have a scheduled process that check timestamps on the files on people and sends mail if they're out of date by a week. But a better solution would be for the DB project to get a Solaris Zone on zones.apache.org and then we could do the doc build and push to the website from there, and the process would be accessible and maintainable by all the Derby committers. Alas, DB has no zone. I've suggested that we get one before, as it would be useful for other things like automated build and push of the website. I don't have time to chase down the details of creating a zone right now, but I'll help out in some way if I can. An interested party should look here: http://www.apache.org/dev/solaris-zones.html I thought it used to require involvement from infra and a PMC vote, etc., but it looks like that has changed. It now looks like Jean, as PMC Chair, may have the necessary karma to just go create one, although she should probably still get the rest of the PMC and infrastructure involved first. FWIW, I think that both Kristian and Knut (and possibly others too) are seasoned zones administrators on their Solaris desktops, and I'm sure they would be more than willing to help out with the technical aspect, if required... Dyre
Re: Latest javadoc not on web-site
Andrew McIntyre wrote: On Wed, Mar 12, 2008 at 12:03 PM, Dyre Tjeldvoll <[EMAIL PROTECTED]> wrote: Daniel John Debrunner wrote: > The last update to the javadoc on the web-site seems to be 22-Feb-2008. > > http://db.apache.org/derby/javadoc/publishedapi/ > > I know there was an issue with javadoc creation, but I thought it was > fixed. > > Where can I look to see what's failing, I couldn't quickly find any > explanation of how this javadoc appears. I've been copying the doc builds with a scheduled process on a machine of mine to people.apache.org using scp. It would be hard to share failure information publicly because it would mean copying it off the private machine, and if it's the copy process itself that is broken then that's not really possible. :-) I think we need to move away from this model, having an individual updating the Derby web-site in a manner that's impossible for other community members to get involved to fix or improve it. Having ones own setup and pointing to it from the Derby site (like the Sun & IBM test runs) seems ok, on-site content seems not. The solaris zones sound like the best approach. Dan.
[jira] Commented: (DERBY-3448) Allow the MailJdbc system test to run under junit.
[ https://issues.apache.org/jira/browse/DERBY-3448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12578034#action_12578034 ] Kathey Marsden commented on DERBY-3448: --- Hi Manjula, I took a quick look at your patch. It looks ok to me except there seem to be some indentation issues spaces vs tabs, that you can see by looking at the diff in a text editor. I had one question. The rollback exceptions that are now being thrown, will they get logged somewhere or will we just rely on what's in the derby.log? Kathey > Allow the MailJdbc system test to run under junit. > -- > > Key: DERBY-3448 > URL: https://issues.apache.org/jira/browse/DERBY-3448 > Project: Derby > Issue Type: Improvement > Components: Test >Reporter: Daniel John Debrunner >Assignee: Manjula Kutty >Priority: Minor > Attachments: DERBY-3448_diff.txt_02_26_ver2.txt, > DERBY-3448_diff_02_26.txt, DERBY-3448_diff_02_27.txt, > DERBY-3448_stat_02_26.txt, derby_3448_dbtasks_cleanup.txt > > > It would be good to get the mailjdbc test to run under junit to allow use of > the utilities there and decorators such as running the test getting all > connections from a data source with a statement caching. > Could still allow the test to run standalone in its current form -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3448) Allow the MailJdbc system test to run under junit.
[ https://issues.apache.org/jira/browse/DERBY-3448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12578057#action_12578057 ] Manjula Kutty commented on DERBY-3448: -- Thanks for looking in to the patch. Those Roll back exceptions will be in the derby.log and while running the test I would re-direct the output to a file to catch any error message printed on the console. > Allow the MailJdbc system test to run under junit. > -- > > Key: DERBY-3448 > URL: https://issues.apache.org/jira/browse/DERBY-3448 > Project: Derby > Issue Type: Improvement > Components: Test >Reporter: Daniel John Debrunner >Assignee: Manjula Kutty >Priority: Minor > Attachments: DERBY-3448_diff.txt_02_26_ver2.txt, > DERBY-3448_diff_02_26.txt, DERBY-3448_diff_02_27.txt, > DERBY-3448_stat_02_26.txt, derby_3448_dbtasks_cleanup.txt > > > It would be good to get the mailjdbc test to run under junit to allow use of > the utilities there and decorators such as running the test getting all > connections from a data source with a statement caching. > Could still allow the test to run standalone in its current form -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3347) ERROR XSDB3: Container information cannot change once written
[ https://issues.apache.org/jira/browse/DERBY-3347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12578061#action_12578061 ] Kathey Marsden commented on DERBY-3347: --- Bogden, can you try the latest on the 10.3 branch, now that DERBY-3362 has been fixed and see if you still see the problem? > ERROR XSDB3: Container information cannot change once written > - > > Key: DERBY-3347 > URL: https://issues.apache.org/jira/browse/DERBY-3347 > Project: Derby > Issue Type: Bug > Components: Store >Affects Versions: 10.3.1.4, 10.3.2.1 > Environment: Windows 2003 Server > Sun Java 1.6.0_03 >Reporter: Bogdan Calmac >Priority: Critical > > We are using derby as an embedded DB for our data collection server. During > an endurance test when we do around 270 inserts and 9 updates per second, for > about a week, I ocasionally see the error below in the deby log (and nothing > else beside this). > This is a vanilla installation, we run derby embedded with no extra > configuration. I can confirm that there is no memory problem, the heap usage > seems constant over time. > Can somebody provide some more information regarding the effects of this > error? By looking at the stacktrace, it looks like a checkpoint operation is > aborted due to some inconsistency in the internal data structure. If the > error does not repeat immediately, does it mean that the next checkpoint is > successful and there is no data loss? > I can't provide a test case for that, the error happens after about 1-2 day > of running our software. I will rerun the test with the debug jars to capture > the line numbers in the stacktrace. Also, I'm starting another test with > 10.2.2.0, to see if this problem was introduced in the latest version. > There are another two bugs referring to this error, > (https://issues.apache.org/jira/browse/DERBY-2284 and > https://issues.apache.org/jira/browse/DERBY-3087) but they seem to happen in > response to some client action. This use case is a bit different, the client > keeps inserting and updating records for several days in a steady manner and > at some point the error pops up. > And lastly, here is the exception: > Checkpoint Daemon caught standard exception > BEGIN ERROR STACK - > ERROR XSDB3: Container information cannot change once written: was 0, now 80 > at org.apache.derby.iapi.error.StandardException.newException(Unknown > Source) > at > org.apache.derby.impl.store.raw.data.AllocPage.WriteContainerInfo(Unknown > Source) > at > org.apache.derby.impl.store.raw.data.FileContainer.writeHeader(Unknown Source) > at > org.apache.derby.impl.store.raw.data.RAFContainer.writeRAFHeader(Unknown > Source) > at org.apache.derby.impl.store.raw.data.RAFContainer.clean(Unknown > Source) > at org.apache.derby.impl.services.cache.CachedItem.clean(Unknown Source) > at org.apache.derby.impl.services.cache.Clock.cleanCache(Unknown Source) > at org.apache.derby.impl.services.cache.Clock.cleanAll(Unknown Source) > at > org.apache.derby.impl.store.raw.data.BaseDataFileFactory.checkpoint(Unknown > Source) > at > org.apache.derby.impl.store.raw.log.LogToFile.checkpointWithTran(Unknown > Source) > at org.apache.derby.impl.store.raw.log.LogToFile.checkpoint(Unknown > Source) > at org.apache.derby.impl.store.raw.RawStore.checkpoint(Unknown Source) > at org.apache.derby.impl.store.raw.log.LogToFile.performWork(Unknown > Source) > at > org.apache.derby.impl.services.daemon.BasicDaemon.serviceClient(Unknown > Source) > at org.apache.derby.impl.services.daemon.BasicDaemon.work(Unknown > Source) > at org.apache.derby.impl.services.daemon.BasicDaemon.run(Unknown Source) > at java.lang.Thread.run(Thread.java:619) > END ERROR STACK - -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3347) ERROR XSDB3: Container information cannot change once written
[ https://issues.apache.org/jira/browse/DERBY-3347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12578065#action_12578065 ] Bogdan Calmac commented on DERBY-3347: -- Sure, I can try it. But do you think the comment above is valid? To me, the stacktrace does not look similar to DERBY-3362. > ERROR XSDB3: Container information cannot change once written > - > > Key: DERBY-3347 > URL: https://issues.apache.org/jira/browse/DERBY-3347 > Project: Derby > Issue Type: Bug > Components: Store >Affects Versions: 10.3.1.4, 10.3.2.1 > Environment: Windows 2003 Server > Sun Java 1.6.0_03 >Reporter: Bogdan Calmac >Priority: Critical > > We are using derby as an embedded DB for our data collection server. During > an endurance test when we do around 270 inserts and 9 updates per second, for > about a week, I ocasionally see the error below in the deby log (and nothing > else beside this). > This is a vanilla installation, we run derby embedded with no extra > configuration. I can confirm that there is no memory problem, the heap usage > seems constant over time. > Can somebody provide some more information regarding the effects of this > error? By looking at the stacktrace, it looks like a checkpoint operation is > aborted due to some inconsistency in the internal data structure. If the > error does not repeat immediately, does it mean that the next checkpoint is > successful and there is no data loss? > I can't provide a test case for that, the error happens after about 1-2 day > of running our software. I will rerun the test with the debug jars to capture > the line numbers in the stacktrace. Also, I'm starting another test with > 10.2.2.0, to see if this problem was introduced in the latest version. > There are another two bugs referring to this error, > (https://issues.apache.org/jira/browse/DERBY-2284 and > https://issues.apache.org/jira/browse/DERBY-3087) but they seem to happen in > response to some client action. This use case is a bit different, the client > keeps inserting and updating records for several days in a steady manner and > at some point the error pops up. > And lastly, here is the exception: > Checkpoint Daemon caught standard exception > BEGIN ERROR STACK - > ERROR XSDB3: Container information cannot change once written: was 0, now 80 > at org.apache.derby.iapi.error.StandardException.newException(Unknown > Source) > at > org.apache.derby.impl.store.raw.data.AllocPage.WriteContainerInfo(Unknown > Source) > at > org.apache.derby.impl.store.raw.data.FileContainer.writeHeader(Unknown Source) > at > org.apache.derby.impl.store.raw.data.RAFContainer.writeRAFHeader(Unknown > Source) > at org.apache.derby.impl.store.raw.data.RAFContainer.clean(Unknown > Source) > at org.apache.derby.impl.services.cache.CachedItem.clean(Unknown Source) > at org.apache.derby.impl.services.cache.Clock.cleanCache(Unknown Source) > at org.apache.derby.impl.services.cache.Clock.cleanAll(Unknown Source) > at > org.apache.derby.impl.store.raw.data.BaseDataFileFactory.checkpoint(Unknown > Source) > at > org.apache.derby.impl.store.raw.log.LogToFile.checkpointWithTran(Unknown > Source) > at org.apache.derby.impl.store.raw.log.LogToFile.checkpoint(Unknown > Source) > at org.apache.derby.impl.store.raw.RawStore.checkpoint(Unknown Source) > at org.apache.derby.impl.store.raw.log.LogToFile.performWork(Unknown > Source) > at > org.apache.derby.impl.services.daemon.BasicDaemon.serviceClient(Unknown > Source) > at org.apache.derby.impl.services.daemon.BasicDaemon.work(Unknown > Source) > at org.apache.derby.impl.services.daemon.BasicDaemon.run(Unknown Source) > at java.lang.Thread.run(Thread.java:619) > END ERROR STACK - -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3347) ERROR XSDB3: Container information cannot change once written
[ https://issues.apache.org/jira/browse/DERBY-3347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bogdan Calmac updated DERBY-3347: - Comment: was deleted > ERROR XSDB3: Container information cannot change once written > - > > Key: DERBY-3347 > URL: https://issues.apache.org/jira/browse/DERBY-3347 > Project: Derby > Issue Type: Bug > Components: Store >Affects Versions: 10.3.1.4, 10.3.2.1 > Environment: Windows 2003 Server > Sun Java 1.6.0_03 >Reporter: Bogdan Calmac >Priority: Critical > > We are using derby as an embedded DB for our data collection server. During > an endurance test when we do around 270 inserts and 9 updates per second, for > about a week, I ocasionally see the error below in the deby log (and nothing > else beside this). > This is a vanilla installation, we run derby embedded with no extra > configuration. I can confirm that there is no memory problem, the heap usage > seems constant over time. > Can somebody provide some more information regarding the effects of this > error? By looking at the stacktrace, it looks like a checkpoint operation is > aborted due to some inconsistency in the internal data structure. If the > error does not repeat immediately, does it mean that the next checkpoint is > successful and there is no data loss? > I can't provide a test case for that, the error happens after about 1-2 day > of running our software. I will rerun the test with the debug jars to capture > the line numbers in the stacktrace. Also, I'm starting another test with > 10.2.2.0, to see if this problem was introduced in the latest version. > There are another two bugs referring to this error, > (https://issues.apache.org/jira/browse/DERBY-2284 and > https://issues.apache.org/jira/browse/DERBY-3087) but they seem to happen in > response to some client action. This use case is a bit different, the client > keeps inserting and updating records for several days in a steady manner and > at some point the error pops up. > And lastly, here is the exception: > Checkpoint Daemon caught standard exception > BEGIN ERROR STACK - > ERROR XSDB3: Container information cannot change once written: was 0, now 80 > at org.apache.derby.iapi.error.StandardException.newException(Unknown > Source) > at > org.apache.derby.impl.store.raw.data.AllocPage.WriteContainerInfo(Unknown > Source) > at > org.apache.derby.impl.store.raw.data.FileContainer.writeHeader(Unknown Source) > at > org.apache.derby.impl.store.raw.data.RAFContainer.writeRAFHeader(Unknown > Source) > at org.apache.derby.impl.store.raw.data.RAFContainer.clean(Unknown > Source) > at org.apache.derby.impl.services.cache.CachedItem.clean(Unknown Source) > at org.apache.derby.impl.services.cache.Clock.cleanCache(Unknown Source) > at org.apache.derby.impl.services.cache.Clock.cleanAll(Unknown Source) > at > org.apache.derby.impl.store.raw.data.BaseDataFileFactory.checkpoint(Unknown > Source) > at > org.apache.derby.impl.store.raw.log.LogToFile.checkpointWithTran(Unknown > Source) > at org.apache.derby.impl.store.raw.log.LogToFile.checkpoint(Unknown > Source) > at org.apache.derby.impl.store.raw.RawStore.checkpoint(Unknown Source) > at org.apache.derby.impl.store.raw.log.LogToFile.performWork(Unknown > Source) > at > org.apache.derby.impl.services.daemon.BasicDaemon.serviceClient(Unknown > Source) > at org.apache.derby.impl.services.daemon.BasicDaemon.work(Unknown > Source) > at org.apache.derby.impl.services.daemon.BasicDaemon.run(Unknown Source) > at java.lang.Thread.run(Thread.java:619) > END ERROR STACK - -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3347) ERROR XSDB3: Container information cannot change once written
[ https://issues.apache.org/jira/browse/DERBY-3347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12578066#action_12578066 ] Bogdan Calmac commented on DERBY-3347: -- Sure, I can try it, but DERBY-3362 has probably nothing to do with the original problem. My comment from Feb 1st refers to another issue that prevented me from running the test. > ERROR XSDB3: Container information cannot change once written > - > > Key: DERBY-3347 > URL: https://issues.apache.org/jira/browse/DERBY-3347 > Project: Derby > Issue Type: Bug > Components: Store >Affects Versions: 10.3.1.4, 10.3.2.1 > Environment: Windows 2003 Server > Sun Java 1.6.0_03 >Reporter: Bogdan Calmac >Priority: Critical > > We are using derby as an embedded DB for our data collection server. During > an endurance test when we do around 270 inserts and 9 updates per second, for > about a week, I ocasionally see the error below in the deby log (and nothing > else beside this). > This is a vanilla installation, we run derby embedded with no extra > configuration. I can confirm that there is no memory problem, the heap usage > seems constant over time. > Can somebody provide some more information regarding the effects of this > error? By looking at the stacktrace, it looks like a checkpoint operation is > aborted due to some inconsistency in the internal data structure. If the > error does not repeat immediately, does it mean that the next checkpoint is > successful and there is no data loss? > I can't provide a test case for that, the error happens after about 1-2 day > of running our software. I will rerun the test with the debug jars to capture > the line numbers in the stacktrace. Also, I'm starting another test with > 10.2.2.0, to see if this problem was introduced in the latest version. > There are another two bugs referring to this error, > (https://issues.apache.org/jira/browse/DERBY-2284 and > https://issues.apache.org/jira/browse/DERBY-3087) but they seem to happen in > response to some client action. This use case is a bit different, the client > keeps inserting and updating records for several days in a steady manner and > at some point the error pops up. > And lastly, here is the exception: > Checkpoint Daemon caught standard exception > BEGIN ERROR STACK - > ERROR XSDB3: Container information cannot change once written: was 0, now 80 > at org.apache.derby.iapi.error.StandardException.newException(Unknown > Source) > at > org.apache.derby.impl.store.raw.data.AllocPage.WriteContainerInfo(Unknown > Source) > at > org.apache.derby.impl.store.raw.data.FileContainer.writeHeader(Unknown Source) > at > org.apache.derby.impl.store.raw.data.RAFContainer.writeRAFHeader(Unknown > Source) > at org.apache.derby.impl.store.raw.data.RAFContainer.clean(Unknown > Source) > at org.apache.derby.impl.services.cache.CachedItem.clean(Unknown Source) > at org.apache.derby.impl.services.cache.Clock.cleanCache(Unknown Source) > at org.apache.derby.impl.services.cache.Clock.cleanAll(Unknown Source) > at > org.apache.derby.impl.store.raw.data.BaseDataFileFactory.checkpoint(Unknown > Source) > at > org.apache.derby.impl.store.raw.log.LogToFile.checkpointWithTran(Unknown > Source) > at org.apache.derby.impl.store.raw.log.LogToFile.checkpoint(Unknown > Source) > at org.apache.derby.impl.store.raw.RawStore.checkpoint(Unknown Source) > at org.apache.derby.impl.store.raw.log.LogToFile.performWork(Unknown > Source) > at > org.apache.derby.impl.services.daemon.BasicDaemon.serviceClient(Unknown > Source) > at org.apache.derby.impl.services.daemon.BasicDaemon.work(Unknown > Source) > at org.apache.derby.impl.services.daemon.BasicDaemon.run(Unknown Source) > at java.lang.Thread.run(Thread.java:619) > END ERROR STACK - -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3347) ERROR XSDB3: Container information cannot change once written
[ https://issues.apache.org/jira/browse/DERBY-3347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12578068#action_12578068 ] Bogdan Calmac commented on DERBY-3347: -- Would it be valuable to still disable NIO at code level or should I use the unmodified 10.3 branch? > ERROR XSDB3: Container information cannot change once written > - > > Key: DERBY-3347 > URL: https://issues.apache.org/jira/browse/DERBY-3347 > Project: Derby > Issue Type: Bug > Components: Store >Affects Versions: 10.3.1.4, 10.3.2.1 > Environment: Windows 2003 Server > Sun Java 1.6.0_03 >Reporter: Bogdan Calmac >Priority: Critical > > We are using derby as an embedded DB for our data collection server. During > an endurance test when we do around 270 inserts and 9 updates per second, for > about a week, I ocasionally see the error below in the deby log (and nothing > else beside this). > This is a vanilla installation, we run derby embedded with no extra > configuration. I can confirm that there is no memory problem, the heap usage > seems constant over time. > Can somebody provide some more information regarding the effects of this > error? By looking at the stacktrace, it looks like a checkpoint operation is > aborted due to some inconsistency in the internal data structure. If the > error does not repeat immediately, does it mean that the next checkpoint is > successful and there is no data loss? > I can't provide a test case for that, the error happens after about 1-2 day > of running our software. I will rerun the test with the debug jars to capture > the line numbers in the stacktrace. Also, I'm starting another test with > 10.2.2.0, to see if this problem was introduced in the latest version. > There are another two bugs referring to this error, > (https://issues.apache.org/jira/browse/DERBY-2284 and > https://issues.apache.org/jira/browse/DERBY-3087) but they seem to happen in > response to some client action. This use case is a bit different, the client > keeps inserting and updating records for several days in a steady manner and > at some point the error pops up. > And lastly, here is the exception: > Checkpoint Daemon caught standard exception > BEGIN ERROR STACK - > ERROR XSDB3: Container information cannot change once written: was 0, now 80 > at org.apache.derby.iapi.error.StandardException.newException(Unknown > Source) > at > org.apache.derby.impl.store.raw.data.AllocPage.WriteContainerInfo(Unknown > Source) > at > org.apache.derby.impl.store.raw.data.FileContainer.writeHeader(Unknown Source) > at > org.apache.derby.impl.store.raw.data.RAFContainer.writeRAFHeader(Unknown > Source) > at org.apache.derby.impl.store.raw.data.RAFContainer.clean(Unknown > Source) > at org.apache.derby.impl.services.cache.CachedItem.clean(Unknown Source) > at org.apache.derby.impl.services.cache.Clock.cleanCache(Unknown Source) > at org.apache.derby.impl.services.cache.Clock.cleanAll(Unknown Source) > at > org.apache.derby.impl.store.raw.data.BaseDataFileFactory.checkpoint(Unknown > Source) > at > org.apache.derby.impl.store.raw.log.LogToFile.checkpointWithTran(Unknown > Source) > at org.apache.derby.impl.store.raw.log.LogToFile.checkpoint(Unknown > Source) > at org.apache.derby.impl.store.raw.RawStore.checkpoint(Unknown Source) > at org.apache.derby.impl.store.raw.log.LogToFile.performWork(Unknown > Source) > at > org.apache.derby.impl.services.daemon.BasicDaemon.serviceClient(Unknown > Source) > at org.apache.derby.impl.services.daemon.BasicDaemon.work(Unknown > Source) > at org.apache.derby.impl.services.daemon.BasicDaemon.run(Unknown Source) > at java.lang.Thread.run(Thread.java:619) > END ERROR STACK - -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3347) ERROR XSDB3: Container information cannot change once written
[ https://issues.apache.org/jira/browse/DERBY-3347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12578070#action_12578070 ] Kathey Marsden commented on DERBY-3347: --- I think it would be valuable to try with NIO disabled. As I understand it you were blocked from doing that experiment because of DERBY-3362 > ERROR XSDB3: Container information cannot change once written > - > > Key: DERBY-3347 > URL: https://issues.apache.org/jira/browse/DERBY-3347 > Project: Derby > Issue Type: Bug > Components: Store >Affects Versions: 10.3.1.4, 10.3.2.1 > Environment: Windows 2003 Server > Sun Java 1.6.0_03 >Reporter: Bogdan Calmac >Priority: Critical > > We are using derby as an embedded DB for our data collection server. During > an endurance test when we do around 270 inserts and 9 updates per second, for > about a week, I ocasionally see the error below in the deby log (and nothing > else beside this). > This is a vanilla installation, we run derby embedded with no extra > configuration. I can confirm that there is no memory problem, the heap usage > seems constant over time. > Can somebody provide some more information regarding the effects of this > error? By looking at the stacktrace, it looks like a checkpoint operation is > aborted due to some inconsistency in the internal data structure. If the > error does not repeat immediately, does it mean that the next checkpoint is > successful and there is no data loss? > I can't provide a test case for that, the error happens after about 1-2 day > of running our software. I will rerun the test with the debug jars to capture > the line numbers in the stacktrace. Also, I'm starting another test with > 10.2.2.0, to see if this problem was introduced in the latest version. > There are another two bugs referring to this error, > (https://issues.apache.org/jira/browse/DERBY-2284 and > https://issues.apache.org/jira/browse/DERBY-3087) but they seem to happen in > response to some client action. This use case is a bit different, the client > keeps inserting and updating records for several days in a steady manner and > at some point the error pops up. > And lastly, here is the exception: > Checkpoint Daemon caught standard exception > BEGIN ERROR STACK - > ERROR XSDB3: Container information cannot change once written: was 0, now 80 > at org.apache.derby.iapi.error.StandardException.newException(Unknown > Source) > at > org.apache.derby.impl.store.raw.data.AllocPage.WriteContainerInfo(Unknown > Source) > at > org.apache.derby.impl.store.raw.data.FileContainer.writeHeader(Unknown Source) > at > org.apache.derby.impl.store.raw.data.RAFContainer.writeRAFHeader(Unknown > Source) > at org.apache.derby.impl.store.raw.data.RAFContainer.clean(Unknown > Source) > at org.apache.derby.impl.services.cache.CachedItem.clean(Unknown Source) > at org.apache.derby.impl.services.cache.Clock.cleanCache(Unknown Source) > at org.apache.derby.impl.services.cache.Clock.cleanAll(Unknown Source) > at > org.apache.derby.impl.store.raw.data.BaseDataFileFactory.checkpoint(Unknown > Source) > at > org.apache.derby.impl.store.raw.log.LogToFile.checkpointWithTran(Unknown > Source) > at org.apache.derby.impl.store.raw.log.LogToFile.checkpoint(Unknown > Source) > at org.apache.derby.impl.store.raw.RawStore.checkpoint(Unknown Source) > at org.apache.derby.impl.store.raw.log.LogToFile.performWork(Unknown > Source) > at > org.apache.derby.impl.services.daemon.BasicDaemon.serviceClient(Unknown > Source) > at org.apache.derby.impl.services.daemon.BasicDaemon.work(Unknown > Source) > at org.apache.derby.impl.services.daemon.BasicDaemon.run(Unknown Source) > at java.lang.Thread.run(Thread.java:619) > END ERROR STACK - -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
10.4 bug fixing
Now that feature freeze is behind us, it would be great to spend a few weeks attending to the bug backlog. If every developer took just a couple bugs, we could hopefully get the list back down below 300 (assuming we don't find too many more). Below are some links that you might find helpful in your search for bugs to fix. Derby open code bugs: (331) https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&&type=1&pid=10594&status=1&status=3&status=4&component=11407&component=12312171&component=11409&component=11690&component=11410&component=11709&component=12312050&component=11411&component=11415&component=11408&component=11412&component=11414&sorter/field=issuekey&sorter/order=DESC Derby Open Product Regressions (16) https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&&pid=10594&resolution=-1&customfield_12310090=Regression&sorter/field=issuekey&sorter/order=ASC&sorter/field=updated&sorter/order=DESC&sorter/field=priority&sorter/order=DESC High Value Fix Candidates http://wiki.apache.org/db-derby/HighValueFixCandidates First Release Candidate is 2008-04-04, so there is enough but not much time. Please pick up a bug today! Also let me know if you have any ideas to make the bug drive more fun and successful. Did folks like the contests or is it better just to stick with informal peer pressure? Kathey
[jira] Commented: (DERBY-3347) ERROR XSDB3: Container information cannot change once written
[ https://issues.apache.org/jira/browse/DERBY-3347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12578075#action_12578075 ] Bogdan Calmac commented on DERBY-3347: -- Yes, that is correct. OK. > ERROR XSDB3: Container information cannot change once written > - > > Key: DERBY-3347 > URL: https://issues.apache.org/jira/browse/DERBY-3347 > Project: Derby > Issue Type: Bug > Components: Store >Affects Versions: 10.3.1.4, 10.3.2.1 > Environment: Windows 2003 Server > Sun Java 1.6.0_03 >Reporter: Bogdan Calmac >Priority: Critical > > We are using derby as an embedded DB for our data collection server. During > an endurance test when we do around 270 inserts and 9 updates per second, for > about a week, I ocasionally see the error below in the deby log (and nothing > else beside this). > This is a vanilla installation, we run derby embedded with no extra > configuration. I can confirm that there is no memory problem, the heap usage > seems constant over time. > Can somebody provide some more information regarding the effects of this > error? By looking at the stacktrace, it looks like a checkpoint operation is > aborted due to some inconsistency in the internal data structure. If the > error does not repeat immediately, does it mean that the next checkpoint is > successful and there is no data loss? > I can't provide a test case for that, the error happens after about 1-2 day > of running our software. I will rerun the test with the debug jars to capture > the line numbers in the stacktrace. Also, I'm starting another test with > 10.2.2.0, to see if this problem was introduced in the latest version. > There are another two bugs referring to this error, > (https://issues.apache.org/jira/browse/DERBY-2284 and > https://issues.apache.org/jira/browse/DERBY-3087) but they seem to happen in > response to some client action. This use case is a bit different, the client > keeps inserting and updating records for several days in a steady manner and > at some point the error pops up. > And lastly, here is the exception: > Checkpoint Daemon caught standard exception > BEGIN ERROR STACK - > ERROR XSDB3: Container information cannot change once written: was 0, now 80 > at org.apache.derby.iapi.error.StandardException.newException(Unknown > Source) > at > org.apache.derby.impl.store.raw.data.AllocPage.WriteContainerInfo(Unknown > Source) > at > org.apache.derby.impl.store.raw.data.FileContainer.writeHeader(Unknown Source) > at > org.apache.derby.impl.store.raw.data.RAFContainer.writeRAFHeader(Unknown > Source) > at org.apache.derby.impl.store.raw.data.RAFContainer.clean(Unknown > Source) > at org.apache.derby.impl.services.cache.CachedItem.clean(Unknown Source) > at org.apache.derby.impl.services.cache.Clock.cleanCache(Unknown Source) > at org.apache.derby.impl.services.cache.Clock.cleanAll(Unknown Source) > at > org.apache.derby.impl.store.raw.data.BaseDataFileFactory.checkpoint(Unknown > Source) > at > org.apache.derby.impl.store.raw.log.LogToFile.checkpointWithTran(Unknown > Source) > at org.apache.derby.impl.store.raw.log.LogToFile.checkpoint(Unknown > Source) > at org.apache.derby.impl.store.raw.RawStore.checkpoint(Unknown Source) > at org.apache.derby.impl.store.raw.log.LogToFile.performWork(Unknown > Source) > at > org.apache.derby.impl.services.daemon.BasicDaemon.serviceClient(Unknown > Source) > at org.apache.derby.impl.services.daemon.BasicDaemon.work(Unknown > Source) > at org.apache.derby.impl.services.daemon.BasicDaemon.run(Unknown Source) > at java.lang.Thread.run(Thread.java:619) > END ERROR STACK - -- 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-3341) TABLE FUNCTION returning CHAR values does not return a correct value if the Java ResultSet class returns a value less than the length of the defined CHAR.
[ https://issues.apache.org/jira/browse/DERBY-3341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12578083#action_12578083 ] army edited comment on DERBY-3341 at 3/12/08 4:49 PM: - I saw two failures when running suites.All with weme6.1 last night, both in TableFunctionTest with similar diffs. Ex: noSpecialCollation(o.a.dTesting.functionTests.tests.lang.TableFunctionTest)java.sql.SQLException: An attempt was made to get a data value of type 'java.lang.Object' from a data value of type 'DECIMAL'. at o.a.d.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown Source) at o.a.d.impl.jdbc.Util.generateCsSQLException(Unknown Source) at o.a.d.impl.jdbc.TransactionResourceImpl.wrapInSQLException(Unknown Source) at o.a.d.impl.jdbc.TransactionResourceImpl.handleException(Unknown Source) at o.a.d.impl.jdbc.EmbedConnection.handleException(Unknown Source) at o.a.d.impl.jdbc.ConnectionChild.handleException(Unknown Source) at o.a.d.impl.jdbc.EmbedResultSet.closeOnTransactionError(Unknown Source) at o.a.d.impl.jdbc.EmbedResultSet.movePosition(Unknown Source) at o.a.d.impl.jdbc.EmbedResultSet.next(Unknown Source) at o.a.dTesting.functionTests.tests.lang.TableFunctionTest.assertResults(TableFunctionTest.java:1935) at o.a.dTesting.functionTests.tests.lang.TableFunctionTest.assertResults(TableFunctionTest.java:1776) at o.a.dTesting.functionTests.tests.lang.TableFunctionTest.assertResults(TableFunctionTest.java:1762) at o.a.dTesting.functionTests.tests.lang.TableFunctionTest.allLegalDatatypesVTIResults(TableFunctionTest.java:1178) at o.a.dTesting.functionTests.tests.lang.TableFunctionTest.tableFunctionTest(TableFunctionTest.java:921) at o.a.dTesting.functionTests.tests.lang.TableFunctionTest.noSpecialCollation(TableFunctionTest.java:897) at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:205) at o.a.dTesting.junit.BaseTestCase.runBare(BaseTestCase.java:101) Caused by: ERROR 22005: An attempt was made to get a data value of type 'java.lang.Object' from a data value of type 'DECIMAL'. at o.a.d.iapi.error.StandardException.newException(Unknown Source) at o.a.d.iapi.types.DataType.dataTypeConversion(Unknown Source) at o.a.d.iapi.types.DataType.getObject(Unknown Source) at o.a.d.impl.sql.execute.VTIResultSet.cast(Unknown Source) at o.a.d.impl.sql.execute.VTIResultSet.populateFromResultSet(Unknown Source) at o.a.d.impl.sql.execute.VTIResultSet.getNextRowCore(Unknown Source) at o.a.d.impl.sql.execute.BasicNoPutResultSetImpl.getNextRow(Unknown Source) The other failure was the "specialCollation()" fixture. I'm guessing you're not running tests with weme6.1, but any chance you might be able identify the cause? Or should I file a separate issue? was (Author: army): I saw two failures when running suites.All with weme6.1 last night, both in TableTestFunction with similar diffs. Ex: noSpecialCollation(o.a.dTesting.functionTests.tests.lang.TableFunctionTest)java.sql.SQLException: An attempt was made to get a data value of type 'java.lang.Object' from a data value of type 'DECIMAL'. at o.a.d.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown Source) at o.a.d.impl.jdbc.Util.generateCsSQLException(Unknown Source) at o.a.d.impl.jdbc.TransactionResourceImpl.wrapInSQLException(Unknown Source) at o.a.d.impl.jdbc.TransactionResourceImpl.handleException(Unknown Source) at o.a.d.impl.jdbc.EmbedConnection.handleException(Unknown Source) at o.a.d.impl.jdbc.ConnectionChild.handleException(Unknown Source) at o.a.d.impl.jdbc.EmbedResultSet.closeOnTransactionError(Unknown Source) at o.a.d.impl.jdbc.EmbedResultSet.movePosition(Unknown Source) at o.a.d.impl.jdbc.EmbedResultSet.next(Unknown Source) at o.a.dTesting.functionTests.tests.lang.TableFunctionTest.assertResults(TableFunctionTest.java:1935) at o.a.dTesting.functionTests.tests.lang.TableFunctionTest.assertResults(TableFunctionTest.java:1776) at o.a.dTesting.functionTests.tests.lang.TableFunctionTest.assertResults(TableFunctionTest.java:1762) at o.a.dTesting.functionTests.tests.lang.TableFunctionTest.allLegalDatatypesVTIResults(TableFunctionTest.java:1178) at o.a.dTesting.functionTests.tests.lang.TableFunctionTest.tableFunctionTest(TableFunctionTest.java:921) at o.a.dTesting.functionTests.tests.lang.TableFunctionTest.noSpecialCollation(TableFunctionTest.java:897) at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:205) at o.a.dTesting.junit.BaseTestCase.runBare(BaseTestCase.java:101) Caused by: ERROR 22005: An attempt was made to get a data value of type 'java.lang.Object' from a data value of type 'DECIMAL'. at o.a.d.iapi.error.StandardException.newException(Unknown Source) at o.a.d.iapi.types.DataType.dataTypeConversion(Unknown Source) at o.a.d.iapi.types.DataType.getObject(Unknown Source) at o.a.d.impl.sql.execute.VTIResultSet.cast(Unknown Source) at o.a.d.impl.sql.execute.VTIResu
[jira] Commented: (DERBY-3341) TABLE FUNCTION returning CHAR values does not return a correct value if the Java ResultSet class returns a value less than the length of the defined CHAR.
[ https://issues.apache.org/jira/browse/DERBY-3341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12578083#action_12578083 ] A B commented on DERBY-3341: I saw two failures when running suites.All with weme6.1 last night, both in TableTestFunction with similar diffs. Ex: noSpecialCollation(o.a.dTesting.functionTests.tests.lang.TableFunctionTest)java.sql.SQLException: An attempt was made to get a data value of type 'java.lang.Object' from a data value of type 'DECIMAL'. at o.a.d.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown Source) at o.a.d.impl.jdbc.Util.generateCsSQLException(Unknown Source) at o.a.d.impl.jdbc.TransactionResourceImpl.wrapInSQLException(Unknown Source) at o.a.d.impl.jdbc.TransactionResourceImpl.handleException(Unknown Source) at o.a.d.impl.jdbc.EmbedConnection.handleException(Unknown Source) at o.a.d.impl.jdbc.ConnectionChild.handleException(Unknown Source) at o.a.d.impl.jdbc.EmbedResultSet.closeOnTransactionError(Unknown Source) at o.a.d.impl.jdbc.EmbedResultSet.movePosition(Unknown Source) at o.a.d.impl.jdbc.EmbedResultSet.next(Unknown Source) at o.a.dTesting.functionTests.tests.lang.TableFunctionTest.assertResults(TableFunctionTest.java:1935) at o.a.dTesting.functionTests.tests.lang.TableFunctionTest.assertResults(TableFunctionTest.java:1776) at o.a.dTesting.functionTests.tests.lang.TableFunctionTest.assertResults(TableFunctionTest.java:1762) at o.a.dTesting.functionTests.tests.lang.TableFunctionTest.allLegalDatatypesVTIResults(TableFunctionTest.java:1178) at o.a.dTesting.functionTests.tests.lang.TableFunctionTest.tableFunctionTest(TableFunctionTest.java:921) at o.a.dTesting.functionTests.tests.lang.TableFunctionTest.noSpecialCollation(TableFunctionTest.java:897) at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:205) at o.a.dTesting.junit.BaseTestCase.runBare(BaseTestCase.java:101) Caused by: ERROR 22005: An attempt was made to get a data value of type 'java.lang.Object' from a data value of type 'DECIMAL'. at o.a.d.iapi.error.StandardException.newException(Unknown Source) at o.a.d.iapi.types.DataType.dataTypeConversion(Unknown Source) at o.a.d.iapi.types.DataType.getObject(Unknown Source) at o.a.d.impl.sql.execute.VTIResultSet.cast(Unknown Source) at o.a.d.impl.sql.execute.VTIResultSet.populateFromResultSet(Unknown Source) at o.a.d.impl.sql.execute.VTIResultSet.getNextRowCore(Unknown Source) at o.a.d.impl.sql.execute.BasicNoPutResultSetImpl.getNextRow(Unknown Source) The other failure was the "specialCollation()" fixture. I'm guessing you're not running tests with weme6.1, but any chance you might be able identify the cause? Or should I file a separate issue? > TABLE FUNCTION returning CHAR values does not return a correct value if the > Java ResultSet class returns a value less than the length of the defined CHAR. > -- > > Key: DERBY-3341 > URL: https://issues.apache.org/jira/browse/DERBY-3341 > Project: Derby > Issue Type: Bug > Components: SQL >Reporter: Daniel John Debrunner > Fix For: 10.4.0.0 > > Attachments: derby-3341-01-coerce.diff, > derby-3341-01-da-coerceWithTests.diff, derby-3341-02-aa-refGuide.diff, > derby_3341_test.txt, rrefcreatefunctionstatement.html > > > Defining a column in the returned type as CHAR(10) requires that the returned > value be of length 10 characters. > Defining a table function with a return type of: >returns TABLE column0 char( 10 ), column1 char( 10 )) > seems to just return whatever the Java ResultSet implementation handed it. > My guess this is true for all variable length types, no casting of the value > occurs when it is returned to the SQL domain. > Java single value functions and procedure out parameters do perform any > required casting to ensure the value is of the declared type. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2351) ORDER BY with expression with distinct in the select list returns incorrect result
[ https://issues.apache.org/jira/browse/DERBY-2351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12578124#action_12578124 ] Bryan Pendleton commented on DERBY-2351: Thanks Army and Thomas for the continued help! I re-worked modifySynonymResult.diff slightly to incorporate Army's suggestions and committed it to the trunk as revision 636608. If no additional problems arise with this patch in the trunk, I'll investigate merging back to the 10.4 branch. > ORDER BY with expression with distinct in the select list returns incorrect > result > -- > > Key: DERBY-2351 > URL: https://issues.apache.org/jira/browse/DERBY-2351 > Project: Derby > Issue Type: Bug > Components: SQL >Affects Versions: 10.2.1.6, 10.2.2.0, 10.3.1.4 > Environment: Any >Reporter: Yip Ng >Assignee: Bryan Pendleton > Fix For: 10.3.2.2, 10.4.0.0 > > Attachments: d2351_aliasing.diff, d2351_aliasing.diff, > d2351_aliasing_checkQualifiedName.diff, derby_2351.diff, derby_2351_v2.diff, > modifySynonymResults.diff, reproTests.diff > > > When distinct is in the select list and the query has order by with > expression, the resultset produced contains an additional column. > ij> create table t1 (c1 int, c2 varchar(10)) > 0 rows inserted/updated/deleted > ij> insert into t1 values (1,'a'),(2,'b'),(3,'c'); > 3 rows inserted/updated/deleted > select distinct c1, c2 from t1 order by c1; > C1 |C2 > -- > 1 |a > 2 |b > 3 |c > 3 rows selected > ij> select distinct c1, c2 from t1 order by c1+1; > C1 |C2|3 <=returns 3 > columns, incorrect result returned > -- > 1 |a |2 > 2 |b |3 > 3 |c |4 > 3 rows selected -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Merging fixes to 10.4
Hi all, I was just wondering where we're at with the 10.4 branch. Specifically, is the community currently merging bug fixes from the trunk to 10.4, or are we holding off because 10.4 branch is still being set up? thanks, bryan
[jira] Updated: (DERBY-3373) SQL "distinct" and "order by" needed together
[ https://issues.apache.org/jira/browse/DERBY-3373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Pendleton updated DERBY-3373: --- Attachment: mergeWith2351.diff Attached is 'mergeWith2351.diff', an update of the previous patch proposal which resolves the file conflicts with the DERBY-2351 patch. > SQL "distinct" and "order by" needed together > - > > Key: DERBY-3373 > URL: https://issues.apache.org/jira/browse/DERBY-3373 > Project: Derby > Issue Type: Bug > Components: SQL >Affects Versions: 10.3.2.1 > Environment: Solaris Dev Express, Java 5 >Reporter: Thomas Vatter >Assignee: Bryan Pendleton >Priority: Blocker > Fix For: 10.3.2.2 > > Attachments: allowExpressions.diff, mergeWith2351.diff > > > I am pasting here the communication from the mailinglist. I am having a > blocking and large problem with it because I have to make a release that > needs the specified SQL query. > tom_ wrote: > > The errormessage is > > > > The ORDER BY clause may not specify an expression, since the query > > specifies > > DISTINCT > > [Error Code: 2] > > [SQL State: 4287A] > > > > The statement is > > > > select distinct > > t1.t1_id, t2.t2value1, t2.t2value2, t2.t2value3 > > from > > t1, t2, t3 > > where > > ... > > order by lower(t2.t2value2) , lower(t2.t2value1) , lower(t2.t2value3) > > > > > > > > > > Dyre.Tjeldvoll wrote: > > > >> tom_ <[EMAIL PROTECTED]> writes: > >> > >> > >>> I am using "disctinct" because of some self-joins and also needed to add > >>> an > >>> "order by" clause. An error is shown. Is it not possible to use distinct > >>> and > >>> order by together? > >>> > >> I think it is allowed. Executing > >> > >> select distinct * from sys.systables order by tablename; > >> > >> in ij works just fine. Could you show the error message you get, and > >> perhaps what the table looks like? > >> > >> -- > >> dt > >> > >> > >> > « [hide part of quote] > Hi Tom - > I see what you mean using the demo DB toursDB: > ij> select * from airlines order by lower(airline_full); > A&|AIRLINE_FULL|BASIC_RATE|DISTANCE_DISCOUNT > |BUSINESS_LEVEL_FACTOR > |FIRSTCLASS_LEVEL_FACT&|ECONOMY_SE&|BUSINESS_S&|FIRSTCLASS& > --- > > AA|Amazonian Airways |0.18 |0.03 > |0.5 |1.5 |20 |10 |5 > US|Union Standard Airlines |0.19 |0.05 > |0.4 |1.6 |20 |10 |5 > 2 rows selected > ij> select distinct * from airlines order by lower(airline_full); > ERROR 4287A: The ORDER BY clause may not specify an expression, since > the query specifies DISTINCT. > ij> select distinct airline_full from airlines order by lower(airline_full); > ERROR 4287A: The ORDER BY clause may not specify an expression, since > the query specifies DISTINCT. > ij> > I didn't find a JIRA enhancement to remove this restriction. I suggest > you file an Enhancement request to remove the restriction reported by > ERROR 4287A. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Merging fixes to 10.4
Bryan Pendleton wrote: Hi all, I was just wondering where we're at with the 10.4 branch. Specifically, is the community currently merging bug fixes from the trunk to 10.4, or are we holding off because 10.4 branch is still being set up? I think it's ok to merge changes to 10.4, I've seen a couple of fixes go in that were not from the release manager. Dan.
[jira] Commented: (DERBY-3525) Remove unneeded code to get JDBC level in BrokeredConnection and BrokeredStatement classes
[ https://issues.apache.org/jira/browse/DERBY-3525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12578137#action_12578137 ] V.Narayanan commented on DERBY-3525: I think it would be OK to move BrokeredConnection30 to the base class BrokeredConnection since support for java 1.3 is not there anymore. But I guess this change will cascade down to other 30 classes too which I think would be out of scope for this issue and should maybe done in another JIRA. For now I think the patch attached to get rid of jdbcLevel should suffice. > Remove unneeded code to get JDBC level in BrokeredConnection and > BrokeredStatement classes > -- > > Key: DERBY-3525 > URL: https://issues.apache.org/jira/browse/DERBY-3525 > Project: Derby > Issue Type: Improvement > Components: JDBC >Affects Versions: 10.5.0.0 >Reporter: Knut Anders Hatlen >Assignee: Kathey Marsden >Priority: Minor > Attachments: derby-3525_diff.txt > > > BrokeredConnection has a method called getJDBCLevel() whose only purpose is > to provide a value that can be stored in BrokeredStatement.jdbcLevel. This > field is only used once, in BrokeredStatement.createDuplicateStatement(): > if (jdbcLevel == 2) > newStatement = conn.createStatement(resultSetType, > resultSetConcurrency); > else > newStatement = conn.createStatement(resultSetType, > resultSetConcurrency, > resultSetHoldability); > Since getJDBCLevel() only returns 2 if Java version 1.3 is used, and Derby > doesn't support Java 1.3 any more, BrokeredConnection.getJDBCLevel() and > BrokeredStatement.jdbcLevel could be removed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3526) AsynchronousLogShipper#workToDo is blocked while the log shipper sends a log chunk
[ https://issues.apache.org/jira/browse/DERBY-3526?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12578138#action_12578138 ] V.Narayanan commented on DERBY-3526: Good catch Jorgen! Thank you for raising this JIRA. I am confused about having to use different monitors for log shipment and for waiting between log shipment. I am more confused because the javadoc for notify says this "This method should only be called by a thread that is the owner of this object's monitor." So would it be right to use two monitors one to run the thread to do the log shipping and another to wait and notify this same thread. I am not arguing against the scenario raised, I think the JIRA is a fantastic catch. > AsynchronousLogShipper#workToDo is blocked while the log shipper sends a log > chunk > -- > > Key: DERBY-3526 > URL: https://issues.apache.org/jira/browse/DERBY-3526 > Project: Derby > Issue Type: Bug > Components: Replication >Affects Versions: 10.4.0.0, 10.5.0.0 >Reporter: Jørgen Løland > > The replication log shipper thread synchronizes on 'this' both when shipping > log records (shipALogChunk) and when it waits between log shipments. > Transaction threads may try to wake up the log shipper because log has > arrived that should be shipped (i.e., through the method workToDo). These > threads should not have to wait for the monitor if the log shipper is > currently busy shipping log. The solution is to have two monitors - one for > log shipment and one for waiting between log shipment. > This may seem like a minor issue, but if the TCP connection between master > and slave is lost e.g. because a network cable has been unplugged, the log > shipper will block for 2 minutes on ObjectOutputStream#writeObject. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3526) AsynchronousLogShipper#workToDo is blocked while the log shipper sends a log chunk
[ https://issues.apache.org/jira/browse/DERBY-3526?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12578155#action_12578155 ] Øystein Grøvlen commented on DERBY-3526: To use another monitor you will have to use another object to synchronize on. Hence instead of: synchronized(this) { wait(); } you will do: synchronized(obj) { obj.wait(); } > AsynchronousLogShipper#workToDo is blocked while the log shipper sends a log > chunk > -- > > Key: DERBY-3526 > URL: https://issues.apache.org/jira/browse/DERBY-3526 > Project: Derby > Issue Type: Bug > Components: Replication >Affects Versions: 10.4.0.0, 10.5.0.0 >Reporter: Jørgen Løland > > The replication log shipper thread synchronizes on 'this' both when shipping > log records (shipALogChunk) and when it waits between log shipments. > Transaction threads may try to wake up the log shipper because log has > arrived that should be shipped (i.e., through the method workToDo). These > threads should not have to wait for the monitor if the log shipper is > currently busy shipping log. The solution is to have two monitors - one for > log shipment and one for waiting between log shipment. > This may seem like a minor issue, but if the TCP connection between master > and slave is lost e.g. because a network cable has been unplugged, the log > shipper will block for 2 minutes on ObjectOutputStream#writeObject. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3526) AsynchronousLogShipper#workToDo is blocked while the log shipper sends a log chunk
[ https://issues.apache.org/jira/browse/DERBY-3526?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12578161#action_12578161 ] V.Narayanan commented on DERBY-3526: > To use another monitor you will have to use another object to synchronize on. > Hence instead of: Ah! Use a different object into whose waiting pool the log shipping thread will be put in waiting mode. so calling a notify will release this thread and it will start performing log shipping. If the thread is already shipping log the waiting pool will be empty and notify has no work. In both cases the workToDo method returns immediately. So we are basically not using the current object for doing, log shipping and waiting, and, notifying the log shipping thread simultaneously. I guess that is what is meant by "Transaction threads may try to wake up the log shipper because log has arrived that should be shipped (i.e., through the method workToDo). These threads should not have to wait for the monitor if the log shipper is currently busy shipping log. The solution is to have two monitors - one for log shipment and one for waiting between log shipment. " Got it < The incandescent lamp inside Narayanan's head starts burning brightly :-D > Great! Thanks Oystein and Jorgen :) . And once more fantastic catch. > AsynchronousLogShipper#workToDo is blocked while the log shipper sends a log > chunk > -- > > Key: DERBY-3526 > URL: https://issues.apache.org/jira/browse/DERBY-3526 > Project: Derby > Issue Type: Bug > Components: Replication >Affects Versions: 10.4.0.0, 10.5.0.0 >Reporter: Jørgen Løland > > The replication log shipper thread synchronizes on 'this' both when shipping > log records (shipALogChunk) and when it waits between log shipments. > Transaction threads may try to wake up the log shipper because log has > arrived that should be shipped (i.e., through the method workToDo). These > threads should not have to wait for the monitor if the log shipper is > currently busy shipping log. The solution is to have two monitors - one for > log shipment and one for waiting between log shipment. > This may seem like a minor issue, but if the TCP connection between master > and slave is lost e.g. because a network cable has been unplugged, the log > shipper will block for 2 minutes on ObjectOutputStream#writeObject. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (DERBY-3526) AsynchronousLogShipper#workToDo is blocked while the log shipper sends a log chunk
[ https://issues.apache.org/jira/browse/DERBY-3526?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] V.Narayanan reassigned DERBY-3526: -- Assignee: V.Narayanan > AsynchronousLogShipper#workToDo is blocked while the log shipper sends a log > chunk > -- > > Key: DERBY-3526 > URL: https://issues.apache.org/jira/browse/DERBY-3526 > Project: Derby > Issue Type: Bug > Components: Replication >Affects Versions: 10.4.0.0, 10.5.0.0 >Reporter: Jørgen Løland >Assignee: V.Narayanan > > The replication log shipper thread synchronizes on 'this' both when shipping > log records (shipALogChunk) and when it waits between log shipments. > Transaction threads may try to wake up the log shipper because log has > arrived that should be shipped (i.e., through the method workToDo). These > threads should not have to wait for the monitor if the log shipper is > currently busy shipping log. The solution is to have two monitors - one for > log shipment and one for waiting between log shipment. > This may seem like a minor issue, but if the TCP connection between master > and slave is lost e.g. because a network cable has been unplugged, the log > shipper will block for 2 minutes on ObjectOutputStream#writeObject. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.