vert.x
vert.x copied to clipboard
eclipse-vertx
Using vert.x 4.5.0 traffic does not take effect, use Verticle mode to deploy
Questions
I set read and write to 1mb/s, but it can actually reach 10mb/s.
Version
4.5.0
Context
Below is my code：
MqttVertxVerticle:
MqttServer mqttServer = MqttServer.create(vertx, mqttServerOptions);
mqttServer.endpointHandler(vertxHandlerManager::accept);
mqttServer.exceptionHandler(throwable -> vertxHandlerManager.handlerException(null, throwable));
mqttServer.listen().onSuccess(server -> {
serverList.add(server);
ContextHolder.vertxContext.getLoggerManager().printWarn(null,
LogEvent.SYSTEM, "MQTT server started and listening on port " + mqttServer.actualPort());
}).onFailure(throwable -> ContextHolder.vertxContext.getLoggerManager().printError(null,
LogEvent.SYSTEM, throwable.getMessage()))
private MqttServerOptions cast(MqttConfig serverOptions) {
MqttServerOptions castOptions = new MqttServerOptions();
if ("DEBUG".equals(rootConfig.getLogLevel())) {
castOptions.setLogActivity(true);
castOptions.setActivityLogDataFormat(ByteBufFormat.HEX_DUMP);
}
if (serverOptions instanceof TsMqttConfig) {
TsMqttConfig tsMqttConfig = (TsMqttConfig) serverOptions;
castOptions.setSsl(true);
PemKeyCertOptions pemKeyCertOptions = new PemKeyCertOptions();
pemKeyCertOptions.setCertPath(tsMqttConfig.getSsl().getCrt());
pemKeyCertOptions.setKeyPath(tsMqttConfig.getSsl().getKey());
castOptions.setPemKeyCertOptions(pemKeyCertOptions);
if (tsMqttConfig.getSsl().getCa() != null) {
PemTrustOptions pemTrustOptions = new PemTrustOptions();
pemTrustOptions.addCertPath(tsMqttConfig.getSsl().getCa());
castOptions.setPemTrustOptions(pemTrustOptions);
}
}
castOptions.setTrafficShapingOptions(new io.vertx.core.net.TrafficShapingOptions()
.setOutboundGlobalBandwidth(rootConfig.getTraffic().getGlobalWriteSize())
.setInboundGlobalBandwidth(rootConfig.getTraffic().getGlobalReadSize()));
castOptions.setMaxMessageSize(serverOptions.getMaxMessageSize());
castOptions.setPort(serverOptions.getPort());
castOptions.setHost(serverOptions.getHost());
castOptions.setTcpNoDelay(serverOptions.isTcpNoDelay());
castOptions.setTcpKeepAlive(serverOptions.isTcpKeepAlive());
castOptions.setReusePort(serverOptions.isReusePort());
castOptions.setUseWebSocket(serverOptions.isUserWebSocket());
return castOptions;
}
MqttVertxServer：
public static void init() {
ConfigInitializer.initConfig(Vertx.vertx())
.onSuccess(configReader -> {
CoreRootConfig coreRootConfig = configReader.readStaticConfig(Constants.CONFIG_CORE_PATH, CoreRootConfig.class);
MqttVertxServer mqttVertxServer = new MqttVertxServer();
setLogRoot(coreRootConfig.getLogLevel());
setLogAll(coreRootConfig.isLogAll());
ClusterInitializer.
initCluster(coreRootConfig.getCluster())
.onSuccess(vx -> {
int instance = coreRootConfig.getInstance();
instance = instance == 0 ? Runtime.getRuntime().availableProcessors() * 2 : instance;
MqttVertxContext mqttVertxContext = new MqttVertxContext(Vertx.vertx(),configReader, coreRootConfig);
MqttVertxServer.vertxContext = ContextHolder.initVertxContext(mqttVertxContext);
for (int i=0;i<instance;i++){
vx.deployVerticle(new MqttVertxVerticle(mqttVertxServer, coreRootConfig, mqttVertxContext, vx)
,new DeploymentOptions().setHa(true));
}
});
});
}
Do you have a reproducer?
A reproducer is a simple project hosted on GitHub (or another forge supporting git clone operation) that has a build file that can be executed to reproduce the issue.
Reproducers are very helpful for contributors and will likely help them fixing your bug faster.
- Link to github project/gist
Steps to reproduce
- ...
- ...
- ...
- ...
Extra
- Anything that can be relevant such as OS version, JVM version
} castOptions.setTrafficShapingOptions(new io.vertx.core.net.TrafficShapingOptions() .setOutboundGlobalBandwidth(rootConfig.getTraffic().getGlobalWriteSize()) .setInboundGlobalBandwidth(rootConfig.getTraffic().getGlobalReadSize()));
Through stress testing, we found that the actual read and write traffic will be much larger than the set one, so setting the read and write traffic will not take effect. Through our debugging, we found that multiple connections have indeed initialized GlobalTrafficShapingHandler in the pipeline, and it is an object. But I don’t know why it didn’t take effect.
Verticle
The above is the traffic code I set, is there a problem with Verticle?
it could be an issue with the traffic shaper itself ?
On Thu, Dec 7, 2023 at 2:16 AM Joseph Wyatt @.***> wrote:
} castOptions.setTrafficShapingOptions(new io.vertx.core.net.TrafficShapingOptions() .setOutboundGlobalBandwidth(rootConfig.getTraffic().getGlobalWriteSize()) .setInboundGlobalBandwidth(rootConfig.getTraffic().getGlobalReadSize()));Through stress testing, we found that the actual read and write traffic will be much larger than the set one, so setting the read and write traffic will not take effect. Through our debugging, we found that multiple connections have indeed initialized GlobalTrafficShapingHandler in the pipeline, and it is an object. But I don’t know why it didn’t take effect.
— Reply to this email directly, view it on GitHub https://github.com/eclipse-vertx/vert.x/issues/5006#issuecomment-1843975056, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABXDCQZ5MHZINVXQ6AVTJTYIEKHZAVCNFSM6AAAAABAG73FRSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNBTHE3TKMBVGY . You are receiving this because you are subscribed to this thread.Message ID: @.***>
it could be an issue with the traffic shaper itself ? … On Thu, Dec 7, 2023 at 2:16 AM Joseph Wyatt @.> wrote: } castOptions.setTrafficShapingOptions(new io.vertx.core.net.TrafficShapingOptions() .setOutboundGlobalBandwidth(rootConfig.getTraffic().getGlobalWriteSize()) .setInboundGlobalBandwidth(rootConfig.getTraffic().getGlobalReadSize())); Through stress testing, we found that the actual read and write traffic will be much larger than the set one, so setting the read and write traffic will not take effect. Through our debugging, we found that multiple connections have indeed initialized GlobalTrafficShapingHandler in the pipeline, and it is an object. But I don’t know why it didn’t take effect. — Reply to this email directly, view it on GitHub <#5006 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABXDCQZ5MHZINVXQ6AVTJTYIEKHZAVCNFSM6AAAAABAG73FRSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNBTHE3TKMBVGY . You are receiving this because you are subscribed to this thread.Message ID: @.>
No, I have tested Netty’s native traffic and the traffic control is in effect.
can you provide a reproducer ?
On Fri, Dec 8, 2023 at 6:11 AM Joseph Wyatt @.***> wrote:
it could be an issue with the traffic shaper itself ? … <#m_-3598278586074146665_> On Thu, Dec 7, 2023 at 2:16 AM Joseph Wyatt @.> wrote: } castOptions.setTrafficShapingOptions(new io.vertx.core.net.TrafficShapingOptions() .setOutboundGlobalBandwidth(rootConfig.getTraffic().getGlobalWriteSize()) .setInboundGlobalBandwidth(rootConfig.getTraffic().getGlobalReadSize())); Through stress testing, we found that the actual read and write traffic will be much larger than the set one, so setting the read and write traffic will not take effect. Through our debugging, we found that multiple connections have indeed initialized GlobalTrafficShapingHandler in the pipeline, and it is an object. But I don’t know why it didn’t take effect. — Reply to this email directly, view it on GitHub <#5006 (comment) https://github.com/eclipse-vertx/vert.x/issues/5006#issuecomment-1843975056>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABXDCQZ5MHZINVXQ6AVTJTYIEKHZAVCNFSM6AAAAABAG73FRSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNBTHE3TKMBVGY https://github.com/notifications/unsubscribe-auth/AABXDCQZ5MHZINVXQ6AVTJTYIEKHZAVCNFSM6AAAAABAG73FRSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNBTHE3TKMBVGY . You are receiving this because you are subscribed to this thread.Message ID: @.>
No, I have tested Netty’s native traffic and the traffic control is in effect.
— Reply to this email directly, view it on GitHub https://github.com/eclipse-vertx/vert.x/issues/5006#issuecomment-1846556614, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABXDCXIMAF5MLGVNS4MGETYIKOP5AVCNFSM6AAAAABAG73FRSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNBWGU2TMNRRGQ . You are receiving this because you commented.Message ID: @.***>