[jira] Commented: (DERBY-3541) quit; on ij with authentication enabled does not shutdown the derby modules that are loaded
[ https://issues.apache.org/jira/browse/DERBY-3541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12729545#action_12729545 ] V.Narayanan commented on DERBY-3541: Oystein says: "2. Somehow fix the case with authentication so that the database is shut down. (I am not sure how)" Although he does mean that it is difficult to shutdown the database when authentication is enabled (the same way shutdown is done when authentication is not enabled) he does not mean this is not a bug. Like in my comments before, ij is a generic jdbc front end tool, I am not happy with a derby specific call here at all. Ideally speaking you should be capable of using ij with any DB that supports a jdbc driver. If everyone agrees we can probably document that we need to shutdown DB's before quitting and prevent ij from going down without closing the DB's. That would be one probable solution. But again I am not sure I will be happy with such a crude fix. Here is my 2 paisa :) (IJ is a simple and elegant tool. There is a innocent simplicity to the tool that I would never want it to lose. If a user wants a sophisticated front end there are other options. We should not clutter ij unnecessarily.) > quit; on ij with authentication enabled does not shutdown the derby modules > that are loaded > --- > > Key: DERBY-3541 > URL: https://issues.apache.org/jira/browse/DERBY-3541 > Project: Derby > Issue Type: Bug > Components: Tools >Affects Versions: 10.4.1.3 >Reporter: V.Narayanan >Priority: Minor > Attachments: derby.properties, PrintStackTrace.diff, > WithoutAuthentication_StackTrace.txt > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3541) quit; on ij with authentication enabled does not shutdown the derby modules that are loaded
[ https://issues.apache.org/jira/browse/DERBY-3541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12729072#action_12729072 ] V.Narayanan commented on DERBY-3541: Thank you for trying out the reproducible. when you said "I can not reproduce this bug." did you mean that the modules are currently being closed? Are you sure that TopService#shutdown() is now being called with authentication enabled? > quit; on ij with authentication enabled does not shutdown the derby modules > that are loaded > --- > > Key: DERBY-3541 > URL: https://issues.apache.org/jira/browse/DERBY-3541 > Project: Derby > Issue Type: Bug > Components: Tools >Affects Versions: 10.4.1.3 >Reporter: V.Narayanan >Priority: Minor > Attachments: derby.properties, PrintStackTrace.diff, > WithoutAuthentication_StackTrace.txt > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (DERBY-3417) slave side stop in a client server mode results in SQLState printed without proper error message
[ https://issues.apache.org/jira/browse/DERBY-3417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] V.Narayanan closed DERBY-3417. -- Thank you for the backport Dag! Closing Issue! > slave side stop in a client server mode results in SQLState printed without > proper error message > > > Key: DERBY-3417 > URL: https://issues.apache.org/jira/browse/DERBY-3417 > Project: Derby > Issue Type: Bug > Components: Replication >Affects Versions: 10.4.1.3 >Reporter: V.Narayanan >Assignee: Dag H. Wanvik > Fix For: 10.5.1.2, 10.6.0.0 > > Attachments: derby-3417-2.diff, derby-3417-2.stat, derby-3417.diff, > derby-3417.stat > > > I tried a stopSlave on the slave side of the replication system and > found the below > ij> connect 'jdbc:derby://localhost:1528/replicationdb;stopSlave=true'; > ERROR XRE41: DERBY SQL error: SQLCODE: -1, SQLSTATE: XRE41, SQLERRMC: XRE41 > https://issues.apache.org/jira/browse/DERBY-3205 says > ERROR XRE41: Replication operation 'failover' or 'stopSlave' failed because > the connection with the master is working. Issue the 'failover' or > 'stopMaster' operation on the master database instead. > needs to be printed. > I am not sure if this is a generic case for client server replication > messages. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3896) Assert failure in LogicalUndoOperation.doMe() when starting slave with uncommitted transactions on the master
[ https://issues.apache.org/jira/browse/DERBY-3896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12698680#action_12698680 ] V.Narayanan commented on DERBY-3896: The decision on when to log ship, is taken everytime a log buffer element becomes full. When a log buffer element becomes full, this event is communicated to the log shipper via the master controller. The log shipper then takes a decision based on the fill information obtained from the log buffer I think Knut is right in saying that log shipping does not happen when the freeze happens, but I am not sure it is related to the log switch not happening. I think I am going to try triggering the log shipping inside freezePersistentStore() of LogToFile and see what happens! > Assert failure in LogicalUndoOperation.doMe() when starting slave with > uncommitted transactions on the master > - > > Key: DERBY-3896 > URL: https://issues.apache.org/jira/browse/DERBY-3896 > Project: Derby > Issue Type: Bug > Components: Replication >Affects Versions: 10.4.1.3, 10.5.0.0 > Environment: Solaris Express Community Edition snv_99 X86 > Derby trunk, svn revision 701061, sane build > java version "1.6.0_07" > Java(TM) Platform, Standard Edition for Business (build 1.6.0_07-b06) > Java HotSpot(TM) Server VM (build 10.0-b23, mixed mode) >Reporter: Knut Anders Hatlen > > I created and froze the master database like this: > /tmp/master % java -jar /code/derby/trunk1/jars/sane/derbyrun.jar ij > ij version 10.5 > ij> connect 'jdbc:derby:db;create=true'; > ij> autocommit off; > ij> create table t1(x int); > 0 rows inserted/updated/deleted > ij> insert into t1 values 1,2,3,4; > 4 rows inserted/updated/deleted > ij> connect 'jdbc:derby:db'; > ij(CONNECTION1)> call syscs_util.syscs_freeze_database(); > 0 rows inserted/updated/deleted > ij(CONNECTION1)> > Then in another terminal window I copied the database with "cp -rp" and > booted the copy as a slave: > /tmp/slave % java -jar /code/derby/trunk1/jars/sane/derbyrun.jar ij > ij version 10.5 > ij> connect 'jdbc:derby:db;startSlave=true'; > org.apache.derby.shared.common.sanity.AssertFailure: ASSERT FAILED > at > org.apache.derby.shared.common.sanity.SanityManager.ASSERT(SanityManager.java:98) > at > org.apache.derby.impl.store.raw.data.LogicalUndoOperation.doMe(LogicalUndoOperation.java:174) > at > org.apache.derby.impl.store.raw.log.FileLogger.logAndUndo(FileLogger.java:533) > at org.apache.derby.impl.store.raw.xact.Xact.logAndUndo(Xact.java:374) > at > org.apache.derby.impl.store.raw.log.FileLogger.undo(FileLogger.java:1015) > at org.apache.derby.impl.store.raw.xact.Xact.abort(Xact.java:949) > at > org.apache.derby.impl.store.raw.xact.XactFactory.rollbackAllTransactions(XactFactory.java:529) > at > org.apache.derby.impl.store.raw.log.LogToFile.recover(LogToFile.java:1213) > at org.apache.derby.impl.store.raw.RawStore.boot(RawStore.java:334) > at > org.apache.derby.impl.services.monitor.BaseMonitor.boot(BaseMonitor.java:2019) > at > org.apache.derby.impl.services.monitor.TopService.bootModule(TopService.java:291) > at > org.apache.derby.impl.services.monitor.BaseMonitor.startModule(BaseMonitor.java:573) > at > org.apache.derby.iapi.services.monitor.Monitor.bootServiceModule(Monitor.java:427) > at > org.apache.derby.impl.store.access.RAMAccessManager.boot(RAMAccessManager.java:1019) > at > org.apache.derby.impl.services.monitor.BaseMonitor.boot(BaseMonitor.java:2019) > at > org.apache.derby.impl.services.monitor.TopService.bootModule(TopService.java:291) > at > org.apache.derby.impl.services.monitor.BaseMonitor.startModule(BaseMonitor.java:573) > at > org.apache.derby.iapi.services.monitor.Monitor.bootServiceModule(Monitor.java:427) > at > org.apache.derby.impl.db.BasicDatabase.bootStore(BasicDatabase.java:780) > at org.apache.derby.impl.db.BasicDatabase.boot(BasicDatabase.java:196) > at > org.apache.derby.impl.services.monitor.BaseMonitor.boot(BaseMonitor.java:2019) > at > org.apache.derby.impl.services.monitor.TopService.bootModule(TopService.java:291) > at > org.apache.derby.impl.services.monitor.BaseMonitor.bootService(BaseMonitor.java:1856) > at > org.apache.derby.imp
[jira] Commented: (DERBY-3896) Assert failure in LogicalUndoOperation.doMe() when starting slave with uncommitted transactions on the master
[ https://issues.apache.org/jira/browse/DERBY-3896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12698330#action_12698330 ] V.Narayanan commented on DERBY-3896: Knut said: "I think the problem is that if you have uncommitted transactions when you freeze the database, the log file is not switched. so you continue for a while writing to the old log file on the master, but don't ship log to the slave until the log file is actually switched. so you miss the log between freeze and switch on the slave." I will try to look at this bug when I find some time, I will not be working on this issue regularly hence am not assigning it to myself. > Assert failure in LogicalUndoOperation.doMe() when starting slave with > uncommitted transactions on the master > - > > Key: DERBY-3896 > URL: https://issues.apache.org/jira/browse/DERBY-3896 > Project: Derby > Issue Type: Bug > Components: Replication >Affects Versions: 10.4.1.3, 10.5.0.0 > Environment: Solaris Express Community Edition snv_99 X86 > Derby trunk, svn revision 701061, sane build > java version "1.6.0_07" > Java(TM) Platform, Standard Edition for Business (build 1.6.0_07-b06) > Java HotSpot(TM) Server VM (build 10.0-b23, mixed mode) >Reporter: Knut Anders Hatlen > > I created and froze the master database like this: > /tmp/master % java -jar /code/derby/trunk1/jars/sane/derbyrun.jar ij > ij version 10.5 > ij> connect 'jdbc:derby:db;create=true'; > ij> autocommit off; > ij> create table t1(x int); > 0 rows inserted/updated/deleted > ij> insert into t1 values 1,2,3,4; > 4 rows inserted/updated/deleted > ij> connect 'jdbc:derby:db'; > ij(CONNECTION1)> call syscs_util.syscs_freeze_database(); > 0 rows inserted/updated/deleted > ij(CONNECTION1)> > Then in another terminal window I copied the database with "cp -rp" and > booted the copy as a slave: > /tmp/slave % java -jar /code/derby/trunk1/jars/sane/derbyrun.jar ij > ij version 10.5 > ij> connect 'jdbc:derby:db;startSlave=true'; > org.apache.derby.shared.common.sanity.AssertFailure: ASSERT FAILED > at > org.apache.derby.shared.common.sanity.SanityManager.ASSERT(SanityManager.java:98) > at > org.apache.derby.impl.store.raw.data.LogicalUndoOperation.doMe(LogicalUndoOperation.java:174) > at > org.apache.derby.impl.store.raw.log.FileLogger.logAndUndo(FileLogger.java:533) > at org.apache.derby.impl.store.raw.xact.Xact.logAndUndo(Xact.java:374) > at > org.apache.derby.impl.store.raw.log.FileLogger.undo(FileLogger.java:1015) > at org.apache.derby.impl.store.raw.xact.Xact.abort(Xact.java:949) > at > org.apache.derby.impl.store.raw.xact.XactFactory.rollbackAllTransactions(XactFactory.java:529) > at > org.apache.derby.impl.store.raw.log.LogToFile.recover(LogToFile.java:1213) > at org.apache.derby.impl.store.raw.RawStore.boot(RawStore.java:334) > at > org.apache.derby.impl.services.monitor.BaseMonitor.boot(BaseMonitor.java:2019) > at > org.apache.derby.impl.services.monitor.TopService.bootModule(TopService.java:291) > at > org.apache.derby.impl.services.monitor.BaseMonitor.startModule(BaseMonitor.java:573) > at > org.apache.derby.iapi.services.monitor.Monitor.bootServiceModule(Monitor.java:427) > at > org.apache.derby.impl.store.access.RAMAccessManager.boot(RAMAccessManager.java:1019) > at > org.apache.derby.impl.services.monitor.BaseMonitor.boot(BaseMonitor.java:2019) > at > org.apache.derby.impl.services.monitor.TopService.bootModule(TopService.java:291) > at > org.apache.derby.impl.services.monitor.BaseMonitor.startModule(BaseMonitor.java:573) > at > org.apache.derby.iapi.services.monitor.Monitor.bootServiceModule(Monitor.java:427) > at > org.apache.derby.impl.db.BasicDatabase.bootStore(BasicDatabase.java:780) > at org.apache.derby.impl.db.BasicDatabase.boot(BasicDatabase.java:196) > at > org.apache.derby.impl.services.monitor.BaseMonitor.boot(BaseMonitor.java:2019) > at > org.apache.derby.impl.services.monitor.TopService.bootModule(TopService.java:291) > at > org.apache.derby.impl.services.monitor.BaseMonitor.bootService(BaseMonitor.java:1856) > at > org.apache.derby.impl.services.monitor.BaseMonitor.startProviderService(BaseMonitor.java:1722) > a
[jira] Commented: (DERBY-646) In-memory backend storage support
[ https://issues.apache.org/jira/browse/DERBY-646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12676561#action_12676561 ] V.Narayanan commented on DERBY-646: --- can u please assign the issue to your name? Also for major contributions a icla is generally required and this looks like a major feature. my two paisa! > In-memory backend storage support > - > > Key: DERBY-646 > URL: https://issues.apache.org/jira/browse/DERBY-646 > Project: Derby > Issue Type: New Feature > Components: Store > Environment: All >Reporter: Stephen Fitch > Attachments: derby-646-1a-raw-compiles.diff, > derby-646-1a-raw-compiles.stat, derby-646-20090222.diff, > derby-646-20090222.stat, derby-646-2a-vfmem_first_rev.diff, > derby-646-2a-vfmem_first_rev.stat, derby-646-performance_comparison_1a.txt, > svn.diff > > > To allow creation and modification of databases in-memory without requiring > disk access or space to store the database. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (DERBY-2345) truncate on a Blob does not work when the Blob is in memory
[
https://issues.apache.org/jira/browse/DERBY-2345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
V.Narayanan closed DERBY-2345.
--
The final patch has been committed for this issue. Thanks to Anurag and
kristian for the good work!
> truncate on a Blob does not work when the Blob is in memory
> ---
>
> Key: DERBY-2345
> URL: https://issues.apache.org/jira/browse/DERBY-2345
> Project: Derby
> Issue Type: Bug
> Components: JDBC
> Reporter: V.Narayanan
>Assignee: Anurag Shekhar
>Priority: Minor
> Fix For: 10.3.1.4
>
> Attachments: derby-2345.diff
>
>
> I tried the following repro. After calling the truncate the Blob object still
> returns the length as 29 (its original length) .
> import java.sql.*;
> public class TruncateBugRepro {
>
> Connection con = null;
>
> public Connection getEmbeddedConnection() throws Exception {
> if(con == null) {
> Class.forName("org.apache.derby.jdbc.EmbeddedDriver");
> con = DriverManager.getConnection
> ("jdbc:derby:DB1;create=true");
> }
> return con;
> }
>
> public void testTruncate() throws Exception {
> //String used to getBytes from and insert into Blob.
> String str = new String("I am a Blob!!! I am a Blob!!!");
> Connection con = getEmbeddedConnection();
> //create the blob
> Blob blob = con.createBlob();
> //insert bytes
> blob.setBytes(1,str.getBytes());
> //Retuns the Blob length as 29
> System.out.println("" + blob.length());
> blob.truncate(14);
> //returns the Blob length as 29
> System.out.println("" + blob.length());
> }
>
> public static void main(String[] args) throws Exception {
> TruncateBugRepro t = new TruncateBugRepro();
> t.testTruncate();
> }
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2017) Client driver can insert and commit partial data when a LOB stream throws IOException or does not match the specified length
[ https://issues.apache.org/jira/browse/DERBY-2017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12611949#action_12611949 ] V.Narayanan commented on DERBY-2017: One of the solutions proposed in the discussions above is converting Prepared/Callable statements to use locators. Has this solution been rejected? > Client driver can insert and commit partial data when a LOB stream throws > IOException or does not match the specified length > > > Key: DERBY-2017 > URL: https://issues.apache.org/jira/browse/DERBY-2017 > Project: Derby > Issue Type: Bug > Components: JDBC, Network Client >Affects Versions: 10.2.1.6 >Reporter: Knut Anders Hatlen > Attachments: derby2017_try1.diff, Derby_2017_v1.diff, > Derby_2017_v1.stat, StreamErrRepro.java > > > When a LOB stream throws an exception or does not match the specified length, > the client driver does not raise an exception until it has finished executing > the statement. Therefore, the statement will be executed (and possibly > committed) on the server even though the client reports that the statement > failed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-1903) Convert largedata/LobLimits.java to junit
[ https://issues.apache.org/jira/browse/DERBY-1903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12608393#action_12608393 ] V.Narayanan commented on DERBY-1903: Thank you for assigning this to yourself Erlend. Can I pls request you to put in code in small chunks for easy review? (It is a big test) It would be OK even if it is not working code initially. But it would be great to review it in small chunks. > Convert largedata/LobLimits.java to junit > -- > > Key: DERBY-1903 > URL: https://issues.apache.org/jira/browse/DERBY-1903 > Project: Derby > Issue Type: Sub-task > Components: Test > Reporter: V.Narayanan >Assignee: Erlend Birkenes >Priority: Minor > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3709) Exception printed by replication test: Could not perform operation because the database is not in replication master mode.
[ https://issues.apache.org/jira/browse/DERBY-3709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12604200#action_12604200 ] V.Narayanan commented on DERBY-3709: merged with 10.4. The tests in my environment were blubbering incoherently as usual :-/ Sending java/testing/org/apache/derbyTesting/functionTests/tests/replicationTests/ReplicationRun.java Transmitting file data . Committed revision 31. > Exception printed by replication test: Could not perform operation because > the database is not in replication master mode. > -- > > Key: DERBY-3709 > URL: https://issues.apache.org/jira/browse/DERBY-3709 > Project: Derby > Issue Type: Bug > Components: Regression Test Failure, Replication >Affects Versions: 10.4.1.4, 10.5.0.0 > Environment: Java Version:1.6.0_04 > Java Vendor: Sun Microsystems Inc. > OS name: SunOS > OS architecture: x86 > OS version: 5.10 >Reporter: Knut Anders Hatlen >Assignee: Ole Solberg > Attachments: derby-3709_p1-v2.diff.txt, derby-3709_p1.diff.txt > > > I saw the following exception printed when I ran suites.All on trunk > (revision 663064). None of the tests failed. > java.sql.SQLException: DERBY SQL error: SQLCODE: -1, SQLSTATE: XRE07, > SQLERRMC: Could not perform operation because the database is not in > replication master mode. > at > org.apache.derby.client.am.SQLExceptionFactory40.getSQLException(SQLExceptionFactory40.java:96) > at > org.apache.derby.client.am.SqlException.getSQLException(SqlException.java:362) > at org.apache.derby.jdbc.ClientDriver.connect(ClientDriver.java:149) > at java.sql.DriverManager.getConnection(DriverManager.java:582) > at java.sql.DriverManager.getConnection(DriverManager.java:207) > at > org.apache.derbyTesting.functionTests.tests.replicationTests.ReplicationRun.failOver_direct(ReplicationRun.java:1286) > at > org.apache.derbyTesting.functionTests.tests.replicationTests.ReplicationRun.failOver(ReplicationRun.java:1220) > at > org.apache.derbyTesting.functionTests.tests.replicationTests.ReplicationRun_Local.testReplication_Local(ReplicationRun_Local.java:148) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at junit.framework.TestCase.runTest(TestCase.java:164) > at junit.framework.TestCase.runBare(TestCase.java:130) > at > org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:104) > at junit.framework.TestResult$1.protect(TestResult.java:106) > at junit.framework.TestResult.runProtected(TestResult.java:124) > at junit.framework.TestResult.run(TestResult.java:109) > at junit.framework.TestCase.run(TestCase.java:120) > at junit.framework.TestSuite.runTest(TestSuite.java:230) > at junit.framework.TestSuite.run(TestSuite.java:225) > at junit.framework.TestSuite.runTest(TestSuite.java:230) > at junit.framework.TestSuite.run(TestSuite.java:225) > at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) > at junit.extensions.TestSetup$1.protect(TestSetup.java:21) > at junit.framework.TestResult.runProtected(TestResult.java:124) > at junit.extensions.TestSetup.run(TestSetup.java:25) > at junit.framework.TestSuite.runTest(TestSuite.java:230) > at junit.framework.TestSuite.run(TestSuite.java:225) > at junit.framework.TestSuite.runTest(TestSuite.java:230) > at junit.framework.TestSuite.run(TestSuite.java:225) > at junit.textui.TestRunner.doRun(TestRunner.java:121) > at junit.textui.TestRunner.start(TestRunner.java:185) > at junit.textui.TestRunner.main(TestRunner.java:143) > Caused by: org.apache.derby.client.am.SqlException: DERBY SQL error: SQLCODE: > -1, SQLSTATE: XRE07, SQLERRMC: Could not perform operation because the > database is not in replication master mode. > at > org.apache.derby.client.am.Connection.completeSqlca(Connection.java:2068) > at > org.apache.derby.client.net.NetConnectionReply.parseRdbAccessFailed(NetConnectionReply.java:537) > at > org.apache.derby.client.net.NetConnectionReply.parseAccessRdbError(NetConnectionReply.java
[jira] Issue Comment Edited: (DERBY-3709) Exception printed by replication test: Could not perform operation because the database is not in replication master mode.
[ https://issues.apache.org/jira/browse/DERBY-3709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12603802#action_12603802 ] narayanan edited comment on DERBY-3709 at 6/10/08 1:32 AM: - Thank you for the patch Ole I had two unrelated failures while running these tests Sending java/testing/org/apache/derbyTesting/functionTests/tests/replicationTests/ReplicationRun.java Transmitting file data . Committed revision 666006. Will merge it to 10.4 after running tests was (Author: narayanan): Thank you for the patch Ole I had two unrelated failures while running these tests Sending java/testing/org/apache/derbyTesting/functionTests/tests/replicationTests/ReplicationRun.java Transmitting file data . Committed revision 666006. > Exception printed by replication test: Could not perform operation because > the database is not in replication master mode. > -- > > Key: DERBY-3709 > URL: https://issues.apache.org/jira/browse/DERBY-3709 > Project: Derby > Issue Type: Bug > Components: Regression Test Failure, Replication >Affects Versions: 10.4.1.4, 10.5.0.0 > Environment: Java Version:1.6.0_04 > Java Vendor: Sun Microsystems Inc. > OS name: SunOS > OS architecture: x86 > OS version: 5.10 >Reporter: Knut Anders Hatlen >Assignee: Ole Solberg > Attachments: derby-3709_p1-v2.diff.txt, derby-3709_p1.diff.txt > > > I saw the following exception printed when I ran suites.All on trunk > (revision 663064). None of the tests failed. > java.sql.SQLException: DERBY SQL error: SQLCODE: -1, SQLSTATE: XRE07, > SQLERRMC: Could not perform operation because the database is not in > replication master mode. > at > org.apache.derby.client.am.SQLExceptionFactory40.getSQLException(SQLExceptionFactory40.java:96) > at > org.apache.derby.client.am.SqlException.getSQLException(SqlException.java:362) > at org.apache.derby.jdbc.ClientDriver.connect(ClientDriver.java:149) > at java.sql.DriverManager.getConnection(DriverManager.java:582) > at java.sql.DriverManager.getConnection(DriverManager.java:207) > at > org.apache.derbyTesting.functionTests.tests.replicationTests.ReplicationRun.failOver_direct(ReplicationRun.java:1286) > at > org.apache.derbyTesting.functionTests.tests.replicationTests.ReplicationRun.failOver(ReplicationRun.java:1220) > at > org.apache.derbyTesting.functionTests.tests.replicationTests.ReplicationRun_Local.testReplication_Local(ReplicationRun_Local.java:148) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at junit.framework.TestCase.runTest(TestCase.java:164) > at junit.framework.TestCase.runBare(TestCase.java:130) > at > org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:104) > at junit.framework.TestResult$1.protect(TestResult.java:106) > at junit.framework.TestResult.runProtected(TestResult.java:124) > at junit.framework.TestResult.run(TestResult.java:109) > at junit.framework.TestCase.run(TestCase.java:120) > at junit.framework.TestSuite.runTest(TestSuite.java:230) > at junit.framework.TestSuite.run(TestSuite.java:225) > at junit.framework.TestSuite.runTest(TestSuite.java:230) > at junit.framework.TestSuite.run(TestSuite.java:225) > at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) > at junit.extensions.TestSetup$1.protect(TestSetup.java:21) > at junit.framework.TestResult.runProtected(TestResult.java:124) > at junit.extensions.TestSetup.run(TestSetup.java:25) > at junit.framework.TestSuite.runTest(TestSuite.java:230) > at junit.framework.TestSuite.run(TestSuite.java:225) > at junit.framework.TestSuite.runTest(TestSuite.java:230) > at junit.framework.TestSuite.run(TestSuite.java:225) > at junit.textui.TestRunner.doRun(TestRunner.java:121) > at junit.textui.TestRunner.start(TestRunner.java:185) > at junit.textui.TestRunner.main(TestRunner.java:143) > Caused by: org.apache.derby.client.am.SqlException: DERBY SQL error: SQLCODE: > -1, SQLSTATE: XRE07, SQLERRMC: Could not perform operation because the > database is not in replication master mode. > at > org.apache.derby.client.am.Connection.completeSqlca(Connection.java:2068) > at > org.apache.derby.client.net.NetConnectionReply.parseRdbAccessFailed(NetConnectionReply.java:537) >
[jira] Commented: (DERBY-3709) Exception printed by replication test: Could not perform operation because the database is not in replication master mode.
[ https://issues.apache.org/jira/browse/DERBY-3709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12603802#action_12603802 ] V.Narayanan commented on DERBY-3709: Thank you for the patch Ole I had two unrelated failures while running these tests Sending java/testing/org/apache/derbyTesting/functionTests/tests/replicationTests/ReplicationRun.java Transmitting file data . Committed revision 666006. > Exception printed by replication test: Could not perform operation because > the database is not in replication master mode. > -- > > Key: DERBY-3709 > URL: https://issues.apache.org/jira/browse/DERBY-3709 > Project: Derby > Issue Type: Bug > Components: Regression Test Failure, Replication >Affects Versions: 10.4.1.4, 10.5.0.0 > Environment: Java Version:1.6.0_04 > Java Vendor: Sun Microsystems Inc. > OS name: SunOS > OS architecture: x86 > OS version: 5.10 >Reporter: Knut Anders Hatlen >Assignee: Ole Solberg > Attachments: derby-3709_p1-v2.diff.txt, derby-3709_p1.diff.txt > > > I saw the following exception printed when I ran suites.All on trunk > (revision 663064). None of the tests failed. > java.sql.SQLException: DERBY SQL error: SQLCODE: -1, SQLSTATE: XRE07, > SQLERRMC: Could not perform operation because the database is not in > replication master mode. > at > org.apache.derby.client.am.SQLExceptionFactory40.getSQLException(SQLExceptionFactory40.java:96) > at > org.apache.derby.client.am.SqlException.getSQLException(SqlException.java:362) > at org.apache.derby.jdbc.ClientDriver.connect(ClientDriver.java:149) > at java.sql.DriverManager.getConnection(DriverManager.java:582) > at java.sql.DriverManager.getConnection(DriverManager.java:207) > at > org.apache.derbyTesting.functionTests.tests.replicationTests.ReplicationRun.failOver_direct(ReplicationRun.java:1286) > at > org.apache.derbyTesting.functionTests.tests.replicationTests.ReplicationRun.failOver(ReplicationRun.java:1220) > at > org.apache.derbyTesting.functionTests.tests.replicationTests.ReplicationRun_Local.testReplication_Local(ReplicationRun_Local.java:148) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at junit.framework.TestCase.runTest(TestCase.java:164) > at junit.framework.TestCase.runBare(TestCase.java:130) > at > org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:104) > at junit.framework.TestResult$1.protect(TestResult.java:106) > at junit.framework.TestResult.runProtected(TestResult.java:124) > at junit.framework.TestResult.run(TestResult.java:109) > at junit.framework.TestCase.run(TestCase.java:120) > at junit.framework.TestSuite.runTest(TestSuite.java:230) > at junit.framework.TestSuite.run(TestSuite.java:225) > at junit.framework.TestSuite.runTest(TestSuite.java:230) > at junit.framework.TestSuite.run(TestSuite.java:225) > at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) > at junit.extensions.TestSetup$1.protect(TestSetup.java:21) > at junit.framework.TestResult.runProtected(TestResult.java:124) > at junit.extensions.TestSetup.run(TestSetup.java:25) > at junit.framework.TestSuite.runTest(TestSuite.java:230) > at junit.framework.TestSuite.run(TestSuite.java:225) > at junit.framework.TestSuite.runTest(TestSuite.java:230) > at junit.framework.TestSuite.run(TestSuite.java:225) > at junit.textui.TestRunner.doRun(TestRunner.java:121) > at junit.textui.TestRunner.start(TestRunner.java:185) > at junit.textui.TestRunner.main(TestRunner.java:143) > Caused by: org.apache.derby.client.am.SqlException: DERBY SQL error: SQLCODE: > -1, SQLSTATE: XRE07, SQLERRMC: Could not perform operation because the > database is not in replication master mode. > at > org.apache.derby.client.am.Connection.completeSqlca(Connection.java:2068) > at > org.apache.derby.client.net.NetConnectionReply.parseRdbAccessFailed(NetConnectionReply.java:537) > at > org.apache.derby.client.net.NetConnectionReply.parseAccessRdbError(NetConnectionReply.java
[jira] Issue Comment Edited: (DERBY-3709) Exception printed by replication test: Could not perform operation because the database is not in replication master mode.
[ https://issues.apache.org/jira/browse/DERBY-3709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12603554#action_12603554 ] narayanan edited comment on DERBY-3709 at 6/9/08 5:02 AM: Thank you for the patch Ole! Shall run tests and commit tonight or early tomorrow morning. I have my hands full now (sorry that I can't commit this immediately)! Also should this change be reflected in the 10.4 branch also? was (Author: narayanan): Thank you for the patch Ole! Shall run tests and commit tonight or early tomorrow morning. I have my hands full now! Also should this change be reflected in the 10.4 branch also? > Exception printed by replication test: Could not perform operation because > the database is not in replication master mode. > -- > > Key: DERBY-3709 > URL: https://issues.apache.org/jira/browse/DERBY-3709 > Project: Derby > Issue Type: Bug > Components: Regression Test Failure, Replication >Affects Versions: 10.5.0.0 > Environment: Java Version:1.6.0_04 > Java Vendor: Sun Microsystems Inc. > OS name: SunOS > OS architecture: x86 > OS version: 5.10 >Reporter: Knut Anders Hatlen >Assignee: Ole Solberg > Attachments: derby-3709_p1-v2.diff.txt, derby-3709_p1.diff.txt > > > I saw the following exception printed when I ran suites.All on trunk > (revision 663064). None of the tests failed. > java.sql.SQLException: DERBY SQL error: SQLCODE: -1, SQLSTATE: XRE07, > SQLERRMC: Could not perform operation because the database is not in > replication master mode. > at > org.apache.derby.client.am.SQLExceptionFactory40.getSQLException(SQLExceptionFactory40.java:96) > at > org.apache.derby.client.am.SqlException.getSQLException(SqlException.java:362) > at org.apache.derby.jdbc.ClientDriver.connect(ClientDriver.java:149) > at java.sql.DriverManager.getConnection(DriverManager.java:582) > at java.sql.DriverManager.getConnection(DriverManager.java:207) > at > org.apache.derbyTesting.functionTests.tests.replicationTests.ReplicationRun.failOver_direct(ReplicationRun.java:1286) > at > org.apache.derbyTesting.functionTests.tests.replicationTests.ReplicationRun.failOver(ReplicationRun.java:1220) > at > org.apache.derbyTesting.functionTests.tests.replicationTests.ReplicationRun_Local.testReplication_Local(ReplicationRun_Local.java:148) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at junit.framework.TestCase.runTest(TestCase.java:164) > at junit.framework.TestCase.runBare(TestCase.java:130) > at > org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:104) > at junit.framework.TestResult$1.protect(TestResult.java:106) > at junit.framework.TestResult.runProtected(TestResult.java:124) > at junit.framework.TestResult.run(TestResult.java:109) > at junit.framework.TestCase.run(TestCase.java:120) > at junit.framework.TestSuite.runTest(TestSuite.java:230) > at junit.framework.TestSuite.run(TestSuite.java:225) > at junit.framework.TestSuite.runTest(TestSuite.java:230) > at junit.framework.TestSuite.run(TestSuite.java:225) > at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) > at junit.extensions.TestSetup$1.protect(TestSetup.java:21) > at junit.framework.TestResult.runProtected(TestResult.java:124) > at junit.extensions.TestSetup.run(TestSetup.java:25) > at junit.framework.TestSuite.runTest(TestSuite.java:230) > at junit.framework.TestSuite.run(TestSuite.java:225) > at junit.framework.TestSuite.runTest(TestSuite.java:230) > at junit.framework.TestSuite.run(TestSuite.java:225) > at junit.textui.TestRunner.doRun(TestRunner.java:121) > at junit.textui.TestRunner.start(TestRunner.java:185) > at junit.textui.TestRunner.main(TestRunner.java:143) > Caused by: org.apache.derby.client.am.SqlException: DERBY SQL error: SQLCODE: > -1, SQLSTATE: XRE07, SQLERRMC: Could not perform operation because the > database is not in replication master mode. > at > org.apache.derby.client.am.Connection.completeSqlca(Connection.java:2068) > at > org.apache.derby.client.net.NetConnectionReply.parseRdbAccessFailed(NetConnectionReply.java:537) > at > org.apache.derby.client.net.NetConnectionReply.parseAccessRdbError(NetConnectionReply.java:430) > at > org.apache.derby.client.ne
[jira] Commented: (DERBY-3709) Exception printed by replication test: Could not perform operation because the database is not in replication master mode.
[ https://issues.apache.org/jira/browse/DERBY-3709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12603554#action_12603554 ] V.Narayanan commented on DERBY-3709: Thank you for the patch Ole! Shall run tests and commit tonight or early tomorrow morning. I have my hands full now! Also should this change be reflected in the 10.4 branch also? > Exception printed by replication test: Could not perform operation because > the database is not in replication master mode. > -- > > Key: DERBY-3709 > URL: https://issues.apache.org/jira/browse/DERBY-3709 > Project: Derby > Issue Type: Bug > Components: Regression Test Failure, Replication >Affects Versions: 10.5.0.0 > Environment: Java Version:1.6.0_04 > Java Vendor: Sun Microsystems Inc. > OS name: SunOS > OS architecture: x86 > OS version: 5.10 >Reporter: Knut Anders Hatlen >Assignee: Ole Solberg > Attachments: derby-3709_p1-v2.diff.txt, derby-3709_p1.diff.txt > > > I saw the following exception printed when I ran suites.All on trunk > (revision 663064). None of the tests failed. > java.sql.SQLException: DERBY SQL error: SQLCODE: -1, SQLSTATE: XRE07, > SQLERRMC: Could not perform operation because the database is not in > replication master mode. > at > org.apache.derby.client.am.SQLExceptionFactory40.getSQLException(SQLExceptionFactory40.java:96) > at > org.apache.derby.client.am.SqlException.getSQLException(SqlException.java:362) > at org.apache.derby.jdbc.ClientDriver.connect(ClientDriver.java:149) > at java.sql.DriverManager.getConnection(DriverManager.java:582) > at java.sql.DriverManager.getConnection(DriverManager.java:207) > at > org.apache.derbyTesting.functionTests.tests.replicationTests.ReplicationRun.failOver_direct(ReplicationRun.java:1286) > at > org.apache.derbyTesting.functionTests.tests.replicationTests.ReplicationRun.failOver(ReplicationRun.java:1220) > at > org.apache.derbyTesting.functionTests.tests.replicationTests.ReplicationRun_Local.testReplication_Local(ReplicationRun_Local.java:148) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at junit.framework.TestCase.runTest(TestCase.java:164) > at junit.framework.TestCase.runBare(TestCase.java:130) > at > org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:104) > at junit.framework.TestResult$1.protect(TestResult.java:106) > at junit.framework.TestResult.runProtected(TestResult.java:124) > at junit.framework.TestResult.run(TestResult.java:109) > at junit.framework.TestCase.run(TestCase.java:120) > at junit.framework.TestSuite.runTest(TestSuite.java:230) > at junit.framework.TestSuite.run(TestSuite.java:225) > at junit.framework.TestSuite.runTest(TestSuite.java:230) > at junit.framework.TestSuite.run(TestSuite.java:225) > at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) > at junit.extensions.TestSetup$1.protect(TestSetup.java:21) > at junit.framework.TestResult.runProtected(TestResult.java:124) > at junit.extensions.TestSetup.run(TestSetup.java:25) > at junit.framework.TestSuite.runTest(TestSuite.java:230) > at junit.framework.TestSuite.run(TestSuite.java:225) > at junit.framework.TestSuite.runTest(TestSuite.java:230) > at junit.framework.TestSuite.run(TestSuite.java:225) > at junit.textui.TestRunner.doRun(TestRunner.java:121) > at junit.textui.TestRunner.start(TestRunner.java:185) > at junit.textui.TestRunner.main(TestRunner.java:143) > Caused by: org.apache.derby.client.am.SqlException: DERBY SQL error: SQLCODE: > -1, SQLSTATE: XRE07, SQLERRMC: Could not perform operation because the > database is not in replication master mode. > at > org.apache.derby.client.am.Connection.completeSqlca(Connection.java:2068) > at > org.apache.derby.client.net.NetConnectionReply.parseRdbAccessFailed(NetConnectionReply.java:537) > at > org.apache.derby.client.net.NetConnectionReply.parseAccessRdbError(NetConnectionReply.java:430) > at > org.apache.derby.client.net.NetConnectionReply.parseACCRDBreply(NetConnectionReply.j
[jira] Assigned: (DERBY-3709) Exception printed by replication test: Could not perform operation because the database is not in replication master mode.
[ https://issues.apache.org/jira/browse/DERBY-3709?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] V.Narayanan reassigned DERBY-3709: -- Assignee: Ole Solberg > Exception printed by replication test: Could not perform operation because > the database is not in replication master mode. > -- > > Key: DERBY-3709 > URL: https://issues.apache.org/jira/browse/DERBY-3709 > Project: Derby > Issue Type: Bug > Components: Regression Test Failure, Replication >Affects Versions: 10.5.0.0 > Environment: Java Version:1.6.0_04 > Java Vendor: Sun Microsystems Inc. > OS name: SunOS > OS architecture: x86 > OS version: 5.10 >Reporter: Knut Anders Hatlen >Assignee: Ole Solberg > Attachments: derby-3709_p1-v2.diff.txt, derby-3709_p1.diff.txt > > > I saw the following exception printed when I ran suites.All on trunk > (revision 663064). None of the tests failed. > java.sql.SQLException: DERBY SQL error: SQLCODE: -1, SQLSTATE: XRE07, > SQLERRMC: Could not perform operation because the database is not in > replication master mode. > at > org.apache.derby.client.am.SQLExceptionFactory40.getSQLException(SQLExceptionFactory40.java:96) > at > org.apache.derby.client.am.SqlException.getSQLException(SqlException.java:362) > at org.apache.derby.jdbc.ClientDriver.connect(ClientDriver.java:149) > at java.sql.DriverManager.getConnection(DriverManager.java:582) > at java.sql.DriverManager.getConnection(DriverManager.java:207) > at > org.apache.derbyTesting.functionTests.tests.replicationTests.ReplicationRun.failOver_direct(ReplicationRun.java:1286) > at > org.apache.derbyTesting.functionTests.tests.replicationTests.ReplicationRun.failOver(ReplicationRun.java:1220) > at > org.apache.derbyTesting.functionTests.tests.replicationTests.ReplicationRun_Local.testReplication_Local(ReplicationRun_Local.java:148) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at junit.framework.TestCase.runTest(TestCase.java:164) > at junit.framework.TestCase.runBare(TestCase.java:130) > at > org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:104) > at junit.framework.TestResult$1.protect(TestResult.java:106) > at junit.framework.TestResult.runProtected(TestResult.java:124) > at junit.framework.TestResult.run(TestResult.java:109) > at junit.framework.TestCase.run(TestCase.java:120) > at junit.framework.TestSuite.runTest(TestSuite.java:230) > at junit.framework.TestSuite.run(TestSuite.java:225) > at junit.framework.TestSuite.runTest(TestSuite.java:230) > at junit.framework.TestSuite.run(TestSuite.java:225) > at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) > at junit.extensions.TestSetup$1.protect(TestSetup.java:21) > at junit.framework.TestResult.runProtected(TestResult.java:124) > at junit.extensions.TestSetup.run(TestSetup.java:25) > at junit.framework.TestSuite.runTest(TestSuite.java:230) > at junit.framework.TestSuite.run(TestSuite.java:225) > at junit.framework.TestSuite.runTest(TestSuite.java:230) > at junit.framework.TestSuite.run(TestSuite.java:225) > at junit.textui.TestRunner.doRun(TestRunner.java:121) > at junit.textui.TestRunner.start(TestRunner.java:185) > at junit.textui.TestRunner.main(TestRunner.java:143) > Caused by: org.apache.derby.client.am.SqlException: DERBY SQL error: SQLCODE: > -1, SQLSTATE: XRE07, SQLERRMC: Could not perform operation because the > database is not in replication master mode. > at > org.apache.derby.client.am.Connection.completeSqlca(Connection.java:2068) > at > org.apache.derby.client.net.NetConnectionReply.parseRdbAccessFailed(NetConnectionReply.java:537) > at > org.apache.derby.client.net.NetConnectionReply.parseAccessRdbError(NetConnectionReply.java:430) > at > org.apache.derby.client.net.NetConnectionReply.parseACCRDBreply(NetConnectionReply.java:294) > at > org.apache.derby.client.net.NetConnectionReply.readAccessDatabase(NetConnectionReply.java:121) > at > org.apache.derby.client.net.NetConnection.readSecurityCheckAndAccessRd
[jira] Commented: (DERBY-3632) Replication tests must ensure stable replication state has been reached before attempting further connection or new replication commands.
[ https://issues.apache.org/jira/browse/DERBY-3632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12603551#action_12603551 ] V.Narayanan commented on DERBY-3632: Committed to 10.4 branch also, ran tests, Sending java/testing/org/apache/derbyTesting/functionTests/tests/replicationTests/ReplicationRun.java Transmitting file data . Committed revision 664684. Found two failures, unrelated to this issue or the patch submitted 1) testAttributeAccumulatedConnectionCount(org.apache.derbyTesting.functionTests.tests.management.NetworkServerMBeanTest)java.security.PrivilegedActionException: javax.management.InstanceNotFoundException: org.apache.derby:type=NetworkServer,system=c013800d-011a-6ce8-6aa1-ae960ebe at java.security.AccessController.doPrivileged(Native Method) at org.apache.derbyTesting.functionTests.tests.management.MBeanTest.getAttribute(MBeanTest.java:379) at org.apache.derbyTesting.functionTests.tests.management.NetworkServerMBeanTest.testAttributeAccumulatedConnectionCount(NetworkServerMBeanTest.java:93) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:101) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) Caused by: javax.management.InstanceNotFoundException: org.apache.derby:type=NetworkServer,system=c013800d-011a-6ce8-6aa1-ae960ebe at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getMBean(DefaultMBeanServerInterceptor.java:1094) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getAttribute(DefaultMBeanServerInterceptor.java:662) at com.sun.jmx.mbeanserver.JmxMBeanServer.getAttribute(JmxMBeanServer.java:638) at org.apache.derbyTesting.functionTests.tests.management.MBeanTest$4.run(MBeanTest.java:382) ... 41 more 2) testAttributeActiveConnectionCount(org.apache.derbyTesting.functionTests.tests.management.NetworkServerMBeanTest)java.security.PrivilegedActionException: javax.management.InstanceNotFoundException: org.apache.derby:type=NetworkServer,system=c013800d-011a-6ce8-6aa1-ae960ebe at java.security.AccessController.doPrivileged(Native Method) at org.apache.derbyTesting.functionTests.tests.management.MBeanTest.getAttribute(MBeanTest.java:379) at org.apache.derbyTesting.functionTests.tests.management.NetworkServerMBeanTest.testAttributeActiveConnectionCount(NetworkServerMBeanTest.java:103) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:101) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) Caused by: javax.management.InstanceNotFoundException: org.apache.derby:type=NetworkServer,system=c013800d-011a-6ce8-6aa1-ae960ebe at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getMBean(DefaultMBeanServerInterceptor.java:1094) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getAttribute(DefaultMBeanServerInterceptor.java:662)
[jira] Commented: (DERBY-3632) Replication tests must ensure stable replication state has been reached before attempting further connection or new replication commands.
[ https://issues.apache.org/jira/browse/DERBY-3632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12603485#action_12603485 ] V.Narayanan commented on DERBY-3632: Thank you for the diagnosis on the issue and the patch Ole! Sending java/testing/org/apache/derbyTesting/functionTests/tests/replicationTests/ReplicationRun.java Transmitting file data . Committed revision 664639. > Replication tests must ensure stable replication state has been reached > before attempting further connection or new replication commands. > - > > Key: DERBY-3632 > URL: https://issues.apache.org/jira/browse/DERBY-3632 > Project: Derby > Issue Type: Bug > Components: Replication, Test >Affects Versions: 10.4.1.4, 10.5.0.0 > Environment: All >Reporter: Ole Solberg >Assignee: Ole Solberg >Priority: Minor > Attachments: derby-3632_p1.diff.txt, derby-3632_p1.stat.txt > > > When executing replication commands (startslave, startmaster, stopmaster, > stopslave, failover) tests must make sure that correct replication state has > been reached before attempting further connection to the master and slave > databases. > This causes intermittent errors in replication tests. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3632) Replication tests must ensure stable replication state has been reached before attempting further connection or new replication commands.
[ https://issues.apache.org/jira/browse/DERBY-3632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12603483#action_12603483 ] V.Narayanan commented on DERBY-3632: In addition to the 7 failures in tinderbox, I had Derby-3689 recurring. These don't seem to be related to the patch. I am going to commit this patch. Thanks for the patch Ole. > Replication tests must ensure stable replication state has been reached > before attempting further connection or new replication commands. > - > > Key: DERBY-3632 > URL: https://issues.apache.org/jira/browse/DERBY-3632 > Project: Derby > Issue Type: Bug > Components: Replication, Test >Affects Versions: 10.4.1.4, 10.5.0.0 > Environment: All >Reporter: Ole Solberg >Assignee: Ole Solberg >Priority: Minor > Attachments: derby-3632_p1.diff.txt, derby-3632_p1.stat.txt > > > When executing replication commands (startslave, startmaster, stopmaster, > stopslave, failover) tests must make sure that correct replication state has > been reached before attempting further connection to the master and slave > databases. > This causes intermittent errors in replication tests. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3632) Replication tests must ensure stable replication state has been reached before attempting further connection or new replication commands.
[ https://issues.apache.org/jira/browse/DERBY-3632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12603463#action_12603463 ] V.Narayanan commented on DERBY-3632: I ran tests on this patch and noticed multiple failures. 1) I had a "java.net.SocketException: Connection reset" initially 2) A whole lot of java.security.PrivilegedActionException: javax.management.InstanceNotFoundException: org.apache.derby:type=NetworkServer,system=c013800d-011a-69a4-8c8a-861961bb 3) And quite a few Failed to start database 'singleUse/oneuse49', see the next exception for details. These might as well be because I missed a runic option while starting the tests. I will run the tests again and shall report back with the test results. I am careful with this patch because it primarily a timing change in starting the replication master. The failures might also be due to timing changes induced by this patch (Not sure about this one!). Ole, Can you please confirm that the tests passed for you with the attached patch? > Replication tests must ensure stable replication state has been reached > before attempting further connection or new replication commands. > - > > Key: DERBY-3632 > URL: https://issues.apache.org/jira/browse/DERBY-3632 > Project: Derby > Issue Type: Bug > Components: Replication, Test >Affects Versions: 10.4.1.4, 10.5.0.0 > Environment: All >Reporter: Ole Solberg >Assignee: Ole Solberg >Priority: Minor > Attachments: derby-3632_p1.diff.txt, derby-3632_p1.stat.txt > > > When executing replication commands (startslave, startmaster, stopmaster, > stopslave, failover) tests must make sure that correct replication state has > been reached before attempting further connection to the master and slave > databases. > This causes intermittent errors in replication tests. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3709) Exception printed by replication test: Could not perform operation because the database is not in replication master mode.
[ https://issues.apache.org/jira/browse/DERBY-3709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12603419#action_12603419 ] V.Narayanan commented on DERBY-3709: 1) Can't we just leave the 'else' and the catch(Exception ex) parts since the method is already throwing an Exception? 2) I am not sure this usage assertTrue(msg, false); is right, I guess the aim is to print msg all the time. Do we need to use assertTrue in this case? Also, I will get 3632 in first and then switch to this issue. > Exception printed by replication test: Could not perform operation because > the database is not in replication master mode. > -- > > Key: DERBY-3709 > URL: https://issues.apache.org/jira/browse/DERBY-3709 > Project: Derby > Issue Type: Bug > Components: Regression Test Failure, Replication >Affects Versions: 10.5.0.0 > Environment: Java Version:1.6.0_04 > Java Vendor: Sun Microsystems Inc. > OS name: SunOS > OS architecture: x86 > OS version: 5.10 >Reporter: Knut Anders Hatlen > Attachments: derby-3709_p1.diff.txt > > > I saw the following exception printed when I ran suites.All on trunk > (revision 663064). None of the tests failed. > java.sql.SQLException: DERBY SQL error: SQLCODE: -1, SQLSTATE: XRE07, > SQLERRMC: Could not perform operation because the database is not in > replication master mode. > at > org.apache.derby.client.am.SQLExceptionFactory40.getSQLException(SQLExceptionFactory40.java:96) > at > org.apache.derby.client.am.SqlException.getSQLException(SqlException.java:362) > at org.apache.derby.jdbc.ClientDriver.connect(ClientDriver.java:149) > at java.sql.DriverManager.getConnection(DriverManager.java:582) > at java.sql.DriverManager.getConnection(DriverManager.java:207) > at > org.apache.derbyTesting.functionTests.tests.replicationTests.ReplicationRun.failOver_direct(ReplicationRun.java:1286) > at > org.apache.derbyTesting.functionTests.tests.replicationTests.ReplicationRun.failOver(ReplicationRun.java:1220) > at > org.apache.derbyTesting.functionTests.tests.replicationTests.ReplicationRun_Local.testReplication_Local(ReplicationRun_Local.java:148) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at junit.framework.TestCase.runTest(TestCase.java:164) > at junit.framework.TestCase.runBare(TestCase.java:130) > at > org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:104) > at junit.framework.TestResult$1.protect(TestResult.java:106) > at junit.framework.TestResult.runProtected(TestResult.java:124) > at junit.framework.TestResult.run(TestResult.java:109) > at junit.framework.TestCase.run(TestCase.java:120) > at junit.framework.TestSuite.runTest(TestSuite.java:230) > at junit.framework.TestSuite.run(TestSuite.java:225) > at junit.framework.TestSuite.runTest(TestSuite.java:230) > at junit.framework.TestSuite.run(TestSuite.java:225) > at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) > at junit.extensions.TestSetup$1.protect(TestSetup.java:21) > at junit.framework.TestResult.runProtected(TestResult.java:124) > at junit.extensions.TestSetup.run(TestSetup.java:25) > at junit.framework.TestSuite.runTest(TestSuite.java:230) > at junit.framework.TestSuite.run(TestSuite.java:225) > at junit.framework.TestSuite.runTest(TestSuite.java:230) > at junit.framework.TestSuite.run(TestSuite.java:225) > at junit.textui.TestRunner.doRun(TestRunner.java:121) > at junit.textui.TestRunner.start(TestRunner.java:185) > at junit.textui.TestRunner.main(TestRunner.java:143) > Caused by: org.apache.derby.client.am.SqlException: DERBY SQL error: SQLCODE: > -1, SQLSTATE: XRE07, SQLERRMC: Could not perform operation because the > database is not in replication master mode. > at > org.apache.derby.client.am.Connection.completeSqlca(Connection.java:2068) > at > org.apache.derby.client.net.NetConnectionReply.parseRdbAccessFailed(NetConnectionReply.java:537) > at > org.apache.derby.client.net.NetConnectionReply.parseAccessRdbError(NetConnecti
[jira] Issue Comment Edited: (DERBY-3632) Replication tests must ensure stable replication state has been reached before attempting further connection or new replication commands.
[ https://issues.apache.org/jira/browse/DERBY-3632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12603415#action_12603415 ] narayanan edited comment on DERBY-3632 at 6/8/08 10:53 AM: - The patch for the issue seems straightforward to me, will commit this patch if my tests pass. Starting test runs now. was (Author: narayanan): The issue seems straightforward to me, will commit this issue if my tests pass. Starting test runs now. > Replication tests must ensure stable replication state has been reached > before attempting further connection or new replication commands. > - > > Key: DERBY-3632 > URL: https://issues.apache.org/jira/browse/DERBY-3632 > Project: Derby > Issue Type: Bug > Components: Replication, Test >Affects Versions: 10.4.1.4, 10.5.0.0 > Environment: All >Reporter: Ole Solberg >Assignee: Ole Solberg >Priority: Minor > Attachments: derby-3632_p1.diff.txt, derby-3632_p1.stat.txt > > > When executing replication commands (startslave, startmaster, stopmaster, > stopslave, failover) tests must make sure that correct replication state has > been reached before attempting further connection to the master and slave > databases. > This causes intermittent errors in replication tests. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3632) Replication tests must ensure stable replication state has been reached before attempting further connection or new replication commands.
[ https://issues.apache.org/jira/browse/DERBY-3632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12603415#action_12603415 ] V.Narayanan commented on DERBY-3632: The issue seems straightforward to me, will commit this issue if my tests pass. Starting test runs now. > Replication tests must ensure stable replication state has been reached > before attempting further connection or new replication commands. > - > > Key: DERBY-3632 > URL: https://issues.apache.org/jira/browse/DERBY-3632 > Project: Derby > Issue Type: Bug > Components: Replication, Test >Affects Versions: 10.4.1.4, 10.5.0.0 > Environment: All >Reporter: Ole Solberg >Assignee: Ole Solberg >Priority: Minor > Attachments: derby-3632_p1.diff.txt, derby-3632_p1.stat.txt > > > When executing replication commands (startslave, startmaster, stopmaster, > stopslave, failover) tests must make sure that correct replication state has > been reached before attempting further connection to the master and slave > databases. > This causes intermittent errors in replication tests. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3709) Exception printed by replication test: Could not perform operation because the database is not in replication master mode.
[ https://issues.apache.org/jira/browse/DERBY-3709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12602613#action_12602613 ] V.Narayanan commented on DERBY-3709: I remember while working on 3617 thinking that this might be because the tests call failover immediately after a start master, this results in failover being called before replication can be booted completely. I will take a closer look at this over the weekend, unless someone beats me to it. > Exception printed by replication test: Could not perform operation because > the database is not in replication master mode. > -- > > Key: DERBY-3709 > URL: https://issues.apache.org/jira/browse/DERBY-3709 > Project: Derby > Issue Type: Bug > Components: Regression Test Failure, Replication >Affects Versions: 10.5.0.0 > Environment: Java Version:1.6.0_04 > Java Vendor: Sun Microsystems Inc. > OS name: SunOS > OS architecture: x86 > OS version: 5.10 >Reporter: Knut Anders Hatlen > > I saw the following exception printed when I ran suites.All on trunk > (revision 663064). None of the tests failed. > java.sql.SQLException: DERBY SQL error: SQLCODE: -1, SQLSTATE: XRE07, > SQLERRMC: Could not perform operation because the database is not in > replication master mode. > at > org.apache.derby.client.am.SQLExceptionFactory40.getSQLException(SQLExceptionFactory40.java:96) > at > org.apache.derby.client.am.SqlException.getSQLException(SqlException.java:362) > at org.apache.derby.jdbc.ClientDriver.connect(ClientDriver.java:149) > at java.sql.DriverManager.getConnection(DriverManager.java:582) > at java.sql.DriverManager.getConnection(DriverManager.java:207) > at > org.apache.derbyTesting.functionTests.tests.replicationTests.ReplicationRun.failOver_direct(ReplicationRun.java:1286) > at > org.apache.derbyTesting.functionTests.tests.replicationTests.ReplicationRun.failOver(ReplicationRun.java:1220) > at > org.apache.derbyTesting.functionTests.tests.replicationTests.ReplicationRun_Local.testReplication_Local(ReplicationRun_Local.java:148) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at junit.framework.TestCase.runTest(TestCase.java:164) > at junit.framework.TestCase.runBare(TestCase.java:130) > at > org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:104) > at junit.framework.TestResult$1.protect(TestResult.java:106) > at junit.framework.TestResult.runProtected(TestResult.java:124) > at junit.framework.TestResult.run(TestResult.java:109) > at junit.framework.TestCase.run(TestCase.java:120) > at junit.framework.TestSuite.runTest(TestSuite.java:230) > at junit.framework.TestSuite.run(TestSuite.java:225) > at junit.framework.TestSuite.runTest(TestSuite.java:230) > at junit.framework.TestSuite.run(TestSuite.java:225) > at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) > at junit.extensions.TestSetup$1.protect(TestSetup.java:21) > at junit.framework.TestResult.runProtected(TestResult.java:124) > at junit.extensions.TestSetup.run(TestSetup.java:25) > at junit.framework.TestSuite.runTest(TestSuite.java:230) > at junit.framework.TestSuite.run(TestSuite.java:225) > at junit.framework.TestSuite.runTest(TestSuite.java:230) > at junit.framework.TestSuite.run(TestSuite.java:225) > at junit.textui.TestRunner.doRun(TestRunner.java:121) > at junit.textui.TestRunner.start(TestRunner.java:185) > at junit.textui.TestRunner.main(TestRunner.java:143) > Caused by: org.apache.derby.client.am.SqlException: DERBY SQL error: SQLCODE: > -1, SQLSTATE: XRE07, SQLERRMC: Could not perform operation because the > database is not in replication master mode. > at > org.apache.derby.client.am.Connection.completeSqlca(Connection.java:2068) > at > org.apache.derby.client.net.NetConnectionReply.parseRdbAccessFailed(NetConnectionReply.java:537) > at > org.apache.derby.client.net.NetConnectionReply.parseAccessRdbError(NetConnectionReply.java:430) > at > org.apache.derby.client.net.NetConnectionReply.parseACCRDBreply(NetConnectionReply.java:294)
[jira] Issue Comment Edited: (DERBY-2514) convert lang/closed.java to junit
[ https://issues.apache.org/jira/browse/DERBY-2514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12601022#action_12601022 ] narayanan edited comment on DERBY-2514 at 5/29/08 11:14 PM: -- I ran junit all on the patch yesterday night and found some failures unrelated to the issue in hand. Committed the patch. Sending java/testing/org/apache/derbyTesting/functionTests/tests/jdbcapi/DatabaseMetaDataTest.java Transmitting file data . Committed revision 661574. Thanks for the patch Svien Erik! Thank you for the reviews Knut! was (Author: narayanan): Sending java/testing/org/apache/derbyTesting/functionTests/tests/jdbcapi/DatabaseMetaDataTest.java Transmitting file data . Committed revision 661574. Thanks for the patch Svien Erik! Thank you for the reviews Knut! > convert lang/closed.java to junit > - > > Key: DERBY-2514 > URL: https://issues.apache.org/jira/browse/DERBY-2514 > Project: Derby > Issue Type: Test > Components: Newcomer, Test > Environment: convert lang/closed.java to junit >Reporter: Ramandeep Kaur >Assignee: Svein Erik Løvland >Priority: Minor > Attachments: Derby2514_2.diff, Derby2514_3.diff, derby2514_dmd.diff > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2514) convert lang/closed.java to junit
[ https://issues.apache.org/jira/browse/DERBY-2514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12601022#action_12601022 ] V.Narayanan commented on DERBY-2514: Sending java/testing/org/apache/derbyTesting/functionTests/tests/jdbcapi/DatabaseMetaDataTest.java Transmitting file data . Committed revision 661574. Thanks for the patch Svien Erik! Thank you for the reviews Knut! > convert lang/closed.java to junit > - > > Key: DERBY-2514 > URL: https://issues.apache.org/jira/browse/DERBY-2514 > Project: Derby > Issue Type: Test > Components: Newcomer, Test > Environment: convert lang/closed.java to junit >Reporter: Ramandeep Kaur >Assignee: Svein Erik Løvland >Priority: Minor > Attachments: Derby2514_2.diff, Derby2514_3.diff, derby2514_dmd.diff > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2514) convert lang/closed.java to junit
[ https://issues.apache.org/jira/browse/DERBY-2514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12600744#action_12600744 ] V.Narayanan commented on DERBY-2514: starting tests, shall commit as soon as completed > convert lang/closed.java to junit > - > > Key: DERBY-2514 > URL: https://issues.apache.org/jira/browse/DERBY-2514 > Project: Derby > Issue Type: Test > Components: Newcomer, Test > Environment: convert lang/closed.java to junit >Reporter: Ramandeep Kaur >Assignee: Svein Erik Løvland >Priority: Minor > Attachments: Derby2514_2.diff, Derby2514_3.diff, derby2514_dmd.diff > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2514) convert lang/closed.java to junit
[ https://issues.apache.org/jira/browse/DERBY-2514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12600463#action_12600463 ] V.Narayanan commented on DERBY-2514: I think Knut has some very valid points, sorry for my overlooking those important points in my review Svien Erik, I understand it can be frustrating receiving multiple comments and redoing the patch initially. But I think your patch looked really good and knut's comments are mostly minor changes that need some code moving, and a commit on the issue is very close. Thank you for the effort and the quick response to my earlier comments. > convert lang/closed.java to junit > - > > Key: DERBY-2514 > URL: https://issues.apache.org/jira/browse/DERBY-2514 > Project: Derby > Issue Type: Test > Components: Newcomer, Test > Environment: convert lang/closed.java to junit >Reporter: Ramandeep Kaur >Assignee: Svein Erik Løvland >Priority: Minor > Attachments: Derby2514.diff, Derby2514_2.diff, Derby2514_3.diff > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-2514) convert lang/closed.java to junit
[ https://issues.apache.org/jira/browse/DERBY-2514?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] V.Narayanan updated DERBY-2514: --- Attachment: Derby2514_3.diff The patch looks very good. I ran the the mentioned test alone and it passed fine. java junit.textui.TestRunner org.apache.derbyTesting.functionTests.tests.jdbcapi.Derby2514 .. Time: 1.622 OK (2 tests) I took the liberty of making a few cosmetic changes, I am enumerating them below. Also just as a matter of keeping to rules I am running all the tests. This step is unnecessary I know. Cosmetic Changes made --- Added a class level comment explaining what the test does * I checked ParameterMappingTest and HoldabilityTest to see what is the comment given to the test constructor it says /** Creates a new instance of HoldabilityTest */ But I think I like what you have written, so decided to let it be as is. * There were some lines going beyond 80 characters so changed them to keep to 80 characters * Removed the whitespace between testDerby62() and the javadoc. * There was some inconsistenct in the space between try and the parenthesis following it between the methods testDMDconnClosed(), testDerby62(). I have changed them to consistently use a space. * changed these comments to use the // comments and also removed some spurious tabs there //'DROP TABLE' cannot be performed on 'APP.DERBY62_DAIN_SUNDSTROM' //because it does not exist. There were a few spurious tabs in other lines also. Removed them too. * Removed the '^M' characters that were appearing on the _2 patch. Not sure how I removed this They were not there in the patch I generated atleast. * I also did a svn propset svn:eol-style native on the new file, it is mentioned http://db.apache.org/derby/derby_comm.html that you should do this for new files being added. > convert lang/closed.java to junit > - > > Key: DERBY-2514 > URL: https://issues.apache.org/jira/browse/DERBY-2514 > Project: Derby > Issue Type: Test > Components: Newcomer, Test > Environment: convert lang/closed.java to junit >Reporter: Ramandeep Kaur >Assignee: Svein Erik Løvland >Priority: Minor > Attachments: Derby2514.diff, Derby2514_2.diff, Derby2514_3.diff > > -- 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-2514) convert lang/closed.java to junit
[ https://issues.apache.org/jira/browse/DERBY-2514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12600419#action_12600419 ] narayanan edited comment on DERBY-2514 at 5/28/08 2:48 AM: - Not removing lang/closed.java is OK, No problem, It can be removed later also once people are happy with coverage. I personally have no qualms about the name Derby2514.java either. I am OK with you having used a junit test case to add these tests and I think Myrna will be Ok also from what I read of her comments. About the ICLA, I think this patch is small too, I will commit it once I review it in detail It is just that this is my first commit and I am a little tensed about it and want to give it a detailed look. I think at first look you have done a great job with the coding. It looks very neat and organized. Thank you for the re attach. was (Author: narayanan): Not removing lang/closed.java is OK, No problem, It can be removed later also once people are happy with coverage. I personally have qualms about Derby2514.java either. I am OK with you having used a junit test case to add these tests and I think Myrna will be Ok also from what I read of her comments. About the ICLA, I think this patch is small too, I will commit it once I review it in detail It is just that this is my first commit and I am a little tensed about it and want to give it a detailed look. I think at first look you have done a great job with the coding. It looks very neat and organized. Thank you for the re attach. > convert lang/closed.java to junit > - > > Key: DERBY-2514 > URL: https://issues.apache.org/jira/browse/DERBY-2514 > Project: Derby > Issue Type: Test > Components: Newcomer, Test > Environment: convert lang/closed.java to junit >Reporter: Ramandeep Kaur >Assignee: Svein Erik Løvland >Priority: Minor > Attachments: Derby2514.diff, Derby2514_2.diff > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2514) convert lang/closed.java to junit
[ https://issues.apache.org/jira/browse/DERBY-2514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12600419#action_12600419 ] V.Narayanan commented on DERBY-2514: Not removing lang/closed.java is OK, No problem, It can be removed later also once people are happy with coverage. I personally have qualms about Derby2514.java either. I am OK with you having used a junit test case to add these tests and I think Myrna will be Ok also from what I read of her comments. About the ICLA, I think this patch is small too, I will commit it once I review it in detail It is just that this is my first commit and I am a little tensed about it and want to give it a detailed look. I think at first look you have done a great job with the coding. It looks very neat and organized. Thank you for the re attach. > convert lang/closed.java to junit > - > > Key: DERBY-2514 > URL: https://issues.apache.org/jira/browse/DERBY-2514 > Project: Derby > Issue Type: Test > Components: Newcomer, Test > Environment: convert lang/closed.java to junit >Reporter: Ramandeep Kaur >Assignee: Svein Erik Løvland >Priority: Minor > Attachments: Derby2514.diff, Derby2514_2.diff > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (DERBY-2514) convert lang/closed.java to junit
[ https://issues.apache.org/jira/browse/DERBY-2514?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] V.Narayanan reassigned DERBY-2514: -- Assignee: Svein Erik Løvland Taking the liberty of assigning this issue to Svien Erik since he has contributed the patch attached to this issue. > convert lang/closed.java to junit > - > > Key: DERBY-2514 > URL: https://issues.apache.org/jira/browse/DERBY-2514 > Project: Derby > Issue Type: Test > Components: Newcomer, Test > Environment: convert lang/closed.java to junit >Reporter: Ramandeep Kaur >Assignee: Svein Erik Løvland >Priority: Minor > Attachments: Derby2514.diff > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2514) convert lang/closed.java to junit
[ https://issues.apache.org/jira/browse/DERBY-2514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12600404#action_12600404 ] V.Narayanan commented on DERBY-2514: A few comments at first look * new files in derby need to have a license header, the file added seems to be missing a license header * Can you please assign this issue to yourself * Can you please confirm that your icla is filed.If it is not can the community advise on whether this patch is small enough to be committed without one? > convert lang/closed.java to junit > - > > Key: DERBY-2514 > URL: https://issues.apache.org/jira/browse/DERBY-2514 > Project: Derby > Issue Type: Test > Components: Newcomer, Test > Environment: convert lang/closed.java to junit >Reporter: Ramandeep Kaur >Priority: Minor > Attachments: Derby2514.diff > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2514) convert lang/closed.java to junit
[ https://issues.apache.org/jira/browse/DERBY-2514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12600402#action_12600402 ] V.Narayanan commented on DERBY-2514: Sorry for the late reply. Thank you for the patch. I will look at it and shall give a commit if everything is OK. > convert lang/closed.java to junit > - > > Key: DERBY-2514 > URL: https://issues.apache.org/jira/browse/DERBY-2514 > Project: Derby > Issue Type: Test > Components: Newcomer, Test > Environment: convert lang/closed.java to junit >Reporter: Ramandeep Kaur >Priority: Minor > Attachments: Derby2514.diff > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2514) convert lang/closed.java to junit
[ https://issues.apache.org/jira/browse/DERBY-2514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12598656#action_12598656 ] V.Narayanan commented on DERBY-2514: This link gives tips on converting tests to junit http://wiki.apache.org/db-derby/ConvertOldTestToJunitTips . > convert lang/closed.java to junit > - > > Key: DERBY-2514 > URL: https://issues.apache.org/jira/browse/DERBY-2514 > Project: Derby > Issue Type: Test > Components: Newcomer, Test > Environment: convert lang/closed.java to junit >Reporter: Ramandeep Kaur >Priority: Minor > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3638) java/testing/Readme.htm location of derbyTesting.jar
[ https://issues.apache.org/jira/browse/DERBY-3638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12591571#action_12591571 ] V.Narayanan commented on DERBY-3638: I was trying to assign this issue to Svein Erik since he contributed the patch, but was unable to find his name in the drop down assignee list. I guess this issue should be assigned to Svein Erik. > java/testing/Readme.htm location of derbyTesting.jar > > > Key: DERBY-3638 > URL: https://issues.apache.org/jira/browse/DERBY-3638 > Project: Derby > Issue Type: Bug > Components: Documentation > Environment: All >Reporter: Svein Erik Løvland >Priority: Minor > Fix For: 10.5.0.0 > > Attachments: patch_tstjardir_jardir.txt > > Original Estimate: 0.02h > Remaining Estimate: 0.02h > > In the CLASSPATH example in section 2.1 derbyTesting.jar is refered to as > beeing the same path as jakarta-oro-2.0.8.jar and junit.jar. When I build > Derby with ant the derbyTesting.jar is created in ./jars/sane/ which which > resembels $jardir and not $tstjardir > So for the pleasure of copy pasteing I changed the example to reflect this. I > do not know if my assumption that derbyTesting.jar often will be in the same > directory as derby.jar etc. is correct. The important thing is that it is in > the $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-3617) failover on slave hangs after stopmaster on master.
[ https://issues.apache.org/jira/browse/DERBY-3617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12589529#action_12589529 ] V.Narayanan commented on DERBY-3617: Thanks a ton for the clarification Ole. Thank you for the test runs also. > failover on slave hangs after stopmaster on master. > --- > > Key: DERBY-3617 > URL: https://issues.apache.org/jira/browse/DERBY-3617 > Project: Derby > Issue Type: Bug > Components: Replication >Affects Versions: 10.5.0.0 > Environment: OS: Fedora release 7 (Moonshine) 32bits - Linux > 2.6.23.15-80.fc7PAE #1 SMP Sun Feb 10 17:14:36 EST 2008 GNU/Linux > JVM: java version "1.6.0_01" > Java(TM) SE Runtime Environment (build 1.6.0_01-b06) > Java HotSpot(TM) Server VM (build 1.6.0_01-b06, mixed mode) > SVN: 647063 > Reporter: Ole Solberg >Assignee: V.Narayanan >Priority: Minor > Attachments: db_master-derby.log, db_slave-derby.log, log.out > > > 0. Master and slave in repl. mode. > 1. master: stopmaster > 2. slave failover. >hangs. > According to "Functional Specification for Derby Replication" Rev. 9.0: > "Failover": "... . The command is only accepted on the slave if the network > conection with the master is down." so expecting failover to return valid > Connection. > However, failover never finish. > See attached master and slave derby.log and testrun log.out. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3617) failover on slave hangs after stopmaster on master.
[ https://issues.apache.org/jira/browse/DERBY-3617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12589499#action_12589499 ] V.Narayanan commented on DERBY-3617: Hi Ole, would it be possible for you to pls attach the reproducible using which the test was run? Following the steps mentioned does not reproduce this bug. > failover on slave hangs after stopmaster on master. > --- > > Key: DERBY-3617 > URL: https://issues.apache.org/jira/browse/DERBY-3617 > Project: Derby > Issue Type: Bug > Components: Replication >Affects Versions: 10.5.0.0 > Environment: OS: Fedora release 7 (Moonshine) 32bits - Linux > 2.6.23.15-80.fc7PAE #1 SMP Sun Feb 10 17:14:36 EST 2008 GNU/Linux > JVM: java version "1.6.0_01" > Java(TM) SE Runtime Environment (build 1.6.0_01-b06) > Java HotSpot(TM) Server VM (build 1.6.0_01-b06, mixed mode) > SVN: 647063 > Reporter: Ole Solberg >Assignee: V.Narayanan >Priority: Minor > Attachments: db_master-derby.log, db_slave-derby.log, log.out > > > 0. Master and slave in repl. mode. > 1. master: stopmaster > 2. slave failover. >hangs. > According to "Functional Specification for Derby Replication" Rev. 9.0: > "Failover": "... . The command is only accepted on the slave if the network > conection with the master is down." so expecting failover to return valid > Connection. > However, failover never finish. > See attached master and slave derby.log and testrun log.out. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3617) failover on slave hangs after stopmaster on master.
[ https://issues.apache.org/jira/browse/DERBY-3617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12589437#action_12589437 ] V.Narayanan commented on DERBY-3617: I tried a simple run without authentication enabled and and without executing any transactions it seemed to work. I will try this again with authentication enabled and after executing some transactions. On the master -- [EMAIL PROTECTED]:~/work/workspaces/Dery3617/master$ java org.apache.derby.tools.ij ij version 10.5 ij> connect 'jdbc:derby://localhost:1527/replicationdb'; ij> connect 'jdbc:derby://localhost:1527/replicationdb;startMaster=true;slaveHost=localhost;slavePort=8001'; ij(CONNECTION1)> connect 'jdbc:derby://localhost:1527/replicationdb;stopMaster=true;slaveHost=localhost;slavePort=8001'; ij(CONNECTION2)> On the slave --- [EMAIL PROTECTED]:~/work/workspaces/Dery3617/slave$ java org.apache.derby.tools.ij ij version 10.5 ij> connect 'jdbc:derby://localhost:1528/replicationdb;startSlave=true;slaveHost=localhost;slavePort=8001'; ERROR XRE08: DERBY SQL error: SQLCODE: -1, SQLSTATE: XRE08, SQLERRMC: Replication slave mode started successfully for database 'replicationdb'. Connection refused because the database is in replication slave mode. ij> connect 'jdbc:derby://localhost:1528/replicationdb;failover=true'; ERROR XRE11: DERBY SQL error: SQLCODE: -1, SQLSTATE: XRE11, SQLERRMC: failoverreplicationdbXRE11 ij> > failover on slave hangs after stopmaster on master. > --- > > Key: DERBY-3617 > URL: https://issues.apache.org/jira/browse/DERBY-3617 > Project: Derby > Issue Type: Bug > Components: Replication >Affects Versions: 10.5.0.0 > Environment: OS: Fedora release 7 (Moonshine) 32bits - Linux > 2.6.23.15-80.fc7PAE #1 SMP Sun Feb 10 17:14:36 EST 2008 GNU/Linux > JVM: java version "1.6.0_01" > Java(TM) SE Runtime Environment (build 1.6.0_01-b06) > Java HotSpot(TM) Server VM (build 1.6.0_01-b06, mixed mode) > SVN: 647063 >Reporter: Ole Solberg >Assignee: V.Narayanan >Priority: Minor > Attachments: db_master-derby.log, db_slave-derby.log, log.out > > > 0. Master and slave in repl. mode. > 1. master: stopmaster > 2. slave failover. >hangs. > According to "Functional Specification for Derby Replication" Rev. 9.0: > "Failover": "... . The command is only accepted on the slave if the network > conection with the master is down." so expecting failover to return valid > Connection. > However, failover never finish. > See attached master and slave derby.log and testrun log.out. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3616) TableFunctionTest fails under Ubuntu 7.10
[ https://issues.apache.org/jira/browse/DERBY-3616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12588553#action_12588553 ] V.Narayanan commented on DERBY-3616: I see these failures as well in ubuntu 7.10, looks like it is consistently failing here. > TableFunctionTest fails under Ubuntu 7.10 > - > > Key: DERBY-3616 > URL: https://issues.apache.org/jira/browse/DERBY-3616 > Project: Derby > Issue Type: Bug > Components: Regression Test Failure >Affects Versions: 10.5.0.0 > Environment: Operating System: Ubuntu 7.10 > JVMs tested: 1.4 and 1.6 >Reporter: Tiago R. Espinha >Priority: Minor > > When running the test > org.apache.derbyTesting.functionTests.tests.lang.TableFunctionTest, it fails > with the output shown below. This test blocks the proper execution of > suites.All and it was tested under Ubuntu 7.10 (also tested on Windows Vista > and it doesn't throw an error there). > There were 2 errors: > 1) > noSpecialCollation(org.apache.derbyTesting.functionTests.tests.lang.TableFunctionTest)java.sql.SQLException: > The exception 'java.lang.ClassNotFoundException: ERROR XBM0U: No class was > registered for identifier 495.' was thrown while evaluating an expression. > at > org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(SQLExceptionFactory.java:45) > at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Util.java:87) > at org.apache.derby.impl.jdbc.Util.seeNextException(Util.java:223) > at > org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(TransactionResourceImpl.java:398) > at > org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(TransactionResourceImpl.java:346) > at > org.apache.derby.impl.jdbc.EmbedConnection.handleException(EmbedConnection.java:2125) > at > org.apache.derby.impl.jdbc.ConnectionChild.handleException(ConnectionChild.java:81) > at > org.apache.derby.impl.jdbc.EmbedResultSet.closeOnTransactionError(EmbedResultSet.java:4320) > at > org.apache.derby.impl.jdbc.EmbedResultSet.movePosition(EmbedResultSet.java:463) > at > org.apache.derby.impl.jdbc.EmbedResultSet.next(EmbedResultSet.java:367) > at > org.apache.derbyTesting.functionTests.tests.lang.TableFunctionTest.assertResults(TableFunctionTest.java:1935) > at > org.apache.derbyTesting.functionTests.tests.lang.TableFunctionTest.assertResults(TableFunctionTest.java:1776) > at > org.apache.derbyTesting.functionTests.tests.lang.TableFunctionTest.assertResults(TableFunctionTest.java:1762) > at > org.apache.derbyTesting.functionTests.tests.lang.TableFunctionTest.simpleVTIResults(TableFunctionTest.java:1079) > at > org.apache.derbyTesting.functionTests.tests.lang.TableFunctionTest.tableFunctionTest(TableFunctionTest.java:920) > at > org.apache.derbyTesting.functionTests.tests.lang.TableFunctionTest.noSpecialCollation(TableFunctionTest.java:897) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at > org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:103) > Caused by: java.sql.SQLException: Java exception: 'ERROR XBM0U: No class was > registered for identifier 495.: java.lang.ClassNotFoundException'. > at > org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(SQLExceptionFactory.java:45) > at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Util.java:87) > at org.apache.derby.impl.jdbc.Util.javaException(Util.java:244) > at > org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(TransactionResourceImpl.java:403) > ... 29 more > Caused by: java.lang.ClassNotFoundException: ERROR XBM0U: No class was > registered for identifier 495. > at > org.apache.derby.iapi.services.io.FormatIdInputStream.readObject(FormatIdInputStream.java:129) > at > org.apache.derby.catalog.types.TypeDescriptorImpl.readExternal(TypeDescriptorImpl.java:491) > at > org.apache.derby.iapi.services.io.FormatIdInputStream.readObject(FormatIdInputStream.java:126) > at > org.apache.derby.impl.sql.execute.VTIResultSet.thawReturnType(VTIResultSet.java:696) > at > org.apache.derby.impl.sql.execute.VTI
[jira] Assigned: (DERBY-3617) failover on slave hangs after stopmaster on master.
[ https://issues.apache.org/jira/browse/DERBY-3617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] V.Narayanan reassigned DERBY-3617: -- Assignee: V.Narayanan > failover on slave hangs after stopmaster on master. > --- > > Key: DERBY-3617 > URL: https://issues.apache.org/jira/browse/DERBY-3617 > Project: Derby > Issue Type: Bug > Components: Replication >Affects Versions: 10.5.0.0 > Environment: OS: Fedora release 7 (Moonshine) 32bits - Linux > 2.6.23.15-80.fc7PAE #1 SMP Sun Feb 10 17:14:36 EST 2008 GNU/Linux > JVM: java version "1.6.0_01" > Java(TM) SE Runtime Environment (build 1.6.0_01-b06) > Java HotSpot(TM) Server VM (build 1.6.0_01-b06, mixed mode) > SVN: 647063 > Reporter: Ole Solberg >Assignee: V.Narayanan >Priority: Minor > Attachments: db_master-derby.log, db_slave-derby.log, log.out > > > 0. Master and slave in repl. mode. > 1. master: stopmaster > 2. slave failover. >hangs. > According to "Functional Specification for Derby Replication" Rev. 9.0: > "Failover": "... . The command is only accepted on the slave if the network > conection with the master is down." so expecting failover to return valid > Connection. > However, failover never finish. > See attached master and slave derby.log and testrun log.out. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3574) With client, attempting to get the lob length after commit or connection close if there was a call to length() before commit does not throw an exception
[ https://issues.apache.org/jira/browse/DERBY-3574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12586667#action_12586667 ] V.Narayanan commented on DERBY-3574: while working on Derby-694 I understood that Lob implemented Event callback methods in the UnitOfWorkListener interface. The methods are public void listenToUnitOfWork(); public void completeLocalCommit(java.util.Iterator listenerIterator); public void completeLocalRollback(java.util.Iterator listenerIterator); There are three implementations of the UnitOfWorkListener interface Lob,Statement and ResultSet. Each time an object of this type is created they are register themselves to the connection by doing the following agent_.connection_.CommitAndRollbackListeners_.put(this,null); when a End Unit of Work Condition (ENDUOWRM) Reply Mesage is received (see line no 738 NetConnectionReply.java) signifying that the unit of work has ended as a result of the last command a completeLocalCommit() or a completeLocalRollback() is called. These methods are also called in other places. Please refer Derby-694 for more background. Since the primary problem as pointed out is >"Well the lobs are freed on the server with commit/rollback, just not marked >invalid on the client." Could these method implementations in Lob.java be used to invalidate the Lob (isValid=false) when a commit or a rollback happens? Not sure, but maybe we need to call free() here. > With client, attempting to get the lob length after commit or connection > close if there was a call to length() before commit does not throw an > exception > -- > > Key: DERBY-3574 > URL: https://issues.apache.org/jira/browse/DERBY-3574 > Project: Derby > Issue Type: Bug > Components: JDBC, Network Client, Newcomer >Affects Versions: 10.5.0.0 >Reporter: Kathey Marsden >Assignee: Tiago R. Espinha >Priority: Trivial > Attachments: derby-3574.patch, TestLobLength.java > > > Attempting to get call Blob/Clob.length() after commit or connection close > does not fail if there was a previous call to length(). If no previous call > was made an exception is thrown as expected. > See attached program TestLobLength for repro with commit. If you comment out > the two lines to get the length before the commit we get the expected > exception. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3574) With client, attempting to get the lob length after commit or connection close if there was a call to length() before commit does not throw an exception
[ https://issues.apache.org/jira/browse/DERBY-3574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12586395#action_12586395 ] V.Narayanan commented on DERBY-3574: >What if instead of setting lengthObtained_ to false in a free() method on the >Lob, >we would, instead, extract the isValid property of Clob and Blob to its parent >class, >the Lob and set it to false on that free() method? I think this is a very good solution because you do not need to make a stored procedure call to determine that Lob is no longer valid. (unnecessary round trip to the server). >Then when we call sqlLength() on the Lob we could do something like: >if(lengthObtained_ && isValid) return sqlLength_; I think here if isValid is false you should do this throw new SqlException(null,new ClientMessageId(SQLState.LOB_OBJECT_INVALID)) .getSQLException(); > With client, attempting to get the lob length after commit or connection > close if there was a call to length() before commit does not throw an > exception > -- > > Key: DERBY-3574 > URL: https://issues.apache.org/jira/browse/DERBY-3574 > Project: Derby > Issue Type: Bug > Components: JDBC, Network Client, Newcomer >Affects Versions: 10.5.0.0 >Reporter: Kathey Marsden >Assignee: Tiago R. Espinha >Priority: Trivial > Attachments: derby-3574.patch, TestLobLength.java > > > Attempting to get call Blob/Clob.length() after commit or connection close > does not fail if there was a previous call to length(). If no previous call > was made an exception is thrown as expected. > See attached program TestLobLength for repro with commit. If you comment out > the two lines to get the length before the commit we get the expected > exception. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3574) With client, attempting to get the lob length after commit or connection close if there was a call to length() before commit does not throw an exception
[ https://issues.apache.org/jira/browse/DERBY-3574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12586388#action_12586388 ] V.Narayanan commented on DERBY-3574: I have suggested a possible workaround for the related issue Derby-3469. I think the solution suggested there if found OK will work for this issue also. > With client, attempting to get the lob length after commit or connection > close if there was a call to length() before commit does not throw an > exception > -- > > Key: DERBY-3574 > URL: https://issues.apache.org/jira/browse/DERBY-3574 > Project: Derby > Issue Type: Bug > Components: JDBC, Network Client, Newcomer >Affects Versions: 10.5.0.0 >Reporter: Kathey Marsden >Assignee: Tiago R. Espinha >Priority: Trivial > Attachments: derby-3574.patch, TestLobLength.java > > > Attempting to get call Blob/Clob.length() after commit or connection close > does not fail if there was a previous call to length(). If no previous call > was made an exception is thrown as expected. > See attached program TestLobLength for repro with commit. If you comment out > the two lines to get the length before the commit we get the expected > exception. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3469) Clob.length() doesn't detect a closed underlying connection in a consistent way
[
https://issues.apache.org/jira/browse/DERBY-3469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12586387#action_12586387
]
V.Narayanan commented on DERBY-3469:
This issue will have unexpected ramifications for the update sensitive Clob and
Blob streams.
The update sensitive streams upon creation depend on the sqlLength() method to
determine the
validity of the underlying Lob. If the sqlLength method returns the cached
length value these
streams will not fail upon creation (getBinaryStream() and other methods) but
when a read or
write is called upon them. I think they should uniformly fail when
getBinaryStream() is called.
A easy way I can think of resolving this problem is to reset the
"lengthObtained_" boolean, when
free(). This would ensure that the cached value is not used after a free is
called.
I would design this by introducing a free() method in Lob and setting
lengthObtained_=false in that
method and do a super.free() in the free methods of am/Clob and am/Blob.
I have not tested this solution yet, but it seems OK to me at first look.
> Clob.length() doesn't detect a closed underlying connection in a consistent
> way
> ---
>
> Key: DERBY-3469
> URL: https://issues.apache.org/jira/browse/DERBY-3469
> Project: Derby
> Issue Type: Bug
> Components: JDBC, Network Client
>Affects Versions: 10.3.2.1, 10.4.0.0
> Environment: Client-driver
>Reporter: Kristian Waagan
>Priority: Minor
> Attachments: ClosedClobTest.java
>
>
> Depending on the state of the Clob, the method length gives two different SQL
> states when the underlying connection has been closed.
> According to BlobClob4BlobTest.testClobAfterConnectionClose, it should throw
> 08003 (no current connection), but it might also throw XJ215 (invalid lob).
> I think this is caused indirectly by the following method in Lob:
> long sqlLength() throws SqlException
> {
> if (lengthObtained_) return sqlLength_;
>
> if (isLocator()) {
> sqlLength_ = getLocatorLength();
> lengthObtained_ = true;
> } else if (willBeLayerBStreamed()) {
> throw new SqlException(agent_.logWriter_,
>LOB_OBJECT_LENGTH_UNKNOWN_YET);
> } else {
> materializeStream(); // Will set sqlLength_
> }
> return sqlLength_;
> }
> In this method, getLocatorLength will check for a closed connection
> (somewhere down in prepareCallX i believe), whereas the cached length is
> returned if it has already been determined. Clob.length does not check for a
> closed connection.
> There are multiple fixes, but I think a proper investigation should be
> carried out before a solution is chosen.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2954) Add commands to NetworkServerControl for interacting with the replication functionality
[ https://issues.apache.org/jira/browse/DERBY-2954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12586301#action_12586301 ] V.Narayanan commented on DERBY-2954: This JIRA issues has caused changes to the codebase in the form of code that has first been committed and then been reverted. I decided to stick to fixed because there has been code changes as a result of this JIRA (although they have been reverted). Pls do go ahead and change it to "not fixed" if you think that is the right thing here. > Add commands to NetworkServerControl for interacting with the replication > functionality > --- > > Key: DERBY-2954 > URL: https://issues.apache.org/jira/browse/DERBY-2954 > Project: Derby > Issue Type: Sub-task > Components: Miscellaneous >Affects Versions: 10.4.0.0 > Reporter: V.Narayanan >Assignee: V.Narayanan > Fix For: 10.4.0.0 > > Attachments: NetworkServerControlCmds_v1.diff, > NetworkServerControlCmds_v1.stat, NetworkServerControlCmds_v2.diff, > NetworkServerControlCmds_v2.stat, NetworkServerControlCmds_v3.diff, > NetworkServerControlCmds_v3.stat, NetworkServerControlCmds_v4.diff, > NetworkServerControlCmds_v4.stat, NetworkServerControlCmds_v5.diff, > NetworkServerControlCmds_v5.stat, NetworkServerControlCmds_v6.diff, > NetworkServerControlCmds_v6.stat > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (DERBY-3455) Move replication methods from org.apache.derby.database.Database to org.apache.derby.iapi.db.Database
[ https://issues.apache.org/jira/browse/DERBY-3455?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] V.Narayanan resolved DERBY-3455. Resolution: Fixed Fix Version/s: 10.4.0.0 I have raised Derby-3600 to address the follow-up mentioned here. > Move replication methods from org.apache.derby.database.Database to > org.apache.derby.iapi.db.Database > - > > Key: DERBY-3455 > URL: https://issues.apache.org/jira/browse/DERBY-3455 > Project: Derby > Issue Type: Bug > Components: Replication >Affects Versions: 10.4.0.0 >Reporter: V.Narayanan >Assignee: V.Narayanan > Fix For: 10.4.0.0 > > Attachments: Derby3455.diff, Derby3455.stat, Derby3455_v2.diff, > Derby3455_v2.stat > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (DERBY-3600) Change replication methods in org.apache.derby.iapi.db.Database to throw StandardException instead of SQLException
Change replication methods in org.apache.derby.iapi.db.Database to throw StandardException instead of SQLException -- Key: DERBY-3600 URL: https://issues.apache.org/jira/browse/DERBY-3600 Project: Derby Issue Type: Bug Components: Replication Affects Versions: 10.5.0.0 Reporter: V.Narayanan -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (DERBY-3600) Change replication methods in org.apache.derby.iapi.db.Database to throw StandardException instead of SQLException
[ https://issues.apache.org/jira/browse/DERBY-3600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] V.Narayanan reassigned DERBY-3600: -- Assignee: V.Narayanan > Change replication methods in org.apache.derby.iapi.db.Database to throw > StandardException instead of SQLException > -- > > Key: DERBY-3600 > URL: https://issues.apache.org/jira/browse/DERBY-3600 > Project: Derby > Issue Type: Bug > Components: Replication >Affects Versions: 10.5.0.0 >Reporter: V.Narayanan >Assignee: V.Narayanan > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (DERBY-3553) Write tests for unlogged operations when replication is enabled
[ https://issues.apache.org/jira/browse/DERBY-3553?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] V.Narayanan reassigned DERBY-3553: -- Assignee: V.Narayanan > Write tests for unlogged operations when replication is enabled > --- > > Key: DERBY-3553 > URL: https://issues.apache.org/jira/browse/DERBY-3553 > Project: Derby > Issue Type: Sub-task > Components: Replication >Affects Versions: 10.5.0.0 > Reporter: V.Narayanan >Assignee: V.Narayanan > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3533) Replication fails when unlogged operations are used
[ https://issues.apache.org/jira/browse/DERBY-3533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] V.Narayanan updated DERBY-3533: --- Affects Version/s: 10.5.0.0 Derby-3551 and Derby-3552 which are sub-tasks of this issue have been resolved. However Derby-3553 is still open. Hence marking this issue as affecting both 10.4 (due to Derby-3551 and Derby-3552) and 10.5 (Derby-3553) > Replication fails when unlogged operations are used > --- > > Key: DERBY-3533 > URL: https://issues.apache.org/jira/browse/DERBY-3533 > Project: Derby > Issue Type: Bug > Components: Replication >Affects Versions: 10.4.0.0, 10.5.0.0 >Reporter: Øystein Grøvlen >Assignee: V.Narayanan > > I created an index while replication was running, and the slave seems to have > failed at that time. Below is excerpts from derby.log on the slave. The > container id referred to, matches the id of the index on the master. > BEGIN SHUTDOWN ERROR STACK - > BEGIN REPLICATION ERROR MESSAGE (3/11/08 2:32 PM) > ERROR XSLA7: Cannot redo operation Page Operation: Page(349,Container(0, > 1041)) pageVersion 180 : Insert : Slot=177 recordId=183 in the log. > at > org.apache.derby.iapi.error.StandardException.newException(StandardException.java:296) > at > org.apache.derby.impl.store.raw.log.FileLogger.redo(FileLogger.java:1525) > at > org.apache.derby.impl.store.raw.log.LogToFile.recover(LogToFile.java:920) > at org.apache.derby.impl.store.raw.RawStore.boot(RawStore.java:334) > at > org.apache.derby.impl.services.monitor.BaseMonitor.boot(BaseMonitor.java:1999) > at > org.apache.derby.impl.services.monitor.TopService.bootModule(TopService.java:291) > at > org.apache.derby.impl.services.monitor.BaseMonitor.startModule(BaseMonitor.java:553) > at > org.apache.derby.iapi.services.monitor.Monitor.bootServiceModule(Monitor.java:427) > at > org.apache.derby.impl.store.access.RAMAccessManager.boot(RAMAccessManager.java:1019) > at > org.apache.derby.impl.services.monitor.BaseMonitor.boot(BaseMonitor.java:1999) > at > org.apache.derby.impl.services.monitor.TopService.bootModule(TopService.java:291) > at > org.apache.derby.impl.services.monitor.BaseMonitor.startModule(BaseMonitor.java:553) > at > org.apache.derby.iapi.services.monitor.Monitor.bootServiceModule(Monitor.java:427) > at > org.apache.derby.impl.db.BasicDatabase.bootStore(BasicDatabase.java:789) > at org.apache.derby.impl.db.BasicDatabase.boot(BasicDatabase.java:205) > at > org.apache.derby.impl.db.SlaveDatabase.bootBasicDatabase(SlaveDatabase.java:421) > at > org.apache.derby.impl.db.SlaveDatabase.access$000(SlaveDatabase.java:70) > at > org.apache.derby.impl.db.SlaveDatabase$SlaveDatabaseBootThread.run(SlaveDatabase.java:308) > at java.lang.Thread.run(Thread.java:619) > Caused by: ERROR XSDG0: Page Page(349,Container(0, 1041)) could not be read > from disk. > at > org.apache.derby.iapi.error.StandardException.newException(StandardException.java:336) > at > org.apache.derby.impl.store.raw.data.CachedPage.readPage(CachedPage.java:688) > at > org.apache.derby.impl.store.raw.data.CachedPage.setIdentity(CachedPage.java:190) > at > org.apache.derby.impl.services.cache.ConcurrentCache.find(ConcurrentCache.java:288) > at > org.apache.derby.impl.store.raw.data.FileContainer.getAnyPage(FileContainer.java:2493) > at > org.apache.derby.impl.store.raw.data.BaseContainer.getAnyPage(BaseContainer.java:496) > at > org.apache.derby.impl.store.raw.data.BaseContainerHandle.getAnyPage(BaseContainerHandle.java:611) > at > org.apache.derby.impl.store.raw.data.PageBasicOperation.findpage(PageBasicOperation.java:304) > at > org.apache.derby.impl.store.raw.data.PageBasicOperation.needsRedo(PageBasicOperation.java:160) > at > org.apache.derby.impl.store.raw.log.FileLogger.redo(FileLogger.java:1395) > ... 17 more > Caused by: java.io.EOFException: Reached end of file while attempting to read > a whole page. > at > org.apache.derby.impl.store.raw.data.RAFContainer4.readFull(RAFContainer4.java:378) > at > org.apache.derby.impl.store.raw.data.RAFContainer4.readPage(RAFContainer4.java:201) > at > org.apache.derby.impl.store.raw.data.CachedPage.readPage(CachedPage.java:664) > ... 25 more > = begin nested exception, level (1) === > ERROR XSDG0: Pa
[jira] Updated: (DERBY-3553) Write tests for unlogged operations when replication is enabled
[ https://issues.apache.org/jira/browse/DERBY-3553?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] V.Narayanan updated DERBY-3553: --- Affects Version/s: (was: 10.4.0.0) The fix for logging of unlogged operations during replication has already gone in as part of 3551 and 3552. The tests will not be done as part of 10.4. Hence unmarking 10.4 and using 10.5. > Write tests for unlogged operations when replication is enabled > --- > > Key: DERBY-3553 > URL: https://issues.apache.org/jira/browse/DERBY-3553 > Project: Derby > Issue Type: Sub-task > Components: Replication >Affects Versions: 10.5.0.0 > Reporter: V.Narayanan > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (DERBY-3552) Handle jar files that are installed when replication is enabled
[ https://issues.apache.org/jira/browse/DERBY-3552?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] V.Narayanan resolved DERBY-3552. Resolution: Fixed Fix Version/s: 10.4.0.0 Necessary analysis for this issue has been done. The documentation based on the analysis and discussions have been added as part of issue Derby-3169 (Thanks to Kim for the fine work related to this documentation). Resolving this issue since the issue analysis and documentation has been done. > Handle jar files that are installed when replication is enabled > --- > > Key: DERBY-3552 > URL: https://issues.apache.org/jira/browse/DERBY-3552 > Project: Derby > Issue Type: Sub-task > Components: Replication >Affects Versions: 10.4.0.0, 10.5.0.0 > Reporter: V.Narayanan >Assignee: V.Narayanan > Fix For: 10.4.0.0 > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (DERBY-3552) Handle jar files that are installed when replication is enabled
[ https://issues.apache.org/jira/browse/DERBY-3552?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] V.Narayanan reassigned DERBY-3552: -- Assignee: V.Narayanan > Handle jar files that are installed when replication is enabled > --- > > Key: DERBY-3552 > URL: https://issues.apache.org/jira/browse/DERBY-3552 > Project: Derby > Issue Type: Sub-task > Components: Replication >Affects Versions: 10.4.0.0, 10.5.0.0 > Reporter: V.Narayanan >Assignee: V.Narayanan > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (DERBY-3454) 'java.lang.NullPointerException' is thrown when starting a master db before a slave one
[ https://issues.apache.org/jira/browse/DERBY-3454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] V.Narayanan resolved DERBY-3454. Resolution: Fixed Fix Version/s: 10.4.0.0 All relevant patches have been submitted and committed. Resolving issue! > 'java.lang.NullPointerException' is thrown when starting a master db before a > slave one > --- > > Key: DERBY-3454 > URL: https://issues.apache.org/jira/browse/DERBY-3454 > Project: Derby > Issue Type: Bug > Components: Replication >Affects Versions: 10.4.0.0 >Reporter: Serge Tsv >Assignee: V.Narayanan > Fix For: 10.4.0.0 > > Attachments: Derby3454.diff, Derby3454.stat > > > The 'java.lang.NullPointerException' exception is thrown when a database is > started in a master mode and is trying to establish a connection to an slave > database socket, which is not available. > The exception is by the MasterController#startMaster(). First, it tries to > setup connection with a slave database using a transmitter: > MasterController#setupConnection >-> transmitter = new ReplicationMessageTransmit(); > transmitter.initConnection() > -> new InetSocketAddress() -> createSocket() -> connect() > The connect() method throws a ConnectException, and so fails to create a > socketConn instance. The exception is then wrapped several times an > propagated back to the MasterController#startMaster() method. It's caught > there and then a MasterController#teardownNetwork() method is called, which > tries to send a STOP message using the aforementioned transmitter, which > hasn't been able to init a connection. > A transmitter simply tries to call socketConn.writeMessage(message), which > throws NPE because socketConn is null. > Thanks! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (DERBY-2954) Add commands to NetworkServerControl for interacting with the replication functionality
[ https://issues.apache.org/jira/browse/DERBY-2954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] V.Narayanan resolved DERBY-2954. Resolution: Fixed Fix Version/s: 10.4.0.0 "NetworkServerControlImpl will not support commands for replication." Resolving issue since all patches relevant to this have been submitted or committed. > Add commands to NetworkServerControl for interacting with the replication > functionality > --- > > Key: DERBY-2954 > URL: https://issues.apache.org/jira/browse/DERBY-2954 > Project: Derby > Issue Type: Sub-task > Components: Miscellaneous >Affects Versions: 10.4.0.0 >Reporter: V.Narayanan >Assignee: V.Narayanan > Fix For: 10.4.0.0 > > Attachments: NetworkServerControlCmds_v1.diff, > NetworkServerControlCmds_v1.stat, NetworkServerControlCmds_v2.diff, > NetworkServerControlCmds_v2.stat, NetworkServerControlCmds_v3.diff, > NetworkServerControlCmds_v3.stat, NetworkServerControlCmds_v4.diff, > NetworkServerControlCmds_v4.stat, NetworkServerControlCmds_v5.diff, > NetworkServerControlCmds_v5.stat, NetworkServerControlCmds_v6.diff, > NetworkServerControlCmds_v6.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-3554) Change Collation test to run DatabaseMetaDataTest, BatchUpdateTest,GroupByExpressionTest, and UpdateableResultSetTest for only one locale
[ https://issues.apache.org/jira/browse/DERBY-3554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12586282#action_12586282 ] V.Narayanan commented on DERBY-3554: I think a commit message for this issue has wrongly appeared in Derby-3454 Found this message in Derby-3454 ASF #640982 Tue Mar 25 14:06:03 PDT 2008kmarsden DERBY-3454 Change Collation test to run DatabaseMetaDataTest, BatchUpdateTest,GroupByExpressionTest, and UpdateableResultSetTest for only one locale Contributed by Suran Jayathilaka (suranjay at gmail dot com) Files Changed MODIFY /db/derby/code/trunk/java/testing/org/apache/derbyTesting/functionTests/tests/lang/CollationTest.java > Change Collation test to run DatabaseMetaDataTest, > BatchUpdateTest,GroupByExpressionTest, and UpdateableResultSetTest for only > one locale > - > > Key: DERBY-3554 > URL: https://issues.apache.org/jira/browse/DERBY-3554 > Project: Derby > Issue Type: Improvement > Components: Newcomer, Test >Affects Versions: 10.5.0.0 >Reporter: Kathey Marsden >Assignee: Suran Jayathilaka >Priority: Minor > Fix For: 10.5.0.0 > > Attachments: derby-3554-fixed.patch > > > Currently CollationTest runs DatabaseMetaDataTest, > BatchUpdateTest,GroupByExpressionTest, and UpdateableResultSetTest for > multiple locales and territory based collation. It would be sufficient for > these to run with a single locale and would save some time running tests. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (DERBY-3358) After an incorrect(unsuccesfull) startMaster comand, further correct startMaster attempts also fail.
[
https://issues.apache.org/jira/browse/DERBY-3358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
V.Narayanan resolved DERBY-3358.
Resolution: Fixed
Fix Version/s: 10.4.0.0
All relevant patches have been submitted and committed.
Resolving issue!
> After an incorrect(unsuccesfull) startMaster comand, further correct
> startMaster attempts also fail.
>
>
> Key: DERBY-3358
> URL: https://issues.apache.org/jira/browse/DERBY-3358
> Project: Derby
> Issue Type: Bug
> Components: Replication
>Affects Versions: 10.4.0.0
> Environment: Trunk (615841) + patch DERBY-3205/stopSlave_v1b
>Reporter: Ole Solberg
>Assignee: V.Narayanan
> Fix For: 10.4.0.0
>
> Attachments: Derby3358.diff, Derby3358.stat, Derby3358_v2.diff,
> Derby3358_v2.stat, Derby3358_v3.diff, Derby3358_v3.stat, Derby3358_v4.diff,
> Derby3358_v4.stat, Derby3358_v5.diff, Derby3358_v5.stat, Derby3358_v6.diff,
> Derby3358_v6.stat
>
>
> Slave and master servers started.
> startSlave:
> CONNECT
> 'jdbc:derby://atum11:/test;startSlave=true;slaveHost=atum11;slavePort=8989';
> ERROR XRE08: DERBY SQL error: SQLCODE: -1, SQLSTATE: XRE08, SQLERRMC:
> Replication slave mode started successfully for database 'test'. Connection
> refused because the database is in replication slave mode.
> startMaster without specifying slavePort - will use default?
> CONNECT 'jdbc:derby://atum11:/test;startMaster=true;slaveHost=atum11';
> ERROR XRE04: DERBY SQL error: SQLCODE: -1, SQLSTATE: XRE04, SQLERRMC:
> nullXRE04
> master derby.log:
> 2008-01-29 10:02:53.097 GMT:
> Booting Derby version The Apache Software Foundation - Apache Derby -
> 10.4.0.0 alpha - (615841M): instance c013800d-0117-c4fb-9156-03bf6570
> on database directory
> /export/home/tmp/os136789/Replication_common_Trunk/master/test
> Database Class Loader started - derby.database.classpath=''
> 2008-01-29 10:02:53.256 GMT Thread[DRDAConnThread_2,5,main] (XID = 419),
> (SESSIONID = 0), (DATABASE = test), (DRDAID = {1}), Cleanup action starting
> java.sql.SQLException: Could not establish a connection to the peer of the
> replicated database 'null'.
> .
> .
> Cleanup action completed
> 2008-01-29 10:02:53.260 GMT Thread[DRDAConnThread_2,5,main] (DATABASE =
> test), (DRDAID = {1}), Could not establish a connection to the peer of the
> replicated database 'null'.
> startMaster specyfying slavePort:
> CONNECT
> 'jdbc:derby://atum11:/test;startMaster=true;slaveHost=atum11;slavePort=8989';
> ERROR XRE04: DERBY SQL error: SQLCODE: -1, SQLSTATE: XRE04, SQLERRMC:
> nullXRE04
> master derby.log:
> 2008-01-29 10:03:38.201 GMT Thread[DRDAConnThread_2,5,main] (XID = 420),
> (SESSIONID = 1), (DATABASE = test), (DRDAID = {2}), Cleanup action starting
> java.sql.SQLException: Could not establish a connection to the peer of the
> replicated database 'null'.
> .
> .
> Cleanup action completed
> 2008-01-29 10:03:38.205 GMT Thread[DRDAConnThread_2,5,main] (DATABASE =
> test), (DRDAID = {2}), Could not establish a connection to the peer of the
> replicated database 'null'.
> Additional observation/comment:
>
> It would be helpful for debugging if slaveHost and slavePort were written in
> error messages and into derby.log.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3489) Error message XRE04 does not include the right port number.
[ https://issues.apache.org/jira/browse/DERBY-3489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12585581#action_12585581 ] V.Narayanan commented on DERBY-3489: The replication suite of tests passed fine [EMAIL PROTECTED]:~/work/workspaces/Derby3489/test2$ java junit.textui.TestRunner org.apache.derbyTesting.functionTests.tests.replicationTests.ReplicationSuite Time: 706.684 OK (8 tests) > Error message XRE04 does not include the right port number. > --- > > Key: DERBY-3489 > URL: https://issues.apache.org/jira/browse/DERBY-3489 > Project: Derby > Issue Type: Bug > Components: Replication >Affects Versions: 10.4.0.0 >Reporter: Øystein Grøvlen >Assignee: V.Narayanan > Attachments: Derby3489_1.diff, Derby3489_1.stat, Derby3489_2.diff, > Derby3489_2.stat, Derby3489_3.diff, Derby3489_3.stat, Derby3489_4.diff, > Derby3489_4.stat > > > If the master is not able to connect to the slave, the error messages does > not include the right port number: > ij> connect > 'jdbc:derby:masterDB;user=oystein;password=pass;startMaster=true;slaveHost=localhost;slavePort=9901'; > ERROR XRE04: Could not establish a connection to the peer of the replicated > database 'masterDB' on address 'localhost:-1'. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3489) Error message XRE04 does not include the right port number.
[ https://issues.apache.org/jira/browse/DERBY-3489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] V.Narayanan updated DERBY-3489: --- Attachment: Derby3489_4.stat Derby3489_4.diff * Moved logging back to the ReplicationMessageReceive constructor * Replaced unintended diff > Error message XRE04 does not include the right port number. > --- > > Key: DERBY-3489 > URL: https://issues.apache.org/jira/browse/DERBY-3489 > Project: Derby > Issue Type: Bug > Components: Replication >Affects Versions: 10.4.0.0 >Reporter: Øystein Grøvlen >Assignee: V.Narayanan > Attachments: Derby3489_1.diff, Derby3489_1.stat, Derby3489_2.diff, > Derby3489_2.stat, Derby3489_3.diff, Derby3489_3.stat, Derby3489_4.diff, > Derby3489_4.stat > > > If the master is not able to connect to the slave, the error messages does > not include the right port number: > ij> connect > 'jdbc:derby:masterDB;user=oystein;password=pass;startMaster=true;slaveHost=localhost;slavePort=9901'; > ERROR XRE04: Could not establish a connection to the peer of the replicated > database 'masterDB' on address 'localhost:-1'. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3489) Error message XRE04 does not include the right port number.
[ https://issues.apache.org/jira/browse/DERBY-3489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] V.Narayanan updated DERBY-3489: --- Attachment: Derby3489_3.stat Derby3489_3.diff Thank you for the comments/reviews Oystein! I have addressed all the issues pointed out. I have verified that this patch works for default values in both Master and Slave before making the following changes >- ReplicationMessageReceive constructor: Parameter dbname is no > longer used > >- ReplicationMessageReceive: Import of UnknownHostException no longer > necessary. > >- MessageId: Does not seem to contain any significant change. But since these changes were more or less minor and would not have affected code flow I thought it is safe and the verification does not need to be done again after making these changes. Master -- ij version 10.5 ij> connect 'jdbc:derby://localhost:1527/replicationdb'; ij> connect 'jdbc:derby://localhost:1527/replicationdb;startMaster=true;slaveHost=localhost'; ij(CONNECTION1)> create table narayanan(age int, name varchar(30)); 0 rows inserted/updated/deleted ij(CONNECTION1)> connect 'jdbc:derby://localhost:1527/replicationdb;failover=true'; ERROR XRE20: DERBY SQL error: SQLCODE: -1, SQLSTATE: XRE20, SQLERRMC: Failover performed successfully for database 'replicationdb', the database has been shutdown. ij(CONNECTION1)> Slave - ij version 10.5 ij> connect 'jdbc:derby://localhost:1528/replicationdb;startSlave=true;slaveHost=localhost'; ERROR XRE08: DERBY SQL error: SQLCODE: -1, SQLSTATE: XRE08, SQLERRMC: Replication slave mode started successfully for database 'replicationdb'. Connection refused because the database is in replication slave mode. ij> connect 'jdbc:derby://localhost:1528/replicationdb'; ij> select * from narayanan; AGE|NAME -- 0 rows selected The replication suite of tests also passed fine [EMAIL PROTECTED]:~/work/workspaces/Derby3489/test2$ java junit.textui.TestRunner org.apache.derbyTesting.functionTests.tests.replicationTests.ReplicationSuite Time: 629.492 OK (8 tests) > Error message XRE04 does not include the right port number. > --- > > Key: DERBY-3489 > URL: https://issues.apache.org/jira/browse/DERBY-3489 > Project: Derby > Issue Type: Bug > Components: Replication >Affects Versions: 10.4.0.0 >Reporter: Øystein Grøvlen >Assignee: V.Narayanan > Attachments: Derby3489_1.diff, Derby3489_1.stat, Derby3489_2.diff, > Derby3489_2.stat, Derby3489_3.diff, Derby3489_3.stat > > > If the master is not able to connect to the slave, the error messages does > not include the right port number: > ij> connect > 'jdbc:derby:masterDB;user=oystein;password=pass;startMaster=true;slaveHost=localhost;slavePort=9901'; > ERROR XRE04: Could not establish a connection to the peer of the replicated > database 'masterDB' on address 'localhost:-1'. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3169) Add documentation for replication
[ https://issues.apache.org/jira/browse/DERBY-3169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12584993#action_12584993 ] V.Narayanan commented on DERBY-3169: >I agree that something should probably be done about documenting unlogged >operations. >The current version of the backup file you mention, >http://db.apache.org/derby/docs/dev/adminguide/cadminhubbkup01.html, describes >two >unlogged operations. How many more are there? I know of three unlogged operations kim 1) Creation of indexes http://db.apache.org/derby/docs/dev/ref/rrefsqlj20937.html 2) Bulk import operations http://db.apache.org/derby/docs/dev/tools/ctoolsimport16245.html 3) Installation of Jars http://db.apache.org/derby/docs/dev/devguide/cdevdeploy23812.html >If these are the only ones, we could leave the documentation where it is and >refer people to >this topic. I am OK with doing this. If we create a separate documentation page for this, we could list all the operations there and point them to the corresponding documentation link for each operation. For example if we take import there are quite a few import procedures, we could probably list them all and point them to the corresponding documentation links. > Add documentation for replication > - > > Key: DERBY-3169 > URL: https://issues.apache.org/jira/browse/DERBY-3169 > Project: Derby > Issue Type: Improvement > Components: Documentation >Affects Versions: 10.4.0.0 >Reporter: Jørgen Løland >Assignee: Kim Haase > Fix For: 10.4.0.0 > > Attachments: cadminreplicstartrun.html, DERBY-3169-2.diff, > DERBY-3169-2.stat, DERBY-3169-2.zip, DERBY-3169-3.diff, DERBY-3169-3.stat, > DERBY-3169-3.zip, DERBY-3169-4.diff, DERBY-3169-4.zip, DERBY-3169-5.diff, > DERBY-3169-5.zip, DERBY-3169-6.diff, DERBY-3169-7.diff, DERBY-3169.diff, > DERBY-3169.stat, DERBY-3169.zip, rrefattribstartmaster.html, > rrefattribstartmaster.html > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3169) Add documentation for replication
[ https://issues.apache.org/jira/browse/DERBY-3169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12584642#action_12584642 ] V.Narayanan commented on DERBY-3169: In mentioning "Unlogged operations" we have nothing wrong considering that we have kept with similar usage in the documentation for online backup here http://db.apache.org/derby/docs/10.2/adminguide/cadminhubbkup01.html But, I tried to search for whether unlogged operations were documented somewhere is Derby, but failed to find a place where the list of unlogged operations were documented. When a user looks at our documentation he might think what an unlogged operation is We have two options 1) Create a place in the derby documentation where we mention what an unlogged operation is (not sure if it is there already) and link it to this page. 2) Maybe we could mention the list of unlogged operations in this documentation I personally prefer 1) because I feel it will act as a common reference point for the people who search for this keyword in both online backup and replication. If this is already there we might want to re-direct the user to that link. > Add documentation for replication > - > > Key: DERBY-3169 > URL: https://issues.apache.org/jira/browse/DERBY-3169 > Project: Derby > Issue Type: Improvement > Components: Documentation >Affects Versions: 10.4.0.0 >Reporter: Jørgen Løland >Assignee: Kim Haase > Fix For: 10.4.0.0 > > Attachments: cadminreplicstartrun.html, DERBY-3169-2.diff, > DERBY-3169-2.stat, DERBY-3169-2.zip, DERBY-3169-3.diff, DERBY-3169-3.stat, > DERBY-3169-3.zip, DERBY-3169-4.diff, DERBY-3169-4.zip, DERBY-3169-5.diff, > DERBY-3169-5.zip, DERBY-3169-6.diff, DERBY-3169-7.diff, DERBY-3169.diff, > DERBY-3169.stat, DERBY-3169.zip, rrefattribstartmaster.html, > rrefattribstartmaster.html > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3169) Add documentation for replication
[ https://issues.apache.org/jira/browse/DERBY-3169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12584625#action_12584625 ] V.Narayanan commented on DERBY-3169: Thank you for the follow-up on 3551 and 3552 Kim! The changes in the patch DERBY-3169-7.diff and the corresponding output files look good. +1 for a commit. > Add documentation for replication > - > > Key: DERBY-3169 > URL: https://issues.apache.org/jira/browse/DERBY-3169 > Project: Derby > Issue Type: Improvement > Components: Documentation >Affects Versions: 10.4.0.0 >Reporter: Jørgen Løland >Assignee: Kim Haase > Fix For: 10.4.0.0 > > Attachments: cadminreplicstartrun.html, DERBY-3169-2.diff, > DERBY-3169-2.stat, DERBY-3169-2.zip, DERBY-3169-3.diff, DERBY-3169-3.stat, > DERBY-3169-3.zip, DERBY-3169-4.diff, DERBY-3169-4.zip, DERBY-3169-5.diff, > DERBY-3169-5.zip, DERBY-3169-6.diff, DERBY-3169-7.diff, DERBY-3169.diff, > DERBY-3169.stat, DERBY-3169.zip, rrefattribstartmaster.html, > rrefattribstartmaster.html > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3567) AsynchronousLogShipper#forceFlush should time out
[ https://issues.apache.org/jira/browse/DERBY-3567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12584591#action_12584591 ] V.Narayanan commented on DERBY-3567: what happens if network goes down in flushBuffer? The problem reported in this JIRA seems to exist in flushBuffer also. I think we need a thread in that method too. > AsynchronousLogShipper#forceFlush should time out > - > > Key: DERBY-3567 > URL: https://issues.apache.org/jira/browse/DERBY-3567 > Project: Derby > Issue Type: Bug > Components: Replication >Affects Versions: 10.4.0.0, 10.5.0.0 >Reporter: Jørgen Løland >Assignee: Jørgen Løland > Attachments: derby-3567-1a.diff, derby-3567-1a.stat, > derby-3567-1b.diff > > > If the network connection to the slave is lost, > ObjectOutputStream#writeObject may be blocked for 2 minutes before failing > (not configurable TCP property). > Currently, ALS#forceFlush sends a chunk of log to the slave using the client > thread. The client thread cannot be blocked for 2 minutes before giving up. > Rather, it should notify the log shipper that it has to send log immediately, > and then wait for a short while (until notified or e.g. maximum 5 seconds). > If the log shipper has not been able to empty some space in the log buffer by > then, replication should be stopped. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (DERBY-3567) AsynchronousLogShipper#forceFlush should time out
[ https://issues.apache.org/jira/browse/DERBY-3567?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] V.Narayanan reassigned DERBY-3567: -- Assignee: Jørgen Løland The patch attached by Jorgen to this issue looks good to me. Jorgen has also indicated that the replication suite of tests pass. Hence assigning this issue to him. > AsynchronousLogShipper#forceFlush should time out > - > > Key: DERBY-3567 > URL: https://issues.apache.org/jira/browse/DERBY-3567 > Project: Derby > Issue Type: Bug > Components: Replication >Affects Versions: 10.4.0.0, 10.5.0.0 >Reporter: Jørgen Løland >Assignee: Jørgen Løland > Attachments: derby-3567-1a.diff, derby-3567-1a.stat > > > If the network connection to the slave is lost, > ObjectOutputStream#writeObject may be blocked for 2 minutes before failing > (not configurable TCP property). > Currently, ALS#forceFlush sends a chunk of log to the slave using the client > thread. The client thread cannot be blocked for 2 minutes before giving up. > Rather, it should notify the log shipper that it has to send log immediately, > and then wait for a short while (until notified or e.g. maximum 5 seconds). > If the log shipper has not been able to empty some space in the log buffer by > then, replication should be stopped. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3567) AsynchronousLogShipper#forceFlush should time out
[ https://issues.apache.org/jira/browse/DERBY-3567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12584502#action_12584502 ] V.Narayanan commented on DERBY-3567: The patch looks complete and very good, Work has been done to remove the dependency of the forceFlush function on the client thread and instead make the log shipper thread do the work. I request the patch attached to this issue to be pls considered for a commit. > AsynchronousLogShipper#forceFlush should time out > - > > Key: DERBY-3567 > URL: https://issues.apache.org/jira/browse/DERBY-3567 > Project: Derby > Issue Type: Bug > Components: Replication >Affects Versions: 10.4.0.0, 10.5.0.0 >Reporter: Jørgen Løland > Attachments: derby-3567-1a.diff, derby-3567-1a.stat > > > If the network connection to the slave is lost, > ObjectOutputStream#writeObject may be blocked for 2 minutes before failing > (not configurable TCP property). > Currently, ALS#forceFlush sends a chunk of log to the slave using the client > thread. The client thread cannot be blocked for 2 minutes before giving up. > Rather, it should notify the log shipper that it has to send log immediately, > and then wait for a short while (until notified or e.g. maximum 5 seconds). > If the log shipper has not been able to empty some space in the log buffer by > then, replication should be stopped. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3552) Handle jar files that are installed when replication is enabled
[ https://issues.apache.org/jira/browse/DERBY-3552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12584425#action_12584425 ] V.Narayanan commented on DERBY-3552: >I guess the jar installation is recorded in the transaction log that gets sent >over to the slave an applied, so the slave thinks the jars are there even >though >they aren't? correct >It seems as if the error message when you try to run startSlave is rather >misleading. >It says the database is in slave mode, even after a failover, when it is not >actually in >slave mode and the real problem is the jar problem. I may be misunderstanding >the context, >though. When this message is thrown ERROR 08004: DERBY SQL error: SQLCODE: -1, SQLSTATE: 08004, SQLERRMC: Connection refused to database 'replicationdb' because it is in replication slave mode. We have not attempted failover yet. I just posted that message for completeness sake. Failover is attempted before taking a connection to the slave database (i.e.) before this step ij> connect 'jdbc:derby://localhost:1528/replicationdb'; It succeeds without throwing any exception > Handle jar files that are installed when replication is enabled > --- > > Key: DERBY-3552 > URL: https://issues.apache.org/jira/browse/DERBY-3552 > Project: Derby > Issue Type: Sub-task > Components: Replication >Affects Versions: 10.4.0.0, 10.5.0.0 >Reporter: V.Narayanan > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3509) The replication log shipper is not notified when a new replication transmitter is instantiated in MC#handleException.
[ https://issues.apache.org/jira/browse/DERBY-3509?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] V.Narayanan updated DERBY-3509: --- Attachment: Derby3509_1.stat Derby3509_1.diff I have modified the handleException method to return the transmitter object that is created. The log shipper bases its decision on whether it should continue with the log shipping based on if a valid transmitter object is created. > The replication log shipper is not notified when a new replication > transmitter is instantiated in MC#handleException. > - > > Key: DERBY-3509 > URL: https://issues.apache.org/jira/browse/DERBY-3509 > Project: Derby > Issue Type: Bug > Components: Newcomer, Replication >Affects Versions: 10.4.0.0 >Reporter: Jørgen Løland >Assignee: V.Narayanan >Priority: Minor > Attachments: Derby3509_1.diff, Derby3509_1.stat > > > In MasterController#handleException, a new ReplicationMessageTransmit object > is created if the exception is IOException. However, the logShipper is not > notified that the new transmitter should be used. A possible solution would > be to add a setTransmitter method to AsynchronousLogShipper. Note that the > logShipper may contain state information that cannot be discarded, so it > cannot be reinstantiated. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3509) The replication log shipper is not notified when a new replication transmitter is instantiated in MC#handleException.
[ https://issues.apache.org/jira/browse/DERBY-3509?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] V.Narayanan updated DERBY-3509: --- Derby Info: [Patch Available] > The replication log shipper is not notified when a new replication > transmitter is instantiated in MC#handleException. > - > > Key: DERBY-3509 > URL: https://issues.apache.org/jira/browse/DERBY-3509 > Project: Derby > Issue Type: Bug > Components: Newcomer, Replication >Affects Versions: 10.4.0.0 >Reporter: Jørgen Løland >Assignee: V.Narayanan >Priority: Minor > Attachments: Derby3509_1.diff, Derby3509_1.stat > > > In MasterController#handleException, a new ReplicationMessageTransmit object > is created if the exception is IOException. However, the logShipper is not > notified that the new transmitter should be used. A possible solution would > be to add a setTransmitter method to AsynchronousLogShipper. Note that the > logShipper may contain state information that cannot be discarded, so it > cannot be reinstantiated. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3552) Handle jar files that are installed when replication is enabled
[
https://issues.apache.org/jira/browse/DERBY-3552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12584021#action_12584021
]
V.Narayanan commented on DERBY-3552:
Below is the trial of trying to install on the slave after a failover without a
remove/replace
ij version 10.5
Slave start
---
ij> connect
'jdbc:derby://localhost:1528/replicationdb;startSlave=true;slaveHost=localhost;slavePort=8001';
ERROR 08004: DERBY SQL error: SQLCODE: -1, SQLSTATE: 08004, SQLERRMC:
Connection refused to database 'replicationdb' because it is in replication
slave mode.
Taking connection on the slave after failover
-
ij> connect 'jdbc:derby://localhost:1528/replicationdb';
Now try to install on the slave without a remove/replace
-
ij> CALL
SQLJ.install_jar('/home/vn/work/scripts/replication/ReturnOne.jar','APP.ReturnOneJar',0);
ERROR X0Y32: Jar file 'RETURNONEJAR' already exists in Schema 'APP'.
ij>
> Handle jar files that are installed when replication is enabled
> ---
>
> Key: DERBY-3552
> URL: https://issues.apache.org/jira/browse/DERBY-3552
> Project: Derby
> Issue Type: Sub-task
> Components: Replication
>Affects Versions: 10.4.0.0, 10.5.0.0
>Reporter: V.Narayanan
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3552) Handle jar files that are installed when replication is enabled
[ https://issues.apache.org/jira/browse/DERBY-3552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12584011#action_12584011 ] V.Narayanan commented on DERBY-3552: Kim says >Why would you need to do a replace, or a remove/install, on the slave? If the >jars are not installed on the slave, >I would think you would just do an install. Narayanan says (in an earlier comment) >This would mean that allowing jar file operations during deletion would result >in the system catalog table on the slave having a reference to the jar file >that >does not exist in the replicated database So even if you do not do an install the derby system will assume the jar to be present and calling a function that depends on the jar would result in (from an earlier run posted in the comments) >ij> values myInc (5,10); >ERROR 42X51: The class 'MyMathFuncs' does not exist or is inaccessible. This >can happen if the class is not public. >ERROR XJ001: Java exception: 'MyMathFuncs: java.lang.ClassNotFoundException'. Hence you need to replace, remove/install to modify the earlier system catalog entry for that jar. > Handle jar files that are installed when replication is enabled > --- > > Key: DERBY-3552 > URL: https://issues.apache.org/jira/browse/DERBY-3552 > Project: Derby > Issue Type: Sub-task > Components: Replication >Affects Versions: 10.4.0.0, 10.5.0.0 >Reporter: V.Narayanan > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (DERBY-3509) The replication log shipper is not notified when a new replication transmitter is instantiated in MC#handleException.
[ https://issues.apache.org/jira/browse/DERBY-3509?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] V.Narayanan reassigned DERBY-3509: -- Assignee: V.Narayanan > The replication log shipper is not notified when a new replication > transmitter is instantiated in MC#handleException. > - > > Key: DERBY-3509 > URL: https://issues.apache.org/jira/browse/DERBY-3509 > Project: Derby > Issue Type: Bug > Components: Newcomer, Replication >Affects Versions: 10.4.0.0 >Reporter: Jørgen Løland >Assignee: V.Narayanan >Priority: Minor > > In MasterController#handleException, a new ReplicationMessageTransmit object > is created if the exception is IOException. However, the logShipper is not > notified that the new transmitter should be used. A possible solution would > be to add a setTransmitter method to AsynchronousLogShipper. Note that the > logShipper may contain state information that cannot be discarded, so it > cannot be reinstantiated. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (DERBY-3489) Error message XRE04 does not include the right port number.
[ https://issues.apache.org/jira/browse/DERBY-3489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12583642#action_12583642 ] narayanan edited comment on DERBY-3489 at 3/31/08 4:30 AM: - Prints a message in ReplicationMessageReceive once the server socket is created. Restored the previously deleted message. java/shared/org/apache/derby/shared/common/reference/MessageId.java shows up in the diff because I deleted some trailing spaces in R011. I thought the spaces should not be there. Ran replication tests on Derby3489_2.diff. [EMAIL PROTECTED]:~/work/workspaces/Derby3489/test1$ java junit.textui.TestRunner org.apache.derbyTesting.functionTests.tests.replicationTests.ReplicationSuite Time: 652.241 OK (8 tests) was (Author: narayanan): Prints a message in ReplicationMessageReceive once the server socket is created. Restored the previously deleted message. java/shared/org/apache/derby/shared/common/reference/MessageId.java shows up in the diff because I deleted some trailing spaces in R011. I thought the spaces should not be there. > Error message XRE04 does not include the right port number. > --- > > Key: DERBY-3489 > URL: https://issues.apache.org/jira/browse/DERBY-3489 > Project: Derby > Issue Type: Bug > Components: Replication >Affects Versions: 10.4.0.0 >Reporter: Øystein Grøvlen >Assignee: V.Narayanan > Attachments: Derby3489_1.diff, Derby3489_1.stat, Derby3489_2.diff, > Derby3489_2.stat > > > If the master is not able to connect to the slave, the error messages does > not include the right port number: > ij> connect > 'jdbc:derby:masterDB;user=oystein;password=pass;startMaster=true;slaveHost=localhost;slavePort=9901'; > ERROR XRE04: Could not establish a connection to the peer of the replicated > database 'masterDB' on address 'localhost:-1'. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3489) Error message XRE04 does not include the right port number.
[ https://issues.apache.org/jira/browse/DERBY-3489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] V.Narayanan updated DERBY-3489: --- Attachment: Derby3489_2.stat Derby3489_2.diff Prints a message in ReplicationMessageReceive once the server socket is created. Restored the previously deleted message. java/shared/org/apache/derby/shared/common/reference/MessageId.java shows up in the diff because I deleted some trailing spaces in R011. I thought the spaces should not be there. > Error message XRE04 does not include the right port number. > --- > > Key: DERBY-3489 > URL: https://issues.apache.org/jira/browse/DERBY-3489 > Project: Derby > Issue Type: Bug > Components: Replication >Affects Versions: 10.4.0.0 >Reporter: Øystein Grøvlen >Assignee: V.Narayanan > Attachments: Derby3489_1.diff, Derby3489_1.stat, Derby3489_2.diff, > Derby3489_2.stat > > > If the master is not able to connect to the slave, the error messages does > not include the right port number: > ij> connect > 'jdbc:derby:masterDB;user=oystein;password=pass;startMaster=true;slaveHost=localhost;slavePort=9901'; > ERROR XRE04: Could not establish a connection to the peer of the replicated > database 'masterDB' on address 'localhost:-1'. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3489) Error message XRE04 does not include the right port number.
[ https://issues.apache.org/jira/browse/DERBY-3489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12583623#action_12583623 ] V.Narayanan commented on DERBY-3489: > Does this mean that the slave will never report which port it listens on? Seemingly that is the only place where the slave port is reported. So the answer to the question is yes. > The message of which port the slave listens to is very valuable when > debugging why replication > does not start successfully. I agree > It could be that the message should be printed somewhere else than it is > today, OK, I will move the message after successful creation of the server socket and before accepting on the socket. > Error message XRE04 does not include the right port number. > --- > > Key: DERBY-3489 > URL: https://issues.apache.org/jira/browse/DERBY-3489 > Project: Derby > Issue Type: Bug > Components: Replication >Affects Versions: 10.4.0.0 > Reporter: Øystein Grøvlen >Assignee: V.Narayanan > Attachments: Derby3489_1.diff, Derby3489_1.stat > > > If the master is not able to connect to the slave, the error messages does > not include the right port number: > ij> connect > 'jdbc:derby:masterDB;user=oystein;password=pass;startMaster=true;slaveHost=localhost;slavePort=9901'; > ERROR XRE04: Could not establish a connection to the peer of the replicated > database 'masterDB' on address 'localhost:-1'. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3489) Error message XRE04 does not include the right port number.
[ https://issues.apache.org/jira/browse/DERBY-3489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] V.Narayanan updated DERBY-3489: --- Derby Info: [Patch Available] > Error message XRE04 does not include the right port number. > --- > > Key: DERBY-3489 > URL: https://issues.apache.org/jira/browse/DERBY-3489 > Project: Derby > Issue Type: Bug > Components: Replication >Affects Versions: 10.4.0.0 >Reporter: Øystein Grøvlen >Assignee: V.Narayanan > Attachments: Derby3489_1.diff, Derby3489_1.stat > > > If the master is not able to connect to the slave, the error messages does > not include the right port number: > ij> connect > 'jdbc:derby:masterDB;user=oystein;password=pass;startMaster=true;slaveHost=localhost;slavePort=9901'; > ERROR XRE04: Could not establish a connection to the peer of the replicated > database 'masterDB' on address 'localhost:-1'. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3489) Error message XRE04 does not include the right port number.
[
https://issues.apache.org/jira/browse/DERBY-3489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
V.Narayanan updated DERBY-3489:
---
Attachment: Derby3489_1.stat
Derby3489_1.diff
*
java/engine/org/apache/derby/impl/store/replication/net/ReplicationMessageTransmit.java
The constructor has been modified to accept the SlaveAddress object instead of
a host name
and port number as was happening previously.
*
java/engine/org/apache/derby/impl/store/replication/net/ReplicationMessageReceive.java
* java/engine/org/apache/derby/loc/messages.xml
* java/shared/org/apache/derby/shared/common/reference/MessageId.java
Modified the constructor to accept a SlaveAddress object instead of a host name
and port number.
The constructor was printing the following message in the logs
"Replication slave database '{0}' listens for connections from master on
'{1}:{2}'."
But the slave does not listen to connections until initConnections is called.
So I removed this message
from the constructor. I also removed corresponding entries in SQLState.java and
messages.xml.
Removed the getHostName() and getPort() functions, these functions seemed
superfluous. They are
no longer used in the SlaveController, they are used in only once place in the
receiver when an
exception was being thrown.
* java/engine/org/apache/derby/impl/store/replication/slave/SlaveController.java
slavehost and slaveport are no longer used (SlaveAddress object is instead
used).
introduced two functions getHostName and getPortNumber here that return the
hostName
and portNumber from SlaveAddress. (I will remove this if it seems unnecessary)
*
java/engine/org/apache/derby/impl/store/replication/master/MasterController.java
slavehost and slaveport are no longer used (SlaveAddress object is instead
used).
introduced two functions getHostName and getPortNumber here that return the
hostName
and portNumber from SlaveAddress. (I will remove this if it seems unnecessary)
I ran the replication tests
[EMAIL PROTECTED]:~/work/workspaces/Derby3489/test$ java
junit.textui.TestRunner
org.apache.derbyTesting.functionTests.tests.replicationTests.ReplicationSuite
Time: 670.003
OK (8 tests)
I also ran a repro where I tried to connect to a default port number
[EMAIL PROTECTED]:~/work/workspaces/Derby3489/master$ java
org.apache.derby.tools.ij
ij version 10.5
ij> connect 'jdbc:derby://localhost:1527/replicationdb';
ij> connect
'jdbc:derby://localhost:1527/replicationdb;startMaster=true;slaveHost=localhost';
ERROR XRE04: DERBY SQL error: SQLCODE: -1, SQLSTATE: XRE04, SQLERRMC:
replicationdblocalhost4851XRE04
ij>
> Error message XRE04 does not include the right port number.
> ---
>
> Key: DERBY-3489
> URL: https://issues.apache.org/jira/browse/DERBY-3489
> Project: Derby
> Issue Type: Bug
> Components: Replication
>Affects Versions: 10.4.0.0
>Reporter: Øystein Grøvlen
>Assignee: V.Narayanan
> Attachments: Derby3489_1.diff, Derby3489_1.stat
>
>
> If the master is not able to connect to the slave, the error messages does
> not include the right port number:
> ij> connect
> 'jdbc:derby:masterDB;user=oystein;password=pass;startMaster=true;slaveHost=localhost;slavePort=9901';
> ERROR XRE04: Could not establish a connection to the peer of the replicated
> database 'masterDB' on address 'localhost:-1'.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3552) Handle jar files that are installed when replication is enabled
[ https://issues.apache.org/jira/browse/DERBY-3552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12583577#action_12583577 ] V.Narayanan commented on DERBY-3552: Documentation related observation -- >Path two requires a complete restart of replication after installing jars >(including copying the database >to the slave location). On the other hand, path 2 ensures that the slave is >100% up to date and ready for use >after a failover has occurred. I think we should mention that the restart would mean deleting the original slave DB and doing the replication setup from the beginning. General observation (not to be documented) --- >On the other hand, path 2 ensures that the slave is 100% up to date and ready >for use after a failover has >occurred. Path 1 also ensures that the database is up to date and ready for use provided the user following the re-installation of jars that would be required after failover. General I feel that stopping and restarting replication everytime a jar is installed is onerous. But then probably both the steps mentioned can be automated with legerdemain during development of the application that uses replication. > Handle jar files that are installed when replication is enabled > --- > > Key: DERBY-3552 > URL: https://issues.apache.org/jira/browse/DERBY-3552 > Project: Derby > Issue Type: Sub-task > Components: Replication >Affects Versions: 10.4.0.0, 10.5.0.0 >Reporter: V.Narayanan > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3552) Handle jar files that are installed when replication is enabled
[ https://issues.apache.org/jira/browse/DERBY-3552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12583521#action_12583521 ] V.Narayanan commented on DERBY-3552: Thank you for looking at this issue Kim. I apologize for my late reply. Here is my opinion on what needs to be done We can retain this line "If you install jar files on the master system while replication is running, the same jars are not automatically installed on the slave." We could rephrase this line "To ensure that the jars are installed correctly on both systems, you need to force a failover, then install the jars on the slave system (using either sqlj.remove_jar followed by sqlj.install_jar, or sqlj.replace_jar)" to "To ensure that the jars are installed correctly on both systems, after a failover, install the jars on the slave system (using either sqlj.remove_jar followed by sqlj.install_jar, or sqlj.replace_jar)" So I please request that the paragraph above could be "If you install jar files on the master system while replication is running, the same jars are not automatically installed on the slave. To ensure that the jars are installed correctly on both systems, after a failover, install the jars on the slave system (using either sqlj.remove_jar followed by sqlj.install_jar, or sqlj.replace_jar)" --- I suggested the above because Doing a failover just to install jars on the slave in the middle of transactions with the initial set of steps that we have recommended and doing it in reverse again from the slave to the master would be cumbersome to the user. thanks once again for the follow up on this issue > Handle jar files that are installed when replication is enabled > --- > > Key: DERBY-3552 > URL: https://issues.apache.org/jira/browse/DERBY-3552 > Project: Derby > Issue Type: Sub-task > Components: Replication >Affects Versions: 10.4.0.0, 10.5.0.0 >Reporter: V.Narayanan > -- 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 ] V.Narayanan updated DERBY-3526: --- Attachment: Derby3526_1.stat Derby3526_1.diff Thanks for looking at the issue oystein. Fixed issue pointed! > AsynchronousLogShipper#workToDo is blocked while the log shipper sends a log > chunk > -- > > Key: DERBY-3526 > URL: https://issues.apache.org/jira/browse/DERBY-3526 > Project: Derby > Issue Type: Bug > Components: Replication >Affects Versions: 10.4.0.0, 10.5.0.0 >Reporter: Jørgen Løland >Assignee: V.Narayanan > Attachments: Derby3526.diff, Derby3526.stat, Derby3526_1.diff, > Derby3526_1.stat > > > 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-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_v5.stat Derby3447_v5.diff Thank you for taking a look at the patch Oystein I intended the message to be printed that way (similar to the printStackTrace and stop method) I have two justifications for this 1) The only time the message is thrown is when the master has already stopped 2) It is like saying the master has stopped but the following exception occurred (which is this case is only when the master is stopped) I have fixed the nits pointed out. I was hoping to submit regression tests in a follow up. > 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, Derby3447_v3.diff, Derby3447_v3.stat, Derby3447_v4.diff, > Derby3447_v4.stat, Derby3447_v5.diff, Derby3447_v5.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-3552) Handle jar files that are installed when replication is enabled
[ https://issues.apache.org/jira/browse/DERBY-3552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12582251#action_12582251 ] V.Narayanan commented on DERBY-3552: I have been experimenting with this and I do not think SQL.install_jar defaults to derby.system.home. I think we need to document this issue stating that If jar installations are performed when replication is running the same jars will not be automatically installed in the slave. The user will have to ensure that the jars are installed properly after failover is done (this can be done by using either sqlj.replace_jar, or by, sqlj.remove_jar and sqlj.install_jar). > Handle jar files that are installed when replication is enabled > --- > > Key: DERBY-3552 > URL: https://issues.apache.org/jira/browse/DERBY-3552 > Project: Derby > Issue Type: Sub-task > Components: Replication >Affects Versions: 10.4.0.0, 10.5.0.0 >Reporter: V.Narayanan > -- 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 ] V.Narayanan updated DERBY-3526: --- Derby Info: [Patch Available] > AsynchronousLogShipper#workToDo is blocked while the log shipper sends a log > chunk > -- > > Key: DERBY-3526 > URL: https://issues.apache.org/jira/browse/DERBY-3526 > Project: Derby > Issue Type: Bug > Components: Replication >Affects Versions: 10.4.0.0, 10.5.0.0 >Reporter: Jørgen Løland >Assignee: V.Narayanan > Attachments: Derby3526.diff, Derby3526.stat > > > The replication log shipper thread synchronizes on 'this' both when shipping > log records (shipALogChunk) and when it waits between log shipments. > Transaction threads may try to wake up the log shipper because log has > arrived that should be shipped (i.e., through the method workToDo). These > threads should not have to wait for the monitor if the log shipper is > currently busy shipping log. The solution is to have two monitors - one for > log shipment and one for waiting between log shipment. > This may seem like a minor issue, but if the TCP connection between master > and slave is lost e.g. because a network cable has been unplugged, the log > shipper will block for 2 minutes on ObjectOutputStream#writeObject. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3526) AsynchronousLogShipper#workToDo is blocked while the log shipper sends a log chunk
[ https://issues.apache.org/jira/browse/DERBY-3526?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12582146#action_12582146 ] V.Narayanan commented on DERBY-3526: Would it be OK to commit the attached patch and address 3539 as a follow-up? > AsynchronousLogShipper#workToDo is blocked while the log shipper sends a log > chunk > -- > > Key: DERBY-3526 > URL: https://issues.apache.org/jira/browse/DERBY-3526 > Project: Derby > Issue Type: Bug > Components: Replication >Affects Versions: 10.4.0.0, 10.5.0.0 >Reporter: Jørgen Løland >Assignee: V.Narayanan > Attachments: Derby3526.diff, Derby3526.stat > > > 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-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=12582118#action_12582118 ] V.Narayanan commented on DERBY-3447: v4 applies cleanly to a freshworkspace. I had also run tests earlier before I submitted v4. I please request v4 to be considered for a commit if everything is OK. > 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, Derby3447_v3.diff, Derby3447_v3.stat, Derby3447_v4.diff, > Derby3447_v4.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-3551) Implement procedure SYSCS_UTIL.SYSCS_PREPARE_REPLICATION()
[ https://issues.apache.org/jira/browse/DERBY-3551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12582000#action_12582000 ] V.Narayanan commented on DERBY-3551: Thank you for watching this issue Kim. I decided that we should not unfreeze. So now we just throw an exception if it is found that unlogged operations were running. The user needs to decide if he wants to unfreeze. So when the user calls the startMaster command we check to see if there were any unlogged operations running when the user called a freeze. If there were any unlogged operations running we throw an exception with the following message "Replication master cannot be started since unlogged operations are in progress, unfreeze to allow unlogged operations to complete and restart replication" > Implement procedure SYSCS_UTIL.SYSCS_PREPARE_REPLICATION() > -- > > Key: DERBY-3551 > URL: https://issues.apache.org/jira/browse/DERBY-3551 > Project: Derby > Issue Type: Sub-task > Components: Replication >Affects Versions: 10.4.0.0, 10.5.0.0 >Reporter: V.Narayanan >Assignee: V.Narayanan > Fix For: 10.5.0.0 > > Attachments: Derby3551_1.diff, Derby3551_1.stat, Derby3551_2.diff, > Derby3551_2.stat, Derby3551_3.diff, Derby3551_3.stat, runscript_import.sql > > > Jorgen says- > I suggest that the replication step in which the master database is frozen is > replaced by a new system procedure to solve index and import: > Old: SYSCS_UTIL.SYSCS_FREEZE_DATABASE() > New: SYSCS_UTIL.SYSCS_PREPARE_REPLICATION() > The new system procedure should: > 1) Freeze the database > 2) Check if there are any ongoing transactions with unlogged operations. If > so - unfreeze and abort. Otherwise: > 3) Enable logging of unlogged operations -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3552) Handle jar files that are installed when replication is enabled
[ https://issues.apache.org/jira/browse/DERBY-3552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12581403#action_12581403 ] V.Narayanan commented on DERBY-3552: If a complete path to the location of the jar file is not mentioned in SQLJ.install_jar where is the jar searched for by default? In derby.system.home? (Not sure about this need to try this out). If this is true then I think, having the jars that need to be installed in derby.system.home in the master during installing and ensuring that the same jars are present in derby.system.home of the slave during failover would ensure that the jars are correctly installed with the user needing to do a replace_jar or a delete and recreate. > Handle jar files that are installed when replication is enabled > --- > > Key: DERBY-3552 > URL: https://issues.apache.org/jira/browse/DERBY-3552 > Project: Derby > Issue Type: Sub-task > Components: Replication >Affects Versions: 10.4.0.0, 10.5.0.0 >Reporter: V.Narayanan > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3552) Handle jar files that are installed when replication is enabled
[ https://issues.apache.org/jira/browse/DERBY-3552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12581389#action_12581389 ] V.Narayanan commented on DERBY-3552: I have the following comments on what needs to be done for this issue Backup does not run all the time unlike replication, so I do not think it is right to do what we do for jars in backup here (block jar operations). I do not think it is good to restrict a useful database operation when replication is running. I think we should not disable the installation of jars when replication is running. Instead we should document clearly the situation a user will have to face if he uses if he uses installation of jars during replication > Handle jar files that are installed when replication is enabled > --- > > Key: DERBY-3552 > URL: https://issues.apache.org/jira/browse/DERBY-3552 > Project: Derby > Issue Type: Sub-task > Components: Replication >Affects Versions: 10.4.0.0, 10.5.0.0 >Reporter: V.Narayanan > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3552) Handle jar files that are installed when replication is enabled
[
https://issues.apache.org/jira/browse/DERBY-3552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12581388#action_12581388
]
V.Narayanan commented on DERBY-3552:
I have been experimenting with running jars with replication and noticed the
following
I tried a simple installation of a jar that contained a class with a function
that accepts
two numbers and produces their sum (copied the function from here), on the
replication master.
http://mail-archives.apache.org/mod_mbox/db-derby-user/200506.mbox/[EMAIL
PROTECTED]
I used the following steps to install the jar
CALL SQLJ.install_jar('ReturnOne.jar','APP.ReturnOneJar',0);
CALL SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY('derby.database.classpath',
'APP.ReturnOneJar');
create function myInc(increment_value integer, int_value integer) returns
integer language java parameter style java no sql external name
'MyMathFuncs.myInc';
and used
values myInc (5,10); to run it on the master
After the above series of steps I did a failover and did
values myInc(5,10);
on the slave. I got the following output
ij> values myInc (5,10);
ERROR 42X51: The class 'MyMathFuncs' does not exist or is inaccessible. This
can happen if the class is not public.
ERROR XJ001: Java exception: 'MyMathFuncs: java.lang.ClassNotFoundException'.
To fix this problem I did the following on the slave
ij> CALL
sqlj.replace_jar('/home/vn/work/scripts/replication/ReturnOne.jar','APP.ReturnOneJar');
Statement executed.
ij> values myInc (5,10);
1
---
15
> Handle jar files that are installed when replication is enabled
> ---
>
> Key: DERBY-3552
> URL: https://issues.apache.org/jira/browse/DERBY-3552
> Project: Derby
> Issue Type: Sub-task
> Components: Replication
>Affects Versions: 10.4.0.0, 10.5.0.0
>Reporter: V.Narayanan
>
--
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-3552) Handle jar files that are installed when replication is enabled
[ https://issues.apache.org/jira/browse/DERBY-3552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12579795#action_12579795 ] narayanan edited comment on DERBY-3552 at 3/22/08 4:40 PM: - Jar Files - With regards to Jar files * The installed jar files are not logged but system catalog updates are logged when jar files are added/deleted. * This would mean that allowing jar file operations during deletion would result in the system catalog table on the slave having a reference to the jar file that does not exist in the backup database Possible solution * Block jar file operations when replication is in progress * write clear documentation stating that the jar files will have to be manually copied to the slave. was (Author: narayanan): Jar Files - With regards to Jar files * The installed jar files are not logged but system catalog updates are logged when jar files are added/deleted. * This would mean that allowing jar file operations during deletion would result in the system catalog table on the slave having a reference to the jar file that does not exist in the backup database Possible solution * Block jar file operations when backup is in progress * write clear documentation stating that the jar files will have to be manually copied to the slave. > Handle jar files that are installed when replication is enabled > --- > > Key: DERBY-3552 > URL: https://issues.apache.org/jira/browse/DERBY-3552 > Project: Derby > Issue Type: Sub-task > Components: Replication >Affects Versions: 10.4.0.0, 10.5.0.0 >Reporter: V.Narayanan > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3551) Implement procedure SYSCS_UTIL.SYSCS_PREPARE_REPLICATION()
[ https://issues.apache.org/jira/browse/DERBY-3551?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] V.Narayanan updated DERBY-3551: --- Attachment: Derby3551_3.stat Derby3551_3.diff > Since I guess unlogged operations will be blocked when the database is > frozen, > I think it will be safe to delay the check until starting the master. correct, That is why I thought that a combination of the steps, the user should follow and a check to see if the freeze has frozen any already started unlogged operation, should suffice. > I think the proposed patch looks good. Do you plan to add some test cases? I intend to add tests in http://issues.apache.org/jira/browse/Derby-3553. I was hoping to move to installation of jars and look at what will be required there and then move to writing tests for unlogged operations. > * LogToFile#replicationLogUnlogged: This method returns whether db is in > master > mode or not, and I think inReplicationMasterMode or something would be a > better name. > (The way the javadoc is written, it may lead you to think that you should > call this method to > activate logging.) Changed the method name to inReplicationMasterMode(). I also changed the javadoc to the following * Used to determine if the replication master mode has been started, * and the logging for unlogged operations needs to be enabled. > * messages.xml: I would say 'cannot be started' , not 'booted' since the > operation is called > startMaster.' Changed 'booted' to 'started'. > Implement procedure SYSCS_UTIL.SYSCS_PREPARE_REPLICATION() > -- > > Key: DERBY-3551 > URL: https://issues.apache.org/jira/browse/DERBY-3551 > Project: Derby > Issue Type: Sub-task > Components: Replication >Affects Versions: 10.4.0.0, 10.5.0.0 >Reporter: V.Narayanan >Assignee: V.Narayanan > Attachments: Derby3551_1.diff, Derby3551_1.stat, Derby3551_2.diff, > Derby3551_2.stat, Derby3551_3.diff, Derby3551_3.stat, runscript_import.sql > > > Jorgen says- > I suggest that the replication step in which the master database is frozen is > replaced by a new system procedure to solve index and import: > Old: SYSCS_UTIL.SYSCS_FREEZE_DATABASE() > New: SYSCS_UTIL.SYSCS_PREPARE_REPLICATION() > The new system procedure should: > 1) Freeze the database > 2) Check if there are any ongoing transactions with unlogged operations. If > so - unfreeze and abort. Otherwise: > 3) Enable logging of unlogged operations -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3551) Implement procedure SYSCS_UTIL.SYSCS_PREPARE_REPLICATION()
[ https://issues.apache.org/jira/browse/DERBY-3551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12581141#action_12581141 ] V.Narayanan commented on DERBY-3551: I had also earlier tested this patch for a simple index creation and it worked fine. > Implement procedure SYSCS_UTIL.SYSCS_PREPARE_REPLICATION() > -- > > Key: DERBY-3551 > URL: https://issues.apache.org/jira/browse/DERBY-3551 > Project: Derby > Issue Type: Sub-task > Components: Replication >Affects Versions: 10.4.0.0, 10.5.0.0 >Reporter: V.Narayanan >Assignee: V.Narayanan > Attachments: Derby3551_1.diff, Derby3551_1.stat, Derby3551_2.diff, > Derby3551_2.stat, runscript_import.sql > > > Jorgen says- > I suggest that the replication step in which the master database is frozen is > replaced by a new system procedure to solve index and import: > Old: SYSCS_UTIL.SYSCS_FREEZE_DATABASE() > New: SYSCS_UTIL.SYSCS_PREPARE_REPLICATION() > The new system procedure should: > 1) Freeze the database > 2) Check if there are any ongoing transactions with unlogged operations. If > so - unfreeze and abort. Otherwise: > 3) Enable logging of unlogged operations -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3551) Implement procedure SYSCS_UTIL.SYSCS_PREPARE_REPLICATION()
[ https://issues.apache.org/jira/browse/DERBY-3551?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] V.Narayanan updated DERBY-3551: --- Attachment: runscript_import.sql I tested the patch Derby3551_2 with imports and it worked fine. Attached is a ij script that automatically exports and imports data, from tables it creates by itself. It tests the procedures SYSCS_UTIL.SYSCS_IMPORT_DATA and SYSCS_UTIL.SYSCS_IMPORT_TABLE_LOBS_FROM_EXTFILE To use it to test imports in replication just do the initial replication setup in ij and then do run 'runscript_import.sql'; I thought the script might be helpful for people who wants to test imports with this patch without going through the creation of the tables and files necessary. > Implement procedure SYSCS_UTIL.SYSCS_PREPARE_REPLICATION() > -- > > Key: DERBY-3551 > URL: https://issues.apache.org/jira/browse/DERBY-3551 > Project: Derby > Issue Type: Sub-task > Components: Replication >Affects Versions: 10.4.0.0, 10.5.0.0 >Reporter: V.Narayanan >Assignee: V.Narayanan > Attachments: Derby3551_1.diff, Derby3551_1.stat, Derby3551_2.diff, > Derby3551_2.stat, runscript_import.sql > > > Jorgen says- > I suggest that the replication step in which the master database is frozen is > replaced by a new system procedure to solve index and import: > Old: SYSCS_UTIL.SYSCS_FREEZE_DATABASE() > New: SYSCS_UTIL.SYSCS_PREPARE_REPLICATION() > The new system procedure should: > 1) Freeze the database > 2) Check if there are any ongoing transactions with unlogged operations. If > so - unfreeze and abort. Otherwise: > 3) Enable logging of unlogged operations -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3551) Implement procedure SYSCS_UTIL.SYSCS_PREPARE_REPLICATION()
[ https://issues.apache.org/jira/browse/DERBY-3551?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] V.Narayanan updated DERBY-3551: --- Attachment: Derby3551_2.stat Derby3551_2.diff I have modified Derby3551_1.diff to now throw an error when unlogged operations are running. I feel we should not unfreeze and instead should let the user unfreeze. > Implement procedure SYSCS_UTIL.SYSCS_PREPARE_REPLICATION() > -- > > Key: DERBY-3551 > URL: https://issues.apache.org/jira/browse/DERBY-3551 > Project: Derby > Issue Type: Sub-task > Components: Replication >Affects Versions: 10.4.0.0, 10.5.0.0 > Reporter: V.Narayanan >Assignee: V.Narayanan > Attachments: Derby3551_1.diff, Derby3551_1.stat, Derby3551_2.diff, > Derby3551_2.stat > > > Jorgen says- > I suggest that the replication step in which the master database is frozen is > replaced by a new system procedure to solve index and import: > Old: SYSCS_UTIL.SYSCS_FREEZE_DATABASE() > New: SYSCS_UTIL.SYSCS_PREPARE_REPLICATION() > The new system procedure should: > 1) Freeze the database > 2) Check if there are any ongoing transactions with unlogged operations. If > so - unfreeze and abort. Otherwise: > 3) Enable logging of unlogged operations -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3562) Number of log files (and log dir size) on the slave increases continuously
[ https://issues.apache.org/jira/browse/DERBY-3562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12581024#action_12581024 ] V.Narayanan commented on DERBY-3562: Not sure if the analysis here points at the rate of increase in the slave or the increase in the slave relative to the master. But isn't an increase in the log size of a slave expected, because the Slave receives log records from the master and use LogToFile#appendLogRecord to write these to disk. So basically the slave uses the logs received from the master to recover and move to a transaction consistent state. Incase you have not seen the following points from Derby-3071 (Modify logging subsystem for slave replication mode) * SlaveFactory (DERBY-3021) will receive log records from the master and use LogToFile#appendLogRecord to write these to disk. While in slave mode, only SlaveFactory will be allowed to append log records. * The thread running LogToFile#recover will recover (redo) one log file at a time (like now), but will not be allowed to open a log file X until that file is no longer being written to. Thus, while appenLogFile writes to logX.dat, recover will be allowed to read all log files up to and including logX-1.dat but will then have to wait until appendLogRecord starts writing to logX+1.dat. > Number of log files (and log dir size) on the slave increases continuously > -- > > Key: DERBY-3562 > URL: https://issues.apache.org/jira/browse/DERBY-3562 > Project: Derby > Issue Type: Bug > Components: Replication >Affects Versions: 10.4.0.0, 10.5.0.0 > Environment: - >Reporter: Ole Solberg > Attachments: master_slave-db_size-6.jpg > > > I did a simple test inserting tuples in a table during replication: > The attached file 'master_slave-db_size-6.jpg' shows that > the size of the log directory (and number of files in the log directory) > increases continuously during replication, while on master the size > (and number of files) never exceeds ~12Mb (12 files?) in this scenario. > The seg0 directory on the slave stays at the same size as the master > seg0 directory. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3551) Implement procedure SYSCS_UTIL.SYSCS_PREPARE_REPLICATION()
[ https://issues.apache.org/jira/browse/DERBY-3551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12581020#action_12581020 ] V.Narayanan commented on DERBY-3551: >"Check if any unlogged operations are currently running, if yes unfreeze and >throw an exception >saying that replication cannot be started since the database has unlogged >operations running" Not sure if we should unfreeze or just throw an exception informing an user about the unlogged operations and let the user unfreeze the database > Implement procedure SYSCS_UTIL.SYSCS_PREPARE_REPLICATION() > -- > > Key: DERBY-3551 > URL: https://issues.apache.org/jira/browse/DERBY-3551 > Project: Derby > Issue Type: Sub-task > Components: Replication >Affects Versions: 10.4.0.0, 10.5.0.0 > Reporter: V.Narayanan >Assignee: V.Narayanan > Attachments: Derby3551_1.diff, Derby3551_1.stat > > > Jorgen says- > I suggest that the replication step in which the master database is frozen is > replaced by a new system procedure to solve index and import: > Old: SYSCS_UTIL.SYSCS_FREEZE_DATABASE() > New: SYSCS_UTIL.SYSCS_PREPARE_REPLICATION() > The new system procedure should: > 1) Freeze the database > 2) Check if there are any ongoing transactions with unlogged operations. If > so - unfreeze and abort. Otherwise: > 3) Enable logging of unlogged operations -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3551) Implement procedure SYSCS_UTIL.SYSCS_PREPARE_REPLICATION()
[ https://issues.apache.org/jira/browse/DERBY-3551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12581015#action_12581015 ] V.Narayanan commented on DERBY-3551: I feel that the stored procedure will not be required. Turning on logging with the present logic will happen when the master is booted ( connection url with startMaster=true) Turning our attention to the future enhancements planned for 10.5 as mentioned in the functional specification How to start replication - Future enhancement (10.5) When replication is started, the slave checks that the database does not already exist, and that the user is authorized to create a database. The slave then starts to listen for a master on the specified host and port. The master connects to the slave and performs a handshake to ensure that only one master connects to a slave. The master then sends the whole database, including the active log files, to the slave via this connection. Hence, the database is only booted, not created, on the slave. -- The database copying operation happens when the master is connection to the slave. This is also where we turn on logging for unlogged operations. The stored procedure will then result in a series of redundant steps that would need to be performed again when we do the shipping automatically in the future enhancements for 10.5. That said, I think we need to move the steps mentioned above, to when we start the master controller. But I think this can wait till the above enhancements are implemented. For now the series of steps the user follows to start replication combined with the following check during replication startup "Check if any unlogged operations are currently running, if yes unfreeze and throw an exception saying that replication cannot be started since the database has unlogged operations running" Should suffice. > Implement procedure SYSCS_UTIL.SYSCS_PREPARE_REPLICATION() > -- > > Key: DERBY-3551 > URL: https://issues.apache.org/jira/browse/DERBY-3551 > Project: Derby > Issue Type: Sub-task > Components: Replication >Affects Versions: 10.4.0.0, 10.5.0.0 >Reporter: V.Narayanan >Assignee: V.Narayanan > Attachments: Derby3551_1.diff, Derby3551_1.stat > > > Jorgen says- > I suggest that the replication step in which the master database is frozen is > replaced by a new system procedure to solve index and import: > Old: SYSCS_UTIL.SYSCS_FREEZE_DATABASE() > New: SYSCS_UTIL.SYSCS_PREPARE_REPLICATION() > The new system procedure should: > 1) Freeze the database > 2) Check if there are any ongoing transactions with unlogged operations. If > so - unfreeze and abort. Otherwise: > 3) Enable logging of unlogged operations -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3169) Add documentation for replication
[
https://issues.apache.org/jira/browse/DERBY-3169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12580430#action_12580430
]
V.Narayanan commented on DERBY-3169:
Thank you for the excellent work you have been doing for replication
documentation Kim.
>I can see that implementing the SYSCS_UTIL.SYSCS_PREPARE_REPLICATION procedure
>would
>require only a new file in the Reference Manual and some changes to the
>"Starting and
>running replication" topic of the Admin Guide.
You are correct in your estimation of the work required to document this stored
procedure.
This procedure would be involved only during replication startup and its
presence in the
Reference manual in the stored procedures section, and, the Admin guide section
for starting
and running replication should suffice
>There was also something in the comments to DERBY-3552 about a possible need
>for
>documentation concerning jar files, but I don't quite understand this issue
>yet so I'm not
>sure what would be involved.
There are two possibilities
1) Write documentation saying that, if jars need to be installed when
replication is running for
the database the user will have to manually copy the jar files to the slave.
2) Disable jar file operations during replication, in which case we will have
to document saying that
users cannot perform jar operations when replication is running.
I am inclined towards 1) because it gives more flexibility to the user, but I
was hoping to get some more
inputs from the community in the coming days on this, which is why I have left
it open.
-
An example for installing a jar file would be like this
ij> CALL SQLJ.install_jar
('myStuff.jar', 'APP.MyStuffJar', 0);
ij> CALL SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY
('derby.database.classpath', 'APP.MyStuffJar');
I found this example here http://wiki.apache.org/db-derby/DerbySQLroutines
> Add documentation for replication
> -
>
> Key: DERBY-3169
> URL: https://issues.apache.org/jira/browse/DERBY-3169
> Project: Derby
> Issue Type: Improvement
> Components: Documentation
>Affects Versions: 10.4.0.0
>Reporter: Jørgen Løland
>Assignee: Kim Haase
> Attachments: DERBY-3169-2.diff, DERBY-3169-2.stat, DERBY-3169-2.zip,
> DERBY-3169-3.diff, DERBY-3169-3.stat, DERBY-3169-3.zip, DERBY-3169-4.diff,
> DERBY-3169-4.zip, DERBY-3169-5.diff, DERBY-3169-5.zip, DERBY-3169.diff,
> DERBY-3169.stat, DERBY-3169.zip
>
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3551) Implement procedure SYSCS_UTIL.SYSCS_PREPARE_REPLICATION()
[ https://issues.apache.org/jira/browse/DERBY-3551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12580338#action_12580338 ] V.Narayanan commented on DERBY-3551: Please note that Derby3551_1 is not for a commit. It is just for testing the solution. There are many other questions remaining unanswered. 1) Is a stored procedure for starting replication required? 2) What are the behaviour of imports? (There is a separate issue for jars) 3) Tests need to be written for unlogged operations in the context of replication (there is a separate JIRA for this too) > Implement procedure SYSCS_UTIL.SYSCS_PREPARE_REPLICATION() > -- > > Key: DERBY-3551 > URL: https://issues.apache.org/jira/browse/DERBY-3551 > Project: Derby > Issue Type: Sub-task > Components: Replication >Affects Versions: 10.4.0.0, 10.5.0.0 >Reporter: V.Narayanan >Assignee: V.Narayanan > Attachments: Derby3551_1.diff, Derby3551_1.stat > > > Jorgen says- > I suggest that the replication step in which the master database is frozen is > replaced by a new system procedure to solve index and import: > Old: SYSCS_UTIL.SYSCS_FREEZE_DATABASE() > New: SYSCS_UTIL.SYSCS_PREPARE_REPLICATION() > The new system procedure should: > 1) Freeze the database > 2) Check if there are any ongoing transactions with unlogged operations. If > so - unfreeze and abort. Otherwise: > 3) Enable logging of unlogged operations -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3551) Implement procedure SYSCS_UTIL.SYSCS_PREPARE_REPLICATION()
[
https://issues.apache.org/jira/browse/DERBY-3551?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
V.Narayanan updated DERBY-3551:
---
Attachment: Derby3551_1.stat
Derby3551_1.diff
In trying to search for a way to enable only logging of unlogged operations and
not the archiving support available the following observations were very
important
1) Logic to enable logging is found in the BaseDataFileFactory
(org.apache.derby.impl.store.raw.data.BaseDataFileFactory, line no 672)
2) Logic for archiving is present in LogToFile
This partitioning of logic was to the advantage of this issue and made the
coding
logic very simple
Follows a brief explanation of the solution developed
When log archiving needs to be done it is enabled by using a flag in the
following way in the BaseDataFileFactory
if (logFactory.logArchived()) {
mode &= ~(ContainerHandle.MODE_UNLOGGED |
ContainerHandle.MODE_CREATE_UNLOGGED);
}
(The ContainerHandle class contains a very good explanation of the
MODE_UNLOGGED,
MODE_CREATE_UNLOGGED flags.)
Now in addition to just enabling the flags when logArchiving is required the
flags need
to be enabled when replication is active too. To achieve this the above code
was changed to
if (logFactory.logArchived() || logFactory.replicationLogUnlogged()) {
mode &= ~(ContainerHandle.MODE_UNLOGGED |
ContainerHandle.MODE_CREATE_UNLOGGED);
}
Doing the above solved the problem for a simple index creation, what remains to
be seen
is how it works for imports.
Attaching a patch for people who might be interested in testing the solution.
Another interesting decision will be as to whether a stored procedure will be
required now?
(I do not have an answer for this right now, but I surely shall be revisiting
Derby-239 to learn
more about unlogged operations being started before logging is enabled)
> Implement procedure SYSCS_UTIL.SYSCS_PREPARE_REPLICATION()
> --
>
> Key: DERBY-3551
> URL: https://issues.apache.org/jira/browse/DERBY-3551
> Project: Derby
> Issue Type: Sub-task
> Components: Replication
>Affects Versions: 10.4.0.0, 10.5.0.0
>Reporter: V.Narayanan
>Assignee: V.Narayanan
> Attachments: Derby3551_1.diff, Derby3551_1.stat
>
>
> Jorgen says-
> I suggest that the replication step in which the master database is frozen is
> replaced by a new system procedure to solve index and import:
> Old: SYSCS_UTIL.SYSCS_FREEZE_DATABASE()
> New: SYSCS_UTIL.SYSCS_PREPARE_REPLICATION()
> The new system procedure should:
> 1) Freeze the database
> 2) Check if there are any ongoing transactions with unlogged operations. If
> so - unfreeze and abort. Otherwise:
> 3) Enable logging of unlogged operations
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
