vert-x3 / issues Goto Github PK

I want to implement cluster manager based on Apache Ignite. As I can see, Hazelcast-based cluster manager has separate repository. So I have questions: Where I have to start my work? Can anybody create new repository (vertx-ignite)?

The Vert.x use of JSON is prevalent. And therefore if we want to use it throughout part of our apps, it is nice if we can build around it in a way that means the same code can be used OUTSIDE vert.x. Therefore can you separate the Vert.x JSON code into separate module so we can depend on it separately as well?

thanks

Tune Vert.x 3.

In particular:

• file serving (e.g. webserver)
• event bus
• file system

Github Project: https://github.com/vert-x3/vertx-mysql-postgresql-client

thats kinda like the AMQP bridge but reuses Apache Camel's 150+ connectors so that vertx folks can use the event bus to talk to any network protocol, back end system, API, database, messaging system or data format etc

Any chance someone from the vertx team can create an empty git repo then we can try submit a PR for it?

Update the version of the used parents (vertx-parent and vertx-ext-parent).

Github Project: https://github.com/tsegismont/vertx-monitor

For EventBus, you have the VertxOptions.setClusterPort() and setClusterHost() but it is not clearly documented how a port is selected without these (random port, what range, ...?) And for overriding the public published host/port for the cluster it changes to be system properties instead of VertxOptions

So, add setClusterPublicPort and setClusterPublicHost to VertxOptions and document these settings for how they work. Knowing about vertx.cluster.public.port and vertx.cluster.public.host doesn't appear in documentation for vert-x3. And that they override the other setClusterPort() and setClusterhost()

This is important for things like Docker where your internal port/host may not be the same as the public. We are doing a Docker+EC2 discovery (ECS) and it was not obvious where/how to find these properties and how they work.

Related to #32

Provide an easy way to parse the command line argument. The mechanism should support extensibility.

Refer to #32

Automatic redeployment of verticles after a modification of a file

Github Project: https://github.com/eclipse/vert.x
BZ issue: https://bugs.eclipse.org/bugs/show_bug.cgi?id=472827

Github Project: https://github.com/vert-x3/vertx-lang-ceylon

1/ add an end() method to WriteStream (this was agreed for 3.0 but not done)

2/ find a way to have read/write stream that do not support back pressures, for instance:

interface ReadStream<T> {
   ReadStream<T> exceptionHandler(Handler<Throwable> handler);
   ReadStream<T> handler(Handler<T> handler);
   ReadStream<T> endHandler(Handler<Void> endHandler);
}

interace ReactiveReadStream<T> extends ReadStream<T> {
   ReadStream<T> pause();
   ReadStream<T> resume();
}

Same for write stream.

this is a fictional design just to show what I do have in mind. Then we should refactor our stream usage to use reactive / non reactive streams, for instance MessageConsumer would extend the non reactive stream version as we don't support and the reactive ones (HttpServerRequest, AsyncFile, etc...).

This would help the integration with RxJava (and perhaps reactive-streams spec) and avoid confusion about Pump usage that one may have with non reactive streams.

Refer to #32

When we had multiple nodes in the vertx cluster with invalid public published ports, so when send of a message got to the subs to send a message, and it fails, it silently eats the message. Sending failing earlier in the call sometimes logs a failure, but again doesn't let the caller know.

So there is no way for a caller to know send() had a failure (has subscription, wants to send, but can't)

Github Project: https://github.com/eclipse/vert.x
BZ: https://bugs.eclipse.org/bugs/show_bug.cgi?id=472830

Github Project: https://github.com/eclipse/vert.x
Bugzilla Issue: https://bugs.eclipse.org/bugs/show_bug.cgi?id=472831

see vert-x3/vertx-web#181

Hi,

I'm owner of https://github.com/mthenw/heroku-buildpack-vertx. Are you interested in hosting it as a official buildpack? Of course some work is required to update packages to latest version. I'm also not sure if that kind of buildpack is required, maybe the one handling maven (or gradle) is enough for developers using vertx.

Github Project: https://github.com/eclipse/vert.x
Bugzilla issue: https://bugs.eclipse.org/bugs/show_bug.cgi?id=472832

We should be consistent about how we name getters and setters.

In some places we use getXXX() and in other places we just use xxx().

Moved from https://bugs.eclipse.org/bugs/show_bug.cgi?id=470876

Originally posted by @jstrachan.

Right now manually wiring up HazelCast nodes is a PITA and multicast doesn't typically work in docker / kubernetes / clouds.

Here's an example of how to discover nodes using DNS when running on OpenShift or kubernetes with DNS enabled:
https://jimmidyson.github.io/clustering-on-kubernetes--openshift3-using-dns/

Or you could use the Kubernetes REST API (which also requires secrets so its a bit harder to use)
https://github.com/GoogleCloudPlatform/kubernetes/blob/master/examples/cassandra/java/src/io/k8s/cassandra/KubernetesSeedProvider.java#L105

So the DNS option - using an environment variable of the name to lookup; vertx should be able to auto-disover the nodes it needs to connect to for Vertx / Hazelcast etc

e.g.

$ dig @localhost elasticsearch-cluster.default.local. +short
172.17.0.13
172.17.0.10
172.17.0.11

The nice thing about the DNS approach is vertx has DNS support already and there'd be no code dependency on kubernetes then!

IT should be possible to add command to the vertx / Starter command line such as:

• run
• generate
• start / stop / status
  ...

Related to #32

We should be consistent in naming properties in DataObjects

e.g. some places we use xxxPeriod, and in others xxxInterval (for times)

Github Project: https://github.com/vert-x3/vertx-amqp-service

Github Project: https://github.com/vietj/vertx-shell

Add support for HTTP2 server and client

Github Project: https://github.com/eclipse/vert.x

Refer to #32

The argument and option framework implemented on https://github.com/cescoffier/vert.x/tree/starter-refactoring does not support concatenated option.

In order to let vertx-shell reuse the model and parser, the current CLI need to be restructure. This will be done in eclipse-vertx/vert.x#1110

In a break from how we did things in Vert.x 2 I think we should expose a handle to the underlying implementation in various places in Vert.x e.g:

• The Netty Event Loop Group
• The Jackson ObjectMapper
• The Hazelcast instance
• Dropwizard metrics instance
  *etc

In some places we use camel case and in other places snake case (underscores) for naming JSON fields that correspond to properties in DataObjects.

We should be consistent.

Stomp: https://stomp.github.io/

Produce a document (on the wiki) enumerating everything we need to do for a release.

Some of the Async Handlers have type Void as the result type, but that isn't an instantiate-able type, so they instead return null. Other languages on the JVM treat Void as not nullable because when a void method returns it always returns as void. But in the case of vert.x it is always null.

Seems to be a misuse of Void, but I'm not sure. Nor sure what to do about it.

Kotlin for example, has an issue with this. If I weren't using promises I could probably try calling it a Void? but that type isn't allowed in a promise.

We should create some documentation about good security practices with vert.x

• e.g. run vert.x as a separate user which does not have access to files outside your webroot.
• Use Apex rather than core etc

Github Project: https://github.com/vert-x3/vertx-zookeeper

Synchronous but non-OS-thread-blocking verticles

Github Project: https://github.com/vert-x3/vertx-sync

Refer to #32

The option and argument framework implemented on https://github.com/cescoffier/vert.x/tree/starter-refactoring lacks a command model to retrieve command metadata (name, summary, description, hidden).

The current documentation seems to have duplicate sections on running Vert.x at the command line - these should be combined into a single section, as it's confusing currently.

Also we should create a section on how to run and debug Vert.x in an IDE.

Commands should not use System.out but a specified PrintStream.

(Related to #32)

So we can read cluster.xml and other files from a fatjar.

in eclipse I import the vertx-examples-master maven project.

then I try to run src/main/java/io/vertx/example/core/http/https/Server.java under module core-examples.

it failed to load server-keystore.jks .

saying:
Caused by: java.nio.file.NoSuchFileException: D:\work\eclipse_workspaces\mars\vertx-examples-master\core-examples\core-examples\src\main\java\io\vertx\example\core\http\https\server-keystore.jks

if you check the exception , the issue is there are two "core-examples" in the path.

in further debug , I find the issue is in FileResolver

public FileResolver(Vertx vertx) {
this.vertx = vertx;
String cwdOverride = System.getProperty("vertx.cwd");
if (cwdOverride != null) {
cwd = new File(cwdOverride).getAbsoluteFile();
} else {
cwd = null;
}
setupCacheDir();
}

here the cwdOverride is : core-examples/src/main/java/io/vertx/example/core/http/https

after it got the absoluteFile , the file path is changed to : D:\work\eclipse_workspaces\mars\vertx-examples-master\core-examples\core-examples\src\main\java\io\vertx\example\core\http\https

and it adds the extra core-examples to it .

There are currently undocumented sys props

Github Project: https://github.com/vert-x3/vertx-jgroups

Reading the docs, user can't easily find what to add to it's dependency manager.
It would be great to add this information in each documentation's header :

Just add this dependency to your package manager :
Gradle : compile io.vertx:vertx-whatever:3.0.0
Maven :

<dependency>
    <groupId>io.vertx</groupId>
    <artifactId>vertx-whatever</artifactId>
    <version>3.0.0</version>
    <scope>compile</scope>
</dependency> 

Issue from discussion: https://groups.google.com/forum/#!topic/vertx/H_X3afrAuNU

Github Project: https://github.com/eclipse/vert.x
Bugzilla Ticket: https://bugs.eclipse.org/bugs/show_bug.cgi?id=472833

breaks vert.x web - we are getting mixed status responses. I would guess that since we are reusing connections some state was not reseted in netty.

because the Netty event loop should be closed after all undeployments are processed.

Running io.vertx.example.unit.test.MyJUnitTest
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.625 sec
Apr 14, 2015 10:10:57 AM io.netty.channel.AbstractChannel$AbstractUnsafe invokeLater
WARNING: Can't invoke task later as EventLoop rejected it
java.util.concurrent.RejectedExecutionException: event executor terminated
    at io.netty.util.concurrent.SingleThreadEventExecutor.reject(SingleThreadEventExecutor.java:745)
    at io.netty.util.concurrent.SingleThreadEventExecutor.addTask(SingleThreadEventExecutor.java:322)
    at io.netty.util.concurrent.SingleThreadEventExecutor.execute(SingleThreadEventExecutor.java:725)
    at io.netty.channel.AbstractChannel$AbstractUnsafe.invokeLater(AbstractChannel.java:779)
    at io.netty.channel.AbstractChannel$AbstractUnsafe.deregister(AbstractChannel.java:612)
    at io.netty.channel.AbstractChannel$AbstractUnsafe.close(AbstractChannel.java:581)
    at io.netty.channel.DefaultChannelPipeline$HeadContext.close(DefaultChannelPipeline.java:1098)
    at io.netty.channel.AbstractChannelHandlerContext.invokeClose(AbstractChannelHandlerContext.java:543)
    at io.netty.channel.AbstractChannelHandlerContext.access$1100(AbstractChannelHandlerContext.java:32)
    at io.netty.channel.AbstractChannelHandlerContext$13.run(AbstractChannelHandlerContext.java:533)
    at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:380)
    at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:357)
    at io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:116)
    at java.lang.Thread.run(Thread.java:745)