Testing progress
Hello River Folk, My focus in recent years has been addressing security concerns, such as deserialization and TSLv1.2 secure endpoints, during the River project's existance, we've only tested the TCP endpoints with the qa suite (the majority of tests), apart from some jtreg tests that test secure jeri endpoints. I don't talk about security a lot on this list, there are two reasons, the first is it's generally not a good idea to publicly discuss the details of secuity issues, at least until they're fixed anyway, the second is, that historically security has been a sensitive topic, When I first started running the qa test suite with secure endpoints, they didn't work at all, as the test suite was lacking the appropriate configuration and certificates, I've added certificate, keystore and truststore generation. I've been running the qa tests using secure endpoints, initially there were a lot of test failures, but, I've been working though them one by one, some failures were simply missing permissions in policy files, or minor configuration file changes (note configuration files for secure endpoints are independant of tcp configuration files and haven't changed since 2004).Some of the more difficult failures were remote callbacks being made by our service implementations without running in the services logged in Subject's context, necessary to establish a connection using the services certificates (services act as a client when making a remote callback). Basically we need our users to be able to utilise secure endpoints, almost as easily as TCP endpoints, with simple configuration changes, we don't want them having to debug. Anyway, so you know work is happening, I'm making progress and once all qa suite tests are passing using secure endpoints, I'll resume with River's modular build, so we can, module by module, reintegrate my work. The following are tests that were failing, but now are running and passing with JERI secure endpoints. ### FIXED ### #org/apache/river/test/impl/outrigger/admin/DestroyTestMahalo.td,\ #org/apache/river/test/impl/outrigger/admin/LookupGroupAdminTestTxnMgr.td,\ #org/apache/river/test/impl/outrigger/leasing/TxnMgrLeaseGrantTest.td,\ #org/apache/river/test/impl/outrigger/leasing/TxnMgrLeaseGrantTestAnyLength.td,\ #org/apache/river/test/impl/outrigger/leasing/TxnMgrLeaseGrantTestForever.td,\ #org/apache/river/test/impl/outrigger/leasing/UseNotifyLeaseTestShutdown.td,\ #org/apache/river/test/impl/outrigger/leasing/UseTxnMgrLeaseTest.td,\ #org/apache/river/test/impl/outrigger/leasing/UseTxnMgrLeaseTestCancel.td,\ #org/apache/river/test/impl/outrigger/leasing/UseTxnMgrLeaseTestRenew.td,\ #org/apache/river/test/impl/outrigger/leasing/UseTxnMgrLeaseTestRenewCancel.td,\ #org/apache/river/test/impl/outrigger/leasing/UserSpaceLeaseTest.td,\ #org/apache/river/test/impl/mahalo/ServerTransactionEqualityTest.td,\ #org/apache/river/test/impl/mahalo/ServerTransactionToStringTest.td,\ #org/apache/river/test/impl/mahalo/TxnMgrImplNullActivationConfigEntries.td,\ #org/apache/river/test/impl/mahalo/TxnMgrImplNullConfigEntries.td,\ #org/apache/river/test/impl/mahalo/TxnMgrImplNullRecoveredLocators.td,\ #org/apache/river/test/impl/mahalo/TxnMgrProxyEqualityTest.td,\ #org/apache/river/test/impl/mahalo/LeaseExpireCancelTest.td,\ #org/apache/river/test/impl/mahalo/LeaseExpireRenewTest.td,\ #org/apache/river/test/impl/mahalo/LeaseMapTest.td,\ #org/apache/river/test/impl/mahalo/LeaseTest.td,\ #org/apache/river/test/spec/lookupdiscovery/DiscardUnreachable.td,\ #org/apache/river/test/spec/lookupdiscovery/MulticastMonitorStop.td,\ #org/apache/river/test/spec/lookupdiscovery/MulticastMonitorStopReplace.td,\ #org/apache/river/test/spec/lookupdiscovery/MulticastMonitorTerminate.td,\ #org/apache/river/test/spec/lookupdiscovery/AddGroups.td,\ #org/apache/river/test/spec/lookupdiscovery/AddGroupsDups.td,\ #org/apache/river/test/spec/lookupdiscovery/AddNewDiscoveryChangeListener.td,\ #org/apache/river/test/spec/lookupdiscovery/AddNewDiscoveryListener.td,\ #org/apache/river/test/spec/lookupdiscovery/ConstructorAllGroups.td,\ #org/apache/river/test/spec/lookupdiscovery/ConstructorDups.td,\ #org/apache/river/test/spec/lookupdiscovery/DiscardUnreachable.td,\ #org/apache/river/test/spec/lookupdiscovery/Discovered.td,\ #org/apache/river/test/spec/lookupdiscovery/DiscoveredDelay.td,\ #org/apache/river/test/spec/lookupdiscovery/DiscoveredStagger.td,\ #org/apache/river/test/spec/lookupdiscovery/DiscoveryBeginsOnAddGroupsAfterEmpty.td,\ #org/apache/river/test/spec/lookupdiscovery/DiscoveryBeginsOnSetGroupsAfterEmpty.td,\ #org/apache/river/test/spec/lookupdiscovery/DiscoveryBeginsOnSetGroupsAllAfterEmpty.td,\ #org/apache/river/test/spec/lookupdiscovery/DiscoveryEndsOnTerminate.td,\ #org/apache/river/test/spec/lookupdiscovery/GetRegistrars.td,\ #org/apache/river/test/spec/lookupdiscovery/GetRegistrarsNew.td,\ #org/apache/river/test/spec/lookupdiscovery/MulticastMonitorAllChange.td,\ #org
Progress
I've been a little quiet, but have been busy testing, testing, testing. Will get back to work on River's modular build in the near future. AtomicILFactory, is a JERI invocation layer factory alternative to BasicILFactory, which uses atomic input validation during deserialization. Unlike BasicILFactory, proxy's are serialized independantly of other objects in the stream (no shared state), service proxy's have their codebases provisioned after they're authenticated, proxy's aren't deserialized, nor are their codebases provisioned until they're authenticated. Currently the only time a codebase annotation is utilised is during provisioning, the stream uses ClassLoaders at each endpoint. In a modular environment, such as Maven or OSGi, the ClassLoader's at each endpoint (local and remote), use the same codebase (that of the proxy), so all class dependencies are resolved at each endpoint. There are cases where some classes cannot be resolved, such as when a client passes a parameter object, who's class is not resolvable from the proxy's dependencies (the proxy's ClassLoader), I'm currently working on making it an option to use codebase annotations, but only when classes cannot be resolved from the proxy's ClassLoader. In these cases the codebase must resolve dependencies to the same service api version (service api is the public api the client and proxy use to interact) at the remote server endpoint. Regards, Peter.
Re: Thoughts, progress and plans.
Hi Bryan, Yes, I'm hoping that it creates some renewed interest. River is currently limited to local networks and vpn's. So we'll be providing improved security options for developers using local networks, but also be able to completely lock down a public service that's reachable over https. Anyone with an IPv6 address, will be able to provide a service to clients also using IPv6, anywhere in the world over https and we're not going to have the IPv4 private network NAT issue. We'll need a few public lookup services available over https and people will be able to create their own. It's likely that multicast packets will be blocked by some networks, so unicast lookup over https is important to fill that gap. Once people have a link to at least one https lookup service, then they'll be able to search for other lookup services registered there to perform a far wider global search. Then we have delayed unmarshalling to allow local filtering to occur using logical operations before provisioning code. Cheers, Peter. On 20/04/2018 12:09 AM, Bryan Thompson wrote: Peter, That sounds like a quite a bit of interesting progress! Maybe we could brainstorm some examples of secure services on the list, implement some examples, and publish the services and their code? Bryan On Thu, Apr 19, 2018 at 5:19 AM, Peter<j...@zeus.net.au> wrote: What I’ve been up to: 1. Moved atomic serialization and support for OSGi into AtomicILFactory, so BasicILFactory functionality effectively remains unchanged. Taking advantage of the Extensible part of JERI. Note we can also support other protocols by taking advantage of JERI's extensibility. 2. Newly created TLS RMIServerSocketFactory and RMIClientSocketFactory utilise the current Subject for credentials to perform TLS handshakes and connections. This is allows the Registry to be secured for Phoenix, so Phoenix can run in secure mode, using JERI Secure endpoints for the ActivationSystem and other components and use the same LoginModule for both. SSL RMI socket factory's included with the jvm require access to a KeyStore and don't utilise the Subject. Note that a truststore is still required. Using the Subject is more flexible and it's extensible with LoginModule. a. JERI with secure sockets and atomic serialization can now be utilised for the following services in Phoenix: i. ActivationMonitor, ii. ActivationSystem, iii. Activator. b. RMI with TLS sockets for securing: i. Registry service ii. LocateRegistry methods. 3. Lots of additional testing using atomic endpoints over JSSE, transient and activatable configurations for tests. a. We currently have about 1400 tests, and this is being compounded to 5600 tests with each configuration (there’s more configuration options so this can go higher eventually). 1400 tests take about 24 hours to complete, so we’re talking 4 days’ worth of testing for a full run. 4. FindBugs Static testing and more bug fixes. I’m getting ready to fill out the modular build structure for River and populate it with River’s code. Next steps are then to donate externally developed features, module by module, so people can digest the changes and propose improvements they want too. I’m very close to being able to deploy a locked down secure version of Reggie with TLS and atomic serialization over IPv6, so we can have a public lookup service permanently running so people can register their services there, this will be locatable via https unicast and IPv6 Global multicast. We can then update and modernise the service browser, so people can experiment with these services. I’m also thinking we need to set up a small Certificate Authority, so any user can request a user certificate be signed, and service providers also. I think we should keep these separate, as users could remain relatively anonymous, client certificates are only required to prevent MITM attacks. Services will require more discretion as users will consume their code, so I think we need a reputation system, where services that behave badly can be identified and have their certificates revoked at a Hold level, or revoked irreversibly depending on whether they rectify the issue with their service. We could also have different CA signing certs that represent levels of trust, so you basically start with a minimal level of trust and as you build up your reputation, you get your certificate signed with CA signer cert that represents a higher level of trust. Services will be able to track client certificates, but don’t need to know any personal details, your private certificate will be your identity basically. So what I’m thinking is, we can create a service ecosystem, where we’re using secure TLS certificates, so companies / people can interact securely. Regards, Peter.
Re: Thoughts, progress and plans.
Peter, That sounds like a quite a bit of interesting progress! Maybe we could brainstorm some examples of secure services on the list, implement some examples, and publish the services and their code? Bryan On Thu, Apr 19, 2018 at 5:19 AM, Peter <j...@zeus.net.au> wrote: > What I’ve been up to: > > 1. Moved atomic serialization and support for OSGi into AtomicILFactory, so > BasicILFactory functionality effectively remains unchanged. Taking advantage > of the Extensible part of JERI. Note we can also support other protocols by > taking advantage of JERI's extensibility. > 2. Newly created TLS RMIServerSocketFactory and RMIClientSocketFactory > utilise the current Subject for credentials to perform TLS handshakes and > connections. This is allows the Registry to be secured for Phoenix, so > Phoenix can run in secure mode, using JERI Secure endpoints for the > ActivationSystem and other components and use the same LoginModule for both. > SSL RMI socket factory's included with the jvm require access to a KeyStore > and don't utilise the Subject. Note that a truststore is still required. > Using the Subject is more flexible and it's extensible with LoginModule. > a. JERI with secure sockets and atomic serialization can now be utilised for > the following services in Phoenix: > i. ActivationMonitor, > ii. ActivationSystem, > iii. Activator. > b. RMI with TLS sockets for securing: > i. Registry service > ii. LocateRegistry methods. > 3. Lots of additional testing using atomic endpoints over JSSE, transient > and activatable configurations for tests. > a. We currently have about 1400 tests, and this is being compounded to 5600 > tests with each configuration (there’s more configuration options so this > can go higher eventually). 1400 tests take about 24 hours to complete, so > we’re talking 4 days’ worth of testing for a full run. > 4. FindBugs Static testing and more bug fixes. > > I’m getting ready to fill out the modular build structure for River and > populate it with River’s code. > > Next steps are then to donate externally developed features, module by > module, so people can digest the changes and propose improvements they want > too. > > I’m very close to being able to deploy a locked down secure version of > Reggie with TLS and atomic serialization over IPv6, so we can have a public > lookup service permanently running so people can register their services > there, this will be locatable via https unicast and IPv6 Global multicast. > We can then update and modernise the service browser, so people can > experiment with these services. > > I’m also thinking we need to set up a small Certificate Authority, so any > user can request a user certificate be signed, and service providers also. I > think we should keep these separate, as users could remain relatively > anonymous, client certificates are only required to prevent MITM attacks. > Services will require more discretion as users will consume their code, so I > think we need a reputation system, where services that behave badly can be > identified and have their certificates revoked at a Hold level, or revoked > irreversibly depending on whether they rectify the issue with their service. > > We could also have different CA signing certs that represent levels of > trust, so you basically start with a minimal level of trust and as you build > up your reputation, you get your certificate signed with CA signer cert that > represents a higher level of trust. > > Services will be able to track client certificates, but don’t need to know > any personal details, your private certificate will be your identity > basically. > > So what I’m thinking is, we can create a service ecosystem, where we’re > using secure TLS certificates, so companies / people can interact securely. > > Regards, > > Peter.
Thoughts, progress and plans.
What I’ve been up to: 1. Moved atomic serialization and support for OSGi into AtomicILFactory, so BasicILFactory functionality effectively remains unchanged. Taking advantage of the Extensible part of JERI. Note we can also support other protocols by taking advantage of JERI's extensibility. 2. Newly created TLS RMIServerSocketFactory and RMIClientSocketFactory utilise the current Subject for credentials to perform TLS handshakes and connections. This is allows the Registry to be secured for Phoenix, so Phoenix can run in secure mode, using JERI Secure endpoints for the ActivationSystem and other components and use the same LoginModule for both. SSL RMI socket factory's included with the jvm require access to a KeyStore and don't utilise the Subject. Note that a truststore is still required. Using the Subject is more flexible and it's extensible with LoginModule. a. JERI with secure sockets and atomic serialization can now be utilised for the following services in Phoenix: i. ActivationMonitor, ii. ActivationSystem, iii. Activator. b. RMI with TLS sockets for securing: i. Registry service ii. LocateRegistry methods. 3. Lots of additional testing using atomic endpoints over JSSE, transient and activatable configurations for tests. a. We currently have about 1400 tests, and this is being compounded to 5600 tests with each configuration (there’s more configuration options so this can go higher eventually). 1400 tests take about 24 hours to complete, so we’re talking 4 days’ worth of testing for a full run. 4. FindBugs Static testing and more bug fixes. I’m getting ready to fill out the modular build structure for River and populate it with River’s code. Next steps are then to donate externally developed features, module by module, so people can digest the changes and propose improvements they want too. I’m very close to being able to deploy a locked down secure version of Reggie with TLS and atomic serialization over IPv6, so we can have a public lookup service permanently running so people can register their services there, this will be locatable via https unicast and IPv6 Global multicast. We can then update and modernise the service browser, so people can experiment with these services. I’m also thinking we need to set up a small Certificate Authority, so any user can request a user certificate be signed, and service providers also. I think we should keep these separate, as users could remain relatively anonymous, client certificates are only required to prevent MITM attacks. Services will require more discretion as users will consume their code, so I think we need a reputation system, where services that behave badly can be identified and have their certificates revoked at a Hold level, or revoked irreversibly depending on whether they rectify the issue with their service. We could also have different CA signing certs that represent levels of trust, so you basically start with a minimal level of trust and as you build up your reputation, you get your certificate signed with CA signer cert that represents a higher level of trust. Services will be able to track client certificates, but don’t need to know any personal details, your private certificate will be your identity basically. So what I’m thinking is, we can create a service ecosystem, where we’re using secure TLS certificates, so companies / people can interact securely. Regards, Peter.
Re: Recent Progress
In case anyone's concerned, maven or osgi isn't mandatory, this is simply intended to make River play well with OSGi. Making River play well with OSGi shouldn't be of concern to those who don't want the option, as the existing functionality and use cases will continue working, this functionality is assured by tests. For OSGi, we're ensuring class visibility is identical at each endpoint. The smart proxy code / bundle / version is a service implementation concern. The use of java serialization is also a service implementation concern that can be replaced in future. It's my intent to bring this functionality to River once it has stabilised. Some River developers / users have often strongly expressed their preference towards maintaining a stable trunk, that hasn't changed. My preference would be for a git based repo, as git workd very well with a stable trunk with fork and merge development. Svn is beter suited to an experimental trunk with a period of stabilisation prior to branching for release. A piece of trivia, the modular build uses maven for code that will be released, ant for the test suite and make for CA cert generation for jtreg tests. Maven modules certainly simplify River , it organises the code into understandable digestible bites. Cheers, Peter. Sent from my Samsung device. Include original message Original message From: Peter <j...@zeus.net.au> Sent: 21/04/2017 12:37:09 pm To: dev@river.apache.org <dev@river.apache.org> Subject: Recent Progress I've recently reached a milestone regarding testing of the jgdms modular maven build (in OSGi bundle format based on River 3.0,) where 99.6% of the qa test suite is now passing. I haven't run the jtreg test suite against it yet, but will do so in coming weeks. Note that at this stage it has not been tested in an OSGi environment. The following changes have been made to provide support for OSGi: 1. Modules are also OSGi bundles 2. Service implementation modules now depend on proxy / download modules (as per Rio module practices). Serializable objects used by a service have the same ClassLoader visibility through the same proxy / download module at the server and client endpoints. Service implementation classes will not be visible to serializable objects and don't need nor should be (a significant security advantage reducing both endpoints attack surface). 3. ServiceLoader providers will be automatically registered with the osgi service registry. The discovery implementations are in their own module and available from the osgi service registry for example. I'm planning on using the module structure / layout / relationships as a guide for River 3.1 I'm also considering renaming JGDMS to Overture after the Jini experimental pre release of the same name. Note this code has been security hardened in other ways including the latest tls v1.2 cyphers, removal of insecure cyphers, input validation for deserialization as well as delayed unmarshalling that allows authentication before provisioning service proxy modules during discovery and lookup. I'm not sure how popular phoenix activation is, but it too now has has the option of using secure sockets for the rmi registry to prevent unauthorised access. Regards, Peter. Sent from my Samsung device.
Recent Progress
I've recently reached a milestone regarding testing of the jgdms modular maven build (in OSGi bundle format based on River 3.0,) where 99.6% of the qa test suite is now passing. I haven't run the jtreg test suite against it yet, but will do so in coming weeks. Note that at this stage it has not been tested in an OSGi environment. The following changes have been made to provide support for OSGi: 1. Modules are also OSGi bundles 2. Service implementation modules now depend on proxy / download modules (as per Rio module practices). Serializable objects used by a service have the same ClassLoader visibility through the same proxy / download module at the server and client endpoints. Service implementation classes will not be visible to serializable objects and don't need nor should be (a significant security advantage reducing both endpoints attack surface). 3. ServiceLoader providers will be automatically registered with the osgi service registry. The discovery implementations are in their own module and available from the osgi service registry for example. I'm planning on using the module structure / layout / relationships as a guide for River 3.1 I'm also considering renaming JGDMS to Overture after the Jini experimental pre release of the same name. Note this code has been security hardened in other ways including the latest tls v1.2 cyphers, removal of insecure cyphers, input validation for deserialization as well as delayed unmarshalling that allows authentication before provisioning service proxy modules during discovery and lookup. I'm not sure how popular phoenix activation is, but it too now has has the option of using secure sockets for the rmi registry to prevent unauthorised access. Regards, Peter. Sent from my Samsung device.
River Progress
After what seems like a marathon, I've just finished converting remaining service implementations to the new com.sun.jini.start.Starter interface, no longer is 'this' allowed to escape during construction. The only remaining instances I'm aware of are the examples, I looked at fixing them, but lets face it, we need better examples that demonstrate best practises, any volunteers? When I set out to refactor the qa suite, I never expected to find so many issues, including those found in the main distribution. Findbugs was helpful to identify issues, other issues revealed themselves as work progressed. I haven't of course fixed all the issues, but I can say that things are better, don't forget most of this code was written prior to the current Java Memory Model, so this is more or less just houskeeping. I've got a little more testing to do, then it's time merge Sim's work back in from trunk and branch for release. To ensure we've got the highest quality build possible, we can allow additional time for release candidate testing. Thanks for all the support, I understand this hasn't been the easiest process. After the next release I recommend we focus more on code simplification and correctness to really make our codebase solid, so it's easier to understand and develop, if we're fortunate enough, wiser, more experienced (not to mention modest) developers will be tempted to jump in and do some really great work. Regards, Peter.
Re: Development Progress update.
1412 passed, 46 skipped, 0 failures in about 58000 seconds. On 10 March 2013 13:26, Dan Creswell dan.cresw...@gmail.com wrote: I'm currently running this and jtreg, I'll report back when it's done. JDK 7 on OS X 10.8.2... On 10 March 2013 13:17, Dennis Reedy dennis.re...@gmail.com wrote: I ran: ant qa.run [java] - [java] GENERAL HARNESS CONFIGURATION INFORMATION: [java] [java]Date started: [java] Sat Mar 09 08:19:09 EST 2013 [java]Installation directory of the JSK: [java] com.sun.jini.jsk.home=/Users/dreedy/dev/src/projects/river/qa-trunk [java]Installation directory of the harness: [java] com.sun.jini.qa.home=/Users/dreedy/dev/src/projects/river/qa-trunk/qa [java]Categories being tested: [java] categories=id loader policyprovider locatordiscovery activation config discoverymanager joinmanager url iiop jrmp reliability thread renewalmanager constraint export lookupdiscovery servicediscovery io security lookupservice renewalservice eventmailbox jeri start discoveryservice discoveryproviders javaspace txnmanager [java] - [java] ENVIRONMENT PROPERTIES: [java] [java]JVM information: [java] Java HotSpot(TM) 64-Bit Server VM, 23.7-b01, 64 bit VM mode [java] Oracle Corporation [java]OS information: [java] Mac OS X, 10.7.5, x86_64 [java] [java] [java] # of tests started = 1412 [java] # of tests completed = 1412 [java] # of tests skipped = 46 [java] # of tests passed= 1412 [java] # of tests failed= 0 [java] [java] - [java] [java]Date finished: [java] Sun Mar 10 00:45:27 EST 2013 [java]Time elapsed: [java] 59178 seconds On Mar 9, 2013, at 840PM, Peter Firmstone wrote: Recent test failures: Solaris sparc: com/sun/jini/test/impl/outrigger/matching/StressTestWithShutdown.td Ubuntu JDK7 com/sun/jini/test/impl/outrigger/leasing/UseTxnMgrSpaceLeaseTestRenewCancel.td com/sun/jini/test/spec/jrmp/jrmpexporter/Unexport_BehaviorTest2.td com/sun/jini/test/spec/jrmp/jrmpexporter/Unexport_BehaviorTest3.td com/sun/jini/test/spec/jrmp/jrmpexporter/Unexport_BehaviorTest4.td com/sun/jini/test/impl/outrigger/transaction/BlockingOnDeadTransactionTest.td Ubuntu Arm embedded com/sun/jini/test/impl/outrigger/leasing/UseNotifyLeaseTestRenewShutdown.td Ubuntu jdk6 com/sun/jini/test/spec/javaspace/conformance/ExpirationNotifyTest.td There are some remaining issues relating to unsafe publication, identified by find bugs (calling Thread.start() during construction), I'll fix these during the week, the failed jrmpexporter tests simply seem to be tests starting before previous tests sockets have been released by the OS. The remaining issues appear to be JavaSpace related. Regards, Peter. Dan Creswell wrote: I'm headed back to the UK so can test OS X in a couple of days if that's still useful... On 7 March 2013 05:25, Peter Firmstone j...@zeus.net.au wrote: There are issues with some builds on Hudson, preventing test execution. Windows: a file can't be deleted in preparation for checkout, preventing build from executing. Solaris: BindException socket in use causes numerous test failures FreeBSD: BindException socket in use, prevents build from executing. OSX: offline. Apart from that, the tests are all passing on my Window's PC, Ubuntu x64 and ARM. I need people who can volunteer to run QA tests! I wasn't attempting to improve performance, recent bug fixes have resulted in the qa suite now finishing one hour earlier, which is a 6% performance increase. Apart from fixing test failures, I've also used FindBugs to fix: * Javaspaces Outrigger: 13 multithreaded correctness bugs. * Jini Platform: 5 inconsistent synchronization bugs. * Jsk lib: 12 multithreaded correctness bugs. * qa test suite: 20 multithreaded correctness bugs. Now's the time to checkout and run qa tests, then lets kick out a release. https://svn.apache.org/repos/asf/river/jtsk/skunk/qa_refactor/trunk or http://svn.apache.org/repos/asf/river/jtsk/skunk/qa_refactor/trunk Regards, Peter.
Re: Development Progress update.
Cool, Thanks Dennis, Dan Bryan, we're getting there! Bryan experienced two test failures on OSX: com/sun/jini/test/impl/start/CodebaseTest.td caused by: [java] CodebaseTest.run FINE: expected codebase for test service 1 proxy: http://Bryan-Thompson-MacBook-Air.local:9082/qa1-start-testservice1-dl.jar http://Bryan-Thompson-MacBook-Air.local:9082/qa1-start-testservice-common-dl.jar [java] CodebaseTest.run FINE: actual codebase for test service 1 proxy: http://bryan-thompson-macbook-air.local:9082/qa1-start-testservice1-dl.jar http://bryan-thompson-macbook-air.local:9082/qa1-start-testservice-common-dl.jar I've fixed it locally so both codebase strings are normalised, I'll upload the fix soon. The other: com/sun/jini/test/spec/javaspace/conformance/snapshot/SnapshotExpirationNotifyTest.td [java] Test Failed: Test Failed: com.sun.jini.qa.harness.TestException: Not all listeners've got expected number of events. I'm hoping that this is caused by the following bug I've discovered in com.sun.jini.jeri.internal.mux.StreamConnectionIO The LinkedList sendQueue access is synchronized with Mux.muxLock, unfortunately sendQueue's reference was copied to an instance variable and allowed to escape synchronization, FindBugs wasn't able to find this one, I had to track it down the old way, it caused the following test to fail on sparc: com/sun/jini/test/impl/outrigger/matching/StressTestWithShutdown.td . I believe I've found the cause, but won't be entirely sure until I run the tests on the old sparc again (might have to do it remotely, it's about 180km away). Anyway basically what appears to be happening is while the contents of sendQueue are being sent to open a connection to the server, other tasks are writing to the sendQueue, so the server on occassion ends up getting some other garbled info instead and doesn't respond, leaving the test hanging. So I think I've got it this time! Will commit soon. On 11/03/2013 6:13 PM, Dan Creswell wrote: 1412 passed, 46 skipped, 0 failures in about 58000 seconds. On 10 March 2013 13:26, Dan Creswelldan.cresw...@gmail.com wrote: I'm currently running this and jtreg, I'll report back when it's done. JDK 7 on OS X 10.8.2... On 10 March 2013 13:17, Dennis Reedydennis.re...@gmail.com wrote: I ran: ant qa.run [java] - [java] GENERAL HARNESS CONFIGURATION INFORMATION: [java] [java]Date started: [java] Sat Mar 09 08:19:09 EST 2013 [java]Installation directory of the JSK: [java] com.sun.jini.jsk.home=/Users/dreedy/dev/src/projects/river/qa-trunk [java]Installation directory of the harness: [java] com.sun.jini.qa.home=/Users/dreedy/dev/src/projects/river/qa-trunk/qa [java]Categories being tested: [java] categories=id loader policyprovider locatordiscovery activation config discoverymanager joinmanager url iiop jrmp reliability thread renewalmanager constraint export lookupdiscovery servicediscovery io security lookupservice renewalservice eventmailbox jeri start discoveryservice discoveryproviders javaspace txnmanager [java] - [java] ENVIRONMENT PROPERTIES: [java] [java]JVM information: [java] Java HotSpot(TM) 64-Bit Server VM, 23.7-b01, 64 bit VM mode [java] Oracle Corporation [java]OS information: [java] Mac OS X, 10.7.5, x86_64 [java] [java] [java] # of tests started = 1412 [java] # of tests completed = 1412 [java] # of tests skipped = 46 [java] # of tests passed= 1412 [java] # of tests failed= 0 [java] [java] - [java] [java]Date finished: [java] Sun Mar 10 00:45:27 EST 2013 [java]Time elapsed: [java] 59178 seconds On Mar 9, 2013, at 840PM, Peter Firmstone wrote: Recent test failures: Solaris sparc: com/sun/jini/test/impl/outrigger/matching/StressTestWithShutdown.td Ubuntu JDK7 com/sun/jini/test/impl/outrigger/leasing/UseTxnMgrSpaceLeaseTestRenewCancel.td com/sun/jini/test/spec/jrmp/jrmpexporter/Unexport_BehaviorTest2.td com/sun/jini/test/spec/jrmp/jrmpexporter/Unexport_BehaviorTest3.td com/sun/jini/test/spec/jrmp/jrmpexporter/Unexport_BehaviorTest4.td com/sun/jini/test/impl/outrigger/transaction/BlockingOnDeadTransactionTest.td Ubuntu Arm embedded com/sun/jini/test/impl/outrigger/leasing/UseNotifyLeaseTestRenewShutdown.td Ubuntu jdk6 com/sun/jini/test/spec/javaspace/conformance/ExpirationNotifyTest.td There are some remaining issues relating to unsafe publication, identified by find bugs (calling Thread.start() during construction), I'll fix these during the week, the failed jrmpexporter tests simply seem to be tests starting before previous tests sockets have been released by the OS. The remaining issues appear to be JavaSpace related. Regards, Peter. Dan Creswell wrote: I'm headed back to the UK so can test OS X in a couple of days if that's still
Re: Development Progress update.
Cool, Thanks Dennis, Dan Bryan, we're getting there! Bryan experienced two test failures on OSX: com/sun/jini/test/impl/start/CodebaseTest.td caused by: [java] CodebaseTest.run FINE: expected codebase for test service 1 proxy: http://Bryan-Thompson-MacBook-Air.local:9082/qa1-start-testservice1-dl.jar http://Bryan-Thompson-MacBook-Air.local:9082/qa1-start-testservice-common-dl.jar [java] CodebaseTest.run FINE: actual codebase for test service 1 proxy: http://bryan-thompson-macbook-air.local:9082/qa1-start-testservice1-dl.jar http://bryan-thompson-macbook-air.local:9082/qa1-start-testservice-common-dl.jar I've fixed it locally so both codebase strings are normalised, I'll upload the fix soon. The other: com/sun/jini/test/spec/javaspace/conformance/snapshot/SnapshotExpirationNotifyTest.td [java] Test Failed: Test Failed: com.sun.jini.qa.harness.TestException: Not all listeners've got expected number of events. I'm hoping that this is caused by the following bug I've discovered in com.sun.jini.jeri.internal.mux.StreamConnectionIO The LinkedList sendQueue access is synchronized with Mux.muxLock, unfortunately sendQueue's reference was copied to an instance variable and allowed to escape synchronization, FindBugs wasn't able to find this one, I had to track it down the old way, it caused the following test to fail on sparc: com/sun/jini/test/impl/outrigger/matching/StressTestWithShutdown.td . I believe I've found the cause, but won't be entirely sure until I run the tests on the old sparc again (might have to do it remotely, it's about 180km away). Anyway basically what appears to be happening is while the contents of sendQueue are being sent to open a connection to the server, other tasks are writing to the sendQueue, so the server on occassion ends up getting some other garbled info instead and doesn't respond, leaving the test hanging. So I think I've got it this time! Will commit soon. On 11/03/2013 6:13 PM, Dan Creswell wrote: 1412 passed, 46 skipped, 0 failures in about 58000 seconds. On 10 March 2013 13:26, Dan Creswelldan.cresw...@gmail.com wrote: I'm currently running this and jtreg, I'll report back when it's done. JDK 7 on OS X 10.8.2... On 10 March 2013 13:17, Dennis Reedydennis.re...@gmail.com wrote: I ran: ant qa.run [java] - [java] GENERAL HARNESS CONFIGURATION INFORMATION: [java] [java]Date started: [java] Sat Mar 09 08:19:09 EST 2013 [java]Installation directory of the JSK: [java] com.sun.jini.jsk.home=/Users/dreedy/dev/src/projects/river/qa-trunk [java]Installation directory of the harness: [java] com.sun.jini.qa.home=/Users/dreedy/dev/src/projects/river/qa-trunk/qa [java]Categories being tested: [java] categories=id loader policyprovider locatordiscovery activation config discoverymanager joinmanager url iiop jrmp reliability thread renewalmanager constraint export lookupdiscovery servicediscovery io security lookupservice renewalservice eventmailbox jeri start discoveryservice discoveryproviders javaspace txnmanager [java] - [java] ENVIRONMENT PROPERTIES: [java] [java]JVM information: [java] Java HotSpot(TM) 64-Bit Server VM, 23.7-b01, 64 bit VM mode [java] Oracle Corporation [java]OS information: [java] Mac OS X, 10.7.5, x86_64 [java] [java] [java] # of tests started = 1412 [java] # of tests completed = 1412 [java] # of tests skipped = 46 [java] # of tests passed= 1412 [java] # of tests failed= 0 [java] [java] - [java] [java]Date finished: [java] Sun Mar 10 00:45:27 EST 2013 [java]Time elapsed: [java] 59178 seconds On Mar 9, 2013, at 840PM, Peter Firmstone wrote: Recent test failures: Solaris sparc: com/sun/jini/test/impl/outrigger/matching/StressTestWithShutdown.td Ubuntu JDK7 com/sun/jini/test/impl/outrigger/leasing/UseTxnMgrSpaceLeaseTestRenewCancel.td com/sun/jini/test/spec/jrmp/jrmpexporter/Unexport_BehaviorTest2.td com/sun/jini/test/spec/jrmp/jrmpexporter/Unexport_BehaviorTest3.td com/sun/jini/test/spec/jrmp/jrmpexporter/Unexport_BehaviorTest4.td com/sun/jini/test/impl/outrigger/transaction/BlockingOnDeadTransactionTest.td Ubuntu Arm embedded com/sun/jini/test/impl/outrigger/leasing/UseNotifyLeaseTestRenewShutdown.td Ubuntu jdk6 com/sun/jini/test/spec/javaspace/conformance/ExpirationNotifyTest.td There are some remaining issues relating to unsafe publication, identified by find bugs (calling Thread.start() during construction), I'll fix these during the week, the failed jrmpexporter tests simply seem to be tests starting before previous tests sockets have been released by the OS. The remaining issues appear to be JavaSpace related. Regards, Peter. Dan Creswell wrote: I'm headed back to the UK so can test OS X in a couple of days if that's still
Re: Development Progress update.
How do I run 'em? (I know about jtreg itself, just want the appropriate ant/command-line incantations to save me time). On 8 March 2013 22:32, Peter Firmstone j...@zeus.net.au wrote: Yes definitely, the more testing before release the better. Are you able to run the jtreg tests as well? They've only been tested on Solaris 10 sparc, I'm not aware of anyone else running jtreg tests for some time. Dan Creswell wrote: I'm headed back to the UK so can test OS X in a couple of days if that's still useful... On 7 March 2013 05:25, Peter Firmstone j...@zeus.net.au wrote: There are issues with some builds on Hudson, preventing test execution. Windows: a file can't be deleted in preparation for checkout, preventing build from executing. Solaris: BindException socket in use causes numerous test failures FreeBSD: BindException socket in use, prevents build from executing. OSX: offline. Apart from that, the tests are all passing on my Window's PC, Ubuntu x64 and ARM. I need people who can volunteer to run QA tests! I wasn't attempting to improve performance, recent bug fixes have resulted in the qa suite now finishing one hour earlier, which is a 6% performance increase. Apart from fixing test failures, I've also used FindBugs to fix: * Javaspaces Outrigger: 13 multithreaded correctness bugs. * Jini Platform: 5 inconsistent synchronization bugs. * Jsk lib: 12 multithreaded correctness bugs. * qa test suite: 20 multithreaded correctness bugs. Now's the time to checkout and run qa tests, then lets kick out a release. https://svn.apache.org/repos/asf/river/jtsk/skunk/qa_refactor/trunk or http://svn.apache.org/repos/asf/river/jtsk/skunk/qa_refactor/trunk Regards, Peter.
Re: Development Progress update.
I ran: ant qa.run [java] - [java] GENERAL HARNESS CONFIGURATION INFORMATION: [java] [java]Date started: [java] Sat Mar 09 08:19:09 EST 2013 [java]Installation directory of the JSK: [java] com.sun.jini.jsk.home=/Users/dreedy/dev/src/projects/river/qa-trunk [java]Installation directory of the harness: [java] com.sun.jini.qa.home=/Users/dreedy/dev/src/projects/river/qa-trunk/qa [java]Categories being tested: [java] categories=id loader policyprovider locatordiscovery activation config discoverymanager joinmanager url iiop jrmp reliability thread renewalmanager constraint export lookupdiscovery servicediscovery io security lookupservice renewalservice eventmailbox jeri start discoveryservice discoveryproviders javaspace txnmanager [java] - [java] ENVIRONMENT PROPERTIES: [java] [java]JVM information: [java] Java HotSpot(TM) 64-Bit Server VM, 23.7-b01, 64 bit VM mode [java] Oracle Corporation [java]OS information: [java] Mac OS X, 10.7.5, x86_64 [java] [java] [java] # of tests started = 1412 [java] # of tests completed = 1412 [java] # of tests skipped = 46 [java] # of tests passed= 1412 [java] # of tests failed= 0 [java] [java] - [java] [java]Date finished: [java] Sun Mar 10 00:45:27 EST 2013 [java]Time elapsed: [java] 59178 seconds On Mar 9, 2013, at 840PM, Peter Firmstone wrote: Recent test failures: Solaris sparc: com/sun/jini/test/impl/outrigger/matching/StressTestWithShutdown.td Ubuntu JDK7 com/sun/jini/test/impl/outrigger/leasing/UseTxnMgrSpaceLeaseTestRenewCancel.td com/sun/jini/test/spec/jrmp/jrmpexporter/Unexport_BehaviorTest2.td com/sun/jini/test/spec/jrmp/jrmpexporter/Unexport_BehaviorTest3.td com/sun/jini/test/spec/jrmp/jrmpexporter/Unexport_BehaviorTest4.td com/sun/jini/test/impl/outrigger/transaction/BlockingOnDeadTransactionTest.td Ubuntu Arm embedded com/sun/jini/test/impl/outrigger/leasing/UseNotifyLeaseTestRenewShutdown.td Ubuntu jdk6 com/sun/jini/test/spec/javaspace/conformance/ExpirationNotifyTest.td There are some remaining issues relating to unsafe publication, identified by find bugs (calling Thread.start() during construction), I'll fix these during the week, the failed jrmpexporter tests simply seem to be tests starting before previous tests sockets have been released by the OS. The remaining issues appear to be JavaSpace related. Regards, Peter. Dan Creswell wrote: I'm headed back to the UK so can test OS X in a couple of days if that's still useful... On 7 March 2013 05:25, Peter Firmstone j...@zeus.net.au wrote: There are issues with some builds on Hudson, preventing test execution. Windows: a file can't be deleted in preparation for checkout, preventing build from executing. Solaris: BindException socket in use causes numerous test failures FreeBSD: BindException socket in use, prevents build from executing. OSX: offline. Apart from that, the tests are all passing on my Window's PC, Ubuntu x64 and ARM. I need people who can volunteer to run QA tests! I wasn't attempting to improve performance, recent bug fixes have resulted in the qa suite now finishing one hour earlier, which is a 6% performance increase. Apart from fixing test failures, I've also used FindBugs to fix: * Javaspaces Outrigger: 13 multithreaded correctness bugs. * Jini Platform: 5 inconsistent synchronization bugs. * Jsk lib: 12 multithreaded correctness bugs. * qa test suite: 20 multithreaded correctness bugs. Now's the time to checkout and run qa tests, then lets kick out a release. https://svn.apache.org/repos/asf/river/jtsk/skunk/qa_refactor/trunk or http://svn.apache.org/repos/asf/river/jtsk/skunk/qa_refactor/trunk Regards, Peter.
Re: Development Progress update.
Recent test failures: Solaris sparc: com/sun/jini/test/impl/outrigger/matching/StressTestWithShutdown.td Ubuntu JDK7 com/sun/jini/test/impl/outrigger/leasing/UseTxnMgrSpaceLeaseTestRenewCancel.td com/sun/jini/test/spec/jrmp/jrmpexporter/Unexport_BehaviorTest2.td com/sun/jini/test/spec/jrmp/jrmpexporter/Unexport_BehaviorTest3.td com/sun/jini/test/spec/jrmp/jrmpexporter/Unexport_BehaviorTest4.td com/sun/jini/test/impl/outrigger/transaction/BlockingOnDeadTransactionTest.td Ubuntu Arm embedded com/sun/jini/test/impl/outrigger/leasing/UseNotifyLeaseTestRenewShutdown.td Ubuntu jdk6 com/sun/jini/test/spec/javaspace/conformance/ExpirationNotifyTest.td There are some remaining issues relating to unsafe publication, identified by find bugs (calling Thread.start() during construction), I'll fix these during the week, the failed jrmpexporter tests simply seem to be tests starting before previous tests sockets have been released by the OS. The remaining issues appear to be JavaSpace related. Regards, Peter. Dan Creswell wrote: I'm headed back to the UK so can test OS X in a couple of days if that's still useful... On 7 March 2013 05:25, Peter Firmstone j...@zeus.net.au wrote: There are issues with some builds on Hudson, preventing test execution. Windows: a file can't be deleted in preparation for checkout, preventing build from executing. Solaris: BindException socket in use causes numerous test failures FreeBSD: BindException socket in use, prevents build from executing. OSX: offline. Apart from that, the tests are all passing on my Window's PC, Ubuntu x64 and ARM. I need people who can volunteer to run QA tests! I wasn't attempting to improve performance, recent bug fixes have resulted in the qa suite now finishing one hour earlier, which is a 6% performance increase. Apart from fixing test failures, I've also used FindBugs to fix: * Javaspaces Outrigger: 13 multithreaded correctness bugs. * Jini Platform: 5 inconsistent synchronization bugs. * Jsk lib: 12 multithreaded correctness bugs. * qa test suite: 20 multithreaded correctness bugs. Now's the time to checkout and run qa tests, then lets kick out a release. https://svn.apache.org/repos/asf/river/jtsk/skunk/qa_refactor/trunk or http://svn.apache.org/repos/asf/river/jtsk/skunk/qa_refactor/trunk Regards, Peter.
Re: Development Progress update.
I'm headed back to the UK so can test OS X in a couple of days if that's still useful... On 7 March 2013 05:25, Peter Firmstone j...@zeus.net.au wrote: There are issues with some builds on Hudson, preventing test execution. Windows: a file can't be deleted in preparation for checkout, preventing build from executing. Solaris: BindException socket in use causes numerous test failures FreeBSD: BindException socket in use, prevents build from executing. OSX: offline. Apart from that, the tests are all passing on my Window's PC, Ubuntu x64 and ARM. I need people who can volunteer to run QA tests! I wasn't attempting to improve performance, recent bug fixes have resulted in the qa suite now finishing one hour earlier, which is a 6% performance increase. Apart from fixing test failures, I've also used FindBugs to fix: * Javaspaces Outrigger: 13 multithreaded correctness bugs. * Jini Platform: 5 inconsistent synchronization bugs. * Jsk lib: 12 multithreaded correctness bugs. * qa test suite: 20 multithreaded correctness bugs. Now's the time to checkout and run qa tests, then lets kick out a release. https://svn.apache.org/repos/asf/river/jtsk/skunk/qa_refactor/trunk or http://svn.apache.org/repos/asf/river/jtsk/skunk/qa_refactor/trunk Regards, Peter.
Development Progress update.
There are issues with some builds on Hudson, preventing test execution. Windows: a file can't be deleted in preparation for checkout, preventing build from executing. Solaris: BindException socket in use causes numerous test failures FreeBSD: BindException socket in use, prevents build from executing. OSX: offline. Apart from that, the tests are all passing on my Window's PC, Ubuntu x64 and ARM. I need people who can volunteer to run QA tests! I wasn't attempting to improve performance, recent bug fixes have resulted in the qa suite now finishing one hour earlier, which is a 6% performance increase. Apart from fixing test failures, I've also used FindBugs to fix: * Javaspaces Outrigger: 13 multithreaded correctness bugs. * Jini Platform: 5 inconsistent synchronization bugs. * Jsk lib: 12 multithreaded correctness bugs. * qa test suite: 20 multithreaded correctness bugs. Now's the time to checkout and run qa tests, then lets kick out a release. https://svn.apache.org/repos/asf/river/jtsk/skunk/qa_refactor/trunk or http://svn.apache.org/repos/asf/river/jtsk/skunk/qa_refactor/trunk Regards, Peter.
Windows progress update
Getting much closer to passing all tests on Windows without cigwin. - - # of tests started = 1412 # of tests started = 1412 # of tests completed = 1412 # of tests completed = 1412 # of tests skipped = 46 # of tests skipped = 46 # of tests passed= 1410 # of tests passed= 1410 # of tests failed= 2 # of tests failed= 2 - - Date finished: Date finished: Wed Jul 18 15:18:36 EST 2012 Wed Jul 18 15:18:36 EST 2012 Time elapsed: Time elapsed: 67903 seconds 67903 seconds
