but in the docs for MessageProducer the only method that allows a replyHandler (send) has been marked as deprecated in 3.x and has indeed been removed in 4.x (which is what i'm using). yet MessageConsumer still has a
reply method. how am i meant to add a reply handler to a message in vert.x 4?
In our codebase, we are using Vertx web 3.9.4 version.
Router is used for both pure Http requests and upgraded websocket calls. Now, there is a common handler RoutingContext.addEndBodyHandler, which does some logging important for both usecases Http and Websocket.
I discovered for Websocket calls this handler is not called. As per javadoc
Provides a handler that will be called after the last part of the body is written to the wire. The handler is called asynchronously of when the response has been received by the client. This provides a hook allowing you to do more operations once the request has been sent over the wire. Do not use this for resource cleanup as this handler might never get called (e.g. if the connection is reset).Question: Whats the alternative to have this common code for both usecases?
poolCleanerPeriod on the pool, is it on the client?
3 replies
Does Vert.X Mongo support resumable file uploads?
The idea is to use the Youtube Resumeable Upload protocol to upload large binary files to MongoDB/GridFS but I can't find an equivalent to an append function for GridFS (to resume the upload).
Okay at least for MongoDB I might have found the answer to my own question - due to concurrency the API won't support append: https://jira.mongodb.org/browse/JAVA-2765
Currently we have http client instance per verticle. We don't share http clients against verticles because responses were handled by random event loops which were different from event loops handling requests.
Also currently we have circuit breaker instances in relation 1:1 with http client instances.
Now we do consider sharing the same instance of circuit breaker by clients in all verticles invoking the same target service.
So i.e. we would have 16 verticles, 16 clients and 1 circuit breaker instance shared by all 16 client.
Initial tests confirmed responses are handled by the same event loop as requests so we can't see any issue with that approach.
Are there any known recommendations/reasons advising against going this path?
I am following https://github.com/vert-x3/vertx-guide-for-java-devs/blob/3.8/step-1/src/main/java/io/vertx/guides/wiki/MainVerticle.java
Code there is as:
@Override
public void start(Promise<Void> promise) throws Exception {
Future<Void> steps = prepareDatabase().compose(v -> startHttpServer());
steps.setHandler(promise);
}
But in available pdf, its:
@Override public void start(Future<Void> startFuture) throws Exception
{
startFuture.complete();
}
....}
We have used set vertx.setPeriodic for to schedule these tasks. But we are observing strange behaviour after upgrading to 3.9.7. set periodic stops working after 14, 15 days of service uptime.
Earlier we were on 3.5.2 and everything were working fine. Is there anyone facing the same issue.
Can someone please have look
transport-ws protocol, how to test it? I have added https://github.com/hantsy/vertx-sandbox/blob/master/graphql-transport-ws/src/test/java/com/example/demo/TestMainVerticle.java
4 replies
How to log all database queries? I am using io.vertx:vertx-jdbc-client and io.vertx:vertx-pg-client
Hi, if you are using io.vertx:vertx-jdbc-client, you can use https://github.com/p6spy/p6spy to log query sql