How to get errorcode when attempting to connect a server which is down using vertx-eventbus.js

92 views
Skip to first unread message

Oren Shvalb

unread,
Nov 12, 2016, 1:02:24 PM11/12/16
to vert.x
Hi guys,

Pretty much the first scenario you try to develop when interacting between javascript client side and application server side.

I'm using the following code:

var eb = new EventBus(address, {"vertxbus_ping_interval": 300000});
eb
.onopen = function() {
  console
.info("Connection established");
};

eb
.onerror = function(err) {
    console
.error("CONNECTION ERROR=" + JSON.stringify(err));
};


It works if the server I'm trying to connect is available.

*BUT* if server is down, you don't get any kind of results, just the following error in the console:

sockjs.js:1622GET http://localhost:8080/sbg_eventbus/info?t=1478973660958 net::ERR_CONNECTION_REFUSED

Here is part of the stack:

AbstractXHRObject._start@sockjs.js:1622
(anonymous function)@sockjs.js:1511
setTimeout (async)
AbstractXHRObject@sockjs.js:1510
XHRCorsObject@sockjs.js:2886
InfoAjax@sockjs.js:356
InfoReceiver._getReceiver@sockjs.js:539
InfoReceiver.doXhr@sockjs.js:556
(anonymous function)@sockjs.js:525
setTimeout (async)
InfoReceiver@sockjs.js:524
SockJS@sockjs.js:730
EventBus@vertxbus-3.2.0.js:79
ServerConnector@server_connector.js:5


Any idea what I'm doing wrong and how to get some kind of indication that server is down?

Thank you!

Oren Shvalb

unread,
Jan 3, 2017, 12:08:26 PM1/3/17
to vert.x
Anyone?!?

Paulo Lopes

unread,
Jan 9, 2017, 5:15:19 AM1/9/17
to vert.x
I guess a try catch around you line #5 would allow you to catch the exception?

Oren Shvalb

unread,
Jan 9, 2017, 9:07:25 AM1/9/17
to ve...@googlegroups.com
Thank you I'll try that.

Paulo, Could you please tell me how to complete my pull request 
#488 - I really want this one to enter the next version.


--
You received this message because you are subscribed to a topic in the Google Groups "vert.x" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/vertx/7lFkwdgAHhI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to vertx+unsubscribe@googlegroups.com.
Visit this group at https://groups.google.com/group/vertx.
To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/4a27c06a-0f54-4234-b684-2a6fcbf0d0a8%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

Oren Shvalb

unread,
Jan 9, 2017, 9:26:46 AM1/9/17
to ve...@googlegroups.com
Wrapping the 'onclose' with try/catch didn't work for me
It never reaches the catch clause.

I finally ended up using a 3 sec timeout as a workaround...not so elegant but at least it works.

Cheers.

Sent from my iPhone
--
You received this message because you are subscribed to a topic in the Google Groups "vert.x" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/vertx/7lFkwdgAHhI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to vertx+un...@googlegroups.com.

Henrik Östman

unread,
Jan 10, 2017, 4:38:05 PM1/10/17
to vert.x
I use:
        eb.onclose = function () {
            console.debug('connection closed!');
            setTimeout(setupConnection, 2000);
        };

And it work pretty well for me. 

Oren Shvalb

unread,
Jan 10, 2017, 4:58:12 PM1/10/17
to ve...@googlegroups.com
Does it work for the following case:

Load you client-side app when the sever is down. Are you able to catch the exception or anything else that you can use in order to display some kind of error message?

--
You received this message because you are subscribed to a topic in the Google Groups "vert.x" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/vertx/7lFkwdgAHhI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to vertx+unsubscribe@googlegroups.com.

Henrik Östman

unread,
Jan 11, 2017, 7:03:44 PM1/11/17
to vert.x
I currently have a very basic client implementation where I catch no errors, however I do listen to onclose events to try reestablish the connection to the server. The connection could be lost during restart of server, poor mobile connection, or mobile going to sleep, among other scenarios. Since the same Vert.x application hosts the client I can't load the client without the server running, however if I shut down the server after the client have loaded I can see alot of connection attempts in the browser console, e.g:

sockjs.min.js:27 GET http://<my host>/eventbus/info 502 (Bad Gateway)u._start @ sockjs.min.js:27(anonymous function) @ sockjs.min.js:27
app.js:234 connection closed!     <---- this is printed out when "onclosed" is called.
app.js:210 connecting...   <--- I then after 2 seconds try to reconnect.

These three lines above repeats until I start the server again and a "onopen"-event is triggered where as I reregister the handler: "eb.registerHandler(....)".

It's working very well for being such a simple implementation.

To unsubscribe from this group and all its topics, send an email to vertx+un...@googlegroups.com.

Oren Shvalb

unread,
Jan 11, 2017, 9:39:15 PM1/11/17
to ve...@googlegroups.com
What about a case where you server is in maintenance and client tries to connect, How it works for this case?

To unsubscribe from this group and all its topics, send an email to vertx+unsubscribe@googlegroups.com.

Henrik Östman

unread,
Jan 13, 2017, 5:45:23 PM1/13/17
to vert.x
It depends on what you mean with "How it works" and what the "client" is.

My Vert.x application runs on a Raspberry Pi, the clients are mobile phones, tablets, and desktop computers running a web browser.
1. If the server goes down and a client tries to connect, it receives a "service down"-page that are provided by the Nginx reverse proxy that sits in front of my Raspberry Pi server.
2. If the client has downloaded the application and are running it in the web browser when the server goes down, it work as I haved described before with the client trying to reestablish the connection to the server endlessly.
Visually for the user I flip a icon between connected and disconnected depending on if "onopen" or "onclose" was executed last, so the user can see if he/she are connected or not.

In case #1, I have plans to cache the client code in a "service worker"(https://developers.google.com/web/fundamentals/getting-started/primers/service-workers) that would allow the user to start the webapp and use old cached data even if the server is down, and then receive fresh data when the server comes up. The next best thing it to host all static files (HTML, Javascript, CSS) on a separate web server, that would allow the client to load the webapp while the Vert.x API-service is down, old data could be cached and used from LocalStorage.

// Henrik

Oren Shvalb

unread,
Jan 13, 2017, 11:11:17 PM1/13/17
to ve...@googlegroups.com
Thanks Henrik,

Seems like you have it all figured out nicely :-)

To unsubscribe from this group and all its topics, send an email to vertx+unsubscribe@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages