[jira] [Closed] (SCB-764) Vertx tests failed when running 'mvn install'
[ https://issues.apache.org/jira/browse/SCB-764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ZhenJu closed SCB-764. -- Resolution: Fixed Assignee: wujimin > Vertx tests failed when running 'mvn install' > - > > Key: SCB-764 > URL: https://issues.apache.org/jira/browse/SCB-764 > Project: Apache ServiceComb > Issue Type: Test > Components: Java-Chassis > Environment: JDK: openjdk 1.8.0 > Linux Distribution: Arch Linux > Kernel Version: 4.17.5 >Reporter: ZhenJu >Assignee: wujimin >Priority: Blocker > Labels: Vertx, maven, test > Attachments: mvn-install-result.log > > > Hi, guys, when I run 'mvn clean install' with the latest commit > 82f098f67745af2659f5a1822f5edc988d9a3402 on master branch, I get some errors > in Vertx testing: > Tests in error: > TestClientPoolManager.findByContext_otherVertx:205 » NullPointer > TestClientPoolManager.findByContext_woker:222 » NullPointer > TestAbstractTcpClientPoolFactory.createClientPool:37 » NullPointer > TestTcpClientConnectionPool.setup:38 » NullPointer > I put the full log in the attachments, any thoughts on this? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SCB-764) Vertx tests failed when running 'mvn install'
[ https://issues.apache.org/jira/browse/SCB-764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16610197#comment-16610197 ] ZhenJu commented on SCB-764: Hi, [~wujimin] , I test with the latest commit and everything works well, thanks for the great job, closing the issue. > Vertx tests failed when running 'mvn install' > - > > Key: SCB-764 > URL: https://issues.apache.org/jira/browse/SCB-764 > Project: Apache ServiceComb > Issue Type: Test > Components: Java-Chassis > Environment: JDK: openjdk 1.8.0 > Linux Distribution: Arch Linux > Kernel Version: 4.17.5 >Reporter: ZhenJu >Priority: Blocker > Labels: Vertx, maven, test > Attachments: mvn-install-result.log > > > Hi, guys, when I run 'mvn clean install' with the latest commit > 82f098f67745af2659f5a1822f5edc988d9a3402 on master branch, I get some errors > in Vertx testing: > Tests in error: > TestClientPoolManager.findByContext_otherVertx:205 » NullPointer > TestClientPoolManager.findByContext_woker:222 » NullPointer > TestAbstractTcpClientPoolFactory.createClientPool:37 » NullPointer > TestTcpClientConnectionPool.setup:38 » NullPointer > I put the full log in the attachments, any thoughts on this? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (SCB-824) Failed to build saga demos
ZhenJu created SCB-824: -- Summary: Failed to build saga demos Key: SCB-824 URL: https://issues.apache.org/jira/browse/SCB-824 Project: Apache ServiceComb Issue Type: Bug Components: Saga Reporter: ZhenJu Assignee: ZhenJu Failed to build dependency-free-transaction demo and conditional-transaction demo, mvn clean install complains "Cannot find xxx docker image" -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (SCB-823) Set up a fully functional test in kubernetes environment
[ https://issues.apache.org/jira/browse/SCB-823?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ZhenJu updated SCB-823: --- Summary: Set up a fully functional test in kubernetes environment (was: Set up a fully functional test environment in kubernetes) > Set up a fully functional test in kubernetes environment > > > Key: SCB-823 > URL: https://issues.apache.org/jira/browse/SCB-823 > Project: Apache ServiceComb > Issue Type: Test > Components: Saga >Reporter: ZhenJu >Assignee: ZhenJu >Priority: Minor > Labels: kubernetes, test > > It would be great if we have a kubernetes test environment running the demos > in containers. > With the environment, it's easier to: > * Scale up / down the services to test saga in different size distributed > systems > * Simulate the scenarios that different forms of errors would occur, like > unavailable connection, internal server error, or network delay. This could > be easily done by Istio -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (SCB-823) Set up a fully functional test in kubernetes environment
[ https://issues.apache.org/jira/browse/SCB-823?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ZhenJu updated SCB-823: --- Description: It would be great if we have a kubernetes test solution running the demos in containers. With the environment, it's easier to: * Scale up / down the services to test saga in different size distributed systems * Simulate the scenarios that different forms of errors would occur, like unavailable connection, internal server error, or network delay. This could be easily done by Istio was: It would be great if we have a kubernetes test environment running the demos in containers. With the environment, it's easier to: * Scale up / down the services to test saga in different size distributed systems * Simulate the scenarios that different forms of errors would occur, like unavailable connection, internal server error, or network delay. This could be easily done by Istio > Set up a fully functional test in kubernetes environment > > > Key: SCB-823 > URL: https://issues.apache.org/jira/browse/SCB-823 > Project: Apache ServiceComb > Issue Type: Test > Components: Saga >Reporter: ZhenJu >Assignee: ZhenJu >Priority: Minor > Labels: kubernetes, test > > It would be great if we have a kubernetes test solution running the demos in > containers. > With the environment, it's easier to: > * Scale up / down the services to test saga in different size distributed > systems > * Simulate the scenarios that different forms of errors would occur, like > unavailable connection, internal server error, or network delay. This could > be easily done by Istio -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (SCB-823) Set up a fully functional test environment in kubernetes
ZhenJu created SCB-823: -- Summary: Set up a fully functional test environment in kubernetes Key: SCB-823 URL: https://issues.apache.org/jira/browse/SCB-823 Project: Apache ServiceComb Issue Type: Test Components: Saga Reporter: ZhenJu Assignee: ZhenJu It would be great if we have a kubernetes test environment running the demos in containers. With the environment, it's easier to: * Scale up / down the services to test saga in different size distributed systems * Simulate the scenarios that different forms of errors would occur, like unavailable connection, internal server error, or network delay. This could be easily done by Istio -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SCB-139) Optimization suggestions for README
[ https://issues.apache.org/jira/browse/SCB-139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16558457#comment-16558457 ] ZhenJu commented on SCB-139: Can't agree more, a good documentation is always NEEDed > Optimization suggestions for README > --- > > Key: SCB-139 > URL: https://issues.apache.org/jira/browse/SCB-139 > Project: Apache ServiceComb > Issue Type: Improvement > Components: Java-Chassis >Reporter: mabin >Priority: Major > > For the user to understand chassis quickly, it is better to added some more > summary informations in README, eg. > 1.Major features list > 2.Summary design graph > 3.Module dependency graph > 4.Complete quick start guide > 5.FAQ > What is your opinion? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (SCB-764) Vertx tests failed when running 'mvn install'
[ https://issues.apache.org/jira/browse/SCB-764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ZhenJu updated SCB-764: --- Description: Hi, guys, when I run 'mvn clean install' with the latest commit 82f098f67745af2659f5a1822f5edc988d9a3402 on master branch, I get some errors in Vertx testing: Tests in error: TestClientPoolManager.findByContext_otherVertx:205 » NullPointer TestClientPoolManager.findByContext_woker:222 » NullPointer TestAbstractTcpClientPoolFactory.createClientPool:37 » NullPointer TestTcpClientConnectionPool.setup:38 » NullPointer I put the full log in the attachments, any thoughts on this? was: Hi, guys, when I run 'mvn clean install' with the latest commit 82f098f67745af2659f5a1822f5edc988d9a3402 on master branch, I get some errors in Vertx testing: Tests in error: TestClientPoolManager.findByContext_otherVertx:205 » NullPointer TestClientPoolManager.findByContext_woker:222 » NullPointer TestAbstractTcpClientPoolFactory.createClientPool:37 » NullPointer TestTcpClientConnectionPool.setup:38 » NullPointer > Vertx tests failed when running 'mvn install' > - > > Key: SCB-764 > URL: https://issues.apache.org/jira/browse/SCB-764 > Project: Apache ServiceComb > Issue Type: Test > Components: Java-Chassis > Environment: JDK: openjdk 1.8.0 > Linux Distribution: Arch Linux > Kernel Version: 4.17.5 >Reporter: ZhenJu >Priority: Blocker > Labels: Vertx, maven, test > Attachments: mvn-install-result.log > > > Hi, guys, when I run 'mvn clean install' with the latest commit > 82f098f67745af2659f5a1822f5edc988d9a3402 on master branch, I get some errors > in Vertx testing: > Tests in error: > TestClientPoolManager.findByContext_otherVertx:205 » NullPointer > TestClientPoolManager.findByContext_woker:222 » NullPointer > TestAbstractTcpClientPoolFactory.createClientPool:37 » NullPointer > TestTcpClientConnectionPool.setup:38 » NullPointer > I put the full log in the attachments, any thoughts on this? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (SCB-764) Vertx tests failed when running 'mvn install'
[ https://issues.apache.org/jira/browse/SCB-764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ZhenJu updated SCB-764: --- Description: Hi, guys, when I run 'mvn clean install' with the latest commit 82f098f67745af2659f5a1822f5edc988d9a3402 on master branch, I get some errors in Vertx testing: Tests in error: TestClientPoolManager.findByContext_otherVertx:205 » NullPointer TestClientPoolManager.findByContext_woker:222 » NullPointer TestAbstractTcpClientPoolFactory.createClientPool:37 » NullPointer TestTcpClientConnectionPool.setup:38 » NullPointer was: Hi, guys, when I'm running 'mvn clean install' with the latest commit , I just get the error complaining that the test application can't connect to port 8080, below is the whole log: --- T E S T S --- Running io.vertx.ext.web.impl.TestHttpServerRequestUtils Running io.vertx.ext.web.impl.TestMimeTypesUtils Tests run: 8, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.425 sec - in io.vertx.ext.web.impl.TestMimeTypesUtils Running io.vertx.core.impl.TestVertxImplEx Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.662 sec - in io.vertx.ext.web.impl.TestHttpServerRequestUtils Running org.apache.servicecomb.foundation.vertx.TestStream Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.141 sec - in org.apache.servicecomb.foundation.vertx.TestStream Running org.apache.servicecomb.foundation.vertx.TestAddressResolverConfig 2018-07-20 11:35:32,758 [main ] WARN URLConfigurationSource - No URLs will be polled as dynamic configuration sources. 2018-07-20 11:35:32,759 [main ] INFO URLConfigurationSource - To enable URLs as dynamic configuration sources, define System property archaius.configurationSource.additionalUrls or make config.properties available on classpath. 2018-07-20 11:35:32,788 [main ] WARN URLConfigurationSource - No URLs will be polled as dynamic configuration sources. 2018-07-20 11:35:32,788 [main ] INFO URLConfigurationSource - To enable URLs as dynamic configuration sources, define System property archaius.configurationSource.additionalUrls or make config.properties available on classpath. Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.447 sec - in io.vertx.core.impl.TestVertxImplEx 2018-07-20 11:35:32,790 [main ] INFO DynamicPropertyFactory - DynamicPropertyFactory is initialized with configuration sources: com.netflix.config.ConcurrentCompositeConfiguration@2362f559 Running org.apache.servicecomb.foundation.vertx.TestVertxUtils 2018-07-20 11:35:32,811 [main ] WARN AddressResolverConfig - Address resover key:addressResolver.test.cacheMinTimeToLive's value:0 is not positive, please check! 2018-07-20 11:35:32,811 [main ] WARN AddressResolverConfig - Address resover key:addressResolver.cacheMinTimeToLive's value:0 is not positive, please check! 2018-07-20 11:35:32,811 [main ] WARN AddressResolverConfig - Address resover key:addressResolver.test.cacheMaxTimeToLive's value:0 is not positive, please check! 2018-07-20 11:35:32,812 [main ] WARN AddressResolverConfig - Address resover key:addressResolver.cacheMaxTimeToLive's value:0 is not positive, please check! 2018-07-20 11:35:32,812 [main ] WARN AddressResolverConfig - Address resover key:addressResolver.test.cacheNegativeTimeToLive's value:0 is not positive, please check! 2018-07-20 11:35:32,812 [main ] WARN AddressResolverConfig - Address resover key:addressResolver.cacheNegativeTimeToLive's value:0 is not positive, please check! 2018-07-20 11:35:32,813 [main ] WARN AddressResolverConfig - Address resover key:addressResolver.test.queryTimeout's value:0 is not positive, please check! 2018-07-20 11:35:32,813 [main ] WARN AddressResolverConfig - Address resover key:addressResolver.test.maxQueries's value:0 is not positive, please check! 2018-07-20 11:35:32,813 [main ] WARN AddressResolverConfig - Address resover key:addressResolver.maxQueries's value:-2 is not positive, please check! 2018-07-20 11:35:32,814 [main ] WARN AddressResolverConfig - Address resover key:addressResolver.test.ndots's value:0 is not positive, please check! 2018-07-20 11:35:32,814 [main ] WARN AddressResolverConfig - Address resover key:addressResolver.ndots's value:0 is not positive, please check! 2018-07-20 11:35:32,819 [main ] WARN URLConfigurationSource - No URLs will be polled as dynamic configuration sources. 2018-07-20 11:35:32,819 [main ] INFO URLConfigurationSource - To enable URLs as dynamic configuration sources, define System property archaius.configurationSource.additionalUrls or make config.properties available on classpath. 2018-07-20 11:35:32,819 [main ] INFO DynamicPropertyFactory - DynamicPropertyFactory is initialized with configuration sources: com.netflix.config.ConcurrentCompositeConfiguration@4e50c791 2018-07-20 11:35:32,830 [main
[jira] [Created] (SCB-764) Vertx tests failed when running 'mvn install'
ZhenJu created SCB-764: -- Summary: Vertx tests failed when running 'mvn install' Key: SCB-764 URL: https://issues.apache.org/jira/browse/SCB-764 Project: Apache ServiceComb Issue Type: Test Components: Java-Chassis Environment: JDK: openjdk 1.8.0 Linux Distribution: Arch Linux Kernel Version: 4.17.5 Reporter: ZhenJu Hi, guys, when I'm running 'mvn clean install' with the latest commit , I just get the error complaining that the test application can't connect to port 8080, below is the whole log: --- T E S T S --- Running io.vertx.ext.web.impl.TestHttpServerRequestUtils Running io.vertx.ext.web.impl.TestMimeTypesUtils Tests run: 8, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.425 sec - in io.vertx.ext.web.impl.TestMimeTypesUtils Running io.vertx.core.impl.TestVertxImplEx Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.662 sec - in io.vertx.ext.web.impl.TestHttpServerRequestUtils Running org.apache.servicecomb.foundation.vertx.TestStream Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.141 sec - in org.apache.servicecomb.foundation.vertx.TestStream Running org.apache.servicecomb.foundation.vertx.TestAddressResolverConfig 2018-07-20 11:35:32,758 [main ] WARN URLConfigurationSource - No URLs will be polled as dynamic configuration sources. 2018-07-20 11:35:32,759 [main ] INFO URLConfigurationSource - To enable URLs as dynamic configuration sources, define System property archaius.configurationSource.additionalUrls or make config.properties available on classpath. 2018-07-20 11:35:32,788 [main ] WARN URLConfigurationSource - No URLs will be polled as dynamic configuration sources. 2018-07-20 11:35:32,788 [main ] INFO URLConfigurationSource - To enable URLs as dynamic configuration sources, define System property archaius.configurationSource.additionalUrls or make config.properties available on classpath. Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.447 sec - in io.vertx.core.impl.TestVertxImplEx 2018-07-20 11:35:32,790 [main ] INFO DynamicPropertyFactory - DynamicPropertyFactory is initialized with configuration sources: com.netflix.config.ConcurrentCompositeConfiguration@2362f559 Running org.apache.servicecomb.foundation.vertx.TestVertxUtils 2018-07-20 11:35:32,811 [main ] WARN AddressResolverConfig - Address resover key:addressResolver.test.cacheMinTimeToLive's value:0 is not positive, please check! 2018-07-20 11:35:32,811 [main ] WARN AddressResolverConfig - Address resover key:addressResolver.cacheMinTimeToLive's value:0 is not positive, please check! 2018-07-20 11:35:32,811 [main ] WARN AddressResolverConfig - Address resover key:addressResolver.test.cacheMaxTimeToLive's value:0 is not positive, please check! 2018-07-20 11:35:32,812 [main ] WARN AddressResolverConfig - Address resover key:addressResolver.cacheMaxTimeToLive's value:0 is not positive, please check! 2018-07-20 11:35:32,812 [main ] WARN AddressResolverConfig - Address resover key:addressResolver.test.cacheNegativeTimeToLive's value:0 is not positive, please check! 2018-07-20 11:35:32,812 [main ] WARN AddressResolverConfig - Address resover key:addressResolver.cacheNegativeTimeToLive's value:0 is not positive, please check! 2018-07-20 11:35:32,813 [main ] WARN AddressResolverConfig - Address resover key:addressResolver.test.queryTimeout's value:0 is not positive, please check! 2018-07-20 11:35:32,813 [main ] WARN AddressResolverConfig - Address resover key:addressResolver.test.maxQueries's value:0 is not positive, please check! 2018-07-20 11:35:32,813 [main ] WARN AddressResolverConfig - Address resover key:addressResolver.maxQueries's value:-2 is not positive, please check! 2018-07-20 11:35:32,814 [main ] WARN AddressResolverConfig - Address resover key:addressResolver.test.ndots's value:0 is not positive, please check! 2018-07-20 11:35:32,814 [main ] WARN AddressResolverConfig - Address resover key:addressResolver.ndots's value:0 is not positive, please check! 2018-07-20 11:35:32,819 [main ] WARN URLConfigurationSource - No URLs will be polled as dynamic configuration sources. 2018-07-20 11:35:32,819 [main ] INFO URLConfigurationSource - To enable URLs as dynamic configuration sources, define System property archaius.configurationSource.additionalUrls or make config.properties available on classpath. 2018-07-20 11:35:32,819 [main ] INFO DynamicPropertyFactory - DynamicPropertyFactory is initialized with configuration sources: com.netflix.config.ConcurrentCompositeConfiguration@4e50c791 2018-07-20 11:35:32,830 [main ] WARN URLConfigurationSource - No URLs will be polled as dynamic configuration sources. 2018-07-20 11:35:32,831 [main ] INFO URLConfigurationSource - To enable URLs as dynamic configuration sources,
[jira] [Closed] (SCB-740) Unified config handler of ServiceComb and other micro service frameworks
[ https://issues.apache.org/jira/browse/SCB-740?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ZhenJu closed SCB-740. -- Resolution: Not A Problem We'll discuss this in the mailing list. > Unified config handler of ServiceComb and other micro service frameworks > > > Key: SCB-740 > URL: https://issues.apache.org/jira/browse/SCB-740 > Project: Apache ServiceComb > Issue Type: New Feature >Reporter: ZhenJu >Priority: Minor > > Hi, gang! > I'm thinking about handling configs of both ServiceComb and other > frameworks(like Istio), then provide a unified solution for config > management, to support the hybrid solution scenario(like, user use > ServiceComb and Istio at the same time). > So the first thing to do, is to make sure that the chassis configs have a > equivalent mapping of other frameworks. Currently I'm testing the rate limit > configs between ServiceComb and Istio, it's working. I write a demo about > this at [https://github.com/crystaldust/configcomb,] receive a chassis.yaml, > read the Flowcontrol field, then convert it to Istio rate limit rules and > apply the rules in a kubernetes cluster. It should also work the opposite way. > By doing so, it is possible to provide a unified solution for config > management, any ideas? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SCB-740) Unified config handler of ServiceComb and other micro service frameworks
[ https://issues.apache.org/jira/browse/SCB-740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16542665#comment-16542665 ] ZhenJu commented on SCB-740: OK, Willem, I'll send the idea to the mailing list > Unified config handler of ServiceComb and other micro service frameworks > > > Key: SCB-740 > URL: https://issues.apache.org/jira/browse/SCB-740 > Project: Apache ServiceComb > Issue Type: New Feature >Reporter: ZhenJu >Priority: Minor > > Hi, gang! > I'm thinking about handling configs of both ServiceComb and other > frameworks(like Istio), then provide a unified solution for config > management, to support the hybrid solution scenario(like, user use > ServiceComb and Istio at the same time). > So the first thing to do, is to make sure that the chassis configs have a > equivalent mapping of other frameworks. Currently I'm testing the rate limit > configs between ServiceComb and Istio, it's working. I write a demo about > this at [https://github.com/crystaldust/configcomb,] receive a chassis.yaml, > read the Flowcontrol field, then convert it to Istio rate limit rules and > apply the rules in a kubernetes cluster. It should also work the opposite way. > By doing so, it is possible to provide a unified solution for config > management, any ideas? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (SCB-740) Unified config handler of ServiceComb and other micro service frameworks
ZhenJu created SCB-740: -- Summary: Unified config handler of ServiceComb and other micro service frameworks Key: SCB-740 URL: https://issues.apache.org/jira/browse/SCB-740 Project: Apache ServiceComb Issue Type: New Feature Reporter: ZhenJu Hi, gang! I'm thinking about handling configs of both ServiceComb and other frameworks(like Istio), then provide a unified solution for config management, to support the hybrid solution scenario(like, user use ServiceComb and Istio at the same time). So the first thing to do, is to make sure that the chassis configs have a equivalent mapping of other frameworks. Currently I'm testing the rate limit configs between ServiceComb and Istio, it's working. I write a demo about this at [https://github.com/crystaldust/configcomb,] receive a chassis.yaml, read the Flowcontrol field, then convert it to Istio rate limit rules and apply the rules in a kubernetes cluster. It should also work the opposite way. By doing so, it is possible to provide a unified solution for config management, any ideas? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
