By default, applications in wildfly are deployed to localhost:8080/app. How to deploy application on dedicated port, i.e. open it on localhost:8282 without application name ending?
I need to change the port for certain application, not the default port.
I have not tried this, but AFAICT it should be possible to:
run a single Wildfly instance listening on multiple HTTP ports. This is, in theory at least, possible (ref: https://developer.jboss.org/thread/233414?start=0&tstart=0)
Configure undertow subsystem as a reverse proxy, and proxy your app to the other port/location (ref: http://www.mastertheboss.com/jboss-server/wildfly-8/configuring-a-reverse-proxy-with-undertow). That said, I have never used undertow for a reverse proxy and as such cannot speak for whether this really works.
Once you have done this, you have effectively just turned your Wildfly instance into an overly complex application server and reverse proxy in one. Ultimately however, the app in question would still be running on both ports, but you redirect the traffic using the proxy the way you would like.
The same proxy configuration in an Apache (ref: https://httpd.apache.org/docs/current/mod/mod_proxy.html#forwardreverse or https://www.leaseweb.com/labs/2014/12/tutorial-apache-2-4-transparent-reverse-proxy/) or NGINX (ref: https://www.nginx.com/resources/admin-guide/reverse-proxy/) would be IMHO less complex and better tested in countless production scenarios.
Related
The standard behaviour for wildfly-17 (and 18) with microprofile-health-smallrye is, that the /health endpoints are published under the management port.
Is there a way to configure it to use a different port?
That behaviour is difficult in some situations (with docker and kubernetes) to open up the management port completely, and make it accessible, for other "machines" than localhost.
Thanks in advance,
Gabriel
Jeff Mesnil answered my thread on the wildfly-user chat -> It is not possible to run health endpoint on application port. WildFly only expose them to the managment port.
Whilst I could not find a direct answer I did have a similar issue myself and implemented a solution.
I added the flag Dswarm.port.offset=100. For my thorntail set up this shifted all the port by 100.
My solution to publish metrics within a docker swarm, where port 9990 is not exposed, was to write a Proxy-Servlet registered under /metrics that returns the contents of http://127.0.0.1:9990/metrics.
That way you don't expose the whole admin panel, but only the metrics part.
I have read up on web sockets providing full duplex connections over TCP which can be used in scenarios where long polling was used to get live updates to client from server. Now I have a Tomcat based application which serves multiple REST based web service response, and I want couple of API's to be implemented using web sockets say to render dashboard with latest data where multiple users are working on them concurrently, is that possible ? My concern here was even if the connection was upgraded to TCP from HTTP wouldn't web socket require a separate port to run than the default Tomcat port 8080. In that case should I house the Web Socket based endpoints separate to the Tomcat based application already running. Please do correct me if any of the above is wrong.
A couple of month ago, I wrote a small Spring Boot webapp with embedded Tomcat that provides both, REST endpoints and websocket support, and both via the same port. So, yes that works... if you wanna sneak a peek: https://github.com/tommybrettschneider/pinterest-boot
Besides that, this post should also clarify things:
Shall I use WebSocket on ports other than 80?
I would like to create a web service with GoLang that runs either on IIS (7, 8 or 10) or under Tomcat 7.0. We have multiple environments, each with multiple servers, all being Windows 2008 R2, 2012 or 2016. All servers are private (10.x). My goal is to add some REST services to a COTS product that uses both IIS and Tomcat. I'd prefer to avoid gluing nginx or something else onto either server at the risk of impairing the COTS product or having their tech support people not answer the phone. Again .. the servers are only accessible via corporate VPN and are not public internet-facing.
Which server would offer the easiest path to get something working -- Tomcat or IIS?
That's not really about Go, but still there exist at least two solutions I can think of:
Reverse proxying of HTTP requests.
Write a plain Go server serving requests via HTTP.
Maybe turn it into a proper Windows service using golang.org/x/sys/windows/svc.
Deploy it.
If it's to be hosted on the same machine which runs IIS, then it's fine to make it listen on localhost only. Note that it will need a dedicated TCP port to listen on, and you'll need to make it possible for your server to be somehow configurable in this regard.
Set up reverse proxying in your IIS so that it forwards requests coming to whatever (part of an) URL you want to the Go server.
Use FastCGI.
Go supports serving requests over the FastCGI
protocol by means of its standard library,
and IIS suports FastCGI workers.
So it's possible to (re-)write your Go server to use FastCGI
instead of HTTP and then hook it into IIS via this protocol.
The pros and cons of these solutions—as I view them—are:
Serving over plain HTTP is more familiar to a developer and
makes the server more "portable"—in the sense it will be easier to change its deployment scheme if/when you'll need it.
Right to making it available to the Internet directly.
Conversely, with FastCGI, you'll always need a FastCGI host as a "middleware".
There were rumors that HTTP code is more fine-tuned in terms
of performance than that of FastCGI.
Still, this only will be of concern for reasonably hard-core loads.
One possible upside of FastCGI over HTTP is that it can
be served over pipes rather than TCP. For instance, you might
get it served over named pipes as it's supported by IIS's FastCGI module and there exists 3rd-party packages for Go implementing support for them
(even including one from Microsoft®).
The upside of this is that pipes are beleived to incur lesser overhead for data transfer (basically it's just shoveling bytes between in-kernel buffers belonging to two processes instead of pushing them through the whole TCP/IP stack), and using pipes frees you from the need of dedicating a TCP port to the Go server.
Still, I have no personal experience with this kind of setup and its performance trade-offs.
I'm really struggling to know what the problem is here...
I have 2 websites configured in IIS...
**PH.Website** (STANDARD MVC PROJECT)
**PH.Api** (MVC WEB API PRIOJECT)
When you hit the PH.Website it uses a WebClient class in one of the controllers to download data from the PH.Api. However fiddler only sees traffic going to the PH.Website not the PH.Api.
After reading around on the internet I apparently have to do some configuration of the Syste.Net in the Web Api Project. So I added...
<system.net>
<defaultProxy>
<proxy
usesystemdefault="False"
bypassonlocal="True"
proxyaddress="http://PH.Api"
/>
</defaultProxy>
</system.net>
But still no luck. I know the request is happening I just cant see it.
Whats even more confusing is when I configure Fiddler to use Port 80 its says it cannot listen on that port. But hang on if it cant listen on 80 then how the hell can it see traffic on the Http port:80 anyway?
P.s. I really need to be able to run multiple sites locally so. I hate running sites under Localhost or 127.0.0.1 seems so silly when you can create seperate sites for everything in IIS and know exactly where everything maps....
Let's back up.
Fiddler's a proxy server; it sees all of the traffic that is sent to it. Generally speaking (unless you're using it as a Reverse Proxy) you never want to configure Fiddler to run on port 80; instead leave it up at port 8888 where it runs by default. You instead configure your client to proxy its traffic through Fiddler.
Now, what "reading around on the Internet" did you do that caused you to modify your machine.config or web.config file (you didn't mention which you edited)?
If your goal is to watch traffic with Fiddler, you need to point the ASP.NET proxy settings at Fiddler, not at whatever "PH.api" is (e.g. use "127.0.0.1:8888" and set bypassOnLocal to false). The further complexity arises in that System.NET bypasses the proxy for any request to "localhost" or "127.0.0.1", so if you're using those addresses for your target, you should change them to "localhost.fiddler" temporarily while debugging.
I'm stuck with jboss and blazeds clusterization.
What I have now is :
2 Jboss Instances, running in all mode
One load balancer with apache and mod_jk, as suggested by Jboss docs
A spring/flex integration app
A flex application that I do not want to throw errors when one of my JBoss instances falls
I find Adobe documentation really lacking, and being new at clustering, jgroups and balancing I cannot find how to deploy my app in clustered environment.
Actually this solution is working fine with remote calls. If one of jboss instances goes down the rpc gets routed to the other instance. What is not working are push messages, cause if client is connected to JBossA, and JBossA goes down, client displays an error message, stating that it can't reach JBossA, when it should failover to JBossB, without the user noticing anything.
From what I understood if configured correctly blazeds should tell flex client about failover servers upon connection. Then if flex client can't connect to the main server it goes to another. But the hard part for me is getting there.
Can someone point me to the right direction?
Thanks in advance
If you have an apache web server sitting between the clients and the JBoss servers, with mod_jk handling communication between apache and JBoss, then that should be your failover requirements met already.
mod_jk will detect if any of the JBoss servers fails, and send requests to the other one. As far as the clients are concerned, they see a single server, which is the apache server. They see nothing of the JBoss servers behind it.
I know nothing about BlazeDS clustering, but I'm guessing it has some form of manual failover mechanism, which it tells clients about a list of server addresses, and the clients pick one that works. This should only be necessary if you don't have a mod_jk middleman, so hopefully you can just ignore the blazeds clustering.
Things can, of course, get a lot more complicated, such as when you need to JBoss servers to commnunicate amongst themselves (e.g. session replication, clustered JMS, distributed caching, etc), but if you don't need any of that, then you can safely ignore it.