[jira] Updated: (DERBY-3162) Create a framework for replication tests
[ https://issues.apache.org/jira/browse/DERBY-3162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ole Solberg updated DERBY-3162: --- Attachment: derby-3162.4-v2.stat.txt derby-3162.4-v2.diff.txt Patch derby-3162.4-v2 replaces derby-3162.4-v1: This patch fixes some stupid classpath / pathSeparator problems which also showed up on Windows. I do however still have trouble running the tests on Windows: I am seeing messages like 'Warning: UnknkownHostException: OLESO-FERRARI: OLESO-FERRARI.' in connection with InetAddress.getByName(hostName) in ReplicationRun.pingServer. The patch therefore comments out the replication suite from suites.All. 'org.apache.derbyTesting.functionTests.tests.replicationTests.ReplicationSuite' must thus be run separatly. I am sorry for the inconvenience :-( > Create a framework for replication tests > > > Key: DERBY-3162 > URL: https://issues.apache.org/jira/browse/DERBY-3162 > Project: Derby > Issue Type: Sub-task > Components: Test >Affects Versions: 10.4.0.0 >Reporter: Ole Solberg >Assignee: Ole Solberg >Priority: Minor > Attachments: derby-3162.1-v1.diff.txt, derby-3162.2-v2.diff.txt, > derby-3162.2-v2.stat.txt, derby-3162.3-v1.diff.txt, derby-3162.3-v1.stat.txt, > derby-3162.3-v2.diff.txt, derby-3162.3-v2.stat.txt, derby-3162.3-v3.diff.txt, > derby-3162.3-v3.stat.txt, derby-3162.3-v4c.diff.txt, > derby-3162.3-v4c.stat.txt, derby-3162.3-v4d.diff.txt, > derby-3162.3-v4d.stat.txt, derby-3162.4-v1.diff.txt, > derby-3162.4-v1.stat.txt, derby-3162.4-v2.diff.txt, derby-3162.4-v2.stat.txt > > > Handle > - starting and stopping Derby servers to have the master and slave > replication roles, > - doing administrative commands like startreplication, startslave, > stopreplication, failover, > - performing consistency checks on the slave vs. the master, > - running load clients against master and slave in the various states of > replication, > - provoking error situations on master and slave, and network, > - ... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (DERBY-3373) SQL "distinct" and "order by" needed together
[ https://issues.apache.org/jira/browse/DERBY-3373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Pendleton reassigned DERBY-3373: -- Assignee: Bryan Pendleton > SQL "distinct" and "order by" needed together > - > > Key: DERBY-3373 > URL: https://issues.apache.org/jira/browse/DERBY-3373 > Project: Derby > Issue Type: Bug > Components: SQL >Affects Versions: 10.3.2.1 > Environment: Solaris Dev Express, Java 5 >Reporter: Thomas Vatter >Assignee: Bryan Pendleton >Priority: Blocker > Fix For: 10.3.2.2 > > > I am pasting here the communication from the mailinglist. I am having a > blocking and large problem with it because I have to make a release that > needs the specified SQL query. > tom_ wrote: > > The errormessage is > > > > The ORDER BY clause may not specify an expression, since the query > > specifies > > DISTINCT > > [Error Code: 2] > > [SQL State: 4287A] > > > > The statement is > > > > select distinct > > t1.t1_id, t2.t2value1, t2.t2value2, t2.t2value3 > > from > > t1, t2, t3 > > where > > ... > > order by lower(t2.t2value2) , lower(t2.t2value1) , lower(t2.t2value3) > > > > > > > > > > Dyre.Tjeldvoll wrote: > > > >> tom_ <[EMAIL PROTECTED]> writes: > >> > >> > >>> I am using "disctinct" because of some self-joins and also needed to add > >>> an > >>> "order by" clause. An error is shown. Is it not possible to use distinct > >>> and > >>> order by together? > >>> > >> I think it is allowed. Executing > >> > >> select distinct * from sys.systables order by tablename; > >> > >> in ij works just fine. Could you show the error message you get, and > >> perhaps what the table looks like? > >> > >> -- > >> dt > >> > >> > >> > « [hide part of quote] > Hi Tom - > I see what you mean using the demo DB toursDB: > ij> select * from airlines order by lower(airline_full); > A&|AIRLINE_FULL|BASIC_RATE|DISTANCE_DISCOUNT > |BUSINESS_LEVEL_FACTOR > |FIRSTCLASS_LEVEL_FACT&|ECONOMY_SE&|BUSINESS_S&|FIRSTCLASS& > --- > > AA|Amazonian Airways |0.18 |0.03 > |0.5 |1.5 |20 |10 |5 > US|Union Standard Airlines |0.19 |0.05 > |0.4 |1.6 |20 |10 |5 > 2 rows selected > ij> select distinct * from airlines order by lower(airline_full); > ERROR 4287A: The ORDER BY clause may not specify an expression, since > the query specifies DISTINCT. > ij> select distinct airline_full from airlines order by lower(airline_full); > ERROR 4287A: The ORDER BY clause may not specify an expression, since > the query specifies DISTINCT. > ij> > I didn't find a JIRA enhancement to remove this restriction. I suggest > you file an Enhancement request to remove the restriction reported by > ERROR 4287A. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3373) SQL "distinct" and "order by" needed together
[ https://issues.apache.org/jira/browse/DERBY-3373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12576546#action_12576546 ] Bryan Pendleton commented on DERBY-3373: I think that these lines in OrderByColumn, which were added by DERBY-2351, are the focus of this problem: if (addedColumnOffset >= 0 && target instanceof SelectNode && ( (SelectNode)target ).hasDistinct()) throw StandardException.newException(SQLState.LANG_DISTINCT_ORDER_BY_EXPRESSION); The problem is that these lines should have an additional condition, along the lines of: AND, there exists at least 1 column reference among the column references in this ORDER BY expression, which does not appear as one of the columns which are being selected DISTINCT. The problem is, I'm not sure how to code that AND test I'll have to study the SelectNode data structure to see if I can easily see how to tell "the columns which are being selected DISTINCT". > SQL "distinct" and "order by" needed together > - > > Key: DERBY-3373 > URL: https://issues.apache.org/jira/browse/DERBY-3373 > Project: Derby > Issue Type: Bug > Components: SQL >Affects Versions: 10.3.2.1 > Environment: Solaris Dev Express, Java 5 >Reporter: Thomas Vatter >Assignee: Bryan Pendleton >Priority: Blocker > Fix For: 10.3.2.2 > > > I am pasting here the communication from the mailinglist. I am having a > blocking and large problem with it because I have to make a release that > needs the specified SQL query. > tom_ wrote: > > The errormessage is > > > > The ORDER BY clause may not specify an expression, since the query > > specifies > > DISTINCT > > [Error Code: 2] > > [SQL State: 4287A] > > > > The statement is > > > > select distinct > > t1.t1_id, t2.t2value1, t2.t2value2, t2.t2value3 > > from > > t1, t2, t3 > > where > > ... > > order by lower(t2.t2value2) , lower(t2.t2value1) , lower(t2.t2value3) > > > > > > > > > > Dyre.Tjeldvoll wrote: > > > >> tom_ <[EMAIL PROTECTED]> writes: > >> > >> > >>> I am using "disctinct" because of some self-joins and also needed to add > >>> an > >>> "order by" clause. An error is shown. Is it not possible to use distinct > >>> and > >>> order by together? > >>> > >> I think it is allowed. Executing > >> > >> select distinct * from sys.systables order by tablename; > >> > >> in ij works just fine. Could you show the error message you get, and > >> perhaps what the table looks like? > >> > >> -- > >> dt > >> > >> > >> > « [hide part of quote] > Hi Tom - > I see what you mean using the demo DB toursDB: > ij> select * from airlines order by lower(airline_full); > A&|AIRLINE_FULL|BASIC_RATE|DISTANCE_DISCOUNT > |BUSINESS_LEVEL_FACTOR > |FIRSTCLASS_LEVEL_FACT&|ECONOMY_SE&|BUSINESS_S&|FIRSTCLASS& > --- > > AA|Amazonian Airways |0.18 |0.03 > |0.5 |1.5 |20 |10 |5 > US|Union Standard Airlines |0.19 |0.05 > |0.4 |1.6 |20 |10 |5 > 2 rows selected > ij> select distinct * from airlines order by lower(airline_full); > ERROR 4287A: The ORDER BY clause may not specify an expression, since > the query specifies DISTINCT. > ij> select distinct airline_full from airlines order by lower(airline_full); > ERROR 4287A: The ORDER BY clause may not specify an expression, since > the query specifies DISTINCT. > ij> > I didn't find a JIRA enhancement to remove this restriction. I suggest > you file an Enhancement request to remove the restriction reported by > ERROR 4287A. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3162) Create a framework for replication tests
[
https://issues.apache.org/jira/browse/DERBY-3162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12576548#action_12576548
]
V.Narayanan commented on DERBY-3162:
>I am seeing messages like 'Warning: UnknkownHostException: OLESO-FERRARI:
>OLESO-FERRARI.'
>in connection with InetAddress.getByName(hostName) in
>ReplicationRun.pingServer.
I checked the ping code, seems harmless and also seems to conform to what
NetworkServerControl
comments asks you to do
ping code -
ping( new NetworkServerControl(InetAddress.getByName(hostName),port),
iterations);
NetworkServerControl comments -
This is an example of starting and shutting down the Network Server in the
example
above with the API.
NetworkServerControl serverControl = new
NetworkServerControl(InetAddress.getByName("myhost"),1621)
serverControl.shutdown();
Looks like a lookup failure in windows to me,
I am not sure that your code is at fault.
> Create a framework for replication tests
>
>
> Key: DERBY-3162
> URL: https://issues.apache.org/jira/browse/DERBY-3162
> Project: Derby
> Issue Type: Sub-task
> Components: Test
>Affects Versions: 10.4.0.0
>Reporter: Ole Solberg
>Assignee: Ole Solberg
>Priority: Minor
> Attachments: derby-3162.1-v1.diff.txt, derby-3162.2-v2.diff.txt,
> derby-3162.2-v2.stat.txt, derby-3162.3-v1.diff.txt, derby-3162.3-v1.stat.txt,
> derby-3162.3-v2.diff.txt, derby-3162.3-v2.stat.txt, derby-3162.3-v3.diff.txt,
> derby-3162.3-v3.stat.txt, derby-3162.3-v4c.diff.txt,
> derby-3162.3-v4c.stat.txt, derby-3162.3-v4d.diff.txt,
> derby-3162.3-v4d.stat.txt, derby-3162.4-v1.diff.txt,
> derby-3162.4-v1.stat.txt, derby-3162.4-v2.diff.txt, derby-3162.4-v2.stat.txt
>
>
> Handle
> - starting and stopping Derby servers to have the master and slave
> replication roles,
> - doing administrative commands like startreplication, startslave,
> stopreplication, failover,
> - performing consistency checks on the slave vs. the master,
> - running load clients against master and slave in the various states of
> replication,
> - provoking error situations on master and slave, and network,
> - ...
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [jira] Commented: (DERBY-3514) SecureServerTest failing with timeout waiting for the network server to start only when run in derbynet._Suite
Mike Matrigali wrote: Daniel John Debrunner (JIRA) wrote: [ https://issues.apache.org/jira/browse/DERBY-3514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12576389#action_12576389 ] Daniel John Debrunner commented on DERBY-3514: -- Issue was due to an earlier test calling a network server command that failed (setting trace on with an invalid directory). For most of the network server commands if an exception is thrown the network socket is never closed (left to garbage collection). Most likely the longer wait that NetworkServerTestSetup had was enough time to get the socket closed and thus freed up for the network server to use. I accidentally committed a reduced wait time in NetworkServerTestSetup yesterday while working on DERBY-3504. I plan on leaving this reduced time (10 seconds to start the server rather than the old 300 seconds) as the server should come up in that time and my belief is that extending the time is really just hiding bugs (like this one). Is 10 seconds really the number across all platforms, accounting for any other activity that may be happening on the machine? It would be nice if our tests didn't fail mysteriously with a timeout error if some other activity on the machine happened to affect performance. 10 seconds may be too low but I think 300 is too high. There isn't a lot of code needed to start the network server. Maybe we could leave at 10 for a while and see if anyone hits any problems. It would be great if someone could fix all the tests to properly cleanup, but for now pouring through intermittent timeout diffs is not helping me tell if my latest change broke the codeline or not. The reality is that now I will run less tests, ignoring the failures in those tests that timeout. With the timeout set high at least the tests run and the functionality is tested. I agree there may be a missed bug in a test or even more serious if network startup started to take 5 minutes everytime. Note that the bug I just fixed that was hidden by the 300 seconds timeout was a bug in the network server code, not in any test. Do you have any hints on how to find the previous test that may be causing the bug if I am hitting timeouts for this reason? Just like debugging any other issue, remove elements until the problem disappears and then determine which one is causing the problem. Dan.
[jira] Commented: (DERBY-3515) 23 timeouts encountered while running management junit suite as part of full nightly runs.
[ https://issues.apache.org/jira/browse/DERBY-3515?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12576555#action_12576555 ] Daniel John Debrunner commented on DERBY-3515: -- Just to note these are timeouts trying to connect to JMX. The tests spawn a network server as a separate process with jmx monitoring enabled. Since this server is spawned using the standard decorator it must have successfully started otherwise an exception would have be thrown earlier. So I don't think this is related in any way to the network server timeout reduction to 10 seconds. The management._Suite is the only test that uses JMX so it seems unlikely that a previous test has kept the port ( I think) open. > 23 timeouts encountered while running management junit suite as part of full > nightly runs. > -- > > Key: DERBY-3515 > URL: https://issues.apache.org/jira/browse/DERBY-3515 > Project: Derby > Issue Type: Bug > Components: Regression Test Failure >Affects Versions: 10.4.0.0 > Environment: windows XP, laptop, ibm15 >Reporter: Mike Matrigali > Attachments: summary.out > > > While running full nightly test suite on a classes,SANE build got 23 failures > in management test suite as follows. Tried again in same codeline > just running the management test suite and it worked 50 times in a row. > Maybe issue is similar to DERBY-3514, where a previous test is leaving > a bad state and now that timeout has been reduced again to where it was known > to cause nightly test failures in some environments those issues > are resurfacing. I am trying another full suite run to see if it reproduces > in my environment, if others are seeing this issue, please add a comment. > I will attach full log of errors, but here is the first few: > There were 23 errors: > 1) > testDerbyRegisteredMBeansSimpleInfo(org.apache.derbyTesting.functionTests.tests.management.JMXTest)java.rmi.ConnectIOException: > Exception creating > connection to: 192.168.0.188; nested exception is: > java.net.SocketException: Operation timed out: connect:could be due to > invalid address > at sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:603) > at sun.rmi.transport.tcp.TCPChannel.createConnection(TCPChannel.java:204) > at sun.rmi.transport.tcp.TCPChannel.newConnection(TCPChannel.java:190) > at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:109) > at > javax.management.remote.rmi.RMIServerImpl_Stub.newClient(RMIServerImpl_Stub.java:52) > at > javax.management.remote.rmi.RMIConnector.getConnection(RMIConnector.java:2244) > at javax.management.remote.rmi.RMIConnector.connect(RMIConnector.java:286) > at > javax.management.remote.JMXConnectorFactory.connect(JMXConnectorFactory.java:263) > at > org.apache.derbyTesting.functionTests.tests.management.RemoteConnectionGetter.getMBeanServerConnection(RemoteConnectionGetter.java:49) > at > org.apache.derbyTesting.functionTests.tests.management.MBeanTest.getMBeanServerConnection(MBeanTest.java:177) > at > org.apache.derbyTesting.functionTests.tests.management.MBeanTest.getApplicationManagementMBean(MBeanTest.java:252) > at > org.apache.derbyTesting.functionTests.tests.management.MBeanTest.enableManagement(MBeanTest.java:201) > at > org.apache.derbyTesting.functionTests.tests.management.MBeanTest.setUp(MBeanTest.java:155) > at > org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:101) > at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) > at junit.extensions.TestSetup$1.protect(TestSetup.java:19) > at junit.extensions.TestSetup.run(TestSetup.java:23) > at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) > at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) > at junit.extensions.TestSetup$1.protect(TestSetup.java:19) > at junit.extensions.TestSetup.run(TestSetup.java:23) > at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) > at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) > at junit.extensions.TestSetup$1.protect(TestSetup.java:19) > at junit.extensions.TestSetup.run(TestSetup.java:23) > at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) > at junit.extensions.TestSetup$1.protect(TestSetup.java:19) > at junit.extensions.TestSetup.run(TestSetup.java:23) > Caused by: java.net.SocketException: Operation timed out: connect:could be > due to invalid address > at java.net.PlainSocketImpl.socketConnect(Native Method) > at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:372) > at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:233) > at java.net.PlainSocketI
[jira] Commented: (DERBY-2351) ORDER BY with expression with distinct in the select list returns incorrect result
[ https://issues.apache.org/jira/browse/DERBY-2351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12576558#action_12576558 ] Bryan Pendleton commented on DERBY-2351: I'm considering modifying synonym.out to reflect that select t1.id as idcolumn1, t1.id as idcolumn2 from t1 order by t1.idcolumn1, t1.idcolumn2; should get an error, and then proceeding with a commit of this patch. I think that the patch improves substantially upon the current behavior of the trunk, accepting many more legitimate queries and refusing only more questionable queries. I think the DERBY-3373 issue can be addressed separately. > ORDER BY with expression with distinct in the select list returns incorrect > result > -- > > Key: DERBY-2351 > URL: https://issues.apache.org/jira/browse/DERBY-2351 > Project: Derby > Issue Type: Bug > Components: SQL >Affects Versions: 10.2.1.6, 10.2.2.0, 10.3.1.4 > Environment: Any >Reporter: Yip Ng >Assignee: Bryan Pendleton > Fix For: 10.3.2.2, 10.4.0.0 > > Attachments: d2351_aliasing.diff, d2351_aliasing.diff, > d2351_aliasing_checkQualifiedName.diff, derby_2351.diff, derby_2351_v2.diff, > reproTests.diff > > > When distinct is in the select list and the query has order by with > expression, the resultset produced contains an additional column. > ij> create table t1 (c1 int, c2 varchar(10)) > 0 rows inserted/updated/deleted > ij> insert into t1 values (1,'a'),(2,'b'),(3,'c'); > 3 rows inserted/updated/deleted > select distinct c1, c2 from t1 order by c1; > C1 |C2 > -- > 1 |a > 2 |b > 3 |c > 3 rows selected > ij> select distinct c1, c2 from t1 order by c1+1; > C1 |C2|3 <=returns 3 > columns, incorrect result returned > -- > 1 |a |2 > 2 |b |3 > 3 |c |4 > 3 rows selected -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3515) 23 timeouts encountered while running management junit suite as part of full nightly runs.
[ https://issues.apache.org/jira/browse/DERBY-3515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Matrigali updated DERBY-3515: -- I ran a full set of tests with the timeout back to 300 and got no timeout errors. Dan if you have any suggestions for other experiments to prove/disprove that the timeout errors are related to timeout setting I would appreciate it. > 23 timeouts encountered while running management junit suite as part of full > nightly runs. > -- > > Key: DERBY-3515 > URL: https://issues.apache.org/jira/browse/DERBY-3515 > Project: Derby > Issue Type: Bug > Components: Regression Test Failure >Affects Versions: 10.4.0.0 > Environment: windows XP, laptop, ibm15 >Reporter: Mike Matrigali > Attachments: summary.out > > > While running full nightly test suite on a classes,SANE build got 23 failures > in management test suite as follows. Tried again in same codeline > just running the management test suite and it worked 50 times in a row. > Maybe issue is similar to DERBY-3514, where a previous test is leaving > a bad state and now that timeout has been reduced again to where it was known > to cause nightly test failures in some environments those issues > are resurfacing. I am trying another full suite run to see if it reproduces > in my environment, if others are seeing this issue, please add a comment. > I will attach full log of errors, but here is the first few: > There were 23 errors: > 1) > testDerbyRegisteredMBeansSimpleInfo(org.apache.derbyTesting.functionTests.tests.management.JMXTest)java.rmi.ConnectIOException: > Exception creating > connection to: 192.168.0.188; nested exception is: > java.net.SocketException: Operation timed out: connect:could be due to > invalid address > at sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:603) > at sun.rmi.transport.tcp.TCPChannel.createConnection(TCPChannel.java:204) > at sun.rmi.transport.tcp.TCPChannel.newConnection(TCPChannel.java:190) > at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:109) > at > javax.management.remote.rmi.RMIServerImpl_Stub.newClient(RMIServerImpl_Stub.java:52) > at > javax.management.remote.rmi.RMIConnector.getConnection(RMIConnector.java:2244) > at javax.management.remote.rmi.RMIConnector.connect(RMIConnector.java:286) > at > javax.management.remote.JMXConnectorFactory.connect(JMXConnectorFactory.java:263) > at > org.apache.derbyTesting.functionTests.tests.management.RemoteConnectionGetter.getMBeanServerConnection(RemoteConnectionGetter.java:49) > at > org.apache.derbyTesting.functionTests.tests.management.MBeanTest.getMBeanServerConnection(MBeanTest.java:177) > at > org.apache.derbyTesting.functionTests.tests.management.MBeanTest.getApplicationManagementMBean(MBeanTest.java:252) > at > org.apache.derbyTesting.functionTests.tests.management.MBeanTest.enableManagement(MBeanTest.java:201) > at > org.apache.derbyTesting.functionTests.tests.management.MBeanTest.setUp(MBeanTest.java:155) > at > org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:101) > at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) > at junit.extensions.TestSetup$1.protect(TestSetup.java:19) > at junit.extensions.TestSetup.run(TestSetup.java:23) > at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) > at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) > at junit.extensions.TestSetup$1.protect(TestSetup.java:19) > at junit.extensions.TestSetup.run(TestSetup.java:23) > at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) > at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) > at junit.extensions.TestSetup$1.protect(TestSetup.java:19) > at junit.extensions.TestSetup.run(TestSetup.java:23) > at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) > at junit.extensions.TestSetup$1.protect(TestSetup.java:19) > at junit.extensions.TestSetup.run(TestSetup.java:23) > Caused by: java.net.SocketException: Operation timed out: connect:could be > due to invalid address > at java.net.PlainSocketImpl.socketConnect(Native Method) > at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:372) > at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:233) > at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:220) > at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:385) > at java.net.Socket.connect(Socket.java:541) > at java.net.Socket.connect(Socket.java:491) > at java.net.Socket.(Socket.java:399) > at java.net.Socket.(Socket.java:208) > at > sun.rmi.transport.proxy.RMIDirectSocketFactory.createSo
[jira] Subscription: Derby: JIRA issues with patch available
Issue Subscription Filter: Derby: JIRA issues with patch available (14 issues) Subscriber: derby-dev Key Summary DERBY-3503 Change stress.multi to dump thread stacks before killing off testers with jdk 1.5 and higher https://issues.apache.org/jira/browse/DERBY-3503 DERBY-3435 Add an MBean for monitoring and managing the Network Server https://issues.apache.org/jira/browse/DERBY-3435 DERBY-3447 Shutdown on a database without stopping replication hangs https://issues.apache.org/jira/browse/DERBY-3447 DERBY-3491 Change SystemPermission to be a two arguement permission with a name (object the permission is on) and an action. https://issues.apache.org/jira/browse/DERBY-3491 DERBY-3448 Allow the MailJdbc system test to run under junit. https://issues.apache.org/jira/browse/DERBY-3448 DERBY-3460 SQL roles: patch to mask off roles on 10.4 release branch https://issues.apache.org/jira/browse/DERBY-3460 DERBY-3327 SQL roles: Implement authorization stack (and SQL session context to hold it) https://issues.apache.org/jira/browse/DERBY-3327 DERBY-3169 Add documentation for replication https://issues.apache.org/jira/browse/DERBY-3169 DERBY-2871 XATransactionTest gets XaException: Error executing a XAResource.commit(), server returned XAER_PROTO. https://issues.apache.org/jira/browse/DERBY-2871 DERBY-3409 Remove JDBC 2.0-specific topics from Reference Manual and merge implementation notes as needed https://issues.apache.org/jira/browse/DERBY-3409 DERBY-3379 "No Current connection" on PooledConnection.getConnection() if pooled connection is reused during connectionClosed processing https://issues.apache.org/jira/browse/DERBY-3379 DERBY-2954 Add commands to NetworkServerControl for interacting with the replication functionality https://issues.apache.org/jira/browse/DERBY-2954 DERBY-2953 Dump the information about rollbacks of the global transaction (introduced in DERBY-2220 and DERBY-2432) to derby.log https://issues.apache.org/jira/browse/DERBY-2953 DERBY-3227 Remove final from all getConnection() methods in EmbeddedDataSource https://issues.apache.org/jira/browse/DERBY-3227
Regression Test Report - Daily 634745 - Sun DBTG
[Auto-generated mail] *Daily* 634745/2008-03-07 18:01:12 MET Failed TestsOK Skip Duration Suite --- *Jvm: 1.6* lin 1274273 087.65% derbyall F:1,E:01041410413 0 1521.95% suitesAll linN+1 NA NA NANA derbyall NA NA NANA suitesAll sles 2274272 085.86% derbyall 01041410414 0 989.36% suitesAll sol 1274273 083.24% derbyall F:0,E:11041410413 0 1597.12% suitesAll solN+1 0274274 098.69% derbyall 01041410414 0 200.74% suitesAll sparc 0274274 066.70% derbyall 01041410414 0 390.31% suitesAll vista 1274273 0 102.48% derbyall NA NA NANA suitesAll w2003 1274273 0 103.38% derbyall NA NA NANA suitesAll Details in http://dbtg.thresher.com/derby/test/Daily/jvm1.6/testing/Limited/testSummary-634745.html Attempted failure analysis in http://dbtg.thresher.com/derby/test/Daily/jvm1.6/FailReports/634745_bySig.html *Jvm: 1.5* lin 0275275 082.97% derbyall NA NA NANA suitesAll linN+1 NA NA NANA derbyall NA NA NANA suitesAll sles 4275271 095.62% derbyall NA NA NANA suitesAll sol 2275273 086.56% derbyall UNKOWNUNKOWNUNKOWN UNKOWN 0.00% suitesAll solN+1 1275274 0 163.09% derbyall NA NA NANA suitesAll sparc 2275273 075.11% derbyall NA NA NANA suitesAll vista NA NA NANA derbyall NA NA NANA suitesAll w2003 NA NA NANA derbyall NA NA NANA suitesAll Details in http://dbtg.thresher.com/derby/test/Daily/jvm1.5/testing/Limited/testSummary-634745.html Attempted failure analysis in http://dbtg.thresher.com/derby/test/Daily/jvm1.5/FailReports/634745_bySig.html *Jvm: 1.4* lin NA NA NANA derbyall NA NA NANA suitesAll linN+1 NA NA NANA derbyall NA NA NANA suitesAll sles NA NA NANA derbyall NA NA NANA suitesAll sol NA NA NANA derbyall NA NA NANA suitesAll solN+1 NA NA NANA derbyall NA NA NANA suitesAll sparc NA NA NANA derbyall NA NA NANA suitesAll vista NA NA NANA derbyall NA NA NANA suitesAll w2003 NA NA NANA derbyall NA NA NANA suitesAll Details in http://dbtg.thresher.com/derby/test/Daily/jvm1.4/testing/Limited/testSummary-634745.html Attempted failure analysis in http://dbtg.thresher.com/derby/test/Daily/jvm1.4/FailReports/634745_bySig.html --- Changes in http://dbtg.thresher.com/derby/test/Daily/UpdateInfo/634745.txt ( All results in http://dbtg.thresher.com/derby/test/ )
[jira] Commented: (DERBY-3515) 23 timeouts encountered while running management junit suite as part of full nightly runs.
[ https://issues.apache.org/jira/browse/DERBY-3515?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12576573#action_12576573 ] Daniel John Debrunner commented on DERBY-3515: -- Not sure what to say. Since the jmx connections are made after the NetworkServerTestSetup has sun its setUp method that implies to me that the NetworkServerTestSetup .setUp() always succeeded and thus the network server timeout was never exceeded. If the server failed to come up in less than 10 seconds you would see a failure of timeout trying to connect to the network server and not see any jmx connection attempts. I try running the tests over the weekend as well. Could it have been a one-off failure in your environment? > 23 timeouts encountered while running management junit suite as part of full > nightly runs. > -- > > Key: DERBY-3515 > URL: https://issues.apache.org/jira/browse/DERBY-3515 > Project: Derby > Issue Type: Bug > Components: Regression Test Failure >Affects Versions: 10.4.0.0 > Environment: windows XP, laptop, ibm15 >Reporter: Mike Matrigali > Attachments: summary.out > > > While running full nightly test suite on a classes,SANE build got 23 failures > in management test suite as follows. Tried again in same codeline > just running the management test suite and it worked 50 times in a row. > Maybe issue is similar to DERBY-3514, where a previous test is leaving > a bad state and now that timeout has been reduced again to where it was known > to cause nightly test failures in some environments those issues > are resurfacing. I am trying another full suite run to see if it reproduces > in my environment, if others are seeing this issue, please add a comment. > I will attach full log of errors, but here is the first few: > There were 23 errors: > 1) > testDerbyRegisteredMBeansSimpleInfo(org.apache.derbyTesting.functionTests.tests.management.JMXTest)java.rmi.ConnectIOException: > Exception creating > connection to: 192.168.0.188; nested exception is: > java.net.SocketException: Operation timed out: connect:could be due to > invalid address > at sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:603) > at sun.rmi.transport.tcp.TCPChannel.createConnection(TCPChannel.java:204) > at sun.rmi.transport.tcp.TCPChannel.newConnection(TCPChannel.java:190) > at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:109) > at > javax.management.remote.rmi.RMIServerImpl_Stub.newClient(RMIServerImpl_Stub.java:52) > at > javax.management.remote.rmi.RMIConnector.getConnection(RMIConnector.java:2244) > at javax.management.remote.rmi.RMIConnector.connect(RMIConnector.java:286) > at > javax.management.remote.JMXConnectorFactory.connect(JMXConnectorFactory.java:263) > at > org.apache.derbyTesting.functionTests.tests.management.RemoteConnectionGetter.getMBeanServerConnection(RemoteConnectionGetter.java:49) > at > org.apache.derbyTesting.functionTests.tests.management.MBeanTest.getMBeanServerConnection(MBeanTest.java:177) > at > org.apache.derbyTesting.functionTests.tests.management.MBeanTest.getApplicationManagementMBean(MBeanTest.java:252) > at > org.apache.derbyTesting.functionTests.tests.management.MBeanTest.enableManagement(MBeanTest.java:201) > at > org.apache.derbyTesting.functionTests.tests.management.MBeanTest.setUp(MBeanTest.java:155) > at > org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:101) > at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) > at junit.extensions.TestSetup$1.protect(TestSetup.java:19) > at junit.extensions.TestSetup.run(TestSetup.java:23) > at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) > at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) > at junit.extensions.TestSetup$1.protect(TestSetup.java:19) > at junit.extensions.TestSetup.run(TestSetup.java:23) > at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) > at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) > at junit.extensions.TestSetup$1.protect(TestSetup.java:19) > at junit.extensions.TestSetup.run(TestSetup.java:23) > at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) > at junit.extensions.TestSetup$1.protect(TestSetup.java:19) > at junit.extensions.TestSetup.run(TestSetup.java:23) > Caused by: java.net.SocketException: Operation timed out: connect:could be > due to invalid address > at java.net.PlainSocketImpl.socketConnect(Native Method) > at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:372) > at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:233) > at java.net.Plain
Regression Test Report - tinderbox_trunk16 634994 - Sun DBTG
[Auto-generated mail] *tinderbox_trunk16* 634994/2008-03-08 17:02:13 CET Failed TestsOK Skip Duration Suite --- *Jvm: 1.6* SunOS-5.10_i86pc-i386 2274272 0 103.04% derbyall 01041610416 0 1312.12% org.apache.derbyTesting.functionTests.suites.All Details in http://dbtg.thresher.com/derby/test/tinderbox_trunk16/jvm1.6/testing/Limited/testSummary-634994.html Attempted failure analysis in http://dbtg.thresher.com/derby/test/tinderbox_trunk16/jvm1.6/FailReports/634994_bySig.html --- Changes in http://dbtg.thresher.com/derby/test/tinderbox_trunk16/UpdateInfo/634994.txt ( All results in http://dbtg.thresher.com/derby/test/ )
[jira] Updated: (DERBY-3373) SQL "distinct" and "order by" needed together
[ https://issues.apache.org/jira/browse/DERBY-3373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Pendleton updated DERBY-3373: --- Attachment: allowExpressions.diff Attached is 'allowExpressions.diff', a patch proposal. This proposal backs out the line of code added by DERBY-2351 which was rejecting DISTINCT queries with ORDER BY expressions which did not appear explicitly in the SELECT list. With this patch, Derby once again allows a range of legitimate queries, such as: select distinct name from person order by lower(name) select distinct * from person order by age + 10 Unfortunately, with this patch, Derby now also allows the invalid query: select distinct name from person order by age*2 I haven't been able to quickly find an easy way to distinguish the valid queries from the invalid ones, and so as a short term measure I think it would be good to restore the previous (10.2 and prior) behavior for DISTINCT queries involving ORDER BY expressions. It was good that the DERBY-2351 patch rejected some invalid queries, but it was far worse that the patch rejected some valid ones. I added a number of new test cases to illustrate the behavior. Please have a look at the patch and let us know what you think! > SQL "distinct" and "order by" needed together > - > > Key: DERBY-3373 > URL: https://issues.apache.org/jira/browse/DERBY-3373 > Project: Derby > Issue Type: Bug > Components: SQL >Affects Versions: 10.3.2.1 > Environment: Solaris Dev Express, Java 5 >Reporter: Thomas Vatter >Assignee: Bryan Pendleton >Priority: Blocker > Fix For: 10.3.2.2 > > Attachments: allowExpressions.diff > > > I am pasting here the communication from the mailinglist. I am having a > blocking and large problem with it because I have to make a release that > needs the specified SQL query. > tom_ wrote: > > The errormessage is > > > > The ORDER BY clause may not specify an expression, since the query > > specifies > > DISTINCT > > [Error Code: 2] > > [SQL State: 4287A] > > > > The statement is > > > > select distinct > > t1.t1_id, t2.t2value1, t2.t2value2, t2.t2value3 > > from > > t1, t2, t3 > > where > > ... > > order by lower(t2.t2value2) , lower(t2.t2value1) , lower(t2.t2value3) > > > > > > > > > > Dyre.Tjeldvoll wrote: > > > >> tom_ <[EMAIL PROTECTED]> writes: > >> > >> > >>> I am using "disctinct" because of some self-joins and also needed to add > >>> an > >>> "order by" clause. An error is shown. Is it not possible to use distinct > >>> and > >>> order by together? > >>> > >> I think it is allowed. Executing > >> > >> select distinct * from sys.systables order by tablename; > >> > >> in ij works just fine. Could you show the error message you get, and > >> perhaps what the table looks like? > >> > >> -- > >> dt > >> > >> > >> > « [hide part of quote] > Hi Tom - > I see what you mean using the demo DB toursDB: > ij> select * from airlines order by lower(airline_full); > A&|AIRLINE_FULL|BASIC_RATE|DISTANCE_DISCOUNT > |BUSINESS_LEVEL_FACTOR > |FIRSTCLASS_LEVEL_FACT&|ECONOMY_SE&|BUSINESS_S&|FIRSTCLASS& > --- > > AA|Amazonian Airways |0.18 |0.03 > |0.5 |1.5 |20 |10 |5 > US|Union Standard Airlines |0.19 |0.05 > |0.4 |1.6 |20 |10 |5 > 2 rows selected > ij> select distinct * from airlines order by lower(airline_full); > ERROR 4287A: The ORDER BY clause may not specify an expression, since > the query specifies DISTINCT. > ij> select distinct airline_full from airlines order by lower(airline_full); > ERROR 4287A: The ORDER BY clause may not specify an expression, since > the query specifies DISTINCT. > ij> > I didn't find a JIRA enhancement to remove this restriction. I suggest > you file an Enhancement request to remove the restriction reported by > ERROR 4287A. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-2351) ORDER BY with expression with distinct in the select list returns incorrect result
[ https://issues.apache.org/jira/browse/DERBY-2351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Pendleton updated DERBY-2351: --- Attachment: modifySynonymResults.diff Patch 'modifySynonymResult.diff' includes the modifies results for the synonym test. I think this patch is worthy of commit; please have a look and let me know what you think. > ORDER BY with expression with distinct in the select list returns incorrect > result > -- > > Key: DERBY-2351 > URL: https://issues.apache.org/jira/browse/DERBY-2351 > Project: Derby > Issue Type: Bug > Components: SQL >Affects Versions: 10.2.1.6, 10.2.2.0, 10.3.1.4 > Environment: Any >Reporter: Yip Ng >Assignee: Bryan Pendleton > Fix For: 10.3.2.2, 10.4.0.0 > > Attachments: d2351_aliasing.diff, d2351_aliasing.diff, > d2351_aliasing_checkQualifiedName.diff, derby_2351.diff, derby_2351_v2.diff, > modifySynonymResults.diff, reproTests.diff > > > When distinct is in the select list and the query has order by with > expression, the resultset produced contains an additional column. > ij> create table t1 (c1 int, c2 varchar(10)) > 0 rows inserted/updated/deleted > ij> insert into t1 values (1,'a'),(2,'b'),(3,'c'); > 3 rows inserted/updated/deleted > select distinct c1, c2 from t1 order by c1; > C1 |C2 > -- > 1 |a > 2 |b > 3 |c > 3 rows selected > ij> select distinct c1, c2 from t1 order by c1+1; > C1 |C2|3 <=returns 3 > columns, incorrect result returned > -- > 1 |a |2 > 2 |b |3 > 3 |c |4 > 3 rows selected -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3493) stress.multi times out waiting on testers with blocked testers waiting on the same statement
[
https://issues.apache.org/jira/browse/DERBY-3493?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Knut Anders Hatlen updated DERBY-3493:
--
Attachment: d3493-1b.diff
Attaching a new patch (1b) since I mistakenly changed find() and create() so
that they left dummy objects in the cache if Cacheable.setIdentity() or
Cacheable.createIdentity() failed, which led to failures in some of the
recovery tests.
suites.All and derbyall ran cleanly with 1b (except the replication tests, see
DERBY-3517).
On a machine where I saw the hang in stress.multi in about 25% of the runs, I
ran 150 times without seeing the hang with the 1a patch, and 60 times with the
1b patch, so I believe the problem is solved.
> stress.multi times out waiting on testers with blocked testers waiting on the
> same statement
>
>
> Key: DERBY-3493
> URL: https://issues.apache.org/jira/browse/DERBY-3493
> Project: Derby
> Issue Type: Bug
> Components: Regression Test Failure, SQL, Test
>Affects Versions: 10.4.0.0
> Environment: IBM 1.5 Linux
>Reporter: Kathey Marsden
>Assignee: Knut Anders Hatlen
> Attachments: d3493-1a.diff, d3493-1b.diff,
> threaddump-1204806990660.tdump
>
>
> The diff is:
> 7 del
> < ...running last checks via final.sql
> 7 add
> > ...timed out trying to kill all testers,
> >skipping last scripts (if any). NOTE: the
> >likely cause of the problem killing testers is
> >probably not enough VM memory OR test cases that
> >run for very long periods of time (so testers do not
> >have a chance to notice stop() requests
> Test Failed.
> The testers that are stuck are stuck on the same statement e.g.
> --
> update main2 set y = 'zzz' where x = 5;
> ERROR 08000: Connection closed by unknown interrupt.
> ERROR XJ001: Java exception: ': java.lang.InterruptedException'.
> The interupt exception shows:
> java.lang.InterruptedException
> at java.lang.Object.wait(Native Method)
> at java.lang.Object.wait(Object.java:199)
> at
> org.apache.derby.impl.sql.GenericStatement.prepMinion(GenericStatement.java:195)
> at
> org.apache.derby.impl.sql.GenericStatement.prepare(GenericStatement.java:88)
> at
> org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.prepareInternalStatement(GenericLanguageConn
> ctionContext.java:768)
> at
> org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:606)
> at
> org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:555)
> at org.apache.derby.impl.tools.ij.ij.executeImmediate(ij.java:329)
> at
> org.apache.derby.impl.tools.ij.utilMain.doCatch(utilMain.java:508)
> at
> org.apache.derby.impl.tools.ij.utilMain.runScriptGuts(utilMain.java:350)
> The code at line 195 of GenericStatement shows:
>
> try {
> preparedStmt.wait();
> } catch (InterruptedException ie) {
> throw StandardException.interrupt(ie);
> }
> My first guess is that this is perhaps some type of Statement cache
> concurrency bug, but perhaps
> I am reading it wrong.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3493) stress.multi times out waiting on testers with blocked testers waiting on the same statement
[
https://issues.apache.org/jira/browse/DERBY-3493?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Knut Anders Hatlen updated DERBY-3493:
--
Derby Info: [Patch Available]
> stress.multi times out waiting on testers with blocked testers waiting on the
> same statement
>
>
> Key: DERBY-3493
> URL: https://issues.apache.org/jira/browse/DERBY-3493
> Project: Derby
> Issue Type: Bug
> Components: Regression Test Failure, SQL, Test
>Affects Versions: 10.4.0.0
> Environment: IBM 1.5 Linux
>Reporter: Kathey Marsden
>Assignee: Knut Anders Hatlen
> Attachments: d3493-1a.diff, d3493-1b.diff,
> threaddump-1204806990660.tdump
>
>
> The diff is:
> 7 del
> < ...running last checks via final.sql
> 7 add
> > ...timed out trying to kill all testers,
> >skipping last scripts (if any). NOTE: the
> >likely cause of the problem killing testers is
> >probably not enough VM memory OR test cases that
> >run for very long periods of time (so testers do not
> >have a chance to notice stop() requests
> Test Failed.
> The testers that are stuck are stuck on the same statement e.g.
> --
> update main2 set y = 'zzz' where x = 5;
> ERROR 08000: Connection closed by unknown interrupt.
> ERROR XJ001: Java exception: ': java.lang.InterruptedException'.
> The interupt exception shows:
> java.lang.InterruptedException
> at java.lang.Object.wait(Native Method)
> at java.lang.Object.wait(Object.java:199)
> at
> org.apache.derby.impl.sql.GenericStatement.prepMinion(GenericStatement.java:195)
> at
> org.apache.derby.impl.sql.GenericStatement.prepare(GenericStatement.java:88)
> at
> org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.prepareInternalStatement(GenericLanguageConn
> ctionContext.java:768)
> at
> org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:606)
> at
> org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:555)
> at org.apache.derby.impl.tools.ij.ij.executeImmediate(ij.java:329)
> at
> org.apache.derby.impl.tools.ij.utilMain.doCatch(utilMain.java:508)
> at
> org.apache.derby.impl.tools.ij.utilMain.runScriptGuts(utilMain.java:350)
> The code at line 195 of GenericStatement shows:
>
> try {
> preparedStmt.wait();
> } catch (InterruptedException ie) {
> throw StandardException.interrupt(ie);
> }
> My first guess is that this is perhaps some type of Statement cache
> concurrency bug, but perhaps
> I am reading it wrong.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3435) Add an MBean for monitoring and managing the Network Server
[ https://issues.apache.org/jira/browse/DERBY-3435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel John Debrunner updated DERBY-3435: - Derby Info: (was: [Patch Available]) NetworkServerMBean test patch applied: Revision: 635115 > Add an MBean for monitoring and managing the Network Server > --- > > Key: DERBY-3435 > URL: https://issues.apache.org/jira/browse/DERBY-3435 > Project: Derby > Issue Type: Sub-task > Components: JMX >Reporter: John H. Embretsen >Assignee: John H. Embretsen > Fix For: 10.4.0.0 > > Attachments: d3435_NetworkServerMBeanTest_v01.diff, d3435_v01.diff, > d3435_v01.stat, derby-3435-live-data-fix-v0.zip, > derby-3435-live-data-fix2-v0.diff, derby-3435-live-data-v0.diff, > derby-3435-live-data-v0.stat, derby-3435-live-data-v1.zip, > derby-3435-live-data-v2.zip > > > Most functionality of and information about a running instance of the Network > Server is currently only available from the host running the Network Server, > using the NetworkServerControl API. > With a JMX Management and Monitoring service in place utilizing JMX > (DERBY-1387), it is possible to expose some of the Network Server > functionality and information through an MBean that is specific to the > Network Server, to both local and remote users (JMX clients), subject to > security restrictions. Access to Derby libraries on the client side is not > even a requirement, potentially making a server administrator's job a lot > easier. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [jira] Commented: (DERBY-3515) 23 timeouts encountered while running management junit suite as part of full nightly runs.
I have now run 4 full runs of the complete junit suite with following results in my environment: 10 second timeout - 23 timeout errors in the JMX suites 10 second timeout - ~10 timeout errors in the JMX suites 300 second timeout - all tests pass (except for reported replication failures). 60 second timeout - all tests pass (except for reported replication failures). I have also run 50 sets of just the JMX with the 10 second timeout and all those pass, so I assume the problem is related to some other test somehow affecting the JVX tests. All the above tests are run on a laptop, connected to a VPN network, both hardware and software firewalls and a dsl line. Would not think any of that really mattered for a connection to network server on same machine, but I have no idea. I am going to try another 10 second run and then follow that to see how low I can get the timeout before getting errors. I wonder if there is a error handling bug that is missing the timeout from network server startup for the JMX tests? Daniel John Debrunner (JIRA) wrote: [ https://issues.apache.org/jira/browse/DERBY-3515?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12576573#action_12576573 ] Daniel John Debrunner commented on DERBY-3515: -- Not sure what to say. Since the jmx connections are made after the NetworkServerTestSetup has sun its setUp method that implies to me that the NetworkServerTestSetup .setUp() always succeeded and thus the network server timeout was never exceeded. If the server failed to come up in less than 10 seconds you would see a failure of timeout trying to connect to the network server and not see any jmx connection attempts. I try running the tests over the weekend as well. Could it have been a one-off failure in your environment? 23 timeouts encountered while running management junit suite as part of full nightly runs. -- Key: DERBY-3515 URL: https://issues.apache.org/jira/browse/DERBY-3515 Project: Derby Issue Type: Bug Components: Regression Test Failure Affects Versions: 10.4.0.0 Environment: windows XP, laptop, ibm15 Reporter: Mike Matrigali Attachments: summary.out While running full nightly test suite on a classes,SANE build got 23 failures in management test suite as follows. Tried again in same codeline just running the management test suite and it worked 50 times in a row. Maybe issue is similar to DERBY-3514, where a previous test is leaving a bad state and now that timeout has been reduced again to where it was known to cause nightly test failures in some environments those issues are resurfacing. I am trying another full suite run to see if it reproduces in my environment, if others are seeing this issue, please add a comment. I will attach full log of errors, but here is the first few: There were 23 errors: 1) testDerbyRegisteredMBeansSimpleInfo(org.apache.derbyTesting.functionTests.tests.management.JMXTest)java.rmi.ConnectIOException: Exception creating connection to: 192.168.0.188; nested exception is: java.net.SocketException: Operation timed out: connect:could be due to invalid address at sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:603) at sun.rmi.transport.tcp.TCPChannel.createConnection(TCPChannel.java:204) at sun.rmi.transport.tcp.TCPChannel.newConnection(TCPChannel.java:190) at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:109) at javax.management.remote.rmi.RMIServerImpl_Stub.newClient(RMIServerImpl_Stub.java:52) at javax.management.remote.rmi.RMIConnector.getConnection(RMIConnector.java:2244) at javax.management.remote.rmi.RMIConnector.connect(RMIConnector.java:286) at javax.management.remote.JMXConnectorFactory.connect(JMXConnectorFactory.java:263) at org.apache.derbyTesting.functionTests.tests.management.RemoteConnectionGetter.getMBeanServerConnection(RemoteConnectionGetter.java:49) at org.apache.derbyTesting.functionTests.tests.management.MBeanTest.getMBeanServerConnection(MBeanTest.java:177) at org.apache.derbyTesting.functionTests.tests.management.MBeanTest.getApplicationManagementMBean(MBeanTest.java:252) at org.apache.derbyTesting.functionTests.tests.management.MBeanTest.enableManagement(MBeanTest.java:201) at org.apache.derbyTesting.functionTests.tests.management.MBeanTest.setUp(MBeanTest.java:155) at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:101) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) at junit.extensions.TestDecorator.basicRun(
[jira] Resolved: (DERBY-3493) stress.multi times out waiting on testers with blocked testers waiting on the same statement
[
https://issues.apache.org/jira/browse/DERBY-3493?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Knut Anders Hatlen resolved DERBY-3493.
---
Resolution: Fixed
Fix Version/s: 10.4.0.0
Derby Info: (was: [Patch Available])
Committed revision 635183.
> stress.multi times out waiting on testers with blocked testers waiting on the
> same statement
>
>
> Key: DERBY-3493
> URL: https://issues.apache.org/jira/browse/DERBY-3493
> Project: Derby
> Issue Type: Bug
> Components: Regression Test Failure, SQL, Test
>Affects Versions: 10.4.0.0
> Environment: IBM 1.5 Linux
>Reporter: Kathey Marsden
>Assignee: Knut Anders Hatlen
> Fix For: 10.4.0.0
>
> Attachments: d3493-1a.diff, d3493-1b.diff,
> threaddump-1204806990660.tdump
>
>
> The diff is:
> 7 del
> < ...running last checks via final.sql
> 7 add
> > ...timed out trying to kill all testers,
> >skipping last scripts (if any). NOTE: the
> >likely cause of the problem killing testers is
> >probably not enough VM memory OR test cases that
> >run for very long periods of time (so testers do not
> >have a chance to notice stop() requests
> Test Failed.
> The testers that are stuck are stuck on the same statement e.g.
> --
> update main2 set y = 'zzz' where x = 5;
> ERROR 08000: Connection closed by unknown interrupt.
> ERROR XJ001: Java exception: ': java.lang.InterruptedException'.
> The interupt exception shows:
> java.lang.InterruptedException
> at java.lang.Object.wait(Native Method)
> at java.lang.Object.wait(Object.java:199)
> at
> org.apache.derby.impl.sql.GenericStatement.prepMinion(GenericStatement.java:195)
> at
> org.apache.derby.impl.sql.GenericStatement.prepare(GenericStatement.java:88)
> at
> org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.prepareInternalStatement(GenericLanguageConn
> ctionContext.java:768)
> at
> org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:606)
> at
> org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:555)
> at org.apache.derby.impl.tools.ij.ij.executeImmediate(ij.java:329)
> at
> org.apache.derby.impl.tools.ij.utilMain.doCatch(utilMain.java:508)
> at
> org.apache.derby.impl.tools.ij.utilMain.runScriptGuts(utilMain.java:350)
> The code at line 195 of GenericStatement shows:
>
> try {
> preparedStmt.wait();
> } catch (InterruptedException ie) {
> throw StandardException.interrupt(ie);
> }
> My first guess is that this is perhaps some type of Statement cache
> concurrency bug, but perhaps
> I am reading it wrong.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
