[jira] [Created] (SCB-1473) Add the description about the config item of max request body size
YaoHaishi created SCB-1473: -- Summary: Add the description about the config item of max request body size Key: SCB-1473 URL: https://issues.apache.org/jira/browse/SCB-1473 Project: Apache ServiceComb Issue Type: Improvement Components: Docs Reporter: YaoHaishi Currently the config item of max body size limitation is mentioned in the [doc of file uploading|https://docs.servicecomb.io/java-chassis/en_US/general-development/file-upload.html]. This is not so obvious. It's better to add it into the FAQ. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Created] (SCB-1472) Allow users to disable the param validation by configuration
YaoHaishi created SCB-1472: -- Summary: Allow users to disable the param validation by configuration Key: SCB-1472 URL: https://issues.apache.org/jira/browse/SCB-1472 Project: Apache ServiceComb Issue Type: Improvement Components: Java-Chassis Reporter: YaoHaishi In org.apache.servicecomb.swagger.invocation.validator.ParameterValidator the parameters are checked before actually passed into the business logic method. Currently this feature always works, and users have no way to disable it even if it's not needed. We should add a config item to allow users disable this function. The config key is "servicecomb.rest.parameter.validation.enabled", and the default value is "true", which means parameter validator is enabled by default. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Created] (SCB-1471) Make the config items description about fallback policy clearer
YaoHaishi created SCB-1471:
--
Summary: Make the config items description about fallback policy
clearer
Key: SCB-1471
URL: https://issues.apache.org/jira/browse/SCB-1471
Project: Apache ServiceComb
Issue Type: Wish
Components: Docs
Reporter: YaoHaishi
Each of the config items of fallback policy contains the "type" field to
indicate whether it's for consumer or provider side. You can reference to the
current docs and get the uniform format like below
{code:java}
servicecomb.[namespace].[type].[MicroServiceName].[interface name].[property
name]
{code}
The valid values of "type" field contains "Consumer" and "Provider".
For example, "servicecomb.circuitBreaker.Consumer.enabled" is for consumer
side, while "servicecomb.circuitBreaker.Provider.enabled" is for provider side.
This field is necessary, but not contained in the config key column of the
config items table. As a result, some users forget to write this field into
their actual configurations, and the configuration items don't take effect.
As a improvement, the "type" field should be added into the "configuration
item" table column. For example, currently in the doc, the config item for
timeout detection is shown as "servicecomb.isolation.timeout.enabled", and it
should be changed to "servicecomb.isolation.[type].timeout.enabled".
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Created] (SCB-1470) Adjust the docs of Metrics
YaoHaishi created SCB-1470: -- Summary: Adjust the docs of Metrics Key: SCB-1470 URL: https://issues.apache.org/jira/browse/SCB-1470 Project: Apache ServiceComb Issue Type: Wish Components: Docs Reporter: YaoHaishi Currently in the docs of metrics, the introduction about the metrics statistic items is ahead of the introduction about how to use the metrics. But the fresh users are more care about the usage of metrics. It's better to adjust the docs and put the usage introduction(part 3 of the doc) ahead of the metrics statistic items introduction(part 2 of the doc). Docs address: * [https://docs.servicecomb.io/java-chassis/zh_CN/general-development/metrics.html] * [https://docs.servicecomb.io/java-chassis/en_US/general-development/metrics.html] -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Created] (SCB-1469) SCBEngine should abandon unfinished invocations if waiting for invocation finished is timed out
YaoHaishi created SCB-1469:
--
Summary: SCBEngine should abandon unfinished invocations if
waiting for invocation finished is timed out
Key: SCB-1469
URL: https://issues.apache.org/jira/browse/SCB-1469
Project: Apache ServiceComb
Issue Type: Bug
Components: Java-Chassis
Reporter: YaoHaishi
When a microservice instance is going to exit, the SCBEngine will block the
exit procedure, waiting for all of the invocations in processing status get
finished. And in the method SCBEngine#validAllInvocationFinished, the
unfinished invocations counter is checked. After waiting for a period of time,
if there are still unfinished invocations, the SCBEngine should print error log
to warn users about those invocations and exit the process forcely.
However, currently in the method SCBEngine#validAllInvocationFinished only the
error log is printed, but no exit operation is done, leaving the exit procedure
still blocked.
You can find the code segment to be fixed like below in the class SCBEngine:
{code:java}
private void validAllInvocationFinished() throws InterruptedException {
long start = System.currentTimeMillis();
while (true) {
long remaining = invocationStartedCounter.get() -
invocationFinishedCounter.get();
if (remaining == 0) {
return;
}
if (System.currentTimeMillis() - start > TimeUnit.SECONDS.toMillis(30)) {
LOGGER.error("wait for all requests timeout, abandon waiting, remaining
requests: {}.", remaining);
// since the waiting logic is timed out, should return to exit here
}
TimeUnit.SECONDS.sleep(1);
}
}
{code}
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Resolved] (SCB-1448) support class inheritance and interface inheritance with template type
[ https://issues.apache.org/jira/browse/SCB-1448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] YaoHaishi resolved SCB-1448. Resolution: Fixed > support class inheritance and interface inheritance with template type > -- > > Key: SCB-1448 > URL: https://issues.apache.org/jira/browse/SCB-1448 > Project: Apache ServiceComb > Issue Type: Improvement > Components: Java-Chassis >Reporter: liubao >Assignee: liubao >Priority: Major > Fix For: java-chassis-1.3.0 > > Time Spent: 40m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Created] (SCB-1468) Improve the instance registry mechanism
YaoHaishi created SCB-1468: -- Summary: Improve the instance registry mechanism Key: SCB-1468 URL: https://issues.apache.org/jira/browse/SCB-1468 Project: Apache ServiceComb Issue Type: Improvement Components: Java-Chassis Affects Versions: java-chassis-1.3.0 Reporter: YaoHaishi In the pull request of SCB-1407, an extra query operation is added into the procedure of instance registering to get the instance registering timestamp. This seems can be optimized. It's necessary to check whether the service-center can accept timestamp from the instance registry request body. If so, the instance registering timestamp can be generated by the microservice instance locally and passed to the service-center, sparing the time of another instance query operation. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Updated] (SCB-1306) When the request body of VertxServerRequestToHttpServletRequest is modified, the field VertxServerRequestToHttpServletRequest#inputStream should be set to null
[ https://issues.apache.org/jira/browse/SCB-1306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] YaoHaishi updated SCB-1306: --- Description: Currently if users set the request body of VertxServerRequestToHttpServletRequest, the inputStream of VertxServerRequestToHttpServletRequest isn't set to null. As a result, if VertxServerRequestToHttpServletRequest#getInputStream is called, the input stream isn't regenerated and the previous unmodified input stream is returned. (was: Currently if users modify the request body of ) > When the request body of VertxServerRequestToHttpServletRequest is modified, > the field VertxServerRequestToHttpServletRequest#inputStream should be set to > null > --- > > Key: SCB-1306 > URL: https://issues.apache.org/jira/browse/SCB-1306 > Project: Apache ServiceComb > Issue Type: Bug > Components: Java-Chassis >Affects Versions: java-chassis-1.2.1 >Reporter: wangsheng >Assignee: wangsheng >Priority: Major > Fix For: java-chassis-1.3.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Currently if users set the request body of > VertxServerRequestToHttpServletRequest, the inputStream of > VertxServerRequestToHttpServletRequest isn't set to null. As a result, if > VertxServerRequestToHttpServletRequest#getInputStream is called, the input > stream isn't regenerated and the previous unmodified input stream is returned. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Updated] (SCB-1306) When the request body of VertxServerRequestToHttpServletRequest is modified, the field VertxServerRequestToHttpServletRequest#inputStream should be set to null
[ https://issues.apache.org/jira/browse/SCB-1306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] YaoHaishi updated SCB-1306: --- Description: Currently if users modify the request body of > When the request body of VertxServerRequestToHttpServletRequest is modified, > the field VertxServerRequestToHttpServletRequest#inputStream should be set to > null > --- > > Key: SCB-1306 > URL: https://issues.apache.org/jira/browse/SCB-1306 > Project: Apache ServiceComb > Issue Type: Bug > Components: Java-Chassis >Affects Versions: java-chassis-1.2.1 >Reporter: wangsheng >Assignee: wangsheng >Priority: Major > Fix For: java-chassis-1.3.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Currently if users modify the request body of -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Updated] (SCB-1306) When the request body of VertxServerRequestToHttpServletRequest is modified, the field VertxServerRequestToHttpServletRequest#inputStream should be set to null
[ https://issues.apache.org/jira/browse/SCB-1306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] YaoHaishi updated SCB-1306: --- Summary: When the request body of VertxServerRequestToHttpServletRequest is modified, the field VertxServerRequestToHttpServletRequest#inputStream should be set to null (was: When VertxServerRequestToHttpServletRequest modified body,but get inputStream is from original body) > When the request body of VertxServerRequestToHttpServletRequest is modified, > the field VertxServerRequestToHttpServletRequest#inputStream should be set to > null > --- > > Key: SCB-1306 > URL: https://issues.apache.org/jira/browse/SCB-1306 > Project: Apache ServiceComb > Issue Type: Bug > Components: Java-Chassis >Affects Versions: java-chassis-1.2.1 >Reporter: wangsheng >Assignee: wangsheng >Priority: Major > Fix For: java-chassis-1.3.0 > > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Closed] (SCB-970) [SCB-970] 970 move long short to it-tests
[ https://issues.apache.org/jira/browse/SCB-970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] YaoHaishi closed SCB-970. - Resolution: Won't Fix I've communicated with He Yile , and he say there is no need to fix this issue anymore. Please feel free to reopen this issue if necessary. > [SCB-970] 970 move long short to it-tests > - > > Key: SCB-970 > URL: https://issues.apache.org/jira/browse/SCB-970 > Project: Apache ServiceComb > Issue Type: Bug > Components: Java-Chassis >Reporter: 何一乐 >Assignee: 何一乐 >Priority: Minor > -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Closed] (SCB-1249) VertxServerRequestToHttpServletRequest#setBodyBuffer not reset inputstream to null
[ https://issues.apache.org/jira/browse/SCB-1249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] YaoHaishi closed SCB-1249. -- Resolution: Fixed Duplicated with SCB-1306 > VertxServerRequestToHttpServletRequest#setBodyBuffer not reset inputstream to > null > -- > > Key: SCB-1249 > URL: https://issues.apache.org/jira/browse/SCB-1249 > Project: Apache ServiceComb > Issue Type: Bug > Components: Java-Chassis >Reporter: jeho0815 >Assignee: jeho0815 >Priority: Major > > setBodyBuffer not reset inputstream to null, will cause getInpustream return > old buffer > > duplicated with SCB-1306 -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Updated] (SCB-1249) VertxServerRequestToHttpServletRequest#setBodyBuffer not reset inputstream to null
[ https://issues.apache.org/jira/browse/SCB-1249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] YaoHaishi updated SCB-1249: --- Description: setBodyBuffer not reset inputstream to null, will cause getInpustream return old buffer duplicated with SCB-1306 was:setBodyBuffer not reset inputstream to null, will cause getInpustream return old buffer > VertxServerRequestToHttpServletRequest#setBodyBuffer not reset inputstream to > null > -- > > Key: SCB-1249 > URL: https://issues.apache.org/jira/browse/SCB-1249 > Project: Apache ServiceComb > Issue Type: Bug > Components: Java-Chassis >Reporter: jeho0815 >Assignee: jeho0815 >Priority: Major > > setBodyBuffer not reset inputstream to null, will cause getInpustream return > old buffer > > duplicated with SCB-1306 -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Closed] (SCB-925) Springmvc, when have defaultValue, required should be false
[ https://issues.apache.org/jira/browse/SCB-925?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] YaoHaishi closed SCB-925. - Fix Version/s: java-chassis-1.2.0 Resolution: Fixed > Springmvc, when have defaultValue, required should be false > --- > > Key: SCB-925 > URL: https://issues.apache.org/jira/browse/SCB-925 > Project: Apache ServiceComb > Issue Type: Bug > Components: Java-Chassis >Reporter: WeiChao >Assignee: WeiChao >Priority: Major > Fix For: java-chassis-1.2.0 > > -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Reopened] (SCB-925) Springmvc, when have defaultValue, required should be false
[ https://issues.apache.org/jira/browse/SCB-925?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] YaoHaishi reopened SCB-925: --- > Springmvc, when have defaultValue, required should be false > --- > > Key: SCB-925 > URL: https://issues.apache.org/jira/browse/SCB-925 > Project: Apache ServiceComb > Issue Type: Bug > Components: Java-Chassis >Reporter: WeiChao >Assignee: WeiChao >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Reopened] (SCB-1105) NoRouteToHostException, should allow all error message
[ https://issues.apache.org/jira/browse/SCB-1105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] YaoHaishi reopened SCB-1105: > NoRouteToHostException, should allow all error message > -- > > Key: SCB-1105 > URL: https://issues.apache.org/jira/browse/SCB-1105 > Project: Apache ServiceComb > Issue Type: Bug > Components: Java-Chassis >Reporter: WeiChao >Assignee: WeiChao >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > NoRouteToHostException, should allow all error message; > e.g. Host is unreachable, No route to host -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Resolved] (SCB-1275) BMI example cannot be started
[
https://issues.apache.org/jira/browse/SCB-1275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
YaoHaishi resolved SCB-1275.
Fix Version/s: java-chassis-1.2.1
Resolution: Fixed
> BMI example cannot be started
> -
>
> Key: SCB-1275
> URL: https://issues.apache.org/jira/browse/SCB-1275
> Project: Apache ServiceComb
> Issue Type: Bug
> Components: Java-Chassis
>Affects Versions: java-chassis-1.2.0
>Reporter: Willem Jiang
>Assignee: Willem Jiang
>Priority: Major
> Fix For: java-chassis-1.2.1
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> {code}
> Error creating bean with name 'standardJacksonObjectMapperBuilderCustomizer'
> defined in class path resource
> [org/springframework/boot/autoconfigure/jackson/JacksonAutoConfiguration$Jackson2ObjectMapperBuilderCustomizerConfiguration.class]:
> Unsatisfied dependency expressed through method
> 'standardJacksonObjectMapperBuilderCustomizer' parameter 1; nested exception
> is org.springframework.beans.factory.BeanCreationException: Error creating
> bean with name
> 'spring.jackson-org.springframework.boot.autoconfigure.jackson.JacksonProperties':
> Initialization of bean failed; nested exception is
> java.lang.NoClassDefFoundError:
> javax/validation/valueextraction/ValueExtractorDeclarationException
> {code}
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Resolved] (SCB-1287) refactor edge dispatcher to make them more extensible
[ https://issues.apache.org/jira/browse/SCB-1287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] YaoHaishi resolved SCB-1287. Fix Version/s: java-chassis-1.3.0 Resolution: Fixed > refactor edge dispatcher to make them more extensible > - > > Key: SCB-1287 > URL: https://issues.apache.org/jira/browse/SCB-1287 > Project: Apache ServiceComb > Issue Type: Improvement > Components: Java-Chassis >Reporter: liubao >Assignee: liubao >Priority: Major > Fix For: java-chassis-1.3.0 > > Time Spent: 20m > Remaining Estimate: 0h > > make DefaultEdgeDispatcher, URLMappedDispatcher & VertxHttpDistapacher more > extensible. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Resolved] (SCB-1291) Support rest interface method overriding by @ApiOperation
[ https://issues.apache.org/jira/browse/SCB-1291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] YaoHaishi resolved SCB-1291. Fix Version/s: java-chassis-1.3.0 Resolution: Fixed > Support rest interface method overriding by @ApiOperation > - > > Key: SCB-1291 > URL: https://issues.apache.org/jira/browse/SCB-1291 > Project: Apache ServiceComb > Issue Type: Improvement > Components: Java-Chassis >Affects Versions: java-chassis-1.2.0, java-chassis-1.2.1 >Reporter: YaoHaishi >Assignee: pengliang >Priority: Minor > Fix For: java-chassis-1.3.0 > > Time Spent: 40m > Remaining Estimate: 0h > > See details in > [https://github.com/apache/servicecomb-java-chassis/issues/1213] > Expectation: > for both @RestSchema and @RpcSchema, @ApiOperation can be used in REST > interface method overriding -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Resolved] (SCB-1305) CseAsyncRestTemplate is not support set headers
[ https://issues.apache.org/jira/browse/SCB-1305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] YaoHaishi resolved SCB-1305. Resolution: Fixed > CseAsyncRestTemplate is not support set headers > --- > > Key: SCB-1305 > URL: https://issues.apache.org/jira/browse/SCB-1305 > Project: Apache ServiceComb > Issue Type: Bug > Components: Java-Chassis >Affects Versions: java-chassis-1.2.1 >Reporter: wangsheng >Assignee: wangsheng >Priority: Major > Fix For: java-chassis-1.3.0 > > Time Spent: 1h 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Resolved] (SCB-1306) When VertxServerRequestToHttpServletRequest modified body,but get inputStream is from original body
[ https://issues.apache.org/jira/browse/SCB-1306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] YaoHaishi resolved SCB-1306. Resolution: Fixed > When VertxServerRequestToHttpServletRequest modified body,but get inputStream > is from original body > --- > > Key: SCB-1306 > URL: https://issues.apache.org/jira/browse/SCB-1306 > Project: Apache ServiceComb > Issue Type: Bug > Components: Java-Chassis >Affects Versions: java-chassis-1.2.1 >Reporter: wangsheng >Assignee: wangsheng >Priority: Major > Fix For: java-chassis-1.3.0 > > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Resolved] (SCB-1308) Improve instance isolation mechanism
[ https://issues.apache.org/jira/browse/SCB-1308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] YaoHaishi resolved SCB-1308. Fix Version/s: java-chassis-1.3.0 Resolution: Fixed > Improve instance isolation mechanism > > > Key: SCB-1308 > URL: https://issues.apache.org/jira/browse/SCB-1308 > Project: Apache ServiceComb > Issue Type: Improvement > Components: Java-Chassis >Affects Versions: java-chassis-1.2.1 >Reporter: YaoHaishi >Assignee: YaoHaishi >Priority: Major > Fix For: java-chassis-1.3.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Currently, when the error instance has been isolated for as long as > singleTestTime, it can be tried until the lastVisitTime is refreshed. But if > the error instance is still in timeout error status, it takes too long time > to get the invocation result and get the lastVisitTime refreshed. And before > the lastVisitTime is refreshed, there may be too many requests routed to the > error instance, causing massive invocation errors. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Updated] (SCB-1392) If Multiple java bean param types are given the same name by using @ApiModel, there should be error tips in microservice's booting log
[ https://issues.apache.org/jira/browse/SCB-1392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] YaoHaishi updated SCB-1392: --- Description: Currently, if different java bean param types are given the same param type name by @ApiModel annotation, there is no error thrown and the microservice instance can boot up and process requests, which may cause confusing runtime error. The microservice schema generating mechanism should check the duplicated param types and warn the users of them. was: Multiple classes have the same apimodle, and class will occur when generating schemaids. Join the check at startup and throw an exception when this problem occurs. > If Multiple java bean param types are given the same name by using @ApiModel, > there should be error tips in microservice's booting log > -- > > Key: SCB-1392 > URL: https://issues.apache.org/jira/browse/SCB-1392 > Project: Apache ServiceComb > Issue Type: Improvement > Components: Java-Chassis >Affects Versions: java-chassis-1.2.1 >Reporter: YongLiang Guo >Assignee: YongLiang Guo >Priority: Major > Fix For: java-chassis-1.3.0 > > Time Spent: 1h > Remaining Estimate: 0h > > Currently, if different java bean param types are given the same param type > name by @ApiModel annotation, there is no error thrown and the microservice > instance can boot up and process requests, which may cause confusing runtime > error. > The microservice schema generating mechanism should check the duplicated > param types and warn the users of them. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Updated] (SCB-1392) If Multiple java bean param types are given the same name by using @ApiModel, there should be error tips in microservice's booting log
[ https://issues.apache.org/jira/browse/SCB-1392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] YaoHaishi updated SCB-1392: --- Summary: If Multiple java bean param types are given the same name by using @ApiModel, there should be error tips in microservice's booting log (was: Multiple classes have the same apimodle, and class will occur when generating schemaids.) > If Multiple java bean param types are given the same name by using @ApiModel, > there should be error tips in microservice's booting log > -- > > Key: SCB-1392 > URL: https://issues.apache.org/jira/browse/SCB-1392 > Project: Apache ServiceComb > Issue Type: Improvement > Components: Java-Chassis >Affects Versions: java-chassis-1.2.1 >Reporter: YongLiang Guo >Assignee: YongLiang Guo >Priority: Major > Fix For: java-chassis-1.3.0 > > Time Spent: 1h > Remaining Estimate: 0h > > Multiple classes have the same apimodle, and class will occur when generating > schemaids. Join the check at startup and throw an exception when this problem > occurs. > -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Resolved] (SCB-1392) Multiple classes have the same apimodle, and class will occur when generating schemaids.
[ https://issues.apache.org/jira/browse/SCB-1392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] YaoHaishi resolved SCB-1392. Resolution: Fixed > Multiple classes have the same apimodle, and class will occur when generating > schemaids. > > > Key: SCB-1392 > URL: https://issues.apache.org/jira/browse/SCB-1392 > Project: Apache ServiceComb > Issue Type: Improvement > Components: Java-Chassis >Affects Versions: java-chassis-1.2.1 >Reporter: YongLiang Guo >Assignee: YongLiang Guo >Priority: Major > Fix For: java-chassis-1.3.0 > > Time Spent: 1h > Remaining Estimate: 0h > > Multiple classes have the same apimodle, and class will occur when generating > schemaids. Join the check at startup and throw an exception when this problem > occurs. > -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Updated] (SCB-1405) support maxWaitQueueSize setting in RestTransportClient
[ https://issues.apache.org/jira/browse/SCB-1405?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] YaoHaishi updated SCB-1405: --- Fix Version/s: java-chassis-1.3.0 > 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 > Fix For: java-chassis-1.3.0 > > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Closed] (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 ] YaoHaishi closed SCB-1408. -- No pull request related. Close this issue. > 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 (v8.3.2#803003)
[jira] [Resolved] (SCB-1437) Upgrading third party dependency versions
[ https://issues.apache.org/jira/browse/SCB-1437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] YaoHaishi resolved SCB-1437. Resolution: Fixed > 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 >Priority: Major > Fix For: java-chassis-1.3.0 > > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Resolved] (SCB-1450) Microservice instance may get stuck when watch connection to sc is recovered and pulling instance action is executed in eventloop thread
[ https://issues.apache.org/jira/browse/SCB-1450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] YaoHaishi resolved SCB-1450. Resolution: Fixed > Microservice instance may get stuck when watch connection to sc is recovered > and pulling instance action is executed in eventloop thread > > > Key: SCB-1450 > URL: https://issues.apache.org/jira/browse/SCB-1450 > Project: Apache ServiceComb > Issue Type: Improvement > Components: Java-Chassis >Reporter: Liu HuaiZhou >Priority: Major > Fix For: java-chassis-1.3.0 > > Time Spent: 20m > Remaining Estimate: 0h > > If you set property of servicecomb.service.registry.instance.watch to true > and then set the peoperty of > servicecomb.service.registry.client.eventLoopPoolSize to the smaller value as > you can ,like 2. Unluckily, service center crashed..The following poor > scenario you may fall in: > 1 You had been informed while Service Center recovered a few minutes > later.It is so sad ,you can't get micro-service instance information from the > Service Center. > 2 You can never to shutdown your micro-service instance gracefully, > Following are the dump logs: > [ WARN ] [2019-06-11 22:32:38.417] [178.42.0.21] > [vertx-blocked-thread-checker] > [io.vertx.core.impl.BlockedThreadChecker$1.run(BlockedThreadChecker.java:55)] > - Thread Thread[registry-vert.x-eventloop-thread-2,5,main] has been blocked > for 20417526 ms, time limit is 2000 ms > io.vertx.core.VertxException: Thread blocked > at sun.misc.Unsafe.park(Native Method) ~[?:1.8.0_212] > at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) > ~[?:1.8.0_212] > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836) > ~[?:1.8.0_212] > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997) > ~[?:1.8.0_212] > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304) > ~[?:1.8.0_212] > at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231) > ~[?:1.8.0_212] > at > org.apache.servicecomb.serviceregistry.client.http.ServiceRegistryClientImpl.findServiceInstances(ServiceRegistryClientImpl.java:739) > ~[service-registry-1.0.0.B003.H69.jar:1.0.0.B003.H69] > at > org.apache.servicecomb.serviceregistry.registry.AbstractServiceRegistry.findServiceInstances(AbstractServiceRegistry.java:236) > ~[service-registry-1.0.0.B003.H69.jar:1.0.0.B003.H69] > at > org.apache.servicecomb.serviceregistry.RegistryUtils.findServiceInstances(RegistryUtils.java:231) > ~[service-registry-1.0.0.B003.H69.jar:1.0.0.B003.H69] > at > org.apache.servicecomb.serviceregistry.consumer.MicroserviceVersions.pullInstances(MicroserviceVersions.java:138) > ~[service-registry-1.0.0.B003.H69.jar:1.0.0.B003.H69] > at > org.apache.servicecomb.serviceregistry.consumer.MicroserviceVersions.submitPull(MicroserviceVersions.java:130) > ~[service-registry-1.0.0.B003.H69.jar:1.0.0.B003.H69] > at > org.apache.servicecomb.serviceregistry.consumer.MicroserviceManager.refreshInstances(MicroserviceManager.java:99) > ~[service-registry-1.0.0.B003.H69.jar:1.0.0.B003.H69 -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Resolved] (SCB-1457) delete no use code in ProtobufManager
[ https://issues.apache.org/jira/browse/SCB-1457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] YaoHaishi resolved SCB-1457. Resolution: Fixed > delete no use code in ProtobufManager > - > > Key: SCB-1457 > URL: https://issues.apache.org/jira/browse/SCB-1457 > Project: Apache ServiceComb > Issue Type: Improvement >Affects Versions: java-chassis-1.2.1 >Reporter: YongLiang Guo >Assignee: YongLiang Guo >Priority: Trivial > Fix For: java-chassis-1.3.0 > > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Resolved] (SCB-1451) Printing the service information on the log
[ https://issues.apache.org/jira/browse/SCB-1451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] YaoHaishi resolved SCB-1451. Resolution: Fixed > Printing the service information on the log > --- > > Key: SCB-1451 > URL: https://issues.apache.org/jira/browse/SCB-1451 > Project: Apache ServiceComb > Issue Type: Improvement > Components: Java-Chassis >Reporter: ZihangJiao >Priority: Major > Fix For: java-chassis-1.3.0 > > Time Spent: 40m > Remaining Estimate: 0h > > Some feedbacks from users declared that it is hard for them to trace the > service information when the initilization of the service failed, and they > would be willing to see all those information clearly in the log – actually, > they are always in there, but those information are not sticked together, > which may consume users a large amount of time to find them. > To make those information more eye-grabing and easy-finding, those > information are put together and printed on the log by this improvement, > right after the message"ServiceComb is ready." > No matter the initialization of the service succeeded or not, the information > below will be printed: > the sc/cc/ds address, AppID, ServiceName,Version, Environment, ServiceID, > InstanceID > User can also search " Service information" or " Service information is shown > below:" on the log to track the position of these information -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Resolved] (SCB-1318) There may be memory leak in RSAProviderTokenManager
[
https://issues.apache.org/jira/browse/SCB-1318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
YaoHaishi resolved SCB-1318.
Fix Version/s: java-chassis-1.3.0
Resolution: Fixed
> There may be memory leak in RSAProviderTokenManager
> ---
>
> Key: SCB-1318
> URL: https://issues.apache.org/jira/browse/SCB-1318
> Project: Apache ServiceComb
> Issue Type: Bug
> Components: Java-Chassis
>Affects Versions: java-chassis-1.0.0, java-chassis-1.1.0,
> java-chassis-1.2.0, java-chassis-1.2.1
>Reporter: YaoHaishi
>Assignee: YaoHaishi
>Priority: Major
> Fix For: java-chassis-1.3.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> For
> {code:java}
> org.apache.servicecomb.authentication.provider.RSAProviderTokenManager#validatedToken
> {code}
> RsaTokens are added into this set, but seems never removed.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Reopened] (SCB-1392) Multiple classes have the same apimodle, and class will occur when generating schemaids.
[ https://issues.apache.org/jira/browse/SCB-1392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] YaoHaishi reopened SCB-1392: > Multiple classes have the same apimodle, and class will occur when generating > schemaids. > > > Key: SCB-1392 > URL: https://issues.apache.org/jira/browse/SCB-1392 > Project: Apache ServiceComb > Issue Type: Improvement > Components: Java-Chassis >Affects Versions: java-chassis-1.2.1 >Reporter: YongLiang Guo >Priority: Major > Fix For: java-chassis-1.3.0 > > > Multiple classes have the same apimodle, and class will occur when generating > schemaids. Join the check at startup and throw an exception when this problem > occurs. > -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Created] (SCB-1354) Fix static code check problems in ServiceComb-Java-Chassis
YaoHaishi created SCB-1354: -- Summary: Fix static code check problems in ServiceComb-Java-Chassis Key: SCB-1354 URL: https://issues.apache.org/jira/browse/SCB-1354 Project: Apache ServiceComb Issue Type: Improvement Components: Java-Chassis Reporter: YaoHaishi Assignee: YaoHaishi There a several problems pointed out by static code checks in the source code of ServiceComb-Java-Chassis. Since there are too many files involved, this issue should be fixed after the weak-type work getting done. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (SCB-1318) There may be memory leak in RSAProviderTokenManager
YaoHaishi created SCB-1318:
--
Summary: There may be memory leak in RSAProviderTokenManager
Key: SCB-1318
URL: https://issues.apache.org/jira/browse/SCB-1318
Project: Apache ServiceComb
Issue Type: Bug
Components: Java-Chassis
Affects Versions: java-chassis-1.2.1, java-chassis-1.2.0,
java-chassis-1.1.0, java-chassis-1.0.0
Reporter: YaoHaishi
Assignee: YaoHaishi
For
{code:java}
org.apache.servicecomb.authentication.provider.RSAProviderTokenManager#validatedToken
{code}
RsaTokens are added into this set, but seems never removed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (SCB-1305) CseAsyncRestTemplate is not support set headers
[ https://issues.apache.org/jira/browse/SCB-1305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] YaoHaishi reassigned SCB-1305: -- Assignee: YaoHaishi (was: Wang Sheng) > CseAsyncRestTemplate is not support set headers > --- > > Key: SCB-1305 > URL: https://issues.apache.org/jira/browse/SCB-1305 > Project: Apache ServiceComb > Issue Type: Bug > Components: Java-Chassis >Affects Versions: java-chassis-1.2.1 >Reporter: wangsheng >Assignee: YaoHaishi >Priority: Major > Fix For: java-chassis-1.3.0 > > Time Spent: 1h 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (SCB-1305) CseAsyncRestTemplate is not support set headers
[ https://issues.apache.org/jira/browse/SCB-1305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] YaoHaishi reassigned SCB-1305: -- Assignee: Wang Sheng > CseAsyncRestTemplate is not support set headers > --- > > Key: SCB-1305 > URL: https://issues.apache.org/jira/browse/SCB-1305 > Project: Apache ServiceComb > Issue Type: Bug > Components: Java-Chassis >Affects Versions: java-chassis-1.2.1 >Reporter: wangsheng >Assignee: Wang Sheng >Priority: Major > Fix For: java-chassis-1.3.0 > > Time Spent: 1h 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (SCB-1308) Improve instance isolation mechanism
YaoHaishi created SCB-1308: -- Summary: Improve instance isolation mechanism Key: SCB-1308 URL: https://issues.apache.org/jira/browse/SCB-1308 Project: Apache ServiceComb Issue Type: Improvement Components: Java-Chassis Affects Versions: java-chassis-1.2.1 Reporter: YaoHaishi Assignee: YaoHaishi Currently, when the error instance has been isolated for as long as singleTestTime, it can be tried until the lastVisitTime is refreshed. But if the error instance is still in timeout error status, it takes too long time to get the invocation result and get the lastVisitTime refreshed. And before the lastVisitTime is refreshed, there may be too many requests routed to the error instance, causing massive invocation errors. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (SCB-1278) ServiceComb related headers are not exposed to 3rd party services by default
[ https://issues.apache.org/jira/browse/SCB-1278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] YaoHaishi resolved SCB-1278. Resolution: Fixed Fix Version/s: java-chassis-1.3.0 > ServiceComb related headers are not exposed to 3rd party services by default > > > Key: SCB-1278 > URL: https://issues.apache.org/jira/browse/SCB-1278 > Project: Apache ServiceComb > Issue Type: Improvement >Reporter: YaoHaishi >Assignee: YaoHaishi >Priority: Major > Fix For: java-chassis-1.3.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Currently, ServiceComb headers such as x-cse-target-microservice, > x-cse-context are sent to 3rd party services and users cannot stop this > behavior. > This behavior should be disabled by default. And a certain way should be > provided to let users enable it. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (SCB-1278) ServiceComb related headers are not exposed to 3rd party services by default
[ https://issues.apache.org/jira/browse/SCB-1278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16841868#comment-16841868 ] YaoHaishi edited comment on SCB-1278 at 6/2/19 10:16 AM: - The specific solution is that: 1. add a property in org.apache.servicecomb.serviceregistry.api.registry.Microservice to check whether it is a 3rd party microservice. 2. filter out x-cse* headers added by ServiceComb-Java-Chassis in 3rd party client requests by default. And add a config item to allow users to disable this feature. was (Author: yaohaishi): The specific solution is that: 1. add a property in org.apache.servicecomb.serviceregistry.api.registry.MicroserviceInstance to check whether a certain invocation is a 3rd party invocation. 2. filter out x-cse* headers in 3rd party client requests by default. And add a config item to allow users to disable this feature. 3. Add a regex config to allow users specify which kind of request headers should be filtered out in 3rd party invocations > ServiceComb related headers are not exposed to 3rd party services by default > > > Key: SCB-1278 > URL: https://issues.apache.org/jira/browse/SCB-1278 > Project: Apache ServiceComb > Issue Type: Improvement >Reporter: YaoHaishi >Assignee: YaoHaishi >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > Currently, ServiceComb headers such as x-cse-target-microservice, > x-cse-context are sent to 3rd party services and users cannot stop this > behavior. > This behavior should be disabled by default. And a certain way should be > provided to let users enable it. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (SCB-1304) FallbackPolicy interface support returns an exception
[ https://issues.apache.org/jira/browse/SCB-1304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] YaoHaishi reassigned SCB-1304: -- Assignee: pengliang > FallbackPolicy interface support returns an exception > - > > Key: SCB-1304 > URL: https://issues.apache.org/jira/browse/SCB-1304 > Project: Apache ServiceComb > Issue Type: Bug > Components: Java-Chassis >Reporter: pengliang >Assignee: pengliang >Priority: Major > Fix For: java-chassis-1.3.0 > > > *WHY* > The service downgrade function opens the > org.apache.servicecomb.bizkeeper.FallbackPolicy interface for users to extend > the downgrade function, but the getFallbackResponse method of the interface > only accepts Invocation, and does not receive exception information, causing > the user to extend the interface to generate a downgrade response without > knowing that the request failed. Due to what kind of abnormality, it may > cause problems such as the retry mechanism does not take effect. > *WHAT* > Satisfying conditions will definitely happen > *HOW* > org.apache.servicecomb.bizkeeper.FallbackPolicyManager.getFallbackResponse(String > type, Throwable error, Invocation invocation) Change the call to the > FallbackPolicy interface, pass in the Throwable > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (SCB-1297) Print warn log about config resolving failure while fetching config from Spring Environment
YaoHaishi created SCB-1297: -- Summary: Print warn log about config resolving failure while fetching config from Spring Environment Key: SCB-1297 URL: https://issues.apache.org/jira/browse/SCB-1297 Project: Apache ServiceComb Issue Type: Improvement Components: Java-Chassis Affects Versions: java-chassis-1.2.1 Reporter: YaoHaishi Assignee: YaoHaishi Currently the ConfigurationSpringInitializer is deployed to get the Environment from Spring. All of the config items in the Environment are fetched with the value resolved from the Environment. These config items are later inject into the configurations of ServiceComb-Java-Chassis. If there are some environment items with irregular value, the Spring Environment may fail to resolve the config item and throw an Exception, even though that environment items are not relative to the microservice instances. It's necessary to provide a switch to disable the Exception in this situation. If users don't want the boot up process to be interrupted by such failure, they can enable the suppression feature, then all of such Exceptions are caught and only warn logs are printed to show which config keys are failed to be resolved. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (SCB-1291) Support rest interface method overriding by @ApiOperation
[ https://issues.apache.org/jira/browse/SCB-1291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] YaoHaishi updated SCB-1291: --- Description: See details in [https://github.com/apache/servicecomb-java-chassis/issues/1213] Expectation: for both @RestSchema and @RpcSchema, @ApiOperation can be used in REST interface method overriding was:See details in https://github.com/apache/servicecomb-java-chassis/issues/1213 > Support rest interface method overriding by @ApiOperation > - > > Key: SCB-1291 > URL: https://issues.apache.org/jira/browse/SCB-1291 > Project: Apache ServiceComb > Issue Type: Improvement > Components: Java-Chassis >Affects Versions: java-chassis-1.2.0, java-chassis-1.2.1 >Reporter: YaoHaishi >Assignee: YaoHaishi >Priority: Minor > > See details in > [https://github.com/apache/servicecomb-java-chassis/issues/1213] > Expectation: > for both @RestSchema and @RpcSchema, @ApiOperation can be used in REST > interface method overriding -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (SCB-1291) Support rest interface method overriding by @ApiOperation
YaoHaishi created SCB-1291: -- Summary: Support rest interface method overriding by @ApiOperation Key: SCB-1291 URL: https://issues.apache.org/jira/browse/SCB-1291 Project: Apache ServiceComb Issue Type: Improvement Components: Java-Chassis Affects Versions: java-chassis-1.2.0, java-chassis-1.2.1 Reporter: YaoHaishi Assignee: YaoHaishi See details in https://github.com/apache/servicecomb-java-chassis/issues/1213 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (SCB-1289) When sending request by RestTemplate without query param, a segment "?null" is appended to the tail of request url
YaoHaishi created SCB-1289: -- Summary: When sending request by RestTemplate without query param, a segment "?null" is appended to the tail of request url Key: SCB-1289 URL: https://issues.apache.org/jira/browse/SCB-1289 Project: Apache ServiceComb Issue Type: Bug Reporter: YaoHaishi Assignee: YaoHaishi See details in https://github.com/apache/servicecomb-java-chassis/issues/1215 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (SCB-1288) Responses are sent before all of the HttpServerFilters are executed in file downloading situation
YaoHaishi created SCB-1288:
--
Summary: Responses are sent before all of the HttpServerFilters
are executed in file downloading situation
Key: SCB-1288
URL: https://issues.apache.org/jira/browse/SCB-1288
Project: Apache ServiceComb
Issue Type: Bug
Reporter: YaoHaishi
Assignee: YaoHaishi
See Github issue
[https://github.com/apache/servicecomb-java-chassis/issues/1201]
In the file downloading situation, the body of responses are sent in method
org.apache.servicecomb.common.rest.filter.inner.ServerRestArgsFilter#beforeSendResponseAsync
{code:java}
Object body = response.getResult();
if (response.isFailed()) {
body = ((InvocationException) body).getErrorData();
}
if (Part.class.isInstance(body)) {
// here the body is sent
return responseEx.sendPart((Part) body);
}
{code}
If there are HttpServerFilters executed after ServerRestArgsFilter, it's too
late for them to modify the response because the response has already been sent.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (SCB-1278) ServiceComb related headers are not exposed to 3rd party services by default
[ https://issues.apache.org/jira/browse/SCB-1278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16841868#comment-16841868 ] YaoHaishi edited comment on SCB-1278 at 5/17/19 3:44 AM: - The specific solution is that: 1. add a property in org.apache.servicecomb.serviceregistry.api.registry.MicroserviceInstance to check whether a certain invocation is a 3rd party invocation. 2. filter out x-cse* headers in 3rd party client requests by default. And add a config item to allow users to disable this feature. 3. Add a regex config to allow users specify which kind of request headers should be filtered out in 3rd party invocations was (Author: yaohaishi): The specific solution is that: 1. add a property in org.apache.servicecomb.serviceregistry.api.registry.MicroserviceInstance to check whether a certain invocation is a 3rd party invocation. 2. filter out x-cse* headers in client requests by default. And add a config item to allow users disable this feature. 3. Add a regex config to allow users specify which kind of request headers should be filtered out in 3rd party invocation > ServiceComb related headers are not exposed to 3rd party services by default > > > Key: SCB-1278 > URL: https://issues.apache.org/jira/browse/SCB-1278 > Project: Apache ServiceComb > Issue Type: Improvement >Reporter: YaoHaishi >Assignee: YaoHaishi >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Currently, ServiceComb headers such as x-cse-target-microservice, > x-cse-context are sent to 3rd party services and users cannot stop this > behavior. > This behavior should be disabled by default. And a certain way should be > provided to let users enable it. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SCB-1278) ServiceComb related headers are not exposed to 3rd party services by default
[ https://issues.apache.org/jira/browse/SCB-1278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16841868#comment-16841868 ] YaoHaishi commented on SCB-1278: The specific solution is that: 1. add a property in org.apache.servicecomb.serviceregistry.api.registry.MicroserviceInstance to check whether a certain invocation is a 3rd party invocation. 2. filter out x-cse* headers in client requests by default. And add a config item to allow users disable this feature. 3. Add a regex config to allow users specify which kind of request headers should be filtered out in 3rd party invocation > ServiceComb related headers are not exposed to 3rd party services by default > > > Key: SCB-1278 > URL: https://issues.apache.org/jira/browse/SCB-1278 > Project: Apache ServiceComb > Issue Type: Improvement >Reporter: YaoHaishi >Assignee: YaoHaishi >Priority: Major > > Currently, ServiceComb headers such as x-cse-target-microservice, > x-cse-context are sent to 3rd party services and users cannot stop this > behavior. > This behavior should be disabled by default. And a certain way should be > provided to let users enable it. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (SCB-1280) Fix problem with nested generic list param like List>
[ https://issues.apache.org/jira/browse/SCB-1280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] YaoHaishi resolved SCB-1280. Resolution: Fixed Fix Version/s: java-chassis-1.2.1 > Fix problem with nested generic list param like List> > -- > > Key: SCB-1280 > URL: https://issues.apache.org/jira/browse/SCB-1280 > Project: Apache ServiceComb > Issue Type: Bug >Reporter: YaoHaishi >Assignee: YaoHaishi >Priority: Major > Fix For: java-chassis-1.2.1 > > Time Spent: 20m > Remaining Estimate: 0h > > The nested List params like List> are supporeted by previous > version of ServiceComb-Java-Chassis. But now they will cause exception while > service booting up. > Should fix this problem. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (SCB-1280) Fix problem with nested generic list param like List>
YaoHaishi created SCB-1280: -- Summary: Fix problem with nested generic list param like List> Key: SCB-1280 URL: https://issues.apache.org/jira/browse/SCB-1280 Project: Apache ServiceComb Issue Type: Bug Reporter: YaoHaishi Assignee: YaoHaishi The nested List params like List> are supporeted by previous version of ServiceComb-Java-Chassis. But now they will cause exception while service booting up. Should fix this problem. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (SCB-1278) ServiceComb related headers are not exposed to 3rd party services by default
YaoHaishi created SCB-1278: -- Summary: ServiceComb related headers are not exposed to 3rd party services by default Key: SCB-1278 URL: https://issues.apache.org/jira/browse/SCB-1278 Project: Apache ServiceComb Issue Type: Improvement Reporter: YaoHaishi Assignee: YaoHaishi Currently, ServiceComb headers such as x-cse-target-microservice, x-cse-context are sent to 3rd party services and users cannot stop this behavior. This behavior should be disabled by default. And a certain way should be provided to let users enable it. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SCB-1265) Add doc about maxHeaderSize configuration
[
https://issues.apache.org/jira/browse/SCB-1265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16827851#comment-16827851
]
YaoHaishi commented on SCB-1265:
The description of the config items below is also added:
{code}
servicecomb.rest.server.compression
servicecomb.rest.client.connection.compression
{code}
> Add doc about maxHeaderSize configuration
> -
>
> Key: SCB-1265
> URL: https://issues.apache.org/jira/browse/SCB-1265
> Project: Apache ServiceComb
> Issue Type: Improvement
>Reporter: YaoHaishi
>Assignee: YaoHaishi
>Priority: Minor
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Currently ServiceComb-Java-Chassis provides configuration items to limit the
> max header size on both server side and client side, but there is no doc to
> describe them.
> The related doc should be added.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (SCB-1265) Add doc about maxHeaderSize configuration
[ https://issues.apache.org/jira/browse/SCB-1265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] YaoHaishi resolved SCB-1265. Resolution: Fixed Fix Version/s: java-chassis-1.3.0 > Add doc about maxHeaderSize configuration > - > > Key: SCB-1265 > URL: https://issues.apache.org/jira/browse/SCB-1265 > Project: Apache ServiceComb > Issue Type: Improvement >Reporter: YaoHaishi >Assignee: YaoHaishi >Priority: Minor > Fix For: java-chassis-1.3.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Currently ServiceComb-Java-Chassis provides configuration items to limit the > max header size on both server side and client side, but there is no doc to > describe them. > The related doc should be added. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (SCB-1271) Provide a new access log item to print client port
YaoHaishi created SCB-1271: -- Summary: Provide a new access log item to print client port Key: SCB-1271 URL: https://issues.apache.org/jira/browse/SCB-1271 Project: Apache ServiceComb Issue Type: Improvement Reporter: YaoHaishi Assignee: YaoHaishi Currently there is an access log item to print the address of client side(%h), but there is no item about the port of client side. An access log item should be provided later to print the port of client side. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (SCB-1271) Provide a new access log item to print client port
[ https://issues.apache.org/jira/browse/SCB-1271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] YaoHaishi updated SCB-1271: --- Priority: Minor (was: Major) > Provide a new access log item to print client port > -- > > Key: SCB-1271 > URL: https://issues.apache.org/jira/browse/SCB-1271 > Project: Apache ServiceComb > Issue Type: Improvement >Reporter: YaoHaishi >Assignee: YaoHaishi >Priority: Minor > > Currently there is an access log item to print the address of client > side(%h), but there is no item about the port of client side. > An access log item should be provided later to print the port of client side. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (SCB-1263) forward request in edge should not inherit cse-context
[ https://issues.apache.org/jira/browse/SCB-1263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] YaoHaishi resolved SCB-1263. Resolution: Fixed > forward request in edge should not inherit cse-context > -- > > Key: SCB-1263 > URL: https://issues.apache.org/jira/browse/SCB-1263 > Project: Apache ServiceComb > Issue Type: Task > Components: Java-Chassis >Reporter: wujimin >Assignee: YaoHaishi >Priority: Major > Fix For: java-chassis-1.3.0 > > Time Spent: 20m > Remaining Estimate: 0h > > to avoid attacker to falsify the credentials of other users -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (SCB-1265) Add doc about maxHeaderSize configuration
YaoHaishi created SCB-1265: -- Summary: Add doc about maxHeaderSize configuration Key: SCB-1265 URL: https://issues.apache.org/jira/browse/SCB-1265 Project: Apache ServiceComb Issue Type: Improvement Reporter: YaoHaishi Assignee: YaoHaishi Currently ServiceComb-Java-Chassis provides configuration items to limit the max header size on both server side and client side, but there is no doc to describe them. The related doc should be added. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SCB-1265) Add doc about maxHeaderSize configuration
[ https://issues.apache.org/jira/browse/SCB-1265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16823861#comment-16823861 ] YaoHaishi commented on SCB-1265: Docs about config item "servicecomb.rest.server.maxInitialLineLength" should be added, as well. > Add doc about maxHeaderSize configuration > - > > Key: SCB-1265 > URL: https://issues.apache.org/jira/browse/SCB-1265 > Project: Apache ServiceComb > Issue Type: Improvement >Reporter: YaoHaishi >Assignee: YaoHaishi >Priority: Minor > > Currently ServiceComb-Java-Chassis provides configuration items to limit the > max header size on both server side and client side, but there is no doc to > describe them. > The related doc should be added. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SCB-1263) forward request in edge should not inherit cse-context
[ https://issues.apache.org/jira/browse/SCB-1263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16822959#comment-16822959 ] YaoHaishi commented on SCB-1263: PR has been created, EdgeService does not inherit InvocationContext from outer request by default. And a commit has been added to show how to inherit context by custom HttpServerFilter if users want such feature. > forward request in edge should not inherit cse-context > -- > > Key: SCB-1263 > URL: https://issues.apache.org/jira/browse/SCB-1263 > Project: Apache ServiceComb > Issue Type: Task > Components: Java-Chassis >Reporter: wujimin >Assignee: YaoHaishi >Priority: Major > Fix For: java-chassis-1.3.0 > > Time Spent: 10m > Remaining Estimate: 0h > > to avoid attacker to falsify the credentials of other users -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SCB-1263) forward request in edge should not inherit cse-context
[ https://issues.apache.org/jira/browse/SCB-1263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16822463#comment-16822463 ] YaoHaishi commented on SCB-1263: Hi, how about adding a configuration to determine whether to inherit InvocationContext? Maybe we can add a config item "servicecomb.http.dispatcher.edge.inheritInvocationContext" and its default value is false. Only if it's set to true, the EdgeService inherit x-cse-context from outside requests. > forward request in edge should not inherit cse-context > -- > > Key: SCB-1263 > URL: https://issues.apache.org/jira/browse/SCB-1263 > Project: Apache ServiceComb > Issue Type: Task > Components: Java-Chassis >Reporter: wujimin >Assignee: YaoHaishi >Priority: Major > Fix For: java-chassis-1.3.0 > > > to avoid attacker to falsify the credentials of other users -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SCB-1263) forward request in edge should not inherit cse-context
[ https://issues.apache.org/jira/browse/SCB-1263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16821813#comment-16821813 ] YaoHaishi commented on SCB-1263: Agree with wujimin. Since the EdgeService is facing the request from outside, there is a high risk to allow callers outside to inject value into InvocationContext. If users want to receive InvocationContext in such situation, they can easily achieve it by extending a HttpServerFilter. > forward request in edge should not inherit cse-context > -- > > Key: SCB-1263 > URL: https://issues.apache.org/jira/browse/SCB-1263 > Project: Apache ServiceComb > Issue Type: Task > Components: Java-Chassis >Reporter: wujimin >Assignee: YaoHaishi >Priority: Major > Fix For: java-chassis-1.3.0 > > > to avoid attacker to falsify the credentials of other users -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (SCB-1263) forward request in edge should not inherit cse-context
[ https://issues.apache.org/jira/browse/SCB-1263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] YaoHaishi reassigned SCB-1263: -- Assignee: YaoHaishi > forward request in edge should not inherit cse-context > -- > > Key: SCB-1263 > URL: https://issues.apache.org/jira/browse/SCB-1263 > Project: Apache ServiceComb > Issue Type: Task > Components: Java-Chassis >Reporter: wujimin >Assignee: YaoHaishi >Priority: Major > Fix For: java-chassis-1.3.0 > > > to avoid attacker to falsify the credentials of other users -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (SCB-1253) Adjust the priority of FailureHandler of the dispatchers
[ https://issues.apache.org/jira/browse/SCB-1253?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] YaoHaishi resolved SCB-1253. Resolution: Fixed Fix Version/s: java-chassis-1.3.0 > Adjust the priority of FailureHandler of the dispatchers > > > Key: SCB-1253 > URL: https://issues.apache.org/jira/browse/SCB-1253 > Project: Apache ServiceComb > Issue Type: Bug >Reporter: YaoHaishi >Assignee: YaoHaishi >Priority: Major > Fix For: java-chassis-1.3.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Currently, the GlobalRestFailureHandler has the highest priority. As a > result, when RoutingContext#fail is called, the failed RoutingContext is > always processed by GlobalRestFailureHandler and other failureHandlers take > no effect. > The GlobalRestFailureHandler should have the lowest priority and works only > when there is no other failureHandler handle the failed RoutingContext. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (SCB-1253) Adjust the priority of FailureHandler of the dispatchers
YaoHaishi created SCB-1253: -- Summary: Adjust the priority of FailureHandler of the dispatchers Key: SCB-1253 URL: https://issues.apache.org/jira/browse/SCB-1253 Project: Apache ServiceComb Issue Type: Bug Reporter: YaoHaishi Assignee: YaoHaishi Currently, the GlobalRestFailureHandler has the highest priority. As a result, when RoutingContext#fail is called, the failed RoutingContext is always processed by GlobalRestFailureHandler and other failureHandlers take no effect. The GlobalRestFailureHandler should have the lowest priority and works only when there is no other failureHandler handle the failed RoutingContext. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (SCB-1184) upgrade swagger from 1.5.12 to 1.5.22 to support convert swagger to html
[
https://issues.apache.org/jira/browse/SCB-1184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
YaoHaishi updated SCB-1184:
---
Description:
Before this issue, if a REST operation is defined as below, the response type
in schema is org.springframework.http.ResponseEntity instead of the generic
type of ResponseEntity:
{code:java}
@Path("/responseEntityString")
@GET
public CompletableFuture> responseEntityString()
{code}
The response type of operation "responseEntityString" is expected to be String,
but Java-Chassis takes the ResponseEntity as response data type in schema.
This issue fixed this problem.
> upgrade swagger from 1.5.12 to 1.5.22 to support convert swagger to html
>
>
> Key: SCB-1184
> URL: https://issues.apache.org/jira/browse/SCB-1184
> Project: Apache ServiceComb
> Issue Type: Task
> Components: Java-Chassis
>Reporter: wujimin
>Assignee: wujimin
>Priority: Major
> Fix For: java-chassis-1.2.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Before this issue, if a REST operation is defined as below, the response type
> in schema is org.springframework.http.ResponseEntity instead of the generic
> type of ResponseEntity:
> {code:java}
> @Path("/responseEntityString")
> @GET
> public CompletableFuture> responseEntityString()
> {code}
> The response type of operation "responseEntityString" is expected to be
> String, but Java-Chassis takes the ResponseEntity as response data type in
> schema.
> This issue fixed this problem.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (SCB-1135) Add client max receive header size config item
[ https://issues.apache.org/jira/browse/SCB-1135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] YaoHaishi updated SCB-1135: --- Fix Version/s: java-chassis-1.2.0 > Add client max receive header size config item > -- > > Key: SCB-1135 > URL: https://issues.apache.org/jira/browse/SCB-1135 > Project: Apache ServiceComb > Issue Type: Improvement > Components: Java-Chassis >Affects Versions: java-chassis-1.2.0 >Reporter: YaoHaishi >Assignee: YaoHaishi >Priority: Major > Fix For: java-chassis-1.2.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Currently the max header size that consumer can receive is always 8192 bytes, > which is the default value given by Vert.x. > We need to provide a config item to allow users to change it. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (SCB-1210) improve the average latency precision of the metrics log
[ https://issues.apache.org/jira/browse/SCB-1210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] YaoHaishi resolved SCB-1210. Resolution: Fixed > improve the average latency precision of the metrics log > > > Key: SCB-1210 > URL: https://issues.apache.org/jira/browse/SCB-1210 > Project: Apache ServiceComb > Issue Type: Improvement >Reporter: YaoHaishi >Assignee: YaoHaishi >Priority: Major > Fix For: java-chassis-1.2.0 > > Time Spent: 20m > Remaining Estimate: 0h > > For a long statistical period and low tps situation, for example, metrics > period is 60 sec and there are only two invocation each costs 1.5 second to > process. The metrics log print the max latency correctly(1500ms), but the > printed average latency is 0. > The cause is that a int variable is used to calculate the tps distributed > into every second and the average latency is calculated by (tps distributed > into every second)/(total latency distributed into every second). And in such > situation, the tps data distributed to every second is 0, so the average > latency is 0. > The tps data should be stored in a double variable and the metrics log format > should be adjust slightly. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (SCB-1220) Support regex path param on consumer side
[
https://issues.apache.org/jira/browse/SCB-1220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
YaoHaishi resolved SCB-1220.
Resolution: Fixed
Fix Version/s: java-chassis-1.2.0
> Support regex path param on consumer side
> -
>
> Key: SCB-1220
> URL: https://issues.apache.org/jira/browse/SCB-1220
> Project: Apache ServiceComb
> Issue Type: Improvement
>Reporter: YaoHaishi
>Assignee: YaoHaishi
>Priority: Major
> Fix For: java-chassis-1.2.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Currently, the regex path param is supported on provider side, like:
> {code:java}
> @Path("/{path : .+}")
> @GET
> @ApiResponse(code = 200, message = "", response = File.class)
> public Response getStaticResource(@PathParam("path") String path) {
> {code}
> But if the request is passed via EdgeService, a NullPointerException is
> thrown, because EdgeService take "path : .+" as path param name and when it
> construct the request to the backend service, the correct path param writer
> is not found.
> This problem should be fixed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (SCB-1210) improve the average latency precision of the metrics log
[ https://issues.apache.org/jira/browse/SCB-1210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] YaoHaishi updated SCB-1210: --- Fix Version/s: java-chassis-1.2.0 > improve the average latency precision of the metrics log > > > Key: SCB-1210 > URL: https://issues.apache.org/jira/browse/SCB-1210 > Project: Apache ServiceComb > Issue Type: Improvement >Reporter: YaoHaishi >Assignee: YaoHaishi >Priority: Major > Fix For: java-chassis-1.2.0 > > Time Spent: 20m > Remaining Estimate: 0h > > For a long statistical period and low tps situation, for example, metrics > period is 60 sec and there are only two invocation each costs 1.5 second to > process. The metrics log print the max latency correctly(1500ms), but the > printed average latency is 0. > The cause is that a int variable is used to calculate the tps distributed > into every second and the average latency is calculated by (tps distributed > into every second)/(total latency distributed into every second). And in such > situation, the tps data distributed to every second is 0, so the average > latency is 0. > The tps data should be stored in a double variable and the metrics log format > should be adjust slightly. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (SCB-1234) Mark whether consumer-side slow invocation is retried
YaoHaishi created SCB-1234: -- Summary: Mark whether consumer-side slow invocation is retried Key: SCB-1234 URL: https://issues.apache.org/jira/browse/SCB-1234 Project: Apache ServiceComb Issue Type: Improvement Reporter: YaoHaishi Assignee: YaoHaishi Currently, if an invocation is retried, the metrics info is overwritten by the second time invoke procedure, which will cause handler cost time in metrics larger than the actual value. There seems no good solution yet, but a marker is needed in slow invocation log to avoid misleading developers. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (SCB-1220) Support regex path param on consumer side
YaoHaishi created SCB-1220:
--
Summary: Support regex path param on consumer side
Key: SCB-1220
URL: https://issues.apache.org/jira/browse/SCB-1220
Project: Apache ServiceComb
Issue Type: Improvement
Reporter: YaoHaishi
Assignee: YaoHaishi
Currently, the regex path param is supported on provider side, like:
{code:java}
@Path("/{path : .+}")
@GET
@ApiResponse(code = 200, message = "", response = File.class)
public Response getStaticResource(@PathParam("path") String path) {
{code}
But if the request is passed via EdgeService, a NullPointerException is thrown,
because EdgeService take "path : .+" as path param name and when it construct
the request to the backend service, the correct path param writer is not found.
This problem should be fixed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (SCB-1210) improve the average latency precision of the metrics log
YaoHaishi created SCB-1210: -- Summary: improve the average latency precision of the metrics log Key: SCB-1210 URL: https://issues.apache.org/jira/browse/SCB-1210 Project: Apache ServiceComb Issue Type: Improvement Reporter: YaoHaishi Assignee: YaoHaishi For a long statistical period and low tps situation, for example, metrics period is 60 sec and there are only two invocation each costs 1.5 second to process. The metrics log print the max latency correctly(1500ms), but the printed average latency is 0. The cause is that a int variable is used to calculate the tps distributed into every second and the average latency is calculated by (tps distributed into every second)/(total latency distributed into every second). And in such situation, the tps data distributed to every second is 0, so the average latency is 0. The tps data should be stored in a double variable and the metrics log format should be adjust slightly. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SCB-1154) invocation related log must invoke with marker
[ https://issues.apache.org/jira/browse/SCB-1154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16792452#comment-16792452 ] YaoHaishi commented on SCB-1154: Slow invocation log should add the instanceId and ip:port info of the peer. > invocation related log must invoke with marker > -- > > Key: SCB-1154 > URL: https://issues.apache.org/jira/browse/SCB-1154 > Project: Apache ServiceComb > Issue Type: Sub-task > Components: Java-Chassis >Reporter: wujimin >Assignee: YaoHaishi >Priority: Major > Attachments: schemas.png > > > LOGGER.info(invocation.getMarker(), ..) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SCB-1154) invocation related log must invoke with marker
[ https://issues.apache.org/jira/browse/SCB-1154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16792333#comment-16792333 ] YaoHaishi commented on SCB-1154: Exceptions, timeout problems occurring in the 21 positions mentioned by SCB-1150 should be located by log or other method. > invocation related log must invoke with marker > -- > > Key: SCB-1154 > URL: https://issues.apache.org/jira/browse/SCB-1154 > Project: Apache ServiceComb > Issue Type: Sub-task > Components: Java-Chassis >Reporter: wujimin >Assignee: YaoHaishi >Priority: Major > > LOGGER.info(invocation.getMarker(), ..) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SCB-1154) invocation related log must invoke with marker
[ https://issues.apache.org/jira/browse/SCB-1154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16792340#comment-16792340 ] YaoHaishi commented on SCB-1154: An optimization should be added, schemas listed in the web page should be sorted in lexicographic order. !schemas.png! > invocation related log must invoke with marker > -- > > Key: SCB-1154 > URL: https://issues.apache.org/jira/browse/SCB-1154 > Project: Apache ServiceComb > Issue Type: Sub-task > Components: Java-Chassis >Reporter: wujimin >Assignee: YaoHaishi >Priority: Major > Attachments: schemas.png > > > LOGGER.info(invocation.getMarker(), ..) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (SCB-1154) invocation related log must invoke with marker
[ https://issues.apache.org/jira/browse/SCB-1154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16792340#comment-16792340 ] YaoHaishi edited comment on SCB-1154 at 3/14/19 4:58 AM: - An optimization should be added: schemas listed in the web page should be sorted in lexicographic order. !schemas.png! was (Author: yaohaishi): An optimization should be added, schemas listed in the web page should be sorted in lexicographic order. !schemas.png! > invocation related log must invoke with marker > -- > > Key: SCB-1154 > URL: https://issues.apache.org/jira/browse/SCB-1154 > Project: Apache ServiceComb > Issue Type: Sub-task > Components: Java-Chassis >Reporter: wujimin >Assignee: YaoHaishi >Priority: Major > Attachments: schemas.png > > > LOGGER.info(invocation.getMarker(), ..) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (SCB-1154) invocation related log must invoke with marker
[ https://issues.apache.org/jira/browse/SCB-1154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] YaoHaishi updated SCB-1154: --- Attachment: schemas.png > invocation related log must invoke with marker > -- > > Key: SCB-1154 > URL: https://issues.apache.org/jira/browse/SCB-1154 > Project: Apache ServiceComb > Issue Type: Sub-task > Components: Java-Chassis >Reporter: wujimin >Assignee: YaoHaishi >Priority: Major > Attachments: schemas.png > > > LOGGER.info(invocation.getMarker(), ..) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (SCB-1154) invocation related log must invoke with marker
[ https://issues.apache.org/jira/browse/SCB-1154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] YaoHaishi reassigned SCB-1154: -- Assignee: YaoHaishi > invocation related log must invoke with marker > -- > > Key: SCB-1154 > URL: https://issues.apache.org/jira/browse/SCB-1154 > Project: Apache ServiceComb > Issue Type: Sub-task > Components: Java-Chassis >Reporter: wujimin >Assignee: YaoHaishi >Priority: Major > > LOGGER.info(invocation.getMarker(), ..) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (SCB-1185) Log DNS related exception to help locate problem
[ https://issues.apache.org/jira/browse/SCB-1185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] YaoHaishi resolved SCB-1185. Resolution: Resolved Fix Version/s: java-chassis-1.2.0 > Log DNS related exception to help locate problem > > > Key: SCB-1185 > URL: https://issues.apache.org/jira/browse/SCB-1185 > Project: Apache ServiceComb > Issue Type: Improvement > Components: Java-Chassis >Reporter: YaoHaishi >Assignee: YaoHaishi >Priority: Minor > Fix For: java-chassis-1.2.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Currently when microservice instances failed to connect to sc/cc due to DNS > problem, the exception detail information is not logged. > The DNS related exceptions should be identified and print error log about > them. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (SCB-1185) Log DNS related exception to help locate problem
YaoHaishi created SCB-1185: -- Summary: Log DNS related exception to help locate problem Key: SCB-1185 URL: https://issues.apache.org/jira/browse/SCB-1185 Project: Apache ServiceComb Issue Type: Improvement Components: Java-Chassis Reporter: YaoHaishi Assignee: YaoHaishi Currently when microservice instances failed to connect to sc/cc due to DNS problem, the exception detail information is not logged. The DNS related exceptions should be identified and print error log about them. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (SCB-1175) document for basic configuration rule
[ https://issues.apache.org/jira/browse/SCB-1175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] YaoHaishi resolved SCB-1175. Resolution: Resolved Fix Version/s: java-chassis-1.2.0 > document for basic configuration rule > - > > Key: SCB-1175 > URL: https://issues.apache.org/jira/browse/SCB-1175 > Project: Apache ServiceComb > Issue Type: Sub-task > Components: Java-Chassis >Reporter: wujimin >Assignee: YaoHaishi >Priority: Major > Fix For: java-chassis-1.2.0 > > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (SCB-1176) EdgeService does not report Zipkin data correctly
YaoHaishi created SCB-1176: -- Summary: EdgeService does not report Zipkin data correctly Key: SCB-1176 URL: https://issues.apache.org/jira/browse/SCB-1176 Project: Apache ServiceComb Issue Type: Bug Components: Java-Chassis Affects Versions: java-chassis-1.2.0 Reporter: YaoHaishi Assignee: YaoHaishi If EdgeService works as a gateway service, it's trace data cannot upload to zipkin server properly. As a result, if we look into a trace record, there are only spans of backend service. If we add a common REST service operation in EdgeService and invoke backend service via this operation, there are spans of EdgeService in these trace records. It seems that the trace data is only uploaded in tracing-provider handler. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (SCB-1175) document for basic configuration rule
[ https://issues.apache.org/jira/browse/SCB-1175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] YaoHaishi reassigned SCB-1175: -- Assignee: YaoHaishi > document for basic configuration rule > - > > Key: SCB-1175 > URL: https://issues.apache.org/jira/browse/SCB-1175 > Project: Apache ServiceComb > Issue Type: Sub-task > Components: Java-Chassis >Reporter: wujimin >Assignee: YaoHaishi >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (SCB-1166) Handler#init method is not referenced in anywhere
YaoHaishi created SCB-1166: -- Summary: Handler#init method is not referenced in anywhere Key: SCB-1166 URL: https://issues.apache.org/jira/browse/SCB-1166 Project: Apache ServiceComb Issue Type: Bug Components: Java-Chassis Affects Versions: java-chassis-1.1.0 Reporter: YaoHaishi Assignee: YaoHaishi Currently the method Handler#init is not referenced in anywhere. As the instantiation of Handler is encapsulated by ServiceComb-Java-Chassis, the logic defined in Handler#init will never work. It should be discussed later whether this method should be removed or it should be invoked in the Handler instantiation process. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (SCB-1139) Upgrade Vert.x to 3.6
[ https://issues.apache.org/jira/browse/SCB-1139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] YaoHaishi resolved SCB-1139. Resolution: Fixed Fix Version/s: java-chassis-1.2.0 > Upgrade Vert.x to 3.6 > - > > Key: SCB-1139 > URL: https://issues.apache.org/jira/browse/SCB-1139 > Project: Apache ServiceComb > Issue Type: Improvement > Components: Java-Chassis >Reporter: YaoHaishi >Assignee: jeho0815 >Priority: Major > Fix For: java-chassis-1.2.0 > > Time Spent: 40m > Remaining Estimate: 0h > > Currently ServiceComb-Java-Chassis depends on Vert.x-3.5.3. We should upgrade > to 3.6 later. > Subtasks: > * Vert.x 3.6 change it's behavior about connection idle timeout and > keep-alive timeout. Once we upgrade to 3.6, we need to provide config items > to specify keep-alive timeout and update the related docs. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (SCB-1135) Add client max receive header size config item
[ https://issues.apache.org/jira/browse/SCB-1135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] YaoHaishi resolved SCB-1135. Resolution: Fixed > Add client max receive header size config item > -- > > Key: SCB-1135 > URL: https://issues.apache.org/jira/browse/SCB-1135 > Project: Apache ServiceComb > Issue Type: Improvement > Components: Java-Chassis >Affects Versions: java-chassis-1.2.0 >Reporter: YaoHaishi >Assignee: YaoHaishi >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > Currently the max header size that consumer can receive is always 8192 bytes, > which is the default value given by Vert.x. > We need to provide a config item to allow users to change it. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (SCB-1139) Upgrade Vert.x to 3.6
YaoHaishi created SCB-1139: -- Summary: Upgrade Vert.x to 3.6 Key: SCB-1139 URL: https://issues.apache.org/jira/browse/SCB-1139 Project: Apache ServiceComb Issue Type: Improvement Components: Java-Chassis Reporter: YaoHaishi Assignee: YaoHaishi Currently ServiceComb-Java-Chassis depends on Vert.x-3.5.3. We should upgrade to 3.6 later. Subtasks: * Vert.x 3.6 change it's behavior about connection idle timeout and keep-alive timeout. Once we upgrade to 3.6, we need to provide config items to specify keep-alive timeout and update the related docs. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (SCB-1129) @JsonProperty on enum value is ignored
[
https://issues.apache.org/jira/browse/SCB-1129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
YaoHaishi resolved SCB-1129.
Resolution: Fixed
Fix Version/s: java-chassis-1.2.0
> @JsonProperty on enum value is ignored
> --
>
> Key: SCB-1129
> URL: https://issues.apache.org/jira/browse/SCB-1129
> Project: Apache ServiceComb
> Issue Type: Bug
> Components: Java-Chassis
>Affects Versions: java-chassis-1.2.0
>Reporter: YaoHaishi
>Assignee: YaoHaishi
>Priority: Major
> Fix For: java-chassis-1.2.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Currently the schema generating mechanism will ignore the JsonProperty
> annotation on enum value.
> For the enum param like below, the value in generated schema is "AB", but
> "A-B" is expected.
> {code:java}
> public enum TestEnum {
> @JsonProperty(value = "A-B")
> AB
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SCB-1135) Add client max receive header size config item
[ https://issues.apache.org/jira/browse/SCB-1135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16753653#comment-16753653 ] YaoHaishi commented on SCB-1135: Yes, here is the issue [https://github.com/apache/servicecomb-java-chassis/issues/1067]. I'll update the gitbook later, maybe we can add warning message there? > Add client max receive header size config item > -- > > Key: SCB-1135 > URL: https://issues.apache.org/jira/browse/SCB-1135 > Project: Apache ServiceComb > Issue Type: Improvement > Components: Java-Chassis >Affects Versions: java-chassis-1.2.0 >Reporter: YaoHaishi >Assignee: YaoHaishi >Priority: Major > > Currently the max header size that consumer can receive is always 8192 bytes, > which is the default value given by Vert.x. > We need to provide a config item to allow users to change it. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (SCB-1135) Add client max receive header size config item
YaoHaishi created SCB-1135: -- Summary: Add client max receive header size config item Key: SCB-1135 URL: https://issues.apache.org/jira/browse/SCB-1135 Project: Apache ServiceComb Issue Type: Improvement Components: Java-Chassis Affects Versions: java-chassis-1.2.0 Reporter: YaoHaishi Assignee: YaoHaishi Currently the max header size that consumer can receive is always 8192 bytes, which is the default value given by Vert.x. We need to provide a config item to allow users to change it. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (SCB-1129) @JsonProperty on enum value is ignored
[
https://issues.apache.org/jira/browse/SCB-1129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
YaoHaishi updated SCB-1129:
---
Component/s: Java-Chassis
> @JsonProperty on enum value is ignored
> --
>
> Key: SCB-1129
> URL: https://issues.apache.org/jira/browse/SCB-1129
> Project: Apache ServiceComb
> Issue Type: Bug
> Components: Java-Chassis
>Affects Versions: java-chassis-1.2.0
>Reporter: YaoHaishi
>Assignee: YaoHaishi
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently the schema generating mechanism will ignore the JsonProperty
> annotation on enum value.
> For the enum param like below, the value in generated schema is "AB", but
> "A-B" is expected.
> {code:java}
> public enum TestEnum {
> @JsonProperty(value = "A-B")
> AB
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (SCB-1133) Defining param type in REST service class causes javassist.NotFoundException
[
https://issues.apache.org/jira/browse/SCB-1133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
YaoHaishi updated SCB-1133:
---
Component/s: Java-Chassis
> Defining param type in REST service class causes javassist.NotFoundException
>
>
> Key: SCB-1133
> URL: https://issues.apache.org/jira/browse/SCB-1133
> Project: Apache ServiceComb
> Issue Type: Bug
> Components: Java-Chassis
>Affects Versions: java-chassis-1.2.0
>Reporter: YaoHaishi
>Assignee: YaoHaishi
>Priority: Major
>
> Currently if we define a inner class in a REST service class as parameter
> type, a javassist.NotFoundException will be thrown.
> Service class definition like below will trigger this problem:
> {code:java}
> @RestSchema(schemaId = "testSchema")
> @RequestMapping(path = "test")
> public class TestRestService {
> @PostMapping(path = "post")
> public String post(@RequestBody TestBodyParam body) {
> return null == body ? "null" : body.toString();
> }
> public static class TestBodyParam {
> // fields omitted
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (SCB-1133) Defining param type in REST service class causes javassist.NotFoundException
YaoHaishi created SCB-1133:
--
Summary: Defining param type in REST service class causes
javassist.NotFoundException
Key: SCB-1133
URL: https://issues.apache.org/jira/browse/SCB-1133
Project: Apache ServiceComb
Issue Type: Bug
Affects Versions: java-chassis-1.2.0
Reporter: YaoHaishi
Assignee: YaoHaishi
Currently if we define a inner class in a REST service class as parameter type,
a javassist.NotFoundException will be thrown.
Service class definition like below will trigger this problem:
{code:java}
@RestSchema(schemaId = "testSchema")
@RequestMapping(path = "test")
public class TestRestService {
@PostMapping(path = "post")
public String post(@RequestBody TestBodyParam body) {
return null == body ? "null" : body.toString();
}
public static class TestBodyParam {
// fields omitted
}
}
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (SCB-1131) Error occurs when edge invoking backend service with enum param in highway transport
YaoHaishi created SCB-1131: -- Summary: Error occurs when edge invoking backend service with enum param in highway transport Key: SCB-1131 URL: https://issues.apache.org/jira/browse/SCB-1131 Project: Apache ServiceComb Issue Type: Bug Components: Java-Chassis Affects Versions: java-chassis-1.2.0 Reporter: YaoHaishi Assignee: YaoHaishi When invoking backend service via EdgeService in highway transport and there is enum param in request, error occurs in EdgeService. For the first invocation, the error is "java.lang.NoSuchFieldException: MPEG-2", and the next invocations cause "java.lang.RuntimeException: gen.cse.gen.HelloWorld.provider.hello.HelloServiceIntf.setMedia.Args class is frozen". If the enum param is body, the problem can be avoid by adding the enum class into the classpath of EdgeService. If the enum param is query, this problem cannot be avoid. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (SCB-1129) @JsonProperty on enum value is ignored
YaoHaishi created SCB-1129:
--
Summary: @JsonProperty on enum value is ignored
Key: SCB-1129
URL: https://issues.apache.org/jira/browse/SCB-1129
Project: Apache ServiceComb
Issue Type: Bug
Affects Versions: java-chassis-1.2.0
Reporter: YaoHaishi
Assignee: YaoHaishi
Currently the schema generating mechanism will ignore the JsonProperty
annotation on enum value.
For the enum param like below, the value in generated schema is "AB", but "A-B"
is expected.
{code:java}
public enum TestEnum {
@JsonProperty(value = "A-B")
AB
}
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (SCB-1101) ServiceComb-Java-Chassis support IPv6
[ https://issues.apache.org/jira/browse/SCB-1101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] YaoHaishi resolved SCB-1101. Resolution: Fixed Fix Version/s: java-chassis-1.2.0 > ServiceComb-Java-Chassis support IPv6 > - > > Key: SCB-1101 > URL: https://issues.apache.org/jira/browse/SCB-1101 > Project: Apache ServiceComb > Issue Type: Improvement >Reporter: YaoHaishi >Assignee: YaoHaishi >Priority: Minor > Fix For: java-chassis-1.2.0 > > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (SCB-1101) ServiceComb-Java-Chassis support IPv6
YaoHaishi created SCB-1101: -- Summary: ServiceComb-Java-Chassis support IPv6 Key: SCB-1101 URL: https://issues.apache.org/jira/browse/SCB-1101 Project: Apache ServiceComb Issue Type: Improvement Reporter: YaoHaishi Assignee: YaoHaishi -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (SCB-1073) StaticMicroserviceVersions should be ignored while checking instance cache
[ https://issues.apache.org/jira/browse/SCB-1073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] YaoHaishi resolved SCB-1073. Resolution: Fixed PR has been merged. > StaticMicroserviceVersions should be ignored while checking instance cache > -- > > Key: SCB-1073 > URL: https://issues.apache.org/jira/browse/SCB-1073 > Project: Apache ServiceComb > Issue Type: Bug > Components: Java-Chassis >Reporter: YaoHaishi >Assignee: YaoHaishi >Priority: Minor > Fix For: java-chassis-1.2.0 > > Time Spent: 10m > Remaining Estimate: 0h > > Currently when instance cache checking mechanism is triggered, the locally > registered 3rd party services are also checked. As a result, an error message > is generated, indicating that the 3rd party services don't exist in service > center. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (SCB-1073) StaticMicroserviceVersions should be ignored while checking instance cache
YaoHaishi created SCB-1073: -- Summary: StaticMicroserviceVersions should be ignored while checking instance cache Key: SCB-1073 URL: https://issues.apache.org/jira/browse/SCB-1073 Project: Apache ServiceComb Issue Type: Bug Components: Java-Chassis Reporter: YaoHaishi Assignee: YaoHaishi Fix For: java-chassis-1.2.0 Currently when instance cache checking mechanism is triggered, the locally registered 3rd party services are also checked. As a result, an error message is generated, indicating that the 3rd party services don't exist in service center. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (SCB-1056) Put provider QPS flow control in front
[ https://issues.apache.org/jira/browse/SCB-1056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] YaoHaishi resolved SCB-1056. Resolution: Fixed Fix Version/s: java-chassis-1.2.0 PR has been merged. The other task is tracked by SCB-1056. > Put provider QPS flow control in front > -- > > Key: SCB-1056 > URL: https://issues.apache.org/jira/browse/SCB-1056 > Project: Apache ServiceComb > Issue Type: Improvement > Components: Java-Chassis >Reporter: YaoHaishi >Assignee: YaoHaishi >Priority: Major > Fix For: java-chassis-1.2.0 > > > Currently provider QPS flow control is in ProviderQpsFlowControlHandler which > works in provider handler chain. As a result, the flow control logic takes > effect too late and much CPU resource is wasted on processing those requests > that should be rejected earlier. > Put the provider QPS flow control logic in front can save the resource. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
