Reverse proxy blocked connection after 503
by paroczizs .
Hi Undertow-dev,
we are using the Wildfly(10.1)/Undertow as reverse proxy and facing the
following issue:
The back end hots behind the reverse proxy are load balanced and ssl
terminated by HaProxy. When the real back ends are shutdown the Undertow
responds the request immediately with 503 error that sends by the HaProxy.
This behavior happens as many times as many connections are set to the
reverse proxy. After the max connections/thread are exceeded the responses
are stucked and wit for the connection timeout. It seems to me that after
the 503 may the HaProxy wants to close the socket but the Undertow keeps it
alive but not allow to be accessed by new request. It is released after a
while my the operating system free the socket or there are default idle
timeout and the undertow renew the stucked connections.
Are there any configuration that solves the above issue?
Thank you forward, Zsolt
3 years, 10 months
Cannot Add the alpn-boot jar to WildFly's Boot Classpath
by Hanan Othman
Hello undertow-dev,
I'm trying to use WildFly to send a push notification to iOS devices, which
requires the use of HTTP/2. Using OkHttp (http://square.github.io/okhttp/),
I was able to send a request successfully in an external java project using
the JVM option: -Xbootclasspath/p:<path-to-alpn-boot-jar>.
After checking the documentation here: http://undertow.io/blog/
2015/03/26/HTTP2-In-Wildfly.html, I was unable to do the same in WildFly.
When I run the server I get:
okhttp3.OkHttpClient -- ALPN callback dropped: SPDY and HTTP/2 are
disabled. Is alpn-boot on the boot class path?
which leads me to think that it is not actually on the classpath. I have
the same configuration as that in the blog post, except having Wildfly
10.0.1.Final instead of Wildfly 9.0.0.Beta1. I have the correct alpn-boot
jar version since it already works outside of WildFly, but I do not know
what else I could be missing. Thank you very much for your time.
Best,
Hanan
3 years, 10 months
Proxing with SSL Termination
by Zamir, Alon
Is there an SSL Termination support to be used in conjunction with reverse proxy server ?
I'd like to implement an SSL server which terminates the SSL request and proxies plain HTTP to a remote server.
3 years, 10 months
ClassCastException when retrieving a beans from CDI with Weld Proxy beans
by Eric B
I posted this problem on StackOverflow, but after doing more research, I'm
not sure if this is a Weld, JBoss/WildFly or undertow issue. Or whether
its a framework issue, or how the framework is being used. If this is not
the correct list, can you please let me know which list/group I should be
directing the issue to?
I'm running into a strange problem and error message that I do not
understand. I'm running my application on JBoss 7 EAP.
Caused by: java.lang.ClassCastException: Cannot cast
ejbs.LoginManager$417755913$Proxy$_$$_Weld$EnterpriseProxy$ to
ejbs.LoginManager
I'm trying to programatically retrieve an EJB from the CDI context by using
its interface and am getting this error message. I've created a sample
proof-of-concept that is trying to retrieve EJB beans from the CDI context
public <T> T getSesionBean(Class<T> clazz, String name) {
Properties properties = new Properties();
try {
InitialContext initContext = new InitialContext();
return clazz.cast(CDI.current().select(clazz).get());
} catch (Exception e) {
// TODO Auto-generated catch block
throw new RuntimeException(e);
}}
It is being called as:
LoginManager login = getSesionBean(LoginManager.class);
with my EJB defined as:
@Stateless(name="LoginManager")@Local(LoginManager.class)(a)LocalBinding(jndiBinding="LoginManager")public
class LoginManagerBean implements LoginManager {.........}
I don't understand it. I'm expecting the bean being retrieved from the
context to be a proxy. Shouldn't it be castable to my interface? Otherwise,
how am I supposed to retrieve it?
More interestingly, this does not seem to be a consistent error; sometimes
the code works fine. Sometimes it fails. I haven't been able to determine
what makes it work or throw an exception.
I found a related issue here <https://issues.jboss.org/browse/WELD-1498>,
but not sure if this is the same problem and/or which version of Weld is
used in JB7EAP. I'm including the following dependency in my application:
<dependency>
<groupId>org.wildfly</groupId>
<artifactId>wildfly-ejb-client-bom</artifactId>
<version>10.1.0.Final</version>
<type>pom</type>
</dependency>
Am I doing something completely wrong? If this is a Weld bug, can I use a
different proxy system than Weld? Is this even configurable in undertow?
Thanks,
Eric
3 years, 10 months
ClosedChannelException
by Hicks, Matt
I seem to be experiencing a lot of:
[XNIO-1 task-40] ERROR i.y.E.defaultHandler.???:23 -
java.nio.channels.ClosedChannelException
at io.undertow.protocols.ssl.SslConduit.write(SslConduit.java:369)
at
org.xnio.conduits.ConduitStreamSinkChannel.write(ConduitStreamSinkChannel.java:150)
at
org.xnio.http.HttpUpgrade$HttpUpgradeState$StringWriteListener.handleEvent(HttpUpgrade.java:385)
at
org.xnio.http.HttpUpgrade$HttpUpgradeState$StringWriteListener.handleEvent(HttpUpgrade.java:372)
at
org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
at
org.xnio.conduits.WriteReadyHandler$ChannelListenerHandler.writeReady(WriteReadyHandler.java:65)
at
io.undertow.protocols.ssl.SslConduit$SslWriteReadyHandler.writeReady(SslConduit.java:1225)
at io.undertow.protocols.ssl.SslConduit$3.run(SslConduit.java:275)
at org.xnio.nio.WorkerThread.safeRun(WorkerThread.java:580)
at org.xnio.nio.WorkerThread.run(WorkerThread.java:464)
I'm not positive this is connected to my update to 1.4.12.Final, but I
wanted to check to see if this is something anyone else is seeing? It's
likely it's related to my code, although I have no idea what I would have
changed to cause this.
3 years, 10 months
undertow 1.4.X docs
by Grzegorz Pietrusza
Hi undertow-dev
Is undertow 1.4.X production ready? I see it's released in maven central,
but it's not documented or mentioned anywhere at undertow.io.
Regards
Grzegorz
3 years, 10 months
Is it ok to do a blocking action from a Receiver callback?
by Michael Grove
If I have some code ala
theRequest.getRequestReceiver().receiveFullString((theExchange, str) -> {
...
});
Is it ok to perform a time consuming task w/ the body of the request in the
callback, or is it better to move off the io thread and use
`HttpServerExchange.getInputStream`?
Cheers,
Mike
3 years, 11 months
