Not working on Wildlfy 9CR2

sunchanras commented 9 years ago

Hi Stuart, I followed your instruction to set up Wildlfy as front end load balancer. Here I used only single machine to create 3 virtual servers just like in your instruction, I turned off firewall, and checked every thing is ok, but no luck, it did not work. The front end load balancer server(load-balancer) did not forward request to two other servers(backend1, backend2).

Chanras

Darsstar commented 9 years ago

I got it working with one additional command:

/host=master/system-property=jboss.bind.address:add(value=192.168.1.4, boot-time=false)

Worked on a Windows machine with a freshly unzipped 9.0.1.Final. I had it as the first command I executed, I changed the IP of course.

Then go to http://192.168.1.4:8080/clustering-demo/ (localhost/127.0.0.1 won't work)

mheitnrw commented 9 years ago

Did not get it working on 9.0.0.Final, 9.0.1.Final and 10.0.0.Beta2-0 on Windows 7 and Oracle JDK 1.8.0_60.

On 9.0.0 the applications deployed on back ends seem not to get registered on the front end (if I recall correctly).

On 9.0.1 the front end log says the back end contexts are registered but when trying to access them, it replies 404.

On 10.0.0.Beta2 the front end fails to start undertow service due to a null pointer exception at org.wildfly.extension.undertow.filters.ModClusterResource.getChildrenName s(ModClusterResource.java:136) (this seems to have been fixed in the mean time).

Karm commented 9 years ago

@mheitnrw @Darsstar @sunchanras Guys, Undertow mod_cluster proxy works just fine with the latest Wildfly 10 and Undertow 1.3.0.Beta9+

One needs to:

confifure advertising multicast socket binding
create mod-cluster filter in the Undertow subsystem
add this filter to Undertow's host

Last but not least, do not use 127.0.0.1/localhost interface binding for your tests; it messes up UDP multicast on most operating systems.

If you are uncertain as to how to actually set it up, reply here or on JBoss.org forum and I'll furnish you with step-by step JBoss CLI example.

Cheers -K-

mheitnrw commented 9 years ago

Hello Karm,

thanks for your feedback.

Example worked fine with a build from https://ci.jboss.org/hudson/job/WildFly-latest-master/.

EJB services do not seem to get registered at the front end though.

Do I have to something in order to make EJB service deployed on the back ends available via the front end?

Or doesn't the "mod-cluster"-filter support this?

Cheers Michael

Karm commented 9 years ago

@mheitnrw Hmm, I'm lost. What to you mean by EJB services? Application server worker reports contexts of deployed web applications to the application server balancer. It has nothing to do with JNDI paths. For example, if you have an EAR with a JAR containing your EJBs and business logic and then a WAR containing your servlets, e.g. REST endpoints, then these web app contexts are reported to the balancer.

mheitnrw commented 9 years ago

Thanks for the explanation, @Karm, and sorry for the confusion.

I have a remote EJB client application, not a web application. My shop wants that application servers processing sensitive data are not directly accessible by clients. So I'm looking for something that I can put between the application servers and the clients. Mod_cluster or mod_proxy for Apache HTTPD don't work for that. Remote EJB is HTTP based since Wildfly 8 so I thought maybe this would somehow be supported in mod_cluster for Wildfly.

Karm commented 9 years ago

@mheitnrw Now I see. Well, no, this is not implemented at the moment. On the other hand, it is definitely not impossible. One could picture similar HTTP-upgrade scenario as with, e.g. WebSockets where mod_cluster upgrades the HTTP connection to WebSockets protocol and opens a connection to a worker node. The caveat with contextual, non-request-response protocols is that the balancer does not offer high availability, i.e. once a worker dies, the client must reconnect to the proxy to do a handshake to another worker node (at least this is the situation with WebSocket upgrade).

Regarding the EJB over HTTP proxying: You could create Feature request JIRAs for that. These are the projects involved:

Undertow mod_cluster proxy

i.e. Wildfly with Undertow acting as mod_cluster proxy
project: Undertow
you want a proxy support for HTTP upgrade to whatever EJB transport upgrades to (RMI)
this is optional - one could use Apache HTTP Server as a balancer

Mod_cluster subsystem

i.e. the worker part, the subsystem in your worker Wildfly cluster servers that needs to understand that it should report not only web application context, but also EJB paths
project: mod_cluster - java part
this is mandatory - the worker side code must be implemented regardless the balancer selected

Apache HTTP Server mod_cluster proxy

i.e. if you prefer to use Apache HTTP Server instead of Wildfly Undertow as a load balancing proxy, you need the supporting code in mod_cluster native modules
project: mod_cluster - native part
this is optional - one could use Undertow as a balancer

mheitnrw commented 9 years ago

@Karm, many thanks for writing this concise reply! I will try my luck requesting this for Apache HTTP mod_cluster (and Wildfly mod_cluster sub system). Should there be nobody interested in doing this, I'll try with Undertow mod_cluster, where I or colleagues might be able to contribute.

If you have tips about how to get this forward within the Wildfly community I'd be glad to hear it.

Karm commented 9 years ago

@mheitnrw, the best tip is to file a well written, thoroughly articulated Feature request JIRA and post about it on JBoss.org. GitHub comments are somewhat off the main communication highways.

mheitnrw commented 9 years ago

Thanks for your reply, @Karm.

sunchanras commented 8 years ago

@Karm Thank you, I got it worked on wildfly 10.RC4. But I am not sure if it's going to work with Websocket or not.

Best Regards, Sun Chanras

sunchanras commented 8 years ago

@Karm Everything is working properly except when I changed the root context of application to "/" (blank) the load balancing did not work any more. I found that, we can set root context of application to anything except "/" (blank). It's ok with "/foo","/bar","/f" so on. Anything except blank "/" Best Regards, Chanras

shillner commented 8 years ago

Hi, I'm a bit confused. Is this issue about remote EJB via the load balancer or the invocation of some web application paths via the load balancer? @sunchanras, which invocations did you get to work on WF10, webapp or EJB remote? Btw. the root context path is excluded in the modcluster subsystem, so "/" won't work for you.

Here is my problem, hopefully someone can help me: I have an application for which I need to setup the cluster with load balancing. Unfortunately some colleagues of mine are not willing to port the client-server communication to a REST-based approach. So the challange is now to request the EJBs through the load balancer. My setup so far is that I have a domain-based cluster with 3 hosts:

master: domain controller and load balancer
slave1: 2 servers with HA profile
slave2: 1 server with HA profile

With a sample application running on the cluster, I'm able to request EJBs directly from the slaves but not from the load balancer running on master. I've also read some articles about EJB client load balancing like this: Load-balancing and failover of remote EJB clients in EAP6 and JBoss AS7 But this is not exactly what I want to achive. The point is that the client-side load balancing approach only does round robin or whatever. It cannot look into the server as the server-sider load balancer does (CPU,MEM,REQUESTS,...). And furthermore it needs a cluster node configured as an entry point into the cluster. This should be the load balancer, or maybe two load balancers for failover, ...

So Is there a solution for that in sight?

Thanks and greetings Stanley

stuartwdouglas / modcluster-example