All sockjs transports failing for many users

[steven winner]

I am testing the connection stability of vert.x and sockjs in our production environment to see how many connect/reconnect failures, and have been noticing that there are a decent amount of users not able to connect on ANY transport.  I have all the transports whitelisted, and it seems like all of the iframe transports are failing.

I am using vert.x 1.3.1 final, and sockjs 0.3.4

I have also been able to see this issue in firefox 21 and chrome 27 (os x 10.8.4), by changing the transport whitelist to not include websockets and xhr/xdr etc)

protocols_whitelist: ["iframe-htmlfile", "iframe-eventsource", "iframe-xhr-polling", "jsonp-polling"]

The iframe-* transports/protocols are failing, which is the "best/only" transport available for a sizable portion of our user base.  Would really love to use vert.x/sockjs/eventbus if we can get these connection issues hashed out.

Also, we switched to ssl port 443 for what its worth, because we had read that connections were more stable.

Anyone have any experience with this?  

[steven winner]

Forgot to include the actual errors.  In firefox I am getting this:

Closed transport: iframe-eventsource SimpleEvent(type=close, code=1006, reason=Unable to load an iframe (onload timeout), wasClean=false)

And IE I am getting:

Closed transport: iframe-htmlfile SimpleEvent(type=close, code=2007, reason=Transport timeouted, wasClean=false)

[Tim Fox]

Can you try sockjs 0.2.1 - this is the version tested against for Vert.x
1.3.1 and specified in the documentation.

Also... can you try Vert.x 2.0.CR1 (with sockjs 0.3.4)?

[steven winner]

I was thinking about that, so I just changed sockjs to use 0.2.1, and all the iframe transports are still failing :-/

Opening transport: iframe-eventsource  url:https://rt.fling.com:443/rtn/053/nps4h4ma  RTO:324

rtbus.js (line 27)

Closed transport: iframe-eventsource SimpleEvent(type=close, code=2007, reason=Transport timeouted, wasClean=false)

rtbus.js (line 27)

Opening transport: iframe-xhr-polling  url:https://rt.fling.com:443/rtn/053/znlo1bu8  RTO:324

rtbus.js (line 27)

log: Closed transport: iframe-xhr-polling SimpleEvent(type=close, code=2007, reason=Transport timeouted, wasClean=false)

I also grabbed the latest version of master from git yesterday, and tried to build it, and while it said build was successful, this is what it said:

[ root @ statix ]: /tmp/vert.x-master

$ gradlew assemble

:vertx-core:compileJava

Note: /tmp/vert.x-master/vertx-core/src/main/java/org/vertx/java/core/net/impl/VertxEventLoopGroup.java uses or overrides a deprecated API.

Note: Recompile with -Xlint:deprecation for details.

Note: Some input files use unchecked or unsafe operations.

Note: Recompile with -Xlint:unchecked for details.

:vertx-core:processResources

:vertx-core:classes

:vertx-core:jar

:vertx-core:javadoc

:vertx-core:javadocJar

:vertx-core:sourceJar

:vertx-core:signArchives SKIPPED

:vertx-core:assemble

:vertx-platform:compileJava

/tmp/vert.x-master/vertx-platform/src/main/java/org/vertx/java/platform/impl/ModuleIdentifier.java:30: error: unmappable character for encoding ASCII

  private static final String LEGAL = "[A-Za-z0-9!??$()-_+=@~;,]+";

                                                  ^

/tmp/vert.x-master/vertx-platform/src/main/java/org/vertx/java/platform/impl/ModuleIdentifier.java:30: error: unmappable character for encoding ASCII

  private static final String LEGAL = "[A-Za-z0-9!??$()-_+=@~;,]+";

                                                   ^

:vertx-platform:processResources

:vertx-platform:classes

:vertx-platform:jar

:vertx-platform:javadoc

:vertx-platform:javadocJar

:vertx-platform:sourceJar

:vertx-platform:signArchives SKIPPED

:vertx-platform:assemble

:assemble

BUILD SUCCESSFUL

Total time: 55.955 secs

There is an error:

vert.x-master/vertx-platform/src/main/java/org/vertx/java/platform/impl/ModuleIdentifier.java:30: error: unmappable character for encoding ASCII

  private static final String LEGAL = "[A-Za-z0-9!??$()-_+=@~;,]+";

And when I try to run my code, it says that it is missing: org.vertx.java.deploy.Verticle

Not sure if that moved, or if the error messed up the build.

Any help of this is greatly appreciated.

[Tim Fox]

On 19/06/13 20:04, steven winner wrote:
> I was thinking about that, so I just changed sockjs to use 0.2.1, and all
> the iframe transports are still failing :-/

Can you see if the sockjs example in the distro works for you, after
whitelisting the websockets/polling transports?

Odd, never come across that before.

I guess it's due to the locale/default character encoding on your machine...

[Tim Fox]

I suspect your platform default character encoding is ASCII, not UTF-8 for some reason. You should be able to get Gradle to force to treat the file as UTF-8 as described here:

http://gradle.1045684.n5.nabble.com/How-do-I-configure-UTF-8-encoding-for-Java-compiler-td2636397.html

BTW what OS are you using?

[steven winner]

OS Version:

$ cat /etc/redhat-release

CentOS release 5.9 (Final)

Going to try to force the UTF-8 as detailed in your link... The sockjs/eventbus example included in the distro worked for me, but I haven't tried with whitelisting only the iframe transports.  I will give that a try, since it seems that the websockets and xhr/xdh polling works fine (so long as browser supports it)

[Tim Fox]

On 19/06/13 20:04, steven winner wrote:

> I was thinking about that, so I just changed sockjs to use 0.2.1, and all
> the iframe transports are still failing :-/
>
> Opening transport: iframe-eventsource url:https://rt.fling.com:443/rtn/053/nps4h4ma
> RTO:324
> rtbus.js (line 27)
> Closed transport: iframe-eventsource SimpleEvent(type=close, code=2007,
> reason=Transport timeouted, wasClean=false)
> rtbus.js (line 27)
> Opening transport: iframe-xhr-polling
> url:https://rt.fling.com:443/rtn/053/znlo1bu8 RTO:324
> rtbus.js (line 27)
> log: Closed transport: iframe-xhr-polling SimpleEvent(type=close,
> code=2007, reason=Transport timeouted, wasClean=false)
>
>
> I also grabbed the latest version of master from git yesterday, and tried
> to build it, and while it said build was successful, this is what it said:
> [ root @ statix ]: /tmp/vert.x-master
> $ gradlew assemble

Please use:

./gradlew dist

To build the distro (see BUILD_README.md) for more info.

Once you've built it, you need to install it as if you had just
downloaded it, i.e. unzip it somewhere and add the bin directory to your
PATH

[Tim Fox]

On 19/06/13 20:04, steven winner wrote:

> I was thinking about that, so I just changed sockjs to use 0.2.1, and all
> the iframe transports are still failing :-/
>
> Opening transport: iframe-eventsource url:https://rt.fling.com:443/rtn/053/nps4h4ma
> RTO:324
> rtbus.js (line 27)

One more question: what is rtbus.js?

[steven winner]

Oh... rtbus.js is just the minified version of sockjs, vertbus.js and my javascript that does the calling.  Just combines and minifies them into one file.  Have also tried without minifying, just in case that was a potential issue.

I am getting the original example setup to see if that fails for me.  Could the character encoding issue I encountered be related to the current problems I'm having with sockjs 0.2.1/vert.x 1.3.1 ?

[Tim Fox]

On 19/06/13 20:36, steven winner wrote:
> Oh... rtbus.js is just the minified version of sockjs, vertbus.js and my
> javascript that does the calling. Just combines and minifies them into one
> file. Have also tried without minifying, just in case that was a potential
> issue.
>
> I am getting the original example setup to see if that fails for me. Could
> the character encoding issue I encountered be related to the current
> problems I'm having with sockjs 0.2.1/vert.x 1.3.1 ?

It shouldn't do, but it's worth checking.

I notice you're running as root, any particular reason for that?

Perhaps try setting up the OS / user so Java uses a default char
encoding of UTF-8, and see what happens.

[steven winner]

I am going to try to fix the character encoding UTF-8 a try.  Would definitely like to see how the 2.0 version works.

The reason I run it as root, is because we use supervisord, to daemonize vert.x, so it will be run like an actual daemon/service, and restart if it quits, and provide additional functionality... and that needs to run as root (although it doesn't run vertx as root when it daemonizes it)

[steven winner]

Also, regarding the gradle character encoding... where do you put that option?  The link you provided says to include this:

[compileJava, compileTestJava]*.options.collect {options ->
options.encoding = 'UTF-8'}

But I am new to using gradle, and there are a few files (settings.gradle, gradle.properties etc...)

[Tim Fox]

On 19/06/13 20:55, steven winner wrote:

Also, regarding the gradle character encoding... where do you put that 
option?  The link you provided says to include this:

[compileJava, compileTestJava]*.options.collect {options -> 
options.encoding = 'UTF-8'} 

But I am new to using gradle, and there are a few files (settings.gradle, 
gradle.properties etc...)

It'll be somewhere in build.gradle, but tbh, Gradle baffles me still.. :(

If it's any easy, why not build on a different machine, or just use the CR2 binary I released the other day? (it's in bintray here: https://bintray.com/vertx/downloads/distribution/2.0.0-CR1 )

[steven winner]

Ok, so I downloaded the tarball from the link you provided, and tried to run it, and got the same error: 

$ /tmp/vert.x-2.0.0-CR1/bin/vertx run BridgeServer.java -cp "/opt/overseer/new/:/opt/overseer/new/mods/"

/opt/overseer/new/BridgeServer.java:12: error: package org.vertx.java.deploy does not exist

import org.vertx.java.deploy.Verticle;

                            ^

I extracted it to:

/tmp/vert.x-2.0.0.0-CR1/

And tried running my vert.x code with this:

/tmp/vert.x-2.0.0-CR1/bin/vertx run BridgeServer.java -cp "/opt/overseer/new/:/opt/overseer/new/mods/"

The java file BridgeServer.java (still the examples name, lol) is in /opt/overseer/new/, and I am using a mod I found to bind connects/disconnects to a sharedData variable.  Weird that I still get that same error.  Could the vert.x 1.3.1 install be interfering?

I am attaching the java file for reference.

There has to be something stupid going on here.  Any idea?

Thank you again for your help.

[steven winner]

So I took the tar.gz from the link you supplied me (for the recent 2.0 build), and tried it on my local machine (os x 10.8.4) and got the same results:

Jonathans-MacBook-Pro:vert.x-2.0.0-CR1 je$ /Users/je/vertx/vert.x-2.0.0-CR1/bin/vertx run BridgeServer.java -cp "/Users/je/vertx/vert.x-2.0.0-CR1/:/Users/je/vertx/vert.x-2.0.0-CR1/mods/"

/Users/je/vertx/vert.x-2.0.0-CR1/BridgeServer.java:12: error: package org.vertx.java.deploy does not exist

import org.vertx.java.deploy.Verticle;

                            ^

/Users/je/vertx/vert.x-2.0.0-CR1/BridgeServer.java:25: error: cannot find symbol

public class BridgeServer extends Verticle {

                                  ^

  symbol: class Verticle

There had been nothing on that machine for vert.x previously, which is why I wanted to try it on a machine with no previous vert.x installs. 

Any idea what could be causing this?

[steven winner]

I have noticed however, that the vertx-lang-java-1.3.1.final.jar file isn't there like it is in 1.3.1.  Was there a change, or is the tar.gz file not including that for some reason?

[Tim Fox]

On 19/06/13 22:35, steven winner wrote:
> Ok, so I downloaded the tarball from the link you provided, and tried to
> run it, and got the same error:
> $ /tmp/vert.x-2.0.0-CR1/bin/vertx run BridgeServer.java -cp
> "/opt/overseer/new/:/opt/overseer/new/mods/"
> /opt/overseer/new/BridgeServer.java:12: error: package
> org.vertx.java.deploy does not exist
> import org.vertx.java.deploy.Verticle;

That's because you're running the 1.x version of the example with vert.x 2.0

>> <https://bintray.com/vertx/downloads/distribution/2.0.0-CR1>

[Tim Fox]

On 19/06/13 23:32, steven winner wrote:

I have noticed however, that the vertx-lang-java-1.3.1.final.jar file isn't 
there like it is in 1.3.1.

You're running 2.0 so don't expect to see 1.3.1 jars there!

Vert.x 2.0 examples are here:

https://github.com/vert-x/vertx-examples

 
)
 <https://bintray.com/vertx/downloads/distribution/2.0.0-CR1> 

On Wednesday, June 19, 2013 3:45:36 PM UTC-4, steven winner wrote:

 I am going to try to fix the character encoding UTF-8 a try.  Would 
definitely like to see how the 2.0 version works.

The reason I run it as root, is because we use supervisord, to daemonize 
vert.x, so it will be run like an actual daemon/service, and restart if it 
quits, and provide additional functionality... and that needs to run as 
root (although it doesn't run vertx as root when it daemonizes it)

On Wednesday, June 19, 2013 3:41:14 PM UTC-4, Tim Fox wrote:

 On 19/06/13 20:36, steven winner wrote: 

 Oh... rtbus.js is just the minified version of sockjs, vertbus.js and 

 my 

 javascript that does the calling.  Just combines and minifies them into 

 one 

 file.  Have also tried without minifying, just in case that was a 

 potential 

 issue. 

I am getting the original example setup to see if that fails for me. 

  Could 

 the character encoding issue I encountered be related to the current 
problems I'm having with sockjs 0.2.1/vert.x 1.3.1 ? 

 It shouldn't do, but it's worth checking. 

I notice you're running as root, any particular reason for that? 

Perhaps try setting up the OS / user so Java uses a default char 
encoding of UTF-8, and see what happens. 

 On Wednesday, June 19, 2013 3:28:52 PM UTC-4, Tim Fox wrote: 

 On 19/06/13 20:04, steven winner wrote: 

 I was thinking about that, so I just changed sockjs to use 0.2.1, and 

 all 

 the iframe transports are still failing :-/ 

Opening transport: iframe-eventsource  url: 

 https://rt.fling.com:443/rtn/053/nps4h4ma 

    RTO:324 
rtbus.js (line 27) 

 One more question: what is rtbus.js? 


 Closed transport: iframe-eventsource SimpleEvent(type=close, 

  code=2007, 

  reason=Transport timeouted, wasClean=false) 
rtbus.js (line 27) 
Opening transport: iframe-xhr-polling 
   url:https://rt.fling.com:443/rtn/053/znlo1bu8  RTO:324 
rtbus.js (line 27) 
log: Closed transport: iframe-xhr-polling SimpleEvent(type=close, 
code=2007, reason=Transport timeouted, wasClean=false) 


I also grabbed the latest version of master from git yesterday, and 

 tried 

 to build it, and while it said build was successful, this is what it 

 said: 

 [ root @ statix ]: /tmp/vert.x-master 
$ gradlew assemble 
:vertx-core:compileJava 
Note: 


  /tmp/vert.x-master/vertx-core/src/main/java/org/vertx/java/core/net/impl/VertxEventLoopGroup.java 


  uses or overrides a deprecated API. 
Note: Recompile with -Xlint:deprecation for details. 
Note: Some input files use unchecked or unsafe operations. 
Note: Recompile with -Xlint:unchecked for details. 
:vertx-core:processResources 
:vertx-core:classes 
:vertx-core:jar 
:vertx-core:javadoc 
:vertx-core:javadocJar 
:vertx-core:sourceJar 
:vertx-core:signArchives SKIPPED 
:vertx-core:assemble 
:vertx-platform:compileJava 


  /tmp/vert.x-master/vertx-platform/src/main/java/org/vertx/java/platform/impl/ModuleIdentifier.java:30: 


  error: unmappable character for encoding ASCII 
    private static final String LEGAL = "[A-Za-z0-9!??$()-_+=@~;,]+"; 
                                                    ^ 


  /tmp/vert.x-master/vertx-platform/src/main/java/org/vertx/java/platform/impl/ModuleIdentifier.java:30: 


  error: unmappable character for encoding ASCII 
    private static final String LEGAL = "[A-Za-z0-9!??$()-_+=@~;,]+"; 
                                                     ^ 
:vertx-platform:processResources 
:vertx-platform:classes 
:vertx-platform:jar 
:vertx-platform:javadoc 
:vertx-platform:javadocJar 
:vertx-platform:sourceJar 
:vertx-platform:signArchives SKIPPED 
:vertx-platform:assemble 
:assemble 

BUILD SUCCESSFUL 

Total time: 55.955 secs 


There is an error: 


  vert.x-master/vertx-platform/src/main/java/org/vertx/java/platform/impl/ModuleIdentifier.java:30: 


  error: unmappable character for encoding ASCII 
    private static final String LEGAL = "[A-Za-z0-9!??$()-_+=@~;,]+"; 

And when I try to run my code, it says that it is 
missing: org.vertx.java.deploy.Verticle 

Not sure if that moved, or if the error messed up the build. 

Any help of this is greatly appreciated. 



On Wednesday, June 19, 2013 2:48:03 PM UTC-4, Tim Fox wrote: 

 Can you try sockjs 0.2.1 - this is the version tested against for 

 Vert.x 

 1.3.1 and specified in the documentation. 

Also... can you try Vert.x 2.0.CR1 (with sockjs 0.3.4)? 

On 19/06/13 19:42, steven winner wrote: 

 Forgot to include the actual errors.  In firefox I am getting this: 

Closed transport: iframe-eventsource SimpleEvent(type=close, 

 code=1006,reason 

 =Unable to load an iframe (onload timeout), wasClean=false) 

And IE I am getting: 

Closed transport: iframe-htmlfile SimpleEvent(type=close, 

   code=2007, 

  reason= 

 Transport timeouted, wasClean=false) 




On Wednesday, June 19, 2013 2:28:40 PM UTC-4, steven winner wrote: 

 I am testing the connection stability of vert.x and sockjs in our 
production environment to see how many connect/reconnect failures, 

  and 

 have 

 been noticing that there are a decent amount of users not able to 

 connect 

 on ANY transport.  I have all the transports whitelisted, and it 

  seems 

 like 

 all of the iframe transports are failing. 

I am using vert.x 1.3.1 final, and sockjs 0.3.4 

I have also been able to see this issue in firefox 21 and chrome 

   27 

 (os 

 x 

 10.8.4), by changing the transport whitelist to not include 

  websockets 

 and 

 xhr/xdr etc) 

protocols_whitelist: ["iframe-htmlfile", "iframe-eventsource", 
"iframe-xhr-polling", "jsonp-polling"] 

The iframe-* transports/protocols are failing, which is the 

  "best/only" 

  transport available for a sizable portion of our user base.  Would 

 really 

 love to use vert.x/sockjs/eventbus if we can get these connection 

 issues 

 hashed out. 

Also, we switched to ssl port 443 for what its worth, because we 

   had 

  read 

 that connections were more stable. 

Anyone have any experience with this? 




      
 

[Tim Fox]

Can you follow the instructions in the installation guide for installing
vert.x?

(I.e. unzip it somewhere and add the bin directory to your path)

Then to run the example (please see the example README for explanation
of this), you need to cd to the directory above where the BridgeServer
example is and execute

vertx run eventbusbridge/BridgeServer.java

It should be pretty straightforward

On 19/06/13 23:16, steven winner wrote:

>>> <https://bintray.com/vertx/downloads/distribution/2.0.0-CR1>

[steven winner]

Ok, so I now have vert.x 2.0 running.  The issue was with the changes from 1.3.1 -> 2.0.  Had to change my imports and the way a few things are called:

#version 1.3.1
import org.vertx.java.deploy.Verticle;

#version 2.0
import org.vertx.java.platform.Verticle;

That was why I was getting the error:

error: package org.vertx.java.deploy does not exist

Also, just incase this helps someone else that is trying to build using gradle, and is getting the error

/tmp/vert.x-master/vertx-platform/src/main/java/org/vertx/java/platform/impl/ModuleIdentifier.java:30: error: unmappable character for encoding ASCII

 private static final String LEGAL = "[A-Za-z0-9!??$()-_+=@~;,]+";

                                                 ^

/tmp/vert.x-master/vertx-platform/src/main/java/org/vertx/java/platform/impl/ModuleIdentifier.java:30: error: unmappable character for encoding ASCII

 private static final String LEGAL = "[A-Za-z0-9!??$()-_+=@~;,]+";

                                                  ^

You can fix it with this:

export JAVA_TOOL_OPTIONS=-Dfile.encoding=UTF8

[steven winner]

That being said, I am still having the same issues while trying to force the iframe transports:

Opening transport: iframe-eventsource  url:http://domain.com/rtn/093/8gt39iyp  RTO:283 rtbus.js:288

Closed transport: iframe-eventsource SimpleEvent(type=close, code=2007, reason=Transport timeouted, wasClean=false) rtbus.js:288

Opening transport: iframe-xhr-polling  url:http://domain.com/rtn/093/g6cqgar8  RTO:283 rtbus.js:288

Closed transport: iframe-xhr-polling SimpleEvent(type=close, code=2007, reason=Transport timeouted, wasClean=false) rtbus.js:288

and in firefox:

Opening transport: iframe-eventsource  url:http://domain.com/rtn/722/vbplsj23  RTO:555

rtbus.js (line 288)

Closed transport: iframe-eventsource SimpleEvent(type=close, code=1006, reason=Unable to load an iframe (onload timeout), wasClean=false)

rtbus.js (line 288)

log: Opening transport: iframe-xhr-polling  url:http://domain.com/rtn/722/ntqesf7i  RTO:555

rtbus.js (line 288)

Closed transport: iframe-xhr-polling SimpleEvent(type=close, code=1006, reason=Unable to load an iframe (onload timeout), wasClean=false)

rtbus.js (line 288)

I even tried to increase the timeout in sockjs (which is a bad idea), but that had no effect.

Any ideas why these iframes are timing out? or how to fix this?

[Tim Fox]

Have you tried the sockjs example in the distro, after whitelisting
everything other than iframe?

On 20/06/13 19:14, steven winner wrote:
> That being said, I am still having the same issues while trying to force
> the iframe transports:
>
> Opening transport: iframe-eventsource url:http://domain.com/rtn/093/8gt39iyp

> RTO:283 rtbus.js:288 <http://swinner.www.fling.com/js/1371749062/rtbus.js>

> Closed transport: iframe-eventsource SimpleEvent(type=close, code=2007,

> reason=Transport timeouted, wasClean=false) rtbus.js:288<http://swinner.www.fling.com/js/1371749062/rtbus.js>
> Opening transport: iframe-xhr-polling
> url:http://domain.com/rtn/093/g6cqgar8 RTO:283 rtbus.js:288<http://swinner.www.fling.com/js/1371749062/rtbus.js>

> Closed transport: iframe-xhr-polling SimpleEvent(type=close, code=2007,
> reason=Transport timeouted, wasClean=false) rtbus.js:288

> <http://swinner.www.fling.com/js/1371749062/rtbus.js>

[steven winner]

Just tried the eventbusbridge/BridgeServer.java example with whitelisting only the iframe transports (not having issues with websocket or xhr/xdr).  The iframe-eventsource seems to be working.  Could there be an issue with me creating two servers on two different ports in the same verticle?

I'm attaching my code for reference.

[Tim Fox]

On 20/06/13 19:37, steven winner wrote:
> Just tried the eventbusbridge/BridgeServer.java example with whitelisting
> only the iframe transports (not having issues with websocket or xhr/xdr).
> The iframe-eventsource seems to be working. Could there be an issue with
> me creating two servers on two different ports in the same verticle?

That could indeed cause problems - Vert.x will round robin connections
between the two servers, so let's say your client makes a connection to
the sockjs server, then opens another connection to the same host:port
it might end up on the other server which won't know what to do with it.

[steven winner]

Ok, I separated the two servers, but now if they are run as separate instances (opening two terminal/ssh sessions and running each) they don't seem to be sharing the data in the sharedData, but it seems that the iframe transports are working, although its hard to verify, since the other server is what I was using to as a REST api server, which our site's API will use to send out data on the eventbus to the clients that are registered to channel/address X and have a javascript handler that will handle the data.  It seems that they aren't sharing the eventbus though.  If it is necessary to separate the two, how would I go about doing what I have in my RtServer.java code?  Basically having a REST server with the RouteMatcher used to send/publish to the event bus?

[steven winner]

I hate it when someone finally figures the solution out, and doesn't update the thread, so here it goes...

I finally got this working correctly.  What a ride, lol.  Basically the problem I was having, was that I was running two different http servers, in the same Verticle.  While this was working fine for websockets, and xhr/xdr-steaming/polling, it wasn't working with any of the iframe transports/protocols, in any browser (ff,chrome, etc...)

After getting vert.x-2.0.0-CR1 running (which may have had nothing to do with the fix, not sure), and converting my code to 2.0 (Verticle isn't in java.deploy.Verticle anymore, it's in java.platform.Verticle etc...), I was still not able to get the iframe transports to connect.  So as Tim suggested, I separated the two servers.  One RESTful api server on one port, which we will hit from the api of our website to send data to the users who are online, and the other server for the sockjs eventbus bridge server, that the browser/javascript client will connect to on another port (over ssl, for what its worth).  But you can't launch two different Verticles, in two different JVM instances and have them communicate (sharedData, eventbus), so you need to launch the other Verticle, from the other like so:

container.deployVerticle("RtApiServer.java");

The "RtApiServer.java" is the other java file in the same directory I launch the first Verticle from.  

Seems like the moral of the story here is to separate your Verticles (if you need more then one server like I did) and programmatically launch any other Verticles you need, so they are all running in the same JVM.  At least this is my understanding of it, but it seems to be working like this.

Going to release this in the wild (I am logging disconnects/failures/reconnects, etc...).  Will update to see how it holds up against real users.

Thanks again Tim for your quick response time.  I really appreciate it.

[Tim Fox]

Glad it's working now :)

Some comments below...

On 20/06/13 22:56, steven winner wrote:
> I hate it when someone finally figures the solution out, and doesn't update
> the thread, so here it goes...
>
> I finally got this working correctly. What a ride, lol. Basically the
> problem I was having, was that I was running two different http servers, in
> the same Verticle. While this was working fine for websockets, and
> xhr/xdr-steaming/polling, it wasn't working with any of the iframe
> transports/protocols, in any browser (ff,chrome, etc...)
>
> After getting vert.x-2.0.0-CR1 running (which may have had nothing to do
> with the fix, not sure), and converting my code to 2.0 (Verticle isn't in
> java.deploy.Verticle anymore, it's in java.platform.Verticle etc...),

Yep, there are major API changes between 1.x and 2.0

> I was
> still not able to get the iframe transports to connect. So as Tim
> suggested, I separated the two servers. One RESTful api server on one
> port, which we will hit from the api of our website to send data to the
> users who are online, and the other server for the sockjs eventbus bridge
> server, that the browser/javascript client will connect to on another port
> (over ssl, for what its worth). But you can't launch two different
> Verticles, in two different JVM instances and have them communicate
> (sharedData, eventbus), so you need to launch the other Verticle, from the
> other like so:
>
> container.deployVerticle("RtApiServer.java");
>
> The "RtApiServer.java" is the other java file in the same directory I
> launch the first Verticle from.
>
> Seems like the moral of the story here is to separate your Verticles (if
> you need more then one server like I did)

Actually, your use case should work just by making sure the sockjs
server and your other http server are listening on different ports, even
if they are in the same verticle instance.

However, I think you've done the right thing in separating them out into
separate Verticles as this makes your app scale better. Having them in
one verticle will mean both those servers share a single event loop
(single thread).

> and programmatically launch any
> other Verticles you need, so they are all running in the same JVM.

This is a common pattern in Vert.x - split your application into several
verticles / modules and start them with a "starter" verticle which
basically just starts the other verticles. This is discussed in the docs.

I also recommend packaging your entire app as a module - this
encapsulates it better. The Vert.x 2.0 mods manual goes into a
discussion on this.

> At
> least this is my understanding of it, but it seems to be working like this.
>
> Going to release this in the wild (I am logging
> disconnects/failures/reconnects, etc...). Will update to see how it holds
> up against real users.
>
> Thanks again Tim for your quick response time. I really appreciate it.

No problem!