date:20080312


[ 
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

2008-03-12 Thread Anurag Shekhar

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

2008-03-12 Thread Narayanan

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

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:

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

2008-03-12 Thread Dyre . Tjeldvoll

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

2008-03-12 Thread Knut Anders Hatlen

[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

2008-03-12 Thread Kristian Waagan (JIRA)


[ 
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

2008-03-12 Thread Kristian Waagan (JIRA)


 [ 
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

2008-03-12 Thread Kristian Waagan (JIRA)


 [ 
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

2008-03-12 Thread Henri van de Scheur

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.

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


[ 
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

2008-03-12 Thread Henri van de Scheur

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

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


[ 
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

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


[ 
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

2008-03-12 Thread jira

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

2008-03-12 Thread Anurag Shekhar (JIRA)


[ 
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