[jira] [Closed] (SCB-1717) Return nothing when file upload exception occurs
[ https://issues.apache.org/jira/browse/SCB-1717?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ang Li closed SCB-1717. --- > Return nothing when file upload exception occurs > - > > Key: SCB-1717 > URL: https://issues.apache.org/jira/browse/SCB-1717 > Project: Apache ServiceComb > Issue Type: Bug > Components: Java-Chassis >Reporter: Ang Li >Assignee: Ang Li >Priority: Major > Fix For: java-chassis-2.0.0 > > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (SCB-1705) Update javax.servlet to jakarta.servlet
[ https://issues.apache.org/jira/browse/SCB-1705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ang Li closed SCB-1705. --- > Update javax.servlet to jakarta.servlet > --- > > Key: SCB-1705 > URL: https://issues.apache.org/jira/browse/SCB-1705 > Project: Apache ServiceComb > Issue Type: Improvement > Components: Java-Chassis >Reporter: Ang Li >Assignee: Ang Li >Priority: Trivial > Fix For: java-chassis-2.0.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Javax.servlet has already stopped maintainance, need to be updated to > jakarta.servlet -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (SCB-1705) Update javax.servlet to jakarta.servlet
[ https://issues.apache.org/jira/browse/SCB-1705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ang Li resolved SCB-1705. - Resolution: Fixed > Update javax.servlet to jakarta.servlet > --- > > Key: SCB-1705 > URL: https://issues.apache.org/jira/browse/SCB-1705 > Project: Apache ServiceComb > Issue Type: Improvement > Components: Java-Chassis >Reporter: Ang Li >Assignee: Ang Li >Priority: Trivial > Fix For: java-chassis-2.0.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Javax.servlet has already stopped maintainance, need to be updated to > jakarta.servlet -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (SCB-1717) Return nothing when file upload exception occurs
[ https://issues.apache.org/jira/browse/SCB-1717?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ang Li resolved SCB-1717. - Fix Version/s: java-chassis-2.0.0 Resolution: Fixed > Return nothing when file upload exception occurs > - > > Key: SCB-1717 > URL: https://issues.apache.org/jira/browse/SCB-1717 > Project: Apache ServiceComb > Issue Type: Bug > Components: Java-Chassis >Reporter: Ang Li >Assignee: Ang Li >Priority: Major > Fix For: java-chassis-2.0.0 > > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (SCB-1715) IdleTimeout not work in client side without keepaliveTimeout set
[ https://issues.apache.org/jira/browse/SCB-1715?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ang Li closed SCB-1715. --- > IdleTimeout not work in client side without keepaliveTimeout set > > > Key: SCB-1715 > URL: https://issues.apache.org/jira/browse/SCB-1715 > Project: Apache ServiceComb > Issue Type: Bug > Components: Java-Chassis >Reporter: Ang Li >Assignee: Ang Li >Priority: Major > Fix For: java-chassis-2.0.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Vertx client side need to set keepaliveTimeout to support idleTimeout. Or the > default value 60s will be the same as server timeout 60s, which will cause > 490 error bacause the connection is closed by server side instead released by > client side. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (SCB-1716) High CPU load when there are too many instances
[ https://issues.apache.org/jira/browse/SCB-1716?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ang Li closed SCB-1716. --- > High CPU load when there are too many instances > --- > > Key: SCB-1716 > URL: https://issues.apache.org/jira/browse/SCB-1716 > Project: Apache ServiceComb > Issue Type: Bug > Components: Java-Chassis >Reporter: Ang Li >Assignee: Ang Li >Priority: Major > Fix For: java-chassis-2.0.0 > > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (SCB-1716) High CPU load when there are too many instances
[ https://issues.apache.org/jira/browse/SCB-1716?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ang Li resolved SCB-1716. - Fix Version/s: java-chassis-2.0.0 Resolution: Fixed > High CPU load when there are too many instances > --- > > Key: SCB-1716 > URL: https://issues.apache.org/jira/browse/SCB-1716 > Project: Apache ServiceComb > Issue Type: Bug > Components: Java-Chassis >Reporter: Ang Li >Assignee: Ang Li >Priority: Major > Fix For: java-chassis-2.0.0 > > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (SCB-1715) IdleTimeout not work in client side without keepaliveTimeout set
[ https://issues.apache.org/jira/browse/SCB-1715?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ang Li resolved SCB-1715. - Fix Version/s: java-chassis-2.0.0 Resolution: Fixed > IdleTimeout not work in client side without keepaliveTimeout set > > > Key: SCB-1715 > URL: https://issues.apache.org/jira/browse/SCB-1715 > Project: Apache ServiceComb > Issue Type: Bug > Components: Java-Chassis >Reporter: Ang Li >Assignee: Ang Li >Priority: Major > Fix For: java-chassis-2.0.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Vertx client side need to set keepaliveTimeout to support idleTimeout. Or the > default value 60s will be the same as server timeout 60s, which will cause > 490 error bacause the connection is closed by server side instead released by > client side. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (SCB-1723) support pagination in kie apis
[ https://issues.apache.org/jira/browse/SCB-1723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ang Li updated SCB-1723: Component/s: Kie > support pagination in kie apis > -- > > Key: SCB-1723 > URL: https://issues.apache.org/jira/browse/SCB-1723 > Project: Apache ServiceComb > Issue Type: Improvement > Components: Kie >Reporter: Ang Li >Assignee: Ang Li >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (SCB-1723) support pagination in kie apis
Ang Li created SCB-1723: --- Summary: support pagination in kie apis Key: SCB-1723 URL: https://issues.apache.org/jira/browse/SCB-1723 Project: Apache ServiceComb Issue Type: Improvement Reporter: Ang Li Assignee: Ang Li -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (SCB-1721) Support unique index by key and label
Ang Li created SCB-1721: --- Summary: Support unique index by key and label Key: SCB-1721 URL: https://issues.apache.org/jira/browse/SCB-1721 Project: Apache ServiceComb Issue Type: Improvement Components: Kie Reporter: Ang Li Assignee: Ang Li -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (SCB-1717) Return nothing when file upload exception occurs
Ang Li created SCB-1717: --- Summary: Return nothing when file upload exception occurs Key: SCB-1717 URL: https://issues.apache.org/jira/browse/SCB-1717 Project: Apache ServiceComb Issue Type: Bug Components: Java-Chassis Reporter: Ang Li Assignee: Ang Li -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (SCB-1716) High CPU load when there are too many instances
Ang Li created SCB-1716: --- Summary: High CPU load when there are too many instances Key: SCB-1716 URL: https://issues.apache.org/jira/browse/SCB-1716 Project: Apache ServiceComb Issue Type: Bug Components: Java-Chassis Reporter: Ang Li Assignee: Ang Li -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (SCB-1656) The request is still processed when the server connection is closed by server connection limitation
[
https://issues.apache.org/jira/browse/SCB-1656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17011291#comment-17011291
]
Ang Li commented on SCB-1656:
-
[https://github.com/eclipse-vertx/vert.x/commit/39593e163fe664a7ce3669a25a79ee246465d0f7]
> The request is still processed when the server connection is closed by server
> connection limitation
> ---
>
> Key: SCB-1656
> URL: https://issues.apache.org/jira/browse/SCB-1656
> Project: Apache ServiceComb
> Issue Type: Bug
> Components: Java-Chassis
>Affects Versions: java-chassis-1.3.0
>Reporter: Haishi Yao
>Priority: Major
>
> Now Java-Chassis provide a config item to limit the connection amount on
> server side:
> {code:java}
> servicecomb.rest.server.connection-limit
> {code}
> When the server connection amount reaches the limitation, the newly created
> connection will be closed instantly. But currently it's found that the HTTP
> request from the closed connection is still received and processed, which is
> not as our expectation.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (SCB-1656) The request is still processed when the server connection is closed by server connection limitation
[
https://issues.apache.org/jira/browse/SCB-1656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17010508#comment-17010508
]
Ang Li commented on SCB-1656:
-
[https://github.com/eclipse-vertx/vert.x/issues/3245]
> The request is still processed when the server connection is closed by server
> connection limitation
> ---
>
> Key: SCB-1656
> URL: https://issues.apache.org/jira/browse/SCB-1656
> Project: Apache ServiceComb
> Issue Type: Bug
> Components: Java-Chassis
>Affects Versions: java-chassis-1.3.0
>Reporter: Haishi Yao
>Priority: Major
>
> Now Java-Chassis provide a config item to limit the connection amount on
> server side:
> {code:java}
> servicecomb.rest.server.connection-limit
> {code}
> When the server connection amount reaches the limitation, the newly created
> connection will be closed instantly. But currently it's found that the HTTP
> request from the closed connection is still received and processed, which is
> not as our expectation.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (SCB-1705) Update javax.servlet to jakarta.servlet
Ang Li created SCB-1705: --- Summary: Update javax.servlet to jakarta.servlet Key: SCB-1705 URL: https://issues.apache.org/jira/browse/SCB-1705 Project: Apache ServiceComb Issue Type: Improvement Components: Java-Chassis Reporter: Ang Li Assignee: Ang Li Fix For: java-chassis-2.0.0 Javax.servlet has already stopped maintainance, need to be updated to jakarta.servlet -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (SCB-1559) Use java.time.Clock instead of java.lang.System#currentTimeMillis to get time
[ https://issues.apache.org/jira/browse/SCB-1559?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ang Li closed SCB-1559. --- > Use java.time.Clock instead of java.lang.System#currentTimeMillis to get time > - > > Key: SCB-1559 > URL: https://issues.apache.org/jira/browse/SCB-1559 > Project: Apache ServiceComb > Issue Type: Task > Components: Java-Chassis >Reporter: Haishi Yao >Assignee: Ang Li >Priority: Minor > Fix For: java-chassis-2.0.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Currently most of our code use java.lang.System#currentTimeMillis to get the > current time. > This method is not convenient to mock. > It's recommended to search all of the place we use > java.lang.System#currentTimeMillis and replace them with java.time.Clock. And > it's better to provide a mock clock class in testscaffolding. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (SCB-1559) Use java.time.Clock instead of java.lang.System#currentTimeMillis to get time
[ https://issues.apache.org/jira/browse/SCB-1559?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ang Li reassigned SCB-1559: --- Assignee: Ang Li (was: Haishi Yao) > Use java.time.Clock instead of java.lang.System#currentTimeMillis to get time > - > > Key: SCB-1559 > URL: https://issues.apache.org/jira/browse/SCB-1559 > Project: Apache ServiceComb > Issue Type: Task > Components: Java-Chassis >Reporter: Haishi Yao >Assignee: Ang Li >Priority: Minor > Time Spent: 20m > Remaining Estimate: 0h > > Currently most of our code use java.lang.System#currentTimeMillis to get the > current time. > This method is not convenient to mock. > It's recommended to search all of the place we use > java.lang.System#currentTimeMillis and replace them with java.time.Clock. And > it's better to provide a mock clock class in testscaffolding. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (SCB-1559) Use java.time.Clock instead of java.lang.System#currentTimeMillis to get time
[ https://issues.apache.org/jira/browse/SCB-1559?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ang Li resolved SCB-1559. - Fix Version/s: java-chassis-2.0.0 Resolution: Fixed > Use java.time.Clock instead of java.lang.System#currentTimeMillis to get time > - > > Key: SCB-1559 > URL: https://issues.apache.org/jira/browse/SCB-1559 > Project: Apache ServiceComb > Issue Type: Task > Components: Java-Chassis >Reporter: Haishi Yao >Assignee: Ang Li >Priority: Minor > Fix For: java-chassis-2.0.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Currently most of our code use java.lang.System#currentTimeMillis to get the > current time. > This method is not convenient to mock. > It's recommended to search all of the place we use > java.lang.System#currentTimeMillis and replace them with java.time.Clock. And > it's better to provide a mock clock class in testscaffolding. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (SCB-1662) Use jackson module afterburner to speed up jackson processing
[ https://issues.apache.org/jira/browse/SCB-1662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16994314#comment-16994314 ] Ang Li commented on SCB-1662: - Jackson (https://github.com/FasterXML/jackson) extension module used to enhance performance using bytecode generation to replace use of Reflection for field access and method calls > Use jackson module afterburner to speed up jackson processing > > > Key: SCB-1662 > URL: https://issues.apache.org/jira/browse/SCB-1662 > Project: Apache ServiceComb > Issue Type: Improvement > Components: Java-Chassis >Reporter: Ang Li >Assignee: Ang Li >Priority: Minor > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (SCB-1662) Use jackson module afterburner to speed up jackson processing
Ang Li created SCB-1662: --- Summary: Use jackson module afterburner to speed up jackson processing Key: SCB-1662 URL: https://issues.apache.org/jira/browse/SCB-1662 Project: Apache ServiceComb Issue Type: Improvement Components: Java-Chassis Reporter: Ang Li Assignee: Ang Li -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (SCB-1557) Fix application start info log incorrect
[ https://issues.apache.org/jira/browse/SCB-1557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ang Li closed SCB-1557. --- > Fix application start info log incorrect > > > Key: SCB-1557 > URL: https://issues.apache.org/jira/browse/SCB-1557 > Project: Apache ServiceComb > Issue Type: Improvement > Components: Java-Chassis >Reporter: Ang Li >Assignee: Ang Li >Priority: Minor > Fix For: java-chassis-2.0.0, java-chassis-1.3.1 > > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (SCB-1607) Using swagger 2 instead of swagger 1
Ang Li created SCB-1607: --- Summary: Using swagger 2 instead of swagger 1 Key: SCB-1607 URL: https://issues.apache.org/jira/browse/SCB-1607 Project: Apache ServiceComb Issue Type: Improvement Components: Java-Chassis Reporter: Ang Li -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (SCB-1606) Using log4j2 instead of log4j
Ang Li created SCB-1606: --- Summary: Using log4j2 instead of log4j Key: SCB-1606 URL: https://issues.apache.org/jira/browse/SCB-1606 Project: Apache ServiceComb Issue Type: Improvement Components: Java-Chassis Reporter: Ang Li -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (SCB-1605) Using spring 5 instead of spring 4
Ang Li created SCB-1605: --- Summary: Using spring 5 instead of spring 4 Key: SCB-1605 URL: https://issues.apache.org/jira/browse/SCB-1605 Project: Apache ServiceComb Issue Type: Improvement Components: Java-Chassis Reporter: Ang Li -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (SCB-1582) Upgrading thirdparty dependency versions
[ https://issues.apache.org/jira/browse/SCB-1582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ang Li resolved SCB-1582. - Fix Version/s: java-chassis-2.0.0 Resolution: Fixed > Upgrading thirdparty dependency versions > > > Key: SCB-1582 > URL: https://issues.apache.org/jira/browse/SCB-1582 > Project: Apache ServiceComb > Issue Type: Improvement > Components: Java-Chassis >Reporter: Ang Li >Assignee: Ang Li >Priority: Major > Fix For: java-chassis-2.0.0 > > Time Spent: 1h 40m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (SCB-1489) Micro-service instance wouldn't work after we shotdown our service center for updating while we had enable RSA authentication between services.
[
https://issues.apache.org/jira/browse/SCB-1489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ang Li resolved SCB-1489.
-
Fix Version/s: java-chassis-2.0.0
Resolution: Fixed
> Micro-service instance wouldn't work after we shotdown our service center for
> updating while we had enable RSA authentication between services.
> ---
>
> Key: SCB-1489
> URL: https://issues.apache.org/jira/browse/SCB-1489
> Project: Apache ServiceComb
> Issue Type: Bug
> Components: Java-Chassis
>Reporter: Liu HuaiZhou
>Assignee: Ang Li
>Priority: Major
> Fix For: java-chassis-2.0.0
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> We had add RSA authentication between services following [Documents
> |[https://docs.servicecomb.io/java-chassis/en_US/security/rsa.html]]. The
> micro-service instances interrupted when we shutdown service center and
> update it for latest version.Following are snap logs for comsumer and
> provider instances.
> consumer log：
> [2019-04-27 05:58:10,995/UTC][main][INFO]InvocationException:
> code=490;msg=CommonExceptionData [message=Cse Internal Bad Request]
> com.huawei.paas.cse.demo.pojo.client.PojoClient.main(PojoClient.java:119)
> [2019-04-27 05:58:12,995/UTC][main][INFO]create MicroserviceVersions,
> appId=liushuang-noauth, microserviceName=pojolwx585706.
> org.apache.servicecomb.serviceregistry.consumer.MicroserviceVersions.(MicroserviceVersions.java:84)
> [2019-04-27
> 05:58:13,001/UTC][registry-vert.x-eventloop-thread-0][WARN]failed to
> findInstances:
> {"errorCode":"400012","errorMessage":"Micro-service does not
> exist","detail":"Consumer does not exist."}
> org.apache.servicecomb.serviceregistry.client.http.ServiceRegistryClientImpl.lambda$null$4(ServiceRegistryClientImpl.java:213)
> [2019-04-27 05:58:13,001/UTC][main][INFO]remove microservice,
> appId=liushuang-noauth, microserviceName=pojolwx585706.
> org.apache.servicecomb.serviceregistry.consumer.MicroserviceManager.removeMicroservice(MicroserviceManager.java:76)
> [2019-04-27 05:58:13,001/UTC][main][INFO]create MicroserviceVersionRule,
> appId=liushuang-noauth, microserviceName=pojolwx585706, versionRule=0.0.0+.
> org.apache.servicecomb.serviceregistry.consumer.MicroserviceVersions.createAndInitMicroserviceVersionRule(MicroserviceVersions.java:231)
> [2019-04-27 05:58:13,001/UTC][main][INFO]create MicroserviceVersions,
> appId=liushuang-noauth, microserviceName=pojolwx585706.
> org.apache.servicecomb.serviceregistry.consumer.MicroserviceVersions.(MicroserviceVersions.java:84)
> [2019-04-27
> 05:58:13,004/UTC][registry-vert.x-eventloop-thread-0][WARN]failed to
> findInstances:
> {"errorCode":"400012","errorMessage":"Micro-service does not
> exist","detail":"Consumer does not exist."}
> org.apache.servicecomb.serviceregistry.client.http.ServiceRegistryClientImpl.lambda$null$4(ServiceRegistryClientImpl.java:213)
> [2019-04-27 05:58:13,004/UTC][main][INFO]remove microservice,
> appId=liushuang-noauth, microserviceName=pojolwx585706.
> org.apache.servicecomb.serviceregistry.consumer.MicroserviceManager.removeMicroservice(MicroserviceManager.java:76)
> [2019-04-27 05:58:13,004/UTC][main][ERROR]invoke failed,
> pojolwx585706.helloworldGreeter.SayHello
> org.apache.servicecomb.core.provider.consumer.InvokerUtils.innerSyncInvoke(InvokerUtils.java:80)
> org.apache.servicecomb.foundation.common.exceptions.ServiceCombException:
> org.apache.servicecomb.core.filter.OperationInstancesDiscoveryFilter
> discovery return null.
> at
> org.apache.servicecomb.serviceregistry.discovery.DiscoveryTree.doDiscovery(DiscoveryTree.java:169)
> at
> org.apache.servicecomb.serviceregistry.discovery.DiscoveryTree.discovery(DiscoveryTree.java:130)
> at
> org.apache.servicecomb.serviceregistry.discovery.DiscoveryTree.discovery(DiscoveryTree.java:123)
> at
> org.apache.servicecomb.loadbalance.LoadbalanceHandler.getOrCreateLoadBalancer(LoadbalanceHandler.java:360)
> at
> org.apache.servicecomb.loadbalance.LoadbalanceHandler.handle(LoadbalanceHandler.java:179)
> at org.apache.servicecomb.core.Invocation.next(Invocation.java:151)
> at
> org.apache.servicecomb.core.provider.consumer.InvokerUtils.innerSyncInvoke(InvokerUtils.java:72)
> at org.apache.servicecomb.provider.pojo.Invoker.syncInvoke(Invoker.java:161)
> at org.apache.servicecomb.provider.pojo.Invoker.invoke(Invoker.java:157)
> at com.sun.proxy.$Proxy28.SayHello(Unknown Source)
> at com.huawei.paas.cse.demo.pojo.client.PojoClient.main(PojoClient.java:107)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
>
[jira] [Resolved] (SCB-1557) Fix application start info log incorrect
[ https://issues.apache.org/jira/browse/SCB-1557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ang Li resolved SCB-1557. - Fix Version/s: java-chassis-2.0.0 Resolution: Fixed > Fix application start info log incorrect > > > Key: SCB-1557 > URL: https://issues.apache.org/jira/browse/SCB-1557 > Project: Apache ServiceComb > Issue Type: Improvement > Components: Java-Chassis >Reporter: Ang Li >Assignee: Ang Li >Priority: Minor > Fix For: java-chassis-2.0.0 > > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (SCB-1582) Upgrading thirdparty dependency versions
Ang Li created SCB-1582: --- Summary: Upgrading thirdparty dependency versions Key: SCB-1582 URL: https://issues.apache.org/jira/browse/SCB-1582 Project: Apache ServiceComb Issue Type: Improvement Components: Java-Chassis Reporter: Ang Li Assignee: Ang Li -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (SCB-1557) Fix application start info log no correct
Ang Li created SCB-1557: --- Summary: Fix application start info log no correct Key: SCB-1557 URL: https://issues.apache.org/jira/browse/SCB-1557 Project: Apache ServiceComb Issue Type: Improvement Components: Java-Chassis Reporter: Ang Li Assignee: Ang Li -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (SCB-1557) Fix application start info log incorrect
[ https://issues.apache.org/jira/browse/SCB-1557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ang Li updated SCB-1557: Summary: Fix application start info log incorrect (was: Fix application start info log no correct) > Fix application start info log incorrect > > > Key: SCB-1557 > URL: https://issues.apache.org/jira/browse/SCB-1557 > Project: Apache ServiceComb > Issue Type: Improvement > Components: Java-Chassis >Reporter: Ang Li >Assignee: Ang Li >Priority: Minor > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (SCB-1528) Optimizing some code implementations
[ https://issues.apache.org/jira/browse/SCB-1528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ang Li resolved SCB-1528. - Fix Version/s: java-chassis-1.3.0 Resolution: Fixed > Optimizing some code implementations > > > Key: SCB-1528 > URL: https://issues.apache.org/jira/browse/SCB-1528 > Project: Apache ServiceComb > Issue Type: Improvement > Components: Java-Chassis >Reporter: Ang Li >Assignee: Ang Li >Priority: Trivial > Fix For: java-chassis-1.3.0 > > Time Spent: 40m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (SCB-1523) Stopping retrying another server when no server available
[ https://issues.apache.org/jira/browse/SCB-1523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ang Li updated SCB-1523: Fix Version/s: (was: service-center-1.3.0) java-chassis-1.3.0 > Stopping retrying another server when no server available > - > > Key: SCB-1523 > URL: https://issues.apache.org/jira/browse/SCB-1523 > Project: Apache ServiceComb > Issue Type: Improvement > Components: Java-Chassis >Reporter: Ang Li >Assignee: Ang Li >Priority: Trivial > Fix For: java-chassis-1.3.0 > > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (SCB-1523) Stopping retrying another server when no server available
[ https://issues.apache.org/jira/browse/SCB-1523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ang Li resolved SCB-1523. - Fix Version/s: service-center-1.3.0 Resolution: Fixed > Stopping retrying another server when no server available > - > > Key: SCB-1523 > URL: https://issues.apache.org/jira/browse/SCB-1523 > Project: Apache ServiceComb > Issue Type: Improvement > Components: Java-Chassis >Reporter: Ang Li >Assignee: Ang Li >Priority: Trivial > Fix For: service-center-1.3.0 > > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (SCB-1489) Micro-service instance wouldn't work after we shotdown our service center for updating while we had enable RSA authentication between services.
[
https://issues.apache.org/jira/browse/SCB-1489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16954199#comment-16954199
]
Ang Li commented on SCB-1489:
-
The re-registering process has been changed by [GitHub Pull Request
#1355|https://github.com/apache/servicecomb-java-chassis/pull/1355], now
instance will use instanceId obtained by service center at the beginning till
the process termination.
It can be checked by following steps:
# Start a servicecomb service and the instance will be registered to service
center
# Munally delete the instance in service center
# Check the log, every instanceId will be the same now
> Micro-service instance wouldn't work after we shotdown our service center for
> updating while we had enable RSA authentication between services.
> ---
>
> Key: SCB-1489
> URL: https://issues.apache.org/jira/browse/SCB-1489
> Project: Apache ServiceComb
> Issue Type: Bug
> Components: Java-Chassis
>Reporter: Liu HuaiZhou
>Assignee: Ang Li
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> We had add RSA authentication between services following [Documents
> |[https://docs.servicecomb.io/java-chassis/en_US/security/rsa.html]]. The
> micro-service instances interrupted when we shutdown service center and
> update it for latest version.Following are snap logs for comsumer and
> provider instances.
> consumer log：
> [2019-04-27 05:58:10,995/UTC][main][INFO]InvocationException:
> code=490;msg=CommonExceptionData [message=Cse Internal Bad Request]
> com.huawei.paas.cse.demo.pojo.client.PojoClient.main(PojoClient.java:119)
> [2019-04-27 05:58:12,995/UTC][main][INFO]create MicroserviceVersions,
> appId=liushuang-noauth, microserviceName=pojolwx585706.
> org.apache.servicecomb.serviceregistry.consumer.MicroserviceVersions.(MicroserviceVersions.java:84)
> [2019-04-27
> 05:58:13,001/UTC][registry-vert.x-eventloop-thread-0][WARN]failed to
> findInstances:
> {"errorCode":"400012","errorMessage":"Micro-service does not
> exist","detail":"Consumer does not exist."}
> org.apache.servicecomb.serviceregistry.client.http.ServiceRegistryClientImpl.lambda$null$4(ServiceRegistryClientImpl.java:213)
> [2019-04-27 05:58:13,001/UTC][main][INFO]remove microservice,
> appId=liushuang-noauth, microserviceName=pojolwx585706.
> org.apache.servicecomb.serviceregistry.consumer.MicroserviceManager.removeMicroservice(MicroserviceManager.java:76)
> [2019-04-27 05:58:13,001/UTC][main][INFO]create MicroserviceVersionRule,
> appId=liushuang-noauth, microserviceName=pojolwx585706, versionRule=0.0.0+.
> org.apache.servicecomb.serviceregistry.consumer.MicroserviceVersions.createAndInitMicroserviceVersionRule(MicroserviceVersions.java:231)
> [2019-04-27 05:58:13,001/UTC][main][INFO]create MicroserviceVersions,
> appId=liushuang-noauth, microserviceName=pojolwx585706.
> org.apache.servicecomb.serviceregistry.consumer.MicroserviceVersions.(MicroserviceVersions.java:84)
> [2019-04-27
> 05:58:13,004/UTC][registry-vert.x-eventloop-thread-0][WARN]failed to
> findInstances:
> {"errorCode":"400012","errorMessage":"Micro-service does not
> exist","detail":"Consumer does not exist."}
> org.apache.servicecomb.serviceregistry.client.http.ServiceRegistryClientImpl.lambda$null$4(ServiceRegistryClientImpl.java:213)
> [2019-04-27 05:58:13,004/UTC][main][INFO]remove microservice,
> appId=liushuang-noauth, microserviceName=pojolwx585706.
> org.apache.servicecomb.serviceregistry.consumer.MicroserviceManager.removeMicroservice(MicroserviceManager.java:76)
> [2019-04-27 05:58:13,004/UTC][main][ERROR]invoke failed,
> pojolwx585706.helloworldGreeter.SayHello
> org.apache.servicecomb.core.provider.consumer.InvokerUtils.innerSyncInvoke(InvokerUtils.java:80)
> org.apache.servicecomb.foundation.common.exceptions.ServiceCombException:
> org.apache.servicecomb.core.filter.OperationInstancesDiscoveryFilter
> discovery return null.
> at
> org.apache.servicecomb.serviceregistry.discovery.DiscoveryTree.doDiscovery(DiscoveryTree.java:169)
> at
> org.apache.servicecomb.serviceregistry.discovery.DiscoveryTree.discovery(DiscoveryTree.java:130)
> at
> org.apache.servicecomb.serviceregistry.discovery.DiscoveryTree.discovery(DiscoveryTree.java:123)
> at
> org.apache.servicecomb.loadbalance.LoadbalanceHandler.getOrCreateLoadBalancer(LoadbalanceHandler.java:360)
> at
> org.apache.servicecomb.loadbalance.LoadbalanceHandler.handle(LoadbalanceHandler.java:179)
> at org.apache.servicecomb.core.Invocation.next(Invocation.java:151)
> at
> org.apache.servicecomb.core.provider.consumer.InvokerUtils.innerSyncInvoke(InvokerUtils.java:72)
> at
[jira] [Assigned] (SCB-1489) Micro-service instance wouldn't work after we shotdown our service center for updating while we had enable RSA authentication between services.
[
https://issues.apache.org/jira/browse/SCB-1489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ang Li reassigned SCB-1489:
---
Assignee: Ang Li
> Micro-service instance wouldn't work after we shotdown our service center for
> updating while we had enable RSA authentication between services.
> ---
>
> Key: SCB-1489
> URL: https://issues.apache.org/jira/browse/SCB-1489
> Project: Apache ServiceComb
> Issue Type: Bug
> Components: Java-Chassis
>Reporter: Liu HuaiZhou
>Assignee: Ang Li
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> We had add RSA authentication between services following [Documents
> |[https://docs.servicecomb.io/java-chassis/en_US/security/rsa.html]]. The
> micro-service instances interrupted when we shutdown service center and
> update it for latest version.Following are snap logs for comsumer and
> provider instances.
> consumer log：
> [2019-04-27 05:58:10,995/UTC][main][INFO]InvocationException:
> code=490;msg=CommonExceptionData [message=Cse Internal Bad Request]
> com.huawei.paas.cse.demo.pojo.client.PojoClient.main(PojoClient.java:119)
> [2019-04-27 05:58:12,995/UTC][main][INFO]create MicroserviceVersions,
> appId=liushuang-noauth, microserviceName=pojolwx585706.
> org.apache.servicecomb.serviceregistry.consumer.MicroserviceVersions.(MicroserviceVersions.java:84)
> [2019-04-27
> 05:58:13,001/UTC][registry-vert.x-eventloop-thread-0][WARN]failed to
> findInstances:
> {"errorCode":"400012","errorMessage":"Micro-service does not
> exist","detail":"Consumer does not exist."}
> org.apache.servicecomb.serviceregistry.client.http.ServiceRegistryClientImpl.lambda$null$4(ServiceRegistryClientImpl.java:213)
> [2019-04-27 05:58:13,001/UTC][main][INFO]remove microservice,
> appId=liushuang-noauth, microserviceName=pojolwx585706.
> org.apache.servicecomb.serviceregistry.consumer.MicroserviceManager.removeMicroservice(MicroserviceManager.java:76)
> [2019-04-27 05:58:13,001/UTC][main][INFO]create MicroserviceVersionRule,
> appId=liushuang-noauth, microserviceName=pojolwx585706, versionRule=0.0.0+.
> org.apache.servicecomb.serviceregistry.consumer.MicroserviceVersions.createAndInitMicroserviceVersionRule(MicroserviceVersions.java:231)
> [2019-04-27 05:58:13,001/UTC][main][INFO]create MicroserviceVersions,
> appId=liushuang-noauth, microserviceName=pojolwx585706.
> org.apache.servicecomb.serviceregistry.consumer.MicroserviceVersions.(MicroserviceVersions.java:84)
> [2019-04-27
> 05:58:13,004/UTC][registry-vert.x-eventloop-thread-0][WARN]failed to
> findInstances:
> {"errorCode":"400012","errorMessage":"Micro-service does not
> exist","detail":"Consumer does not exist."}
> org.apache.servicecomb.serviceregistry.client.http.ServiceRegistryClientImpl.lambda$null$4(ServiceRegistryClientImpl.java:213)
> [2019-04-27 05:58:13,004/UTC][main][INFO]remove microservice,
> appId=liushuang-noauth, microserviceName=pojolwx585706.
> org.apache.servicecomb.serviceregistry.consumer.MicroserviceManager.removeMicroservice(MicroserviceManager.java:76)
> [2019-04-27 05:58:13,004/UTC][main][ERROR]invoke failed,
> pojolwx585706.helloworldGreeter.SayHello
> org.apache.servicecomb.core.provider.consumer.InvokerUtils.innerSyncInvoke(InvokerUtils.java:80)
> org.apache.servicecomb.foundation.common.exceptions.ServiceCombException:
> org.apache.servicecomb.core.filter.OperationInstancesDiscoveryFilter
> discovery return null.
> at
> org.apache.servicecomb.serviceregistry.discovery.DiscoveryTree.doDiscovery(DiscoveryTree.java:169)
> at
> org.apache.servicecomb.serviceregistry.discovery.DiscoveryTree.discovery(DiscoveryTree.java:130)
> at
> org.apache.servicecomb.serviceregistry.discovery.DiscoveryTree.discovery(DiscoveryTree.java:123)
> at
> org.apache.servicecomb.loadbalance.LoadbalanceHandler.getOrCreateLoadBalancer(LoadbalanceHandler.java:360)
> at
> org.apache.servicecomb.loadbalance.LoadbalanceHandler.handle(LoadbalanceHandler.java:179)
> at org.apache.servicecomb.core.Invocation.next(Invocation.java:151)
> at
> org.apache.servicecomb.core.provider.consumer.InvokerUtils.innerSyncInvoke(InvokerUtils.java:72)
> at org.apache.servicecomb.provider.pojo.Invoker.syncInvoke(Invoker.java:161)
> at org.apache.servicecomb.provider.pojo.Invoker.invoke(Invoker.java:157)
> at com.sun.proxy.$Proxy28.SayHello(Unknown Source)
> at com.huawei.paas.cse.demo.pojo.client.PojoClient.main(PojoClient.java:107)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at
[jira] [Commented] (SCB-1489) Micro-service instance wouldn't work after we shotdown our service center for updating while we had enable RSA authentication between services.
[
https://issues.apache.org/jira/browse/SCB-1489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16953688#comment-16953688
]
Ang Li commented on SCB-1489:
-
We need to figure out why resetting instanceId when re-registering microservice
to service center first.
If the root cause is correct, the problem will be solved when using old
instanceId to re-register microservice
> Micro-service instance wouldn't work after we shotdown our service center for
> updating while we had enable RSA authentication between services.
> ---
>
> Key: SCB-1489
> URL: https://issues.apache.org/jira/browse/SCB-1489
> Project: Apache ServiceComb
> Issue Type: Bug
> Components: Java-Chassis
>Reporter: Liu HuaiZhou
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> We had add RSA authentication between services following [Documents
> |[https://docs.servicecomb.io/java-chassis/en_US/security/rsa.html]]. The
> micro-service instances interrupted when we shutdown service center and
> update it for latest version.Following are snap logs for comsumer and
> provider instances.
> consumer log：
> [2019-04-27 05:58:10,995/UTC][main][INFO]InvocationException:
> code=490;msg=CommonExceptionData [message=Cse Internal Bad Request]
> com.huawei.paas.cse.demo.pojo.client.PojoClient.main(PojoClient.java:119)
> [2019-04-27 05:58:12,995/UTC][main][INFO]create MicroserviceVersions,
> appId=liushuang-noauth, microserviceName=pojolwx585706.
> org.apache.servicecomb.serviceregistry.consumer.MicroserviceVersions.(MicroserviceVersions.java:84)
> [2019-04-27
> 05:58:13,001/UTC][registry-vert.x-eventloop-thread-0][WARN]failed to
> findInstances:
> {"errorCode":"400012","errorMessage":"Micro-service does not
> exist","detail":"Consumer does not exist."}
> org.apache.servicecomb.serviceregistry.client.http.ServiceRegistryClientImpl.lambda$null$4(ServiceRegistryClientImpl.java:213)
> [2019-04-27 05:58:13,001/UTC][main][INFO]remove microservice,
> appId=liushuang-noauth, microserviceName=pojolwx585706.
> org.apache.servicecomb.serviceregistry.consumer.MicroserviceManager.removeMicroservice(MicroserviceManager.java:76)
> [2019-04-27 05:58:13,001/UTC][main][INFO]create MicroserviceVersionRule,
> appId=liushuang-noauth, microserviceName=pojolwx585706, versionRule=0.0.0+.
> org.apache.servicecomb.serviceregistry.consumer.MicroserviceVersions.createAndInitMicroserviceVersionRule(MicroserviceVersions.java:231)
> [2019-04-27 05:58:13,001/UTC][main][INFO]create MicroserviceVersions,
> appId=liushuang-noauth, microserviceName=pojolwx585706.
> org.apache.servicecomb.serviceregistry.consumer.MicroserviceVersions.(MicroserviceVersions.java:84)
> [2019-04-27
> 05:58:13,004/UTC][registry-vert.x-eventloop-thread-0][WARN]failed to
> findInstances:
> {"errorCode":"400012","errorMessage":"Micro-service does not
> exist","detail":"Consumer does not exist."}
> org.apache.servicecomb.serviceregistry.client.http.ServiceRegistryClientImpl.lambda$null$4(ServiceRegistryClientImpl.java:213)
> [2019-04-27 05:58:13,004/UTC][main][INFO]remove microservice,
> appId=liushuang-noauth, microserviceName=pojolwx585706.
> org.apache.servicecomb.serviceregistry.consumer.MicroserviceManager.removeMicroservice(MicroserviceManager.java:76)
> [2019-04-27 05:58:13,004/UTC][main][ERROR]invoke failed,
> pojolwx585706.helloworldGreeter.SayHello
> org.apache.servicecomb.core.provider.consumer.InvokerUtils.innerSyncInvoke(InvokerUtils.java:80)
> org.apache.servicecomb.foundation.common.exceptions.ServiceCombException:
> org.apache.servicecomb.core.filter.OperationInstancesDiscoveryFilter
> discovery return null.
> at
> org.apache.servicecomb.serviceregistry.discovery.DiscoveryTree.doDiscovery(DiscoveryTree.java:169)
> at
> org.apache.servicecomb.serviceregistry.discovery.DiscoveryTree.discovery(DiscoveryTree.java:130)
> at
> org.apache.servicecomb.serviceregistry.discovery.DiscoveryTree.discovery(DiscoveryTree.java:123)
> at
> org.apache.servicecomb.loadbalance.LoadbalanceHandler.getOrCreateLoadBalancer(LoadbalanceHandler.java:360)
> at
> org.apache.servicecomb.loadbalance.LoadbalanceHandler.handle(LoadbalanceHandler.java:179)
> at org.apache.servicecomb.core.Invocation.next(Invocation.java:151)
> at
> org.apache.servicecomb.core.provider.consumer.InvokerUtils.innerSyncInvoke(InvokerUtils.java:72)
> at org.apache.servicecomb.provider.pojo.Invoker.syncInvoke(Invoker.java:161)
> at org.apache.servicecomb.provider.pojo.Invoker.invoke(Invoker.java:157)
> at com.sun.proxy.$Proxy28.SayHello(Unknown Source)
> at com.huawei.paas.cse.demo.pojo.client.PojoClient.main(PojoClient.java:107)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>
[jira] [Commented] (SCB-1528) Optimizing some code implementations
[ https://issues.apache.org/jira/browse/SCB-1528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16953463#comment-16953463 ] Ang Li commented on SCB-1528: - # Iterating entrySet() is more efficent than entryKey() when call map.get(key) each time; # Collections.isEmpty() is more efficent than collections.size() == 0 # Util classes should have private constructures # String.valueOf() is more efficent then + "" # BigDecimal() may cause some precision problems while BigDecimal.valueOf() not # Return empty collection instead of null can prevent NPE # Objects.equals(a, b) is better than a.equals(b) because of NPE # Data in enum shoud be private final > Optimizing some code implementations > > > Key: SCB-1528 > URL: https://issues.apache.org/jira/browse/SCB-1528 > Project: Apache ServiceComb > Issue Type: Improvement > Components: Java-Chassis >Reporter: Ang Li >Assignee: Ang Li >Priority: Trivial > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (SCB-1489) Micro-service instance wouldn't work after we shotdown our service center for updating while we had enable RSA authentication between services.
[
https://issues.apache.org/jira/browse/SCB-1489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16953349#comment-16953349
]
Ang Li edited comment on SCB-1489 at 10/17/19 3:18 AM:
---
The root cause is the instanceId changed while the token unchanged.
I think the problem will be solved after restarting the instance because both
the token and the instanceId will be updated.
Since the instanceId is generated and obtained by service-center, we should
update the token every time register the instance.
was (Author: ang li):
The root cause is the instanceId changed while the token unchanged.
I think the problem will be solved after restarting the instance because both
the token and the instanceId will be updated.
Maybe the problem can be easily solved just keeping the instanceId immutable
while the instance running.
> Micro-service instance wouldn't work after we shotdown our service center for
> updating while we had enable RSA authentication between services.
> ---
>
> Key: SCB-1489
> URL: https://issues.apache.org/jira/browse/SCB-1489
> Project: Apache ServiceComb
> Issue Type: Bug
> Components: Java-Chassis
>Reporter: Liu HuaiZhou
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> We had add RSA authentication between services following [Documents
> |[https://docs.servicecomb.io/java-chassis/en_US/security/rsa.html]]. The
> micro-service instances interrupted when we shutdown service center and
> update it for latest version.Following are snap logs for comsumer and
> provider instances.
> consumer log：
> [2019-04-27 05:58:10,995/UTC][main][INFO]InvocationException:
> code=490;msg=CommonExceptionData [message=Cse Internal Bad Request]
> com.huawei.paas.cse.demo.pojo.client.PojoClient.main(PojoClient.java:119)
> [2019-04-27 05:58:12,995/UTC][main][INFO]create MicroserviceVersions,
> appId=liushuang-noauth, microserviceName=pojolwx585706.
> org.apache.servicecomb.serviceregistry.consumer.MicroserviceVersions.(MicroserviceVersions.java:84)
> [2019-04-27
> 05:58:13,001/UTC][registry-vert.x-eventloop-thread-0][WARN]failed to
> findInstances:
> {"errorCode":"400012","errorMessage":"Micro-service does not
> exist","detail":"Consumer does not exist."}
> org.apache.servicecomb.serviceregistry.client.http.ServiceRegistryClientImpl.lambda$null$4(ServiceRegistryClientImpl.java:213)
> [2019-04-27 05:58:13,001/UTC][main][INFO]remove microservice,
> appId=liushuang-noauth, microserviceName=pojolwx585706.
> org.apache.servicecomb.serviceregistry.consumer.MicroserviceManager.removeMicroservice(MicroserviceManager.java:76)
> [2019-04-27 05:58:13,001/UTC][main][INFO]create MicroserviceVersionRule,
> appId=liushuang-noauth, microserviceName=pojolwx585706, versionRule=0.0.0+.
> org.apache.servicecomb.serviceregistry.consumer.MicroserviceVersions.createAndInitMicroserviceVersionRule(MicroserviceVersions.java:231)
> [2019-04-27 05:58:13,001/UTC][main][INFO]create MicroserviceVersions,
> appId=liushuang-noauth, microserviceName=pojolwx585706.
> org.apache.servicecomb.serviceregistry.consumer.MicroserviceVersions.(MicroserviceVersions.java:84)
> [2019-04-27
> 05:58:13,004/UTC][registry-vert.x-eventloop-thread-0][WARN]failed to
> findInstances:
> {"errorCode":"400012","errorMessage":"Micro-service does not
> exist","detail":"Consumer does not exist."}
> org.apache.servicecomb.serviceregistry.client.http.ServiceRegistryClientImpl.lambda$null$4(ServiceRegistryClientImpl.java:213)
> [2019-04-27 05:58:13,004/UTC][main][INFO]remove microservice,
> appId=liushuang-noauth, microserviceName=pojolwx585706.
> org.apache.servicecomb.serviceregistry.consumer.MicroserviceManager.removeMicroservice(MicroserviceManager.java:76)
> [2019-04-27 05:58:13,004/UTC][main][ERROR]invoke failed,
> pojolwx585706.helloworldGreeter.SayHello
> org.apache.servicecomb.core.provider.consumer.InvokerUtils.innerSyncInvoke(InvokerUtils.java:80)
> org.apache.servicecomb.foundation.common.exceptions.ServiceCombException:
> org.apache.servicecomb.core.filter.OperationInstancesDiscoveryFilter
> discovery return null.
> at
> org.apache.servicecomb.serviceregistry.discovery.DiscoveryTree.doDiscovery(DiscoveryTree.java:169)
> at
> org.apache.servicecomb.serviceregistry.discovery.DiscoveryTree.discovery(DiscoveryTree.java:130)
> at
> org.apache.servicecomb.serviceregistry.discovery.DiscoveryTree.discovery(DiscoveryTree.java:123)
> at
> org.apache.servicecomb.loadbalance.LoadbalanceHandler.getOrCreateLoadBalancer(LoadbalanceHandler.java:360)
> at
> org.apache.servicecomb.loadbalance.LoadbalanceHandler.handle(LoadbalanceHandler.java:179)
> at
[jira] [Commented] (SCB-1489) Micro-service instance wouldn't work after we shotdown our service center for updating while we had enable RSA authentication between services.
[
https://issues.apache.org/jira/browse/SCB-1489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16953349#comment-16953349
]
Ang Li commented on SCB-1489:
-
The root cause is the instanceId changed while the token unchanged.
I think the problem will be solved after restarting the instance because both
the token and the instanceId will be updated.
Maybe the problem can be easily solved just keeping the instanceId immutable
while the instance running.
> Micro-service instance wouldn't work after we shotdown our service center for
> updating while we had enable RSA authentication between services.
> ---
>
> Key: SCB-1489
> URL: https://issues.apache.org/jira/browse/SCB-1489
> Project: Apache ServiceComb
> Issue Type: Bug
> Components: Java-Chassis
>Reporter: Liu HuaiZhou
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> We had add RSA authentication between services following [Documents
> |[https://docs.servicecomb.io/java-chassis/en_US/security/rsa.html]]. The
> micro-service instances interrupted when we shutdown service center and
> update it for latest version.Following are snap logs for comsumer and
> provider instances.
> consumer log：
> [2019-04-27 05:58:10,995/UTC][main][INFO]InvocationException:
> code=490;msg=CommonExceptionData [message=Cse Internal Bad Request]
> com.huawei.paas.cse.demo.pojo.client.PojoClient.main(PojoClient.java:119)
> [2019-04-27 05:58:12,995/UTC][main][INFO]create MicroserviceVersions,
> appId=liushuang-noauth, microserviceName=pojolwx585706.
> org.apache.servicecomb.serviceregistry.consumer.MicroserviceVersions.(MicroserviceVersions.java:84)
> [2019-04-27
> 05:58:13,001/UTC][registry-vert.x-eventloop-thread-0][WARN]failed to
> findInstances:
> {"errorCode":"400012","errorMessage":"Micro-service does not
> exist","detail":"Consumer does not exist."}
> org.apache.servicecomb.serviceregistry.client.http.ServiceRegistryClientImpl.lambda$null$4(ServiceRegistryClientImpl.java:213)
> [2019-04-27 05:58:13,001/UTC][main][INFO]remove microservice,
> appId=liushuang-noauth, microserviceName=pojolwx585706.
> org.apache.servicecomb.serviceregistry.consumer.MicroserviceManager.removeMicroservice(MicroserviceManager.java:76)
> [2019-04-27 05:58:13,001/UTC][main][INFO]create MicroserviceVersionRule,
> appId=liushuang-noauth, microserviceName=pojolwx585706, versionRule=0.0.0+.
> org.apache.servicecomb.serviceregistry.consumer.MicroserviceVersions.createAndInitMicroserviceVersionRule(MicroserviceVersions.java:231)
> [2019-04-27 05:58:13,001/UTC][main][INFO]create MicroserviceVersions,
> appId=liushuang-noauth, microserviceName=pojolwx585706.
> org.apache.servicecomb.serviceregistry.consumer.MicroserviceVersions.(MicroserviceVersions.java:84)
> [2019-04-27
> 05:58:13,004/UTC][registry-vert.x-eventloop-thread-0][WARN]failed to
> findInstances:
> {"errorCode":"400012","errorMessage":"Micro-service does not
> exist","detail":"Consumer does not exist."}
> org.apache.servicecomb.serviceregistry.client.http.ServiceRegistryClientImpl.lambda$null$4(ServiceRegistryClientImpl.java:213)
> [2019-04-27 05:58:13,004/UTC][main][INFO]remove microservice,
> appId=liushuang-noauth, microserviceName=pojolwx585706.
> org.apache.servicecomb.serviceregistry.consumer.MicroserviceManager.removeMicroservice(MicroserviceManager.java:76)
> [2019-04-27 05:58:13,004/UTC][main][ERROR]invoke failed,
> pojolwx585706.helloworldGreeter.SayHello
> org.apache.servicecomb.core.provider.consumer.InvokerUtils.innerSyncInvoke(InvokerUtils.java:80)
> org.apache.servicecomb.foundation.common.exceptions.ServiceCombException:
> org.apache.servicecomb.core.filter.OperationInstancesDiscoveryFilter
> discovery return null.
> at
> org.apache.servicecomb.serviceregistry.discovery.DiscoveryTree.doDiscovery(DiscoveryTree.java:169)
> at
> org.apache.servicecomb.serviceregistry.discovery.DiscoveryTree.discovery(DiscoveryTree.java:130)
> at
> org.apache.servicecomb.serviceregistry.discovery.DiscoveryTree.discovery(DiscoveryTree.java:123)
> at
> org.apache.servicecomb.loadbalance.LoadbalanceHandler.getOrCreateLoadBalancer(LoadbalanceHandler.java:360)
> at
> org.apache.servicecomb.loadbalance.LoadbalanceHandler.handle(LoadbalanceHandler.java:179)
> at org.apache.servicecomb.core.Invocation.next(Invocation.java:151)
> at
> org.apache.servicecomb.core.provider.consumer.InvokerUtils.innerSyncInvoke(InvokerUtils.java:72)
> at org.apache.servicecomb.provider.pojo.Invoker.syncInvoke(Invoker.java:161)
> at org.apache.servicecomb.provider.pojo.Invoker.invoke(Invoker.java:157)
> at com.sun.proxy.$Proxy28.SayHello(Unknown Source)
> at
[jira] [Created] (SCB-1528) Optimizing some code implementations
Ang Li created SCB-1528: --- Summary: Optimizing some code implementations Key: SCB-1528 URL: https://issues.apache.org/jira/browse/SCB-1528 Project: Apache ServiceComb Issue Type: Improvement Components: Java-Chassis Reporter: Ang Li Assignee: Ang Li -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (SCB-1523) Stopping retrying another server when no server available
[ https://issues.apache.org/jira/browse/SCB-1523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ang Li updated SCB-1523: Summary: Stopping retrying another server when no server available (was: Stopping retrying another server when serverlist is empty) > Stopping retrying another server when no server available > - > > Key: SCB-1523 > URL: https://issues.apache.org/jira/browse/SCB-1523 > Project: Apache ServiceComb > Issue Type: Improvement > Components: Java-Chassis >Reporter: Ang Li >Assignee: Ang Li >Priority: Trivial > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (SCB-1523) Stopping retrying another server when serverlist is empty
[ https://issues.apache.org/jira/browse/SCB-1523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ang Li updated SCB-1523: Summary: Stopping retrying another server when serverlist is empty (was: Optimizing duplicate logs in LoadBalanceHandler) > Stopping retrying another server when serverlist is empty > - > > Key: SCB-1523 > URL: https://issues.apache.org/jira/browse/SCB-1523 > Project: Apache ServiceComb > Issue Type: Improvement > Components: Java-Chassis >Reporter: Ang Li >Assignee: Ang Li >Priority: Trivial > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (SCB-1516) Upgrade third-party dependency versions
[ https://issues.apache.org/jira/browse/SCB-1516?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ang Li resolved SCB-1516. - Fix Version/s: java-chassis-1.3.0 Resolution: Fixed [https://github.com/apache/servicecomb-java-chassis/commit/451e824dd303cf74365800102da1e1abf0bad841] > Upgrade third-party dependency versions > --- > > Key: SCB-1516 > URL: https://issues.apache.org/jira/browse/SCB-1516 > Project: Apache ServiceComb > Issue Type: Improvement > Components: Java-Chassis >Reporter: Ang Li >Assignee: Ang Li >Priority: Trivial > Fix For: java-chassis-1.3.0 > > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (SCB-1523) Optimizing duplicate logs in LoadBalanceHandler
Ang Li created SCB-1523: --- Summary: Optimizing duplicate logs in LoadBalanceHandler Key: SCB-1523 URL: https://issues.apache.org/jira/browse/SCB-1523 Project: Apache ServiceComb Issue Type: Improvement Components: Java-Chassis Reporter: Ang Li Assignee: Ang Li -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (SCB-1494) Optimizing log when starting a new microservice
[ https://issues.apache.org/jira/browse/SCB-1494?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ang Li resolved SCB-1494. - Fix Version/s: java-chassis-1.3.0 Resolution: Fixed [https://github.com/apache/servicecomb-java-chassis/commit/7428c93560289f42de4ae80ec91421c5215ea77d] > Optimizing log when starting a new microservice > --- > > Key: SCB-1494 > URL: https://issues.apache.org/jira/browse/SCB-1494 > Project: Apache ServiceComb > Issue Type: Improvement > Components: Java-Chassis >Reporter: Ang Li >Assignee: Ang Li >Priority: Minor > Fix For: java-chassis-1.3.0 > > Time Spent: 40m > Remaining Estimate: 0h > > Currently, servicecomb-java-chassis will generate some warn logs indicating > schema not exist. Some users feel confused about that. > Logs should be optimized. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (SCB-1516) Upgrade third-party dependency versions
Ang Li created SCB-1516: --- Summary: Upgrade third-party dependency versions Key: SCB-1516 URL: https://issues.apache.org/jira/browse/SCB-1516 Project: Apache ServiceComb Issue Type: Improvement Components: Java-Chassis Reporter: Ang Li Assignee: Ang Li -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (SCB-1488) Upgrading protobuf version to 3.7.1
Ang Li created SCB-1488: --- Summary: Upgrading protobuf version to 3.7.1 Key: SCB-1488 URL: https://issues.apache.org/jira/browse/SCB-1488 Project: Apache ServiceComb Issue Type: Improvement Components: Java-Chassis Reporter: Ang Li Assignee: Ang Li Fix For: java-chassis-1.3.0 -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Resolved] (SCB-1431) set all dependency version as properties in java-chasis-dependencies
[ https://issues.apache.org/jira/browse/SCB-1431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ang Li resolved SCB-1431. - Resolution: Fixed [https://github.com/apache/servicecomb-java-chassis/pull/1295/commits/1e6f90b03d7ab10eb23baeba344979128d9d2bea] > set all dependency version as properties in java-chasis-dependencies > > > Key: SCB-1431 > URL: https://issues.apache.org/jira/browse/SCB-1431 > Project: Apache ServiceComb > Issue Type: Improvement > Components: Java-Chassis >Reporter: Ang Li >Assignee: Ang Li >Priority: Minor > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Created] (SCB-1437) Upgrading third party dependency versions
Ang Li created SCB-1437: --- Summary: Upgrading third party dependency versions Key: SCB-1437 URL: https://issues.apache.org/jira/browse/SCB-1437 Project: Apache ServiceComb Issue Type: Improvement Components: Java-Chassis Reporter: Ang Li Assignee: Ang Li -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Created] (SCB-1431) set all dependency version as properties in java-chasis-dependencies
Ang Li created SCB-1431: --- Summary: set all dependency version as properties in java-chasis-dependencies Key: SCB-1431 URL: https://issues.apache.org/jira/browse/SCB-1431 Project: Apache ServiceComb Issue Type: Improvement Components: Java-Chassis Reporter: Ang Li Assignee: Ang Li -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Resolved] (SCB-1402) BeanUtils.getImplClassFromBean can not return correctly info in cglib proxy situation
[
https://issues.apache.org/jira/browse/SCB-1402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ang Li resolved SCB-1402.
-
Resolution: Fixed
solved, see [https://github.com/apache/servicecomb-java-chassis/pull/1281]
> BeanUtils.getImplClassFromBean can not return correctly info in cglib proxy
> situation
> -
>
> Key: SCB-1402
> URL: https://issues.apache.org/jira/browse/SCB-1402
> Project: Apache ServiceComb
> Issue Type: Improvement
> Components: Java-Chassis
>Affects Versions: java-chassis-1.2.1
>Reporter: Ang Li
>Assignee: Ang Li
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> I found a problem using
> org.apache.servicecomb.foundation.common.utils.BeanUtils#getImplClassFromBean.
> If the @param bean is a cgLib proxy subclass bean, the getImplClassFromBean
> method will return null instead of super class which is expected. To make the
> issure more clearly, I created a bean class as following:
> *static class* TestBean{
>
> }
>
> *static class* TestBean$$TestBeanByCGLIB$$e1a36bab *extends* TestBean
> *implements* SpringProxy {
>
> }
> The case is to simulate a bean class proxied by cglib proxy.A test case
> provided as following and the case is not past.
> @Test
> *public void* testGetImplClassFromBeanfromCglib(){
> TestBean testBeanByCGLIB = *new* TestBean$$TestBeanByCGLIB$$e1a36bab();
> Assert._assertEquals_(TestBean.*class*,
> BeanUtils._getImplClassFromBean_(testBeanByCGLIB));
> }
> This matters because cglib proxy can be used while using serviceComb
> framework and I think just a few lines of code changing can fix this issue.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Resolved] (SCB-1408) NoClassDefFoundError occurs when starting springboot app as a container
[ https://issues.apache.org/jira/browse/SCB-1408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ang Li resolved SCB-1408. - Resolution: Not A Problem The issue is solved, no servicecomb problem. Users using springboot1.5 as parent project should set the version of javax-validation mannualy. see [https://bbs.huaweicloud.com/blogs/81237675b43111e9b759fa163e330718] > NoClassDefFoundError occurs when starting springboot app as a container > --- > > Key: SCB-1408 > URL: https://issues.apache.org/jira/browse/SCB-1408 > Project: Apache ServiceComb > Issue Type: Bug > Components: Java-Chassis >Reporter: Ang Li >Assignee: Ang Li >Priority: Critical > Time Spent: 20m > Remaining Estimate: 0h > > [https://bbs.huaweicloud.com/blogs/2700e5d390fe11e9b759fa163e330718] -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (SCB-1408) NoClassDefFoundError occurs when starting springboot app as a container
[ https://issues.apache.org/jira/browse/SCB-1408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16900682#comment-16900682 ] Ang Li commented on SCB-1408: - The issue is solved, see [https://bbs.huaweicloud.com/blogs/81237675b43111e9b759fa163e330718] > NoClassDefFoundError occurs when starting springboot app as a container > --- > > Key: SCB-1408 > URL: https://issues.apache.org/jira/browse/SCB-1408 > Project: Apache ServiceComb > Issue Type: Bug > Components: Java-Chassis >Reporter: Ang Li >Assignee: Ang Li >Priority: Critical > Time Spent: 20m > Remaining Estimate: 0h > > [https://bbs.huaweicloud.com/blogs/2700e5d390fe11e9b759fa163e330718] -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Updated] (SCB-1408) NoClassDefFoundError occurs when starting springboot app as a container
[ https://issues.apache.org/jira/browse/SCB-1408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ang Li updated SCB-1408: Summary: NoClassDefFoundError occurs when starting springboot app as a container (was: NoClassDefFoundError occurs when starting springboot app as container) > NoClassDefFoundError occurs when starting springboot app as a container > --- > > Key: SCB-1408 > URL: https://issues.apache.org/jira/browse/SCB-1408 > Project: Apache ServiceComb > Issue Type: Bug > Components: Java-Chassis >Reporter: Ang Li >Assignee: Ang Li >Priority: Critical > > [https://bbs.huaweicloud.com/blogs/2700e5d390fe11e9b759fa163e330718] -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Created] (SCB-1408) NoClassDefFoundError occurs when starting springboot app as container
Ang Li created SCB-1408: --- Summary: NoClassDefFoundError occurs when starting springboot app as container Key: SCB-1408 URL: https://issues.apache.org/jira/browse/SCB-1408 Project: Apache ServiceComb Issue Type: Bug Components: Java-Chassis Reporter: Ang Li Assignee: Ang Li [https://bbs.huaweicloud.com/blogs/2700e5d390fe11e9b759fa163e330718] -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Resolved] (SCB-1405) support maxWaitQueueSize setting in RestTransportClient
[ https://issues.apache.org/jira/browse/SCB-1405?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ang Li resolved SCB-1405. - Resolution: Fixed > support maxWaitQueueSize setting in RestTransportClient > --- > > Key: SCB-1405 > URL: https://issues.apache.org/jira/browse/SCB-1405 > Project: Apache ServiceComb > Issue Type: Improvement > Components: Java-Chassis >Affects Versions: java-chassis-1.2.1 >Reporter: Ang Li >Assignee: Ang Li >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Created] (SCB-1405) support maxWaitQueueSize setting in RestTransportClient
Ang Li created SCB-1405: --- Summary: support maxWaitQueueSize setting in RestTransportClient Key: SCB-1405 URL: https://issues.apache.org/jira/browse/SCB-1405 Project: Apache ServiceComb Issue Type: Improvement Components: Java-Chassis Affects Versions: java-chassis-1.2.1 Reporter: Ang Li Assignee: Ang Li -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Updated] (SCB-1393) websocket supporting
[ https://issues.apache.org/jira/browse/SCB-1393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ang Li updated SCB-1393: Priority: Major (was: Critical) > websocket supporting > - > > Key: SCB-1393 > URL: https://issues.apache.org/jira/browse/SCB-1393 > Project: Apache ServiceComb > Issue Type: New Feature > Components: Java-Chassis >Reporter: Ang Li >Assignee: Ang Li >Priority: Major > > ServiceComb-Java-Chasis is not supporting websocket now -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Updated] (SCB-1402) BeanUtils.getImplClassFromBean can not return correctly info in cglib proxy situation
[
https://issues.apache.org/jira/browse/SCB-1402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ang Li updated SCB-1402:
Summary: BeanUtils.getImplClassFromBean can not return correctly info in
cglib proxy situation (was: BeanUtils)
> BeanUtils.getImplClassFromBean can not return correctly info in cglib proxy
> situation
> -
>
> Key: SCB-1402
> URL: https://issues.apache.org/jira/browse/SCB-1402
> Project: Apache ServiceComb
> Issue Type: Improvement
> Components: Java-Chassis
>Affects Versions: java-chassis-1.2.1
>Reporter: Ang Li
>Assignee: Ang Li
>Priority: Major
>
> I found a problem using
> org.apache.servicecomb.foundation.common.utils.BeanUtils#getImplClassFromBean.
> If the @param bean is a cgLib proxy subclass bean, the getImplClassFromBean
> method will return null instead of super class which is expected. To make the
> issure more clearly, I created a bean class as following:
> *static class* TestBean{
>
> }
>
> *static class* TestBean$$TestBeanByCGLIB$$e1a36bab *extends* TestBean
> *implements* SpringProxy {
>
> }
> The case is to simulate a bean class proxied by cglib proxy.A test case
> provided as following and the case is not past.
> @Test
> *public void* testGetImplClassFromBeanfromCglib(){
> TestBean testBeanByCGLIB = *new* TestBean$$TestBeanByCGLIB$$e1a36bab();
> Assert._assertEquals_(TestBean.*class*,
> BeanUtils._getImplClassFromBean_(testBeanByCGLIB));
> }
> This matters because cglib proxy can be used while using serviceComb
> framework and I think just a few lines of code changing can fix this issue.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Created] (SCB-1402) BeanUtils
Ang Li created SCB-1402:
---
Summary: BeanUtils
Key: SCB-1402
URL: https://issues.apache.org/jira/browse/SCB-1402
Project: Apache ServiceComb
Issue Type: Improvement
Components: Java-Chassis
Affects Versions: java-chassis-1.2.1
Reporter: Ang Li
Assignee: Ang Li
I found a problem using
org.apache.servicecomb.foundation.common.utils.BeanUtils#getImplClassFromBean.
If the @param bean is a cgLib proxy subclass bean, the getImplClassFromBean
method will return null instead of super class which is expected. To make the
issure more clearly, I created a bean class as following:
*static class* TestBean{
}
*static class* TestBean$$TestBeanByCGLIB$$e1a36bab *extends* TestBean
*implements* SpringProxy {
}
The case is to simulate a bean class proxied by cglib proxy.A test case
provided as following and the case is not past.
@Test
*public void* testGetImplClassFromBeanfromCglib(){
TestBean testBeanByCGLIB = *new* TestBean$$TestBeanByCGLIB$$e1a36bab();
Assert._assertEquals_(TestBean.*class*,
BeanUtils._getImplClassFromBean_(testBeanByCGLIB));
}
This matters because cglib proxy can be used while using serviceComb framework
and I think just a few lines of code changing can fix this issue.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Assigned] (SCB-1393) websocket supporting
[ https://issues.apache.org/jira/browse/SCB-1393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ang Li reassigned SCB-1393: --- Assignee: Ang Li > websocket supporting > - > > Key: SCB-1393 > URL: https://issues.apache.org/jira/browse/SCB-1393 > Project: Apache ServiceComb > Issue Type: New Feature > Components: Java-Chassis >Reporter: Ang Li >Assignee: Ang Li >Priority: Critical > > ServiceComb-Java-Chasis is not supporting websocket now -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Assigned] (SCB-1394) consistent hashing load balance supporting
[ https://issues.apache.org/jira/browse/SCB-1394?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ang Li reassigned SCB-1394: --- Assignee: Ang Li > consistent hashing load balance supporting > -- > > Key: SCB-1394 > URL: https://issues.apache.org/jira/browse/SCB-1394 > Project: Apache ServiceComb > Issue Type: New Feature > Components: Java-Chassis >Reporter: Ang Li >Assignee: Ang Li >Priority: Minor > > There are many rules can be chosen in load balance part now, but consistent > hashing rule is not one of them. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Created] (SCB-1394) consistent hashing load balance supporting
Ang Li created SCB-1394: --- Summary: consistent hashing load balance supporting Key: SCB-1394 URL: https://issues.apache.org/jira/browse/SCB-1394 Project: Apache ServiceComb Issue Type: New Feature Components: Java-Chassis Reporter: Ang Li There are many rules can be chosen in load balance part now, but consistent hashing rule is not one of them. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Created] (SCB-1393) websocket supporting
Ang Li created SCB-1393: --- Summary: websocket supporting Key: SCB-1393 URL: https://issues.apache.org/jira/browse/SCB-1393 Project: Apache ServiceComb Issue Type: New Feature Components: Java-Chassis Reporter: Ang Li ServiceComb-Java-Chasis is not supporting websocket now -- This message was sent by Atlassian JIRA (v7.6.14#76016)
