I got a webserver with 2 endpoints that I want to handle on different machines. They are independent and when updating one I don't want to restart the other.
Router router = Router.router(vertx);
router.route("/api*").handler(BodyHandler.create());
router.post("/api/end_point_1").handler(new Handler1());
router.post("/api/end_point_2").handler(new Handler2());
How can I achieve this in Vert.x? I been reading about Vert.x Service Proxy
But I am not quite sure how to apply it to Router.
What you're looking for is called Vertx cluster.
Your handlers would look something like this:
router.post("/api/end_point_1").handler(req -> {
// Extract data from request
// Package it into an object
// Send it over EventBus
vertx.eventBus().send("event1", data);
});
Now create another verticle in a separate application, which should do:
vertx.eventBus().consumer("event1");
consumer.handler(o -> {
System.out.println("Got message" + o.body());
});
Now to run those separate Jars follow this guide: http://vertx.io/docs/vertx-hazelcast/java/
I would simply package the code as two different JARs and deploy them independently. Then a load-balancer/API gateway/reverse-proxy would send the traffic to the right servers depending on the request URI.
Related
I'm using https://github.com/rabbitmq/hop to get all subscriptions by exchangeName. This works for me but I have to ask rabbitmq about subscriptions every time when I need to iterate over them in case any new subscription has been added.
Is there any way to add listener in my application to know if any subscription added?
Or maybe RabbitMQ provides any other tool for adding such listeners?
hop is based on management HTTP API.
You can't add a listener on it.
The management UI executes the HTTP API each X seconds to get the information about subscriptions/queues/exchanges etc.
To convince some people to switch from old school tech, I need to build a chat demo application that manages more than 10K concurrent connections using Java (like Node.Js stuff).
I have tested Netty 5.0 which is awesome but requires lot of work to be done; on the other hand Jetty 9.3 is great but is slow compared to other competitors.
After some search I found the Vert.x 3 toolkit which is based on Netty with a plethora of great tools (no need to reinvent the wheel), I have seen the examples in git and I was able to build a websocket server, etc.
public void start() throws Exception {
vertx.createHttpServer().websocketHandler(new Handler<ServerWebSocket>() {
#Override
public void handle(ServerWebSocket e) {
// business stuff in the old style not yet lambda
}
}).listen(port);
}
Being new to the Vert.x world, I could not figure out how to manage connected users using it, normally the old fashion way is to use something like:
HashMap<UUID,ServerWebSocket> connectedUsers;
When a connection is established I check if it exists; if not I add it as a new entry and do some functions to send, broadcast, retrieve through the collection and so on.
My question is does Vert.x 3 have something to deal with connections to track them and remove those who left (ping pong), broadcast, etc. or should I implement them from scratch using cookies, session, ....)
I could not find any real example using Vert.x 3.
Basically, the scope of the websocketHandler represents a connection. In your example this is your anonymous class. I created a little websocket chat example where I use the Vert.x event bus to distribute the messages to all the clients.
In the start method of the server we handle the websocket connections. You can implement the closeHandler to monitor client disconnection. There are also handlers for exceptions, ping-pong, etc. You can identify a specific connection by using the textHandlerID, but you have also access to the remote address.
public void start() throws Exception {
vertx.createHttpServer().websocketHandler(handler -> {
System.out.println("client connected: "+handler.textHandlerID());
vertx.eventBus().consumer(CHAT_CHANNEL, message -> {
handler.writeTextMessage((String)message.body());
});
handler.textMessageHandler(message -> {
vertx.eventBus().publish(CHAT_CHANNEL,message);
});
handler.closeHandler(message ->{
System.out.println("client disconnected "+handler.textHandlerID());
});
}).listen(8080);
}
The client example is also written in Java. It just prints all the received messages on the websocket connection to the console. After connection it sends a message.
public void start() throws Exception {
HttpClient client = vertx.createHttpClient();
client.websocket(8080, "localhost", "", websocket -> {
websocket.handler(data -> System.out.println(data.toString("ISO-8859-1")));
websocket.writeTextMessage(NAME+ ":hello from client");
});
}
I am trying to write a client server application that communicate using Message Objects(Message Class is defined in my application). there is a scenario in which i want to transfer file between them. First I must send a message to client to notify it about specific file information and after that the file itself is going to be written to channel.
The problem is how can I handle this scenario in client?
Is it a good solution to remove Message handler after receiving message and replace it with a byte array handler?
what are the alternatives?
Sure you can just modify the pipeline on the fly. We do something similar in our portunification example[1].
[1] https://github.com/netty/netty/blob/4.0/example/src/main/java/io/netty/example/portunification/PortUnificationServerHandler.java
I am intercepting messages that are sent through JBossESB. I am using pipeline interceptors to do so.
The problem is, that altough the sender is a service (for example PortReference < logical:BlueServiceESB#BlueListener >), the name of the receiver is a queue (not a service). That is logical because in some case, multiple services can receive messages from a given queue, but usually, each queue is mapped to only one service.
I would like to know which queue is mapped to which service, so I can display/save this information and have it displayed like message: service ---> service (not service ---> queue).
I know that I can get the name of the queue mapped to a service using the registry like this:
System.setProperty("javax.xml.registry.ConnectionFactoryClass", "org.apache.ws.scout.registry.ConnectionFactoryImpl");
// Retrieving information from the ESB Registry
Registry reg = RegistryFactory.getRegistry();
System.out.println(reg.findAllServices());
List<EPR> eprs = reg.findEPRs("FirstServiceESB", "SimpleListener");
System.out.println(eprs);
I would like to reverse this approach - queue is the input and service (EPR = end point reference = service) is the output. Is there any way how to do this or am I just trying to do the impossible here. I have found no tutorials or questions on this topic whatsoever.
Thanks for any tips!
As this question has 25 up-votes, this seems to be an useful feature. JBossESB is open source software. Thus, implement the feature yourself and commit it to the community! Or just create a change request hopping that somebody else will do it...
Try querying for all of the queues and building a reverse-lookup map. But I don't think there is any function that allows searching for services using a queue.
I am trying to implement a simple chat application that connects clients through a central server, with other client so they can exchange messages and files. I also need to implement a notification framework. for example, if a user signs successfully, or if a buddy of him signs in he get a notification.
Now in the RMI world how is this implemented?
I was thinking of having a remote object "connection class" that the clients call methods from it like "login in", "disconnect" etc...
And as for the notification framework classes do they have to be remote too? or can they lie in the server?
thanks
Event messaging between remote systems is a bit tricky. Here's what has to happen:
The client must register interest in the events fired on the server side. To register, the client must be remotely available to the event source object.
In order to be able the register, the client must find the server to begin with, so the server object must be remotely available to the client.
Ick, right? And that's the simple pattern for implementing remote event handling.
A few weeks ago I started a tutorial that was heade down this path -- it's right here, and I'm hoping to add something to it before the end of the week. Alas, the need to make the rent has interfered and I'm not able to add to it as quickly as I'd like.
If you can't wait, however, that's the key: both sides have to be remotely available for the messaging system to work.
that server as well as the client must be remote objects.
Let all clients implement a Remote interface.
RemoteClientIfc extends Remote {
void inform();
}
//have a remote method register() on the *Server* object which accepts RemoteClientIfc.
//c'd be something like this...
register(RemoteClientIfc client){
arrayListofClients.add(client);
}
//So client will do a look up on the remote server object and register itself.
remoteObj.register(clientInstance);
//In the remote server you
//can probably have another method to send notifications to the client.
//Run through the ArrayList and call
//inform() on each of them.
//Thus the client will receive notification.
tellClients(){
Iterator i = ....
while (i.hasNext()){
((RemoteClientIfc).i.next()).inform();
}
}