From miere.teixeira at gmail.com  Tue Sep  1 07:36:53 2015
From: miere.teixeira at gmail.com (Miere Teixeira)
Date: Tue, 01 Sep 2015 11:36:53 +0000
Subject: [undertow-dev] Who Needs JAX-RS...
In-Reply-To: <174477647.11659442.1441076785160.JavaMail.zimbra@redhat.com>
References: <CAK6r_rp05Lp9iAq9mPVfZCOy9u7cgfLDHKAcWf=risC2LCWe4A@mail.gmail.com>
	<176268384.11631736.1441070441871.JavaMail.zimbra@redhat.com>
	<CAHezjrRjxCjQtw8t9O=NKjTWgHp2F6P4eRyeSYKHNe8CGShLbA@mail.gmail.com>
	<174477647.11659442.1441076785160.JavaMail.zimbra@redhat.com>
Message-ID: <CAHezjrTL6V0voWWEJzTpU23AuyNetsMbytGmtBR4Na9o-8JsQA@mail.gmail.com>

Nice. I did know StringReadChannelListener already, but it is a lil'
verbose to use.
I just took look at StringReaderHandler, it seems quite simple and nice.

Anyway... thank you for the clarification. :]
Regards

On Tue, Sep 1, 2015 at 12:06 AM Stuart Douglas <sdouglas at redhat.com> wrote:

>
>
> ------------------------------
>
> *From: *"Miere Teixeira" <miere.teixeira at gmail.com>
> *To: *"Stuart Douglas" <sdouglas at redhat.com>, "Steve Logue" <
> bitvector2 at gmail.com>
> *Cc: *undertow-dev at lists.jboss.org
> *Sent: *Tuesday, 1 September, 2015 12:51:00 PM
> *Subject: *Re: [undertow-dev] Who Needs JAX-RS...
>
>
>
> Btw, Stuart,
> Quite interesting this new non-blocking API that was introduced in the
> 1.3.0 version.
>
>
> It is still possible to do non blocking with the XNIO channel API in prior
> versions (which is what StringReadChannelListener uses), this new API is
> just easier to use.
>
>
> Can you tell me where is a good place to be notified about the 1.3.0's
> roadmap and the upcoming new features?
>
>
> 1.3.0.Final will be released just before Wildfly 10 (which is currently
> planned for early October). In general 1.3.x beta releases are quite
> stable, most of the core functionality remains unchanged.
>
> Stuart
>
>
> On Mon, Aug 31, 2015 at 10:21 PM Stuart Douglas <sdouglas at redhat.com>
> wrote:
>
>> This is not really correct, as you are setting the exchange into blocking
>> mode and reading from an input stream.
>>
>> If you want to go full async there are a few things you need to remove
>> the 'startBlocking()' call. To read the request entity the easiest way
>> before Undertow 1.3 (which is still not quite final) is to use
>> io.undertow.util.StringReadChannelListener. If you are a recent 1.3.0 beta
>> you can use the new HttpServerExchange.getRequestReceiver() API.
>>
>> Here is an example of a handler that uses StringReadChannelListener to
>> simply attach the post data to the exchange:
>>
>>
>> https://github.com/undertow-io/undertow.js/blob/master/src/main/java/io/undertow/js/StringReadHandler.java
>>
>> You can then get it in the next handler using the StringReadHandler.DATA
>> attachment key.
>>
>> Stuart
>>
>> ----- Original Message -----
>> > From: "Steve Logue" <bitvector2 at gmail.com>
>> > To: undertow-dev at lists.jboss.org
>> > Sent: Sunday, 30 August, 2015 12:00:49 PM
>> > Subject: [undertow-dev] Who Needs JAX-RS...
>> >
>> > Hi Folks, I'm definitely new to Undertow and super impressed with it.
>> However
>> > the docs are a bit thin in regards to using the RoutingHandler and doing
>> > full async processing. May I ask for a quick check of my approach to
>> using
>> > Undertow and trying not to block anywhere:
>> >
>> >
>> https://github.com/bitvector2/microservice2/blob/master/src/main/java/org/bitvector/microservice2/HttpActor.java
>> >
>> > -STEVEl
>> >
>> >
>> > --
>> >
>> > http://www.bitvector.org/
>> >
>> > _______________________________________________
>> > undertow-dev mailing list
>> > undertow-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/undertow-dev
>> _______________________________________________
>> undertow-dev mailing list
>> undertow-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/undertow-dev
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20150901/88adf955/attachment.html 

From toby at tcrawley.org  Tue Sep  1 10:06:17 2015
From: toby at tcrawley.org (Toby Crawley)
Date: Tue, 1 Sep 2015 10:06:17 -0400
Subject: [undertow-dev] Possible session lookup bug when no session
	cookie present
In-Reply-To: <423172232.11623478.1441068338285.JavaMail.zimbra@redhat.com>
References: <CAA3Huybwgzx9H+fdmx9-jOhdLquVOEr4c6XqSdHd5=im3r_FLg@mail.gmail.com>
	<1036716020.10850736.1440801457304.JavaMail.zimbra@redhat.com>
	<CAA3HuyYKQQsDb=By2Z1bE1ctzE9CX7T7Cy0SxzpLksCQTeM-0g@mail.gmail.com>
	<423172232.11623478.1441068338285.JavaMail.zimbra@redhat.com>
Message-ID: <CAA3HuyaBZ=iSSG41ec_E=YBoJ45shyOm_xnkN-S=a8P6JukF2A@mail.gmail.com>

Thanks for the quick fix!

On Mon, Aug 31, 2015 at 8:45 PM, Stuart Douglas <sdouglas at redhat.com> wrote:
> I have released 1.2.11.Final with this fix.
>
> Stuart
>
> ----- Original Message -----
>> From: "Toby Crawley" <toby at tcrawley.org>
>> To: "Stuart Douglas" <sdouglas at redhat.com>
>> Cc: undertow-dev at lists.jboss.org
>> Sent: Tuesday, 1 September, 2015 1:33:29 AM
>> Subject: Re: [undertow-dev] Possible session lookup bug when no session cookie present
>>
>> Okay. I filed https://issues.jboss.org/browse/UNDERTOW-528
>>
>> On Fri, Aug 28, 2015 at 6:37 PM, Stuart Douglas <sdouglas at redhat.com> wrote:
>> > This is a bug.
>> >
>> > Stuart
>> >
>> > ----- Original Message -----
>> >> From: "Toby Crawley" <toby at tcrawley.org>
>> >> To: undertow-dev at lists.jboss.org
>> >> Sent: Saturday, 29 August, 2015 4:41:49 AM
>> >> Subject: [undertow-dev] Possible session lookup bug when no session cookie
>> >> present
>> >>
>> >> With this commit[1], calls to Sessions.getOrCreateSession() from
>> >> within a handler where no session cookie was sent with the request
>> >> result in a new Session being created every time, with the last
>> >> Session created actually being the one stored when the exchange is
>> >> completed.
>> >>
>> >> This means that the following in a handler results in "foo" not being
>> >> in the session on the next request:
>> >>
>> >> Sessions.getOrCreateSession(exchange).setAttribute("foo", "bar");
>> >> Sessions.getOrCreateSession(exchange);
>> >>
>> >> Before [1], the second getOrCreateSession() call would return the same
>> >> Session object as the first call, not overwriting the one already
>> >> attached to the request, and "foo" would be preserved.
>> >>
>> >> I'm not sure if you consider this a bug or not, but wanted to point it
>> >> out just in case. We discovered this in an Immutant test when
>> >> upgrading from undertow 1.1.0, and we were able to work around it with
>> >> a small change to that test. I don't believe this will affect any
>> >> Immutant users, since we handle all Session access for them, and call
>> >> getOrCreateSession() only once during regular operation.
>> >>
>> >> Let me know if you do consider this a bug, and I'll file a JIRA.
>> >>
>> >> - Toby
>> >>
>> >> [1]:
>> >> https://github.com/undertow-io/undertow/commit/a97fec29f379fff6cb5a74ae9a39177a9c36d4ae
>> >> _______________________________________________
>> >> undertow-dev mailing list
>> >> undertow-dev at lists.jboss.org
>> >> https://lists.jboss.org/mailman/listinfo/undertow-dev
>> >>
>>

From kakonyi.istvan at alerant.hu  Wed Sep  2 02:38:44 2015
From: kakonyi.istvan at alerant.hu (=?utf-8?B?S8Oha29ueWkgSXN0dsOhbg==?=)
Date: Wed, 2 Sep 2015 06:38:44 +0000
Subject: [undertow-dev] Extending
	io.undertow.servlet.spec.HttpSessionImpl
In-Reply-To: <1005909629.11632003.1441070568048.JavaMail.zimbra@redhat.com>
References: <DB5PR05MB1366DE2317011418FF550FA7E16B0@DB5PR05MB1366.eurprd05.prod.outlook.com>
	<1005909629.11632003.1441070568048.JavaMail.zimbra@redhat.com>
Message-ID: <DB5PR05MB13661F45354273E9DC9BC1E5E1690@DB5PR05MB1366.eurprd05.prod.outlook.com>

Hi Stuart!

Thanks for the quick reply, we will try to implement the wrapper.

Best Regards,
Istvan

-----Original Message-----
From: Stuart Douglas [mailto:sdouglas at redhat.com] 
Sent: Tuesday, September 01, 2015 3:23 AM
To: K?konyi Istv?n <kakonyi.istvan at alerant.hu>
Cc: undertow-dev at lists.jboss.org
Subject: Re: [undertow-dev] Extending io.undertow.servlet.spec.HttpSessionImpl

What exactly is a ConvergedHttpSession ? HttpSessionImpl is not really designed to be extended, the underlying functionality is provided by the Undertow SessionManager which can be extended. 

One possibility would be to just create a HttpServletRequest wrapper than returns a delegate than implements ConvergedHttpSession. Would this meet your requirements?

Stuart

----- Original Message -----
> From: "K?konyi Istv?n" <kakonyi.istvan at alerant.hu>
> To: undertow-dev at lists.jboss.org
> Sent: Monday, 31 August, 2015 5:43:02 PM
> Subject: [undertow-dev] Extending 
> io.undertow.servlet.spec.HttpSessionImpl
> 
> 
> 
> Hi Team!
> 
> 
> 
> I am involved in a github project that try to implement a SIP 
> Application Server under wildfy 8 (check
> https://github.com/Mobicents/sip-servlets/issues/3 for more detail).
> 
> 
> 
> According to SIP Servlet spec we have to implement a 
> ConvergedHttpSession class that provides access to HttpSession related 
> functionality which is only present in a converged HTTP/SIP container. 
> In a converged container, an instance of HttpSession can be cast to 
> ConvergedHttpSession in order to access methods available only to converged applications.
> 
> 
> 
> Wildfly 8 uses undertow-servlet project for session handling and I 
> noticed that currently it is not possible to extend 
> io.undertow.servlet.spec.HttpSessionImpl (it has only a private 
> constructor method and a static method for instantiation), so we are 
> stuck in the implementation a little bit because of that limitation.
> 
> 
> 
> Do you have any suggestion how to resolve this problem? Is there a 
> chance to change HttpSessionImpl?s constructor to ?protected? in order 
> to be able to extend it?
> 
> 
> 
> Best Regards,
> 
> Istvan
> 
> 
> 
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev


From cedric.tranxuan at streamdata.io  Fri Sep  4 08:47:38 2015
From: cedric.tranxuan at streamdata.io (=?UTF-8?Q?C=C3=A9dric_Tran=2DXuan?=)
Date: Fri, 4 Sep 2015 14:47:38 +0200
Subject: [undertow-dev] HTTP/2.0 and SSE
Message-ID: <CAO+25pWqqaEPqpt4vNy419cne8GoXnZGC+4VQOfiFnSK_jxYyw@mail.gmail.com>

Hello,
We are trying to use both SSE and HTTP/2.0 features of Undertow. The idea
is to open an SSE connection with HTTP/2.0 as protocol.
We've tried with the following piece of code:

____________________________________________

        ServerSentEventHandler sseHandler;
        sseHandler = new ServerSentEventHandler(new
SseConnectionCallback(source));

        String bindAddress = System.getProperty("bind.address",
"localhost");
        SSLContext sslContext =
createSSLContext(loadKeyStore("server.keystore"),
loadKeyStore("server.truststore"));
        Undertow server = Undertow.builder()
                .setServerOption(UndertowOptions.ENABLE_HTTP2, true)
                .setServerOption(UndertowOptions.ENABLE_SPDY, true)
                .addHttpsListener(8443, bindAddress, sslContext)
                        .setHandler(path().addPrefixPath("/sse",
sseHandler))
                .build();

        server.start();
____________________________________________

But when connecting to https://localhost:8443/sse, nothing happens in the
client side while we are sending into the ServerSentEventConnection data
every 5 seconds
We think it is related to the HTTP/2.0 frame stuff but we are not sure
about this hypothesis.
On the other hand, we have modified the ServerSentEventConnection to expose
a flush() method that calls the underlying flush() of its sink.

____________________________________________

public class ServerSentEventConnection implements Channel, Attachable {

   ...

    public boolean flush() throws IOException {
        return this.sink.flush();
    }
}

____________________________________________


And somewhere in our callback, we do:

____________________________________________

public class SseConnectionCallback implements
ServerSentEventConnectionCallback {

   ...
            if (connection.isOpen()) {
                connection.send(data, "data", UUID.randomUUID().toString(),
new ServerSentEventConnection.EventCallback() {
                    @Override
                    public void done(ServerSentEventConnection aConnection,
String aData, String aEvent, String aId) {
                        LOGGER.info("Sent!");
                        try {
                            connection.flush();
                        } catch (IOException e) {
                            e.printStackTrace();
                        }
                    }

                    @Override
                    public void failed(ServerSentEventConnection
aConnection, String aData, String aEvent, String aId, IOException e) {
                        LOGGER.info("failed!");
                    }

               });
}
____________________________________________


And we get the SSE events on the client side. So, we were wondering whether
our solution was right or whether there is another solution for our issue.

Thanks in advance!
Best regards,

C?dric.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20150904/f3ebf378/attachment-0001.html 

From sdouglas at redhat.com  Fri Sep  4 19:11:24 2015
From: sdouglas at redhat.com (Stuart Douglas)
Date: Fri, 4 Sep 2015 19:11:24 -0400 (EDT)
Subject: [undertow-dev] HTTP/2.0 and SSE
In-Reply-To: <CAO+25pWqqaEPqpt4vNy419cne8GoXnZGC+4VQOfiFnSK_jxYyw@mail.gmail.com>
References: <CAO+25pWqqaEPqpt4vNy419cne8GoXnZGC+4VQOfiFnSK_jxYyw@mail.gmail.com>
Message-ID: <1051599527.13622456.1441408284457.JavaMail.zimbra@redhat.com>

This does sound like a bug. If you file a JIRA I will look into it.

Stuart

----- Original Message -----
> From: "C?dric Tran-Xuan" <cedric.tranxuan at streamdata.io>
> To: undertow-dev at lists.jboss.org
> Sent: Friday, 4 September, 2015 10:47:38 PM
> Subject: [undertow-dev] HTTP/2.0 and SSE
> 
> Hello,
> We are trying to use both SSE and HTTP/2.0 features of Undertow. The idea is
> to open an SSE connection with HTTP/2.0 as protocol.
> We've tried with the following piece of code:
> 
> ____________________________________________
> 
> ServerSentEventHandler sseHandler;
> sseHandler = new ServerSentEventHandler(new SseConnectionCallback(source));
> 
> String bindAddress = System.getProperty("bind.address", "localhost");
> SSLContext sslContext = createSSLContext(loadKeyStore("server.keystore"),
> loadKeyStore("server.truststore"));
> Undertow server = Undertow.builder()
> .setServerOption(UndertowOptions.ENABLE_HTTP2, true)
> .setServerOption(UndertowOptions.ENABLE_SPDY, true)
> .addHttpsListener(8443, bindAddress, sslContext)
> .setHandler(path().addPrefixPath("/sse", sseHandler))
> .build();
> 
> server.start();
> ____________________________________________
> 
> But when connecting to https://localhost:8443/sse , nothing happens in the
> client side while we are sending into the ServerSentEventConnection data
> every 5 seconds
> We think it is related to the HTTP/2.0 frame stuff but we are not sure about
> this hypothesis.
> On the other hand, we have modified the ServerSentEventConnection to expose a
> flush() method that calls the underlying flush() of its sink.
> 
> ____________________________________________
> 
> public class ServerSentEventConnection implements Channel, Attachable {
> 
> ...
> 
> public boolean flush() throws IOException {
> return this.sink.flush();
> }
> }
> 
> ____________________________________________
> 
> 
> And somewhere in our callback, we do:
> 
> ____________________________________________
> 
> public class SseConnectionCallback implements
> ServerSentEventConnectionCallback {
> ...
> if (connection.isOpen()) {
> connection.send(data, "data", UUID.randomUUID().toString(), new
> ServerSentEventConnection.EventCallback() {
> @Override
> public void done(ServerSentEventConnection aConnection, String aData, String
> aEvent, String aId) {
> LOGGER.info("Sent!");
> try {
> connection.flush();
> } catch (IOException e) {
> e.printStackTrace();
> }
> }
> 
> @Override
> public void failed(ServerSentEventConnection aConnection, String aData,
> String aEvent, String aId, IOException e) {
> LOGGER.info("failed!");
> }
> 
> });
> }
> ____________________________________________
> 
> 
> And we get the SSE events on the client side. So, we were wondering whether
> our solution was right or whether there is another solution for our issue.
> 
> Thanks in advance!
> Best regards,
> 
> C?dric.
> 
> 
> 
> 
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev


From cedric.tranxuan at streamdata.io  Mon Sep  7 09:30:02 2015
From: cedric.tranxuan at streamdata.io (=?UTF-8?Q?C=C3=A9dric_Tran=2DXuan?=)
Date: Mon, 7 Sep 2015 15:30:02 +0200
Subject: [undertow-dev] HTTP/2.0 and SSE
In-Reply-To: <1051599527.13622456.1441408284457.JavaMail.zimbra@redhat.com>
References: <CAO+25pWqqaEPqpt4vNy419cne8GoXnZGC+4VQOfiFnSK_jxYyw@mail.gmail.com>
	<1051599527.13622456.1441408284457.JavaMail.zimbra@redhat.com>
Message-ID: <CAO+25pUOmqpU-prGqCNoDrwF2eNXTwvafkHudOaYqhXmP+Bxeg@mail.gmail.com>

Hello,
Issue created at https://issues.jboss.org/browse/UNDERTOW-535!

Thanks in advance!
Best regards,

C?dric.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20150907/00e01253/attachment.html 

From kakonyi.istvan at alerant.hu  Thu Sep 10 06:54:22 2015
From: kakonyi.istvan at alerant.hu (=?iso-8859-2?Q?K=E1konyi_Istv=E1n?=)
Date: Thu, 10 Sep 2015 10:54:22 +0000
Subject: [undertow-dev] org.jboss.remoting3.NotOpenException with
 java.lang.IllegalStateException while server shutting
Message-ID: <DB5PR05MB13661F11609D2579D7EDEEBDE1510@DB5PR05MB1366.eurprd05.prod.outlook.com>

Hi Team!

I would like to ask your help about a strange behaviour/issue which occurs when stopping a wildfly 8.2.0 server instance:

When stopping a Wildfly 8.2.0 server instance, the following line appeared in the log:

2015-09-04 11:07:39,810 ERROR [org.jboss.remotingjmx.protocol.v2.ServerCommon] org.jboss.remoting3.NotOpenException: Writes closed

Also there is an IllegalStateException right before that ERROR line:

2015-09-04 11:07:39,806 WARN [org.jboss.remotingjmx.protocol.v2.ServerCommon] Unexpected internal error: java.lang.IllegalStateException
at org.jboss.as.patching.installation.InstallationManagerService.getValue(InstallationManagerService.java:87) [wildfly-patching-8.2.0.Final.jar:8.2.0.Final]
at org.jboss.as.patching.installation.InstallationManagerService.getValue(InstallationManagerService.java:28) [wildfly-patching-8.2.0.Final.jar:8.2.0.Final]
at org.jboss.msc.service.ServiceControllerImpl.getValue(ServiceControllerImpl.java:1158) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
at org.jboss.as.patching.management.PatchResource$ElementProviderResourceProvider.children(PatchResource.java:139) [wildfly-patching-8.2.0.Final.jar:8.2.0.Final]
at org.jboss.as.patching.management.PatchResource$ElementProviderResourceProvider.hasChildren(PatchResource.java:134) [wildfly-patching-8.2.0.Final.jar:8.2.0.Final]
at org.jboss.as.controller.registry.AbstractModelResource.hasChildren(AbstractModelResource.java:81) [wildfly-controller-8.2.0.Final.jar:8.2.0.Final]
at org.jboss.as.controller.registry.AbstractModelResource$DelegateResource.hasChildren(AbstractModelResource.java:279) [wildfly-controller-8.2.0.Final.jar:8.2.0.Final]
at org.jboss.as.jmx.model.RootResourceIterator.doIterate(RootResourceIterator.java:57) [wildfly-jmx-8.2.0.Final.jar:8.2.0.Final]
at org.jboss.as.jmx.model.RootResourceIterator.doIterate(RootResourceIterator.java:61) [wildfly-jmx-8.2.0.Final.jar:8.2.0.Final]
at org.jboss.as.jmx.model.RootResourceIterator.iterate(RootResourceIterator.java:43) [wildfly-jmx-8.2.0.Final.jar:8.2.0.Final]
at org.jboss.as.jmx.model.ModelControllerMBeanHelper.getMBeanCount(ModelControllerMBeanHelper.java:105) [wildfly-jmx-8.2.0.Final.jar:8.2.0.Final]
at org.jboss.as.jmx.model.ModelControllerMBeanServerPlugin.getMBeanCount(ModelControllerMBeanServerPlugin.java:157) [wildfly-jmx-8.2.0.Final.jar:8.2.0.Final]
at org.jboss.as.jmx.PluggableMBeanServerImpl.getMBeanCount(PluggableMBeanServerImpl.java:554) [wildfly-jmx-8.2.0.Final.jar:8.2.0.Final]
at org.jboss.as.jmx.BlockingNotificationMBeanServer.getMBeanCount(BlockingNotificationMBeanServer.java:143) [wildfly-jmx-8.2.0.Final.jar:8.2.0.Final]
at org.jboss.remotingjmx.protocol.v2.ServerProxy$GetMBeanCountHandler.handle(ServerProxy.java:655)
at org.jboss.remotingjmx.protocol.v2.ServerCommon$MessageReciever$1$1.run(ServerCommon.java:153)
at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor$1.run(ServerInterceptorFactory.java:75) [wildfly-jmx-8.2.0.Final.jar:8.2.0.Final]
at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor$1.run(ServerInterceptorFactory.java:70) [wildfly-jmx-8.2.0.Final.jar:8.2.0.Final]
at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.8.0_60]
at javax.security.auth.Subject.doAs(Subject.java:422) [rt.jar:1.8.0_60]
at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:94) [wildfly-controller-8.2.0.Final.jar:8.2.0.Final]
at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor.handleEvent(ServerInterceptorFactory.java:70) [wildfly-jmx-8.2.0.Final.jar:8.2.0.Final]
at org.jboss.remotingjmx.protocol.v2.ServerCommon$MessageReciever$1.run(ServerCommon.java:149)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_60]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_60]
at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_60]

It seems as if the server was in the process of shutting down its services when a JMX connection was requested. We were able to confirm this by initiating a JMX connection, then almost at the same time we initiated a graceful stop on the server as well, and the aforementioned ERROR appeared in the log.

Is it possible that during the shutdown phase jmx connections are still allowed by the server which finally causes IllegalStateException?
Regards,
Istvan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20150910/f327e730/attachment.html 

From tomaz.cerar at gmail.com  Thu Sep 10 09:17:26 2015
From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=)
Date: Thu, 10 Sep 2015 15:17:26 +0200
Subject: [undertow-dev] org.jboss.remoting3.NotOpenException with
 java.lang.IllegalStateException while server shutting
In-Reply-To: <DB5PR05MB13661F11609D2579D7EDEEBDE1510@DB5PR05MB1366.eurprd05.prod.outlook.com>
References: <DB5PR05MB13661F11609D2579D7EDEEBDE1510@DB5PR05MB1366.eurprd05.prod.outlook.com>
Message-ID: <CAMquZP50b8B8xb-XpYV7aohZbN=HxDR5kKjKZPLuis1yZmxK4g@mail.gmail.com>

This is more of wildfly-dev mailing list question.

but in short, yes what you describe is possible.
And should be fixed or at least better handled in WildFly 9+ that has
graceful shutdown in place.
As long as you use new version of :shutdown operation that uses timeout.

--
tomaz

On Thu, Sep 10, 2015 at 12:54 PM, K?konyi Istv?n <kakonyi.istvan at alerant.hu>
wrote:

> Hi Team!
>
>
>
> I would like to ask your help about a strange behaviour/issue which occurs
> when stopping a wildfly 8.2.0 server instance:
>
> When stopping a Wildfly 8.2.0 server instance, the following line appeared
> in the log:
>
> 2015-09-04 11:07:39,810 ERROR
> [org.jboss.remotingjmx.protocol.v2.ServerCommon]
> org.jboss.remoting3.NotOpenException: Writes closed
>
> Also there is an IllegalStateException right before that ERROR line:
>
> 2015-09-04 11:07:39,806 WARN
> [org.jboss.remotingjmx.protocol.v2.ServerCommon] Unexpected internal error:
> java.lang.IllegalStateException
> at
> org.jboss.as.patching.installation.InstallationManagerService.getValue(InstallationManagerService.java:87)
> [wildfly-patching-8.2.0.Final.jar:8.2.0.Final]
> at
> org.jboss.as.patching.installation.InstallationManagerService.getValue(InstallationManagerService.java:28)
> [wildfly-patching-8.2.0.Final.jar:8.2.0.Final]
> at
> org.jboss.msc.service.ServiceControllerImpl.getValue(ServiceControllerImpl.java:1158)
> [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
> at
> org.jboss.as.patching.management.PatchResource$ElementProviderResourceProvider.children(PatchResource.java:139)
> [wildfly-patching-8.2.0.Final.jar:8.2.0.Final]
> at
> org.jboss.as.patching.management.PatchResource$ElementProviderResourceProvider.hasChildren(PatchResource.java:134)
> [wildfly-patching-8.2.0.Final.jar:8.2.0.Final]
> at
> org.jboss.as.controller.registry.AbstractModelResource.hasChildren(AbstractModelResource.java:81)
> [wildfly-controller-8.2.0.Final.jar:8.2.0.Final]
> at
> org.jboss.as.controller.registry.AbstractModelResource$DelegateResource.hasChildren(AbstractModelResource.java:279)
> [wildfly-controller-8.2.0.Final.jar:8.2.0.Final]
> at
> org.jboss.as.jmx.model.RootResourceIterator.doIterate(RootResourceIterator.java:57)
> [wildfly-jmx-8.2.0.Final.jar:8.2.0.Final]
> at
> org.jboss.as.jmx.model.RootResourceIterator.doIterate(RootResourceIterator.java:61)
> [wildfly-jmx-8.2.0.Final.jar:8.2.0.Final]
> at
> org.jboss.as.jmx.model.RootResourceIterator.iterate(RootResourceIterator.java:43)
> [wildfly-jmx-8.2.0.Final.jar:8.2.0.Final]
> at
> org.jboss.as.jmx.model.ModelControllerMBeanHelper.getMBeanCount(ModelControllerMBeanHelper.java:105)
> [wildfly-jmx-8.2.0.Final.jar:8.2.0.Final]
> at
> org.jboss.as.jmx.model.ModelControllerMBeanServerPlugin.getMBeanCount(ModelControllerMBeanServerPlugin.java:157)
> [wildfly-jmx-8.2.0.Final.jar:8.2.0.Final]
> at
> org.jboss.as.jmx.PluggableMBeanServerImpl.getMBeanCount(PluggableMBeanServerImpl.java:554)
> [wildfly-jmx-8.2.0.Final.jar:8.2.0.Final]
> at
> org.jboss.as.jmx.BlockingNotificationMBeanServer.getMBeanCount(BlockingNotificationMBeanServer.java:143)
> [wildfly-jmx-8.2.0.Final.jar:8.2.0.Final]
> at
> org.jboss.remotingjmx.protocol.v2.ServerProxy$GetMBeanCountHandler.handle(ServerProxy.java:655)
> at
> org.jboss.remotingjmx.protocol.v2.ServerCommon$MessageReciever$1$1.run(ServerCommon.java:153)
> at
> org.jboss.as.jmx.ServerInterceptorFactory$Interceptor$1.run(ServerInterceptorFactory.java:75)
> [wildfly-jmx-8.2.0.Final.jar:8.2.0.Final]
> at
> org.jboss.as.jmx.ServerInterceptorFactory$Interceptor$1.run(ServerInterceptorFactory.java:70)
> [wildfly-jmx-8.2.0.Final.jar:8.2.0.Final]
> at java.security.AccessController.doPrivileged(Native Method)
> [rt.jar:1.8.0_60]
> at javax.security.auth.Subject.doAs(Subject.java:422) [rt.jar:1.8.0_60]
> at
> org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:94)
> [wildfly-controller-8.2.0.Final.jar:8.2.0.Final]
> at
> org.jboss.as.jmx.ServerInterceptorFactory$Interceptor.handleEvent(ServerInterceptorFactory.java:70)
> [wildfly-jmx-8.2.0.Final.jar:8.2.0.Final]
> at
> org.jboss.remotingjmx.protocol.v2.ServerCommon$MessageReciever$1.run(ServerCommon.java:149)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [rt.jar:1.8.0_60]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [rt.jar:1.8.0_60]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_60]
>
> It seems as if the server was in the process of shutting down its services
> when a JMX connection was requested. We were able to confirm this by
> initiating a JMX connection, then almost at the same time we initiated a
> graceful stop on the server as well, and the aforementioned ERROR appeared
> in the log.
>
> Is it possible that during the shutdown phase jmx connections are still
> allowed by the server which finally causes IllegalStateException?
>
> Regards,
>
> Istvan
>
>
>
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20150910/ae78fb5d/attachment-0001.html 

From devl.development at gmail.com  Fri Sep 11 10:00:48 2015
From: devl.development at gmail.com (Devl Devel)
Date: Fri, 11 Sep 2015 15:00:48 +0100
Subject: [undertow-dev] Some help on Reverse Proxy Server
Message-ID: <CAMQ+LQPoggDY=BLc4UqF4k_Efhne2Je27v=2+SkzZ9kzHn6Spg@mail.gmail.com>

At present the git example for Reverse Proxy is a non https/ssl example.


https://github.com/undertow-io/undertow/blob/master/examples/src/main/java/io/undertow/examples/reverseproxy/ReverseProxyServer.java

Please can you help with an example using SSL and https?

I take it the .addHost(new URI("http://localhost:8081") method

needs and XNioSSL object to work with https redirection? If so, please can
you provide an example of how to configure this?

Thanks
Devl
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20150911/93c10e39/attachment.html 

From sdouglas at redhat.com  Sun Sep 13 21:17:20 2015
From: sdouglas at redhat.com (Stuart Douglas)
Date: Sun, 13 Sep 2015 21:17:20 -0400 (EDT)
Subject: [undertow-dev] Some help on Reverse Proxy Server
In-Reply-To: <CAMQ+LQPoggDY=BLc4UqF4k_Efhne2Je27v=2+SkzZ9kzHn6Spg@mail.gmail.com>
References: <CAMQ+LQPoggDY=BLc4UqF4k_Efhne2Je27v=2+SkzZ9kzHn6Spg@mail.gmail.com>
Message-ID: <793233036.16634511.1442193440707.JavaMail.zimbra@redhat.com>

And example of this can be found in this test:

https://github.com/undertow-io/undertow/blob/master/core/src/test/java/io/undertow/server/handlers/proxy/LoadBalancingProxyHttpsTestCase.java

Stuart

----- Original Message -----
> From: "Devl Devel" <devl.development at gmail.com>
> To: undertow-dev at lists.jboss.org
> Sent: Saturday, 12 September, 2015 12:00:48 AM
> Subject: [undertow-dev] Some help on Reverse Proxy Server
> 
> At present the git example for Reverse Proxy is a non https/ssl example.
> 
> 
> https://github.com/undertow-io/undertow/blob/master/examples/src/main/java/io/undertow/examples/reverseproxy/ReverseProxyServer.java
> 
> Please can you help with an example using SSL and https?
> 
> I take it the .addHost( new URI ( " http://localhost:8081 " ) method
> 
> needs and XNioSSL object to work with https redirection? If so, please can
> you provide an example of how to configure this?
> 
> Thanks
> Devl
> 
> 
> 
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev

From bburke at redhat.com  Mon Sep 14 11:27:53 2015
From: bburke at redhat.com (Bill Burke)
Date: Mon, 14 Sep 2015 11:27:53 -0400
Subject: [undertow-dev] backchannel logout in cluster
Message-ID: <55F6E779.4090301@redhat.com>

I'm running into a problem implementing SAML backchannel logout.  Web 
server could receive an on-of-band, non-browser HTTP request to logout 
out a specific user and/or session.  I would need a way to lookup a 
session by Principal and a way to associate and lookup an external key. 
  SAML doesn't really have any way to push client specific session 
information.


-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From bburke at redhat.com  Mon Sep 14 11:44:22 2015
From: bburke at redhat.com (Bill Burke)
Date: Mon, 14 Sep 2015 11:44:22 -0400
Subject: [undertow-dev] backchannel logout in cluster
In-Reply-To: <55F6E779.4090301@redhat.com>
References: <55F6E779.4090301@redhat.com>
Message-ID: <55F6EB56.1030700@redhat.com>

I should add that SAML provides a "session index" to the web client when 
LOGIN is finished.  This index is sent with the logout request along 
with the principal name.

The only way I could think of to implement it now is to iterate on all 
sessions and compare SAML session info with attributes in each session. 
  Slow, but it would work.  Would be nice to have an Undertow SPI. 
Otherwise, I'm going to have to create a Infinispan cache specifically 
just to map

On 9/14/2015 11:27 AM, Bill Burke wrote:
> I'm running into a problem implementing SAML backchannel logout.  Web
> server could receive an on-of-band, non-browser HTTP request to logout
> out a specific user and/or session.  I would need a way to lookup a
> session by Principal and a way to associate and lookup an external key.
>    SAML doesn't really have any way to push client specific session
> information.
>
>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From sdouglas at redhat.com  Mon Sep 14 18:22:47 2015
From: sdouglas at redhat.com (Stuart Douglas)
Date: Mon, 14 Sep 2015 18:22:47 -0400 (EDT)
Subject: [undertow-dev] backchannel logout in cluster
In-Reply-To: <55F6EB56.1030700@redhat.com>
References: <55F6E779.4090301@redhat.com> <55F6EB56.1030700@redhat.com>
Message-ID: <202624729.17173048.1442269367134.JavaMail.zimbra@redhat.com>

I don't think there is much Undertow can do here, because this is clustered it is basically out of Undertow's control.

For a non clustered version you can just maintain your own map using session listeners, however like you say for the clustered version if you want to maintain this sort of map you will need to create an Infinispan cache to handle the mapping. 

When you mentioned an Undertow SPI what exactly did you have in mind? Some way to query the session manager based on session attributes?

Stuart


----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: undertow-dev at lists.jboss.org
> Sent: Tuesday, 15 September, 2015 1:44:22 AM
> Subject: Re: [undertow-dev] backchannel logout in cluster
> 
> I should add that SAML provides a "session index" to the web client when
> LOGIN is finished.  This index is sent with the logout request along
> with the principal name.
> 
> The only way I could think of to implement it now is to iterate on all
> sessions and compare SAML session info with attributes in each session.
>   Slow, but it would work.  Would be nice to have an Undertow SPI.
> Otherwise, I'm going to have to create a Infinispan cache specifically
> just to map
> 
> On 9/14/2015 11:27 AM, Bill Burke wrote:
> > I'm running into a problem implementing SAML backchannel logout.  Web
> > server could receive an on-of-band, non-browser HTTP request to logout
> > out a specific user and/or session.  I would need a way to lookup a
> > session by Principal and a way to associate and lookup an external key.
> >    SAML doesn't really have any way to push client specific session
> > information.
> >
> >
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev
> 

From cedric.tranxuan at streamdata.io  Tue Sep 15 05:19:35 2015
From: cedric.tranxuan at streamdata.io (=?UTF-8?Q?C=C3=A9dric_Tran=2DXuan?=)
Date: Tue, 15 Sep 2015 11:19:35 +0200
Subject: [undertow-dev] SSE and close stacktrace
Message-ID: <CAO+25pUZ=15z5khb7jm-MbmymOOhUL9rzPeiVhY7Hf5G-7jUMw@mail.gmail.com>

Hello,
We are using the SSE handler to post at interval some events.
Every time a user closes its browser tab, we've got the following exception:

java.nio.channels.ClosedChannelException: null
at
io.undertow.server.protocol.framed.AbstractFramedStreamSinkChannel.safeToSend(AbstractFramedStreamSinkChannel.java:441)
~[classes/:na]
at
io.undertow.server.protocol.framed.AbstractFramedStreamSinkChannel.write(AbstractFramedStreamSinkChannel.java:395)
~[classes/:na]
at
org.xnio.conduits.StreamSinkChannelWrappingConduit.write(StreamSinkChannelWrappingConduit.java:57)
~[xnio-api-3.3.1.Final.jar:3.3.1.Final]
at
org.xnio.conduits.ConduitStreamSinkChannel.write(ConduitStreamSinkChannel.java:150)
~[xnio-api-3.3.1.Final.jar:3.3.1.Final]
at
io.undertow.channels.DetachableStreamSinkChannel.write(DetachableStreamSinkChannel.java:240)
~[classes/:na]
at
io.undertow.server.HttpServerExchange$WriteDispatchChannel.write(HttpServerExchange.java:1980)
~[classes/:na]
at
io.undertow.server.handlers.sse.ServerSentEventConnection$SseWriteListener.handleEvent(ServerSentEventConnection.java:456)
~[classes/:na]
at
io.undertow.server.handlers.sse.ServerSentEventConnection$2.run(ServerSentEventConnection.java:210)
[classes/:na]
at org.xnio.nio.WorkerThread.safeRun(WorkerThread.java:560)
[xnio-nio-3.3.1.Final.jar:3.3.1.Final]
at org.xnio.nio.WorkerThread.run(WorkerThread.java:462)
[xnio-nio-3.3.1.Final.jar:3.3.1.Final]

We guess it comes from the fact that the buffer is not empty at the time
the browser closes the connection. Having this stacktrace in the log files,
for every connection closed is a bit cumbersome for us. So, we were
wondering whether there was a mean to handle this special stacktrace. From
what we have seen, it is a log from a xnio WorkerThread but we don't wish
to mute all the error logs from this class. And we haven't seen any way to
catch the exception too.

Any ideas would be appreciated.
Thanks in advance.

C?dric.

PS: The example to reproduce the ? issue ? can be the one in attachment of
https://issues.jboss.org/browse/UNDERTOW-535.
You can run the example, open a browser at https://localhost:8443/sse and
close the browser tab. The stacktrace should appear.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20150915/a3d5b332/attachment.html 

From bburke at redhat.com  Tue Sep 15 09:12:59 2015
From: bburke at redhat.com (Bill Burke)
Date: Tue, 15 Sep 2015 09:12:59 -0400
Subject: [undertow-dev] backchannel logout in cluster
In-Reply-To: <202624729.17173048.1442269367134.JavaMail.zimbra@redhat.com>
References: <55F6E779.4090301@redhat.com> <55F6EB56.1030700@redhat.com>
	<202624729.17173048.1442269367134.JavaMail.zimbra@redhat.com>
Message-ID: <55F8195B.4040401@redhat.com>



On 9/14/2015 6:22 PM, Stuart Douglas wrote:
> I don't think there is much Undertow can do here, because this is clustered it is basically out of Undertow's control.
>
> For a non clustered version you can just maintain your own map using session listeners, however like you say for the clustered version if you want to maintain this sort of map you will need to create an Infinispan cache to handle the mapping.
>
> When you mentioned an Undertow SPI what exactly did you have in mind? Some way to query the session manager based on session attributes?
>

A Hack I thought of was to create an Http Session that is shared by all 
requests and machines or clone the existing http session and change the 
session id to an SSO session id provided by the IdP.  Undertow doesn't 
have a way to provide your own session id though when creating sessions. 
(Jetty doesn't either, only Tomcat/JBossWeb allow this).

Better extensions to Undertow session manager would be:
* Ability to associate an alias to an http session. i.e. an SSO session ID.
* or the ability to replace the http session id, with a new one.  i.e. 
after authentication, replace the local http session id, with the SSO 
session id
* Additionally, the ability to index http sessions (or session ids) by 
principal or principal name.

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From devl.development at gmail.com  Tue Sep 15 10:59:55 2015
From: devl.development at gmail.com (Devl Devel)
Date: Tue, 15 Sep 2015 15:59:55 +0100
Subject: [undertow-dev] Some help on Reverse Proxy Server
In-Reply-To: <793233036.16634511.1442193440707.JavaMail.zimbra@redhat.com>
References: <CAMQ+LQPoggDY=BLc4UqF4k_Efhne2Je27v=2+SkzZ9kzHn6Spg@mail.gmail.com>
	<793233036.16634511.1442193440707.JavaMail.zimbra@redhat.com>
Message-ID: <CAMQ+LQPr1_x7yyr209Dyd-Dc0BGZhwY5gDjq_hapxoijrr936Q@mail.gmail.com>

Hi Stuart

Thanks for this. I tried the example with a proxy server that has a valid
ssl context, byte buffer slice pool, undertow xnio ssl with worker, and
load balancing proxy client as per your example. Using 1.2.12.Final

On the receiving webserver (which works fine with other https: and other
SSL requests) I have enabled SSLCLientMode.Required and other settings
similar to DefaultServer.  This works when I go direct to the webserver in
the browser - I can use it normally but when I use the proxy and issue a
https request I get:

ERROR proxy - UT005028: Proxy request to / failed

java.io.IOException: overflow

               at
io.undertow.protocols.ssl.SslConduit.doWrap(SslConduit.java:801)

               at
io.undertow.protocols.ssl.SslConduit.write(SslConduit.java:336)

               at
io.undertow.client.http.HttpRequestConduit.processWrite(HttpRequestConduit.java:321)

               at
io.undertow.client.http.HttpRequestConduit.flush(HttpRequestConduit.java:573)

               at
io.undertow.conduits.AbstractFixedLengthStreamSinkConduit.flush(AbstractFixedLengthStreamSinkConduit.java:229)

               at
org.xnio.conduits.ConduitStreamSinkChannel.flush(ConduitStreamSinkChannel.java:162)

               at
io.undertow.client.http.HttpClientConnection.initiateRequest(HttpClientConnection.java:299)

               at
io.undertow.client.http.HttpClientConnection.sendRequest(HttpClientConnection.java:228)

               at
io.undertow.server.handlers.proxy.ProxyHandler$ProxyAction.run(ProxyHandler.java:502)

               at
io.undertow.util.SameThreadExecutor.execute(SameThreadExecutor.java:35)

               at
io.undertow.server.HttpServerExchange.dispatch(HttpServerExchange.java:759)

               at
io.undertow.server.handlers.proxy.ProxyHandler$ProxyClientHandler.completed(ProxyHandler.java:269)

               at
io.undertow.server.handlers.proxy.ProxyHandler$ProxyClientHandler.completed(ProxyHandler.java:245)

               at
io.undertow.server.handlers.proxy.ProxyConnectionPool.connectionReady(ProxyConnectionPool.java:292)

               at
io.undertow.server.handlers.proxy.ProxyConnectionPool.access$800(ProxyConnectionPool.java:54)

               at
io.undertow.server.handlers.proxy.ProxyConnectionPool$1.completed(ProxyConnectionPool.java:245)

               at
io.undertow.server.handlers.proxy.ProxyConnectionPool$1.completed(ProxyConnectionPool.java:233)

               at
io.undertow.client.http.HttpClientProvider.handleConnected(HttpClientProvider.java:163)

               at
io.undertow.client.http.HttpClientProvider.access$000(HttpClientProvider.java:50)

               at
io.undertow.client.http.HttpClientProvider$2.handleEvent(HttpClientProvider.java:126)

               at
io.undertow.client.http.HttpClientProvider$2.handleEvent(HttpClientProvider.java:123)

               at
org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)

               at
io.undertow.protocols.ssl.UndertowXnioSsl$StreamConnectionChannelListener.handleEvent(UndertowXnioSsl.java:312)

               at
io.undertow.protocols.ssl.UndertowXnioSsl$StreamConnectionChannelListener.handleEvent(UndertowXnioSsl.java:294)

               at
org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)

               at
org.xnio.nio.WorkerThread$ConnectHandle.handleReady(WorkerThread.java:324)

               at org.xnio.nio.WorkerThread.run(WorkerThread.java:539)



Will the proxy forward the browser cert to the webserver or is there some
other cause? I cannot share any code but any pointers are appreciated.



Thanks

Devl



On Mon, Sep 14, 2015 at 2:17 AM, Stuart Douglas <sdouglas at redhat.com> wrote:

> And example of this can be found in this test:
>
>
> https://github.com/undertow-io/undertow/blob/master/core/src/test/java/io/undertow/server/handlers/proxy/LoadBalancingProxyHttpsTestCase.java
>
> Stuart
>
> ----- Original Message -----
> > From: "Devl Devel" <devl.development at gmail.com>
> > To: undertow-dev at lists.jboss.org
> > Sent: Saturday, 12 September, 2015 12:00:48 AM
> > Subject: [undertow-dev] Some help on Reverse Proxy Server
> >
> > At present the git example for Reverse Proxy is a non https/ssl example.
> >
> >
> >
> https://github.com/undertow-io/undertow/blob/master/examples/src/main/java/io/undertow/examples/reverseproxy/ReverseProxyServer.java
> >
> > Please can you help with an example using SSL and https?
> >
> > I take it the .addHost( new URI ( " http://localhost:8081 " ) method
> >
> > needs and XNioSSL object to work with https redirection? If so, please
> can
> > you provide an example of how to configure this?
> >
> > Thanks
> > Devl
> >
> >
> >
> > _______________________________________________
> > undertow-dev mailing list
> > undertow-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/undertow-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20150915/269c990a/attachment-0001.html 

From sdouglas at redhat.com  Tue Sep 15 20:45:06 2015
From: sdouglas at redhat.com (Stuart Douglas)
Date: Tue, 15 Sep 2015 20:45:06 -0400 (EDT)
Subject: [undertow-dev] Some help on Reverse Proxy Server
In-Reply-To: <CAMQ+LQPr1_x7yyr209Dyd-Dc0BGZhwY5gDjq_hapxoijrr936Q@mail.gmail.com>
References: <CAMQ+LQPoggDY=BLc4UqF4k_Efhne2Je27v=2+SkzZ9kzHn6Spg@mail.gmail.com>
	<793233036.16634511.1442193440707.JavaMail.zimbra@redhat.com>
	<CAMQ+LQPr1_x7yyr209Dyd-Dc0BGZhwY5gDjq_hapxoijrr936Q@mail.gmail.com>
Message-ID: <1628287686.17628326.1442364306472.JavaMail.zimbra@redhat.com>

If you want to use client-cert mode with a proxy you need to actually send the cert as a header (otherwise you would need a 1:1 mapping between front and back end connections).

Basically on the backend server you need to have a io.undertow.server.handlers.SSLHeaderHandler installed, this will look for the headers and set up the appropriate SSL structures (don't install this handler on an internet facing server).

In your proxy server you then need to add the following code:


        proxyHandler.addRequestHeader(Headers.SSL_CLIENT_CERT, "%{SSL_CLIENT_CERT}");
        proxyHandler.addRequestHeader(Headers.SSL_CIPHER, "%{SSL_CIPHER}");
        proxyHandler.addRequestHeader(Headers.SSL_SESSION_ID, "%{SSL_SESSION_ID}");

(I really should add a simpler way of doing this).

Now the certificate information will be sent on every request as a header, and the backend server can deal with it as normal. This also means you don't have to use HTTPS for the connection to the backend server. 

Stuart


----- Original Message -----
> From: "Devl Devel" <devl.development at gmail.com>
> To: "Stuart Douglas" <sdouglas at redhat.com>
> Cc: undertow-dev at lists.jboss.org
> Sent: Wednesday, 16 September, 2015 12:59:55 AM
> Subject: Re: [undertow-dev] Some help on Reverse Proxy Server
> 
> Hi Stuart
> 
> Thanks for this. I tried the example with a proxy server that has a valid
> ssl context, byte buffer slice pool, undertow xnio ssl with worker, and
> load balancing proxy client as per your example. Using 1.2.12.Final
> 
> On the receiving webserver (which works fine with other https: and other
> SSL requests) I have enabled SSLCLientMode.Required and other settings
> similar to DefaultServer.  This works when I go direct to the webserver in
> the browser - I can use it normally but when I use the proxy and issue a
> https request I get:
> 
> ERROR proxy - UT005028: Proxy request to / failed
> 
> java.io.IOException: overflow
> 
>                at
> io.undertow.protocols.ssl.SslConduit.doWrap(SslConduit.java:801)
> 
>                at
> io.undertow.protocols.ssl.SslConduit.write(SslConduit.java:336)
> 
>                at
> io.undertow.client.http.HttpRequestConduit.processWrite(HttpRequestConduit.java:321)
> 
>                at
> io.undertow.client.http.HttpRequestConduit.flush(HttpRequestConduit.java:573)
> 
>                at
> io.undertow.conduits.AbstractFixedLengthStreamSinkConduit.flush(AbstractFixedLengthStreamSinkConduit.java:229)
> 
>                at
> org.xnio.conduits.ConduitStreamSinkChannel.flush(ConduitStreamSinkChannel.java:162)
> 
>                at
> io.undertow.client.http.HttpClientConnection.initiateRequest(HttpClientConnection.java:299)
> 
>                at
> io.undertow.client.http.HttpClientConnection.sendRequest(HttpClientConnection.java:228)
> 
>                at
> io.undertow.server.handlers.proxy.ProxyHandler$ProxyAction.run(ProxyHandler.java:502)
> 
>                at
> io.undertow.util.SameThreadExecutor.execute(SameThreadExecutor.java:35)
> 
>                at
> io.undertow.server.HttpServerExchange.dispatch(HttpServerExchange.java:759)
> 
>                at
> io.undertow.server.handlers.proxy.ProxyHandler$ProxyClientHandler.completed(ProxyHandler.java:269)
> 
>                at
> io.undertow.server.handlers.proxy.ProxyHandler$ProxyClientHandler.completed(ProxyHandler.java:245)
> 
>                at
> io.undertow.server.handlers.proxy.ProxyConnectionPool.connectionReady(ProxyConnectionPool.java:292)
> 
>                at
> io.undertow.server.handlers.proxy.ProxyConnectionPool.access$800(ProxyConnectionPool.java:54)
> 
>                at
> io.undertow.server.handlers.proxy.ProxyConnectionPool$1.completed(ProxyConnectionPool.java:245)
> 
>                at
> io.undertow.server.handlers.proxy.ProxyConnectionPool$1.completed(ProxyConnectionPool.java:233)
> 
>                at
> io.undertow.client.http.HttpClientProvider.handleConnected(HttpClientProvider.java:163)
> 
>                at
> io.undertow.client.http.HttpClientProvider.access$000(HttpClientProvider.java:50)
> 
>                at
> io.undertow.client.http.HttpClientProvider$2.handleEvent(HttpClientProvider.java:126)
> 
>                at
> io.undertow.client.http.HttpClientProvider$2.handleEvent(HttpClientProvider.java:123)
> 
>                at
> org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> 
>                at
> io.undertow.protocols.ssl.UndertowXnioSsl$StreamConnectionChannelListener.handleEvent(UndertowXnioSsl.java:312)
> 
>                at
> io.undertow.protocols.ssl.UndertowXnioSsl$StreamConnectionChannelListener.handleEvent(UndertowXnioSsl.java:294)
> 
>                at
> org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> 
>                at
> org.xnio.nio.WorkerThread$ConnectHandle.handleReady(WorkerThread.java:324)
> 
>                at org.xnio.nio.WorkerThread.run(WorkerThread.java:539)
> 
> 
> 
> Will the proxy forward the browser cert to the webserver or is there some
> other cause? I cannot share any code but any pointers are appreciated.
> 
> 
> 
> Thanks
> 
> Devl
> 
> 
> 
> On Mon, Sep 14, 2015 at 2:17 AM, Stuart Douglas <sdouglas at redhat.com> wrote:
> 
> > And example of this can be found in this test:
> >
> >
> > https://github.com/undertow-io/undertow/blob/master/core/src/test/java/io/undertow/server/handlers/proxy/LoadBalancingProxyHttpsTestCase.java
> >
> > Stuart
> >
> > ----- Original Message -----
> > > From: "Devl Devel" <devl.development at gmail.com>
> > > To: undertow-dev at lists.jboss.org
> > > Sent: Saturday, 12 September, 2015 12:00:48 AM
> > > Subject: [undertow-dev] Some help on Reverse Proxy Server
> > >
> > > At present the git example for Reverse Proxy is a non https/ssl example.
> > >
> > >
> > >
> > https://github.com/undertow-io/undertow/blob/master/examples/src/main/java/io/undertow/examples/reverseproxy/ReverseProxyServer.java
> > >
> > > Please can you help with an example using SSL and https?
> > >
> > > I take it the .addHost( new URI ( " http://localhost:8081 " ) method
> > >
> > > needs and XNioSSL object to work with https redirection? If so, please
> > can
> > > you provide an example of how to configure this?
> > >
> > > Thanks
> > > Devl
> > >
> > >
> > >
> > > _______________________________________________
> > > undertow-dev mailing list
> > > undertow-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/undertow-dev
> >
> 

From sdouglas at redhat.com  Tue Sep 15 20:49:03 2015
From: sdouglas at redhat.com (Stuart Douglas)
Date: Tue, 15 Sep 2015 20:49:03 -0400 (EDT)
Subject: [undertow-dev] backchannel logout in cluster
In-Reply-To: <55F8195B.4040401@redhat.com>
References: <55F6E779.4090301@redhat.com> <55F6EB56.1030700@redhat.com>
	<202624729.17173048.1442269367134.JavaMail.zimbra@redhat.com>
	<55F8195B.4040401@redhat.com>
Message-ID: <1075409545.17629087.1442364543930.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stuart Douglas" <sdouglas at redhat.com>
> Cc: undertow-dev at lists.jboss.org
> Sent: Tuesday, 15 September, 2015 11:12:59 PM
> Subject: Re: [undertow-dev] backchannel logout in cluster
> 
> 
> 
> On 9/14/2015 6:22 PM, Stuart Douglas wrote:
> > I don't think there is much Undertow can do here, because this is clustered
> > it is basically out of Undertow's control.
> >
> > For a non clustered version you can just maintain your own map using
> > session listeners, however like you say for the clustered version if you
> > want to maintain this sort of map you will need to create an Infinispan
> > cache to handle the mapping.
> >
> > When you mentioned an Undertow SPI what exactly did you have in mind? Some
> > way to query the session manager based on session attributes?
> >
> 
> A Hack I thought of was to create an Http Session that is shared by all
> requests and machines or clone the existing http session and change the
> session id to an SSO session id provided by the IdP.  Undertow doesn't
> have a way to provide your own session id though when creating sessions.
> (Jetty doesn't either, only Tomcat/JBossWeb allow this).

We don't have a documented way, but if you pass in a SessionConfig implementation that returns a constant value for findSessionId 
to the createSession method then this session id will be used for the new session.

This is obviously a hack though, and I will look at adding a new method that supports this directly.

> 
> Better extensions to Undertow session manager would be:
> * Ability to associate an alias to an http session. i.e. an SSO session ID.
> * or the ability to replace the http session id, with a new one.  i.e.
> after authentication, replace the local http session id, with the SSO
> session id

I can do this one as well.

> * Additionally, the ability to index http sessions (or session ids) by
> principal or principal name.

Would you still need this indexing if I give you control over the session ID?

Stuart

> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> 

From chris.back at gmail.com  Tue Sep 15 22:44:32 2015
From: chris.back at gmail.com (Chris Back)
Date: Wed, 16 Sep 2015 02:44:32 +0000
Subject: [undertow-dev] HttpServerExchange.unDispatch()
Message-ID: <CAFqH8G9+MKbf9t_dQu49Jx+TpWQBjQJJabx4Jqy_U2o0_LBjMQ@mail.gmail.com>

I noticed an undocumented (as far as I can tell) public method on the
exchange, unDispatch(). How is this supposed to be used? Is it to move a
process back into the IO thread pool?

I ask because I have written a ChannelListener that reads in the entire
http entity before passing the request through to the next HttpHandler. I
have noticed sometimes without my dispatching the request the exchange gets
dispatched on it own. I assume this is some side effect calling
channel.resumeReads().

Is it safe to use exchange.unDispatch() like dispatch() (only in reverse)?

-Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20150916/7244446c/attachment.html 

From sdouglas at redhat.com  Wed Sep 16 01:01:20 2015
From: sdouglas at redhat.com (Stuart Douglas)
Date: Wed, 16 Sep 2015 01:01:20 -0400 (EDT)
Subject: [undertow-dev] HttpServerExchange.unDispatch()
In-Reply-To: <CAFqH8G9+MKbf9t_dQu49Jx+TpWQBjQJJabx4Jqy_U2o0_LBjMQ@mail.gmail.com>
References: <CAFqH8G9+MKbf9t_dQu49Jx+TpWQBjQJJabx4Jqy_U2o0_LBjMQ@mail.gmail.com>
Message-ID: <1537531201.17703321.1442379680512.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Chris Back" <chris.back at gmail.com>
> To: undertow-dev at lists.jboss.org
> Sent: Wednesday, 16 September, 2015 12:44:32 PM
> Subject: [undertow-dev] HttpServerExchange.unDispatch()
> 
> I noticed an undocumented (as far as I can tell) public method on the
> exchange, unDispatch(). How is this supposed to be used? Is it to move a
> process back into the IO thread pool?
> 
> I ask because I have written a ChannelListener that reads in the entire http
> entity before passing the request through to the next HttpHandler. I have
> noticed sometimes without my dispatching the request the exchange gets
> dispatched on it own. I assume this is some side effect calling
> channel.resumeReads().

unDispatch basically just clears the 'dispatch' flag, cancelling an earlier dispatch. Basically the only real use for this is for servlet, if a user calls startAsync() then AC.complete() immediately we call unDispatch() to cancel the dispatch(). 

Also you are correct that calling resumeReads() results in a dispatch, basically this allows us to wait until the call stack has returned before actually resuming reads (otherwise both the current thread and the IO thread could be modifying the exchange at the same time).

Stuart

> 
> Is it safe to use exchange.unDispatch() like dispatch() (only in reverse)?
> 
> -Chris
> 
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev

From bburke at redhat.com  Wed Sep 16 08:41:41 2015
From: bburke at redhat.com (Bill Burke)
Date: Wed, 16 Sep 2015 08:41:41 -0400
Subject: [undertow-dev] backchannel logout in cluster
In-Reply-To: <1075409545.17629087.1442364543930.JavaMail.zimbra@redhat.com>
References: <55F6E779.4090301@redhat.com> <55F6EB56.1030700@redhat.com>
	<202624729.17173048.1442269367134.JavaMail.zimbra@redhat.com>
	<55F8195B.4040401@redhat.com>
	<1075409545.17629087.1442364543930.JavaMail.zimbra@redhat.com>
Message-ID: <55F96385.7030809@redhat.com>



On 9/15/2015 8:49 PM, Stuart Douglas wrote:
>
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: "Stuart Douglas" <sdouglas at redhat.com>
>> Cc: undertow-dev at lists.jboss.org
>> Sent: Tuesday, 15 September, 2015 11:12:59 PM
>> Subject: Re: [undertow-dev] backchannel logout in cluster
>>
>>
>>
>> On 9/14/2015 6:22 PM, Stuart Douglas wrote:
>>> I don't think there is much Undertow can do here, because this is clustered
>>> it is basically out of Undertow's control.
>>>
>>> For a non clustered version you can just maintain your own map using
>>> session listeners, however like you say for the clustered version if you
>>> want to maintain this sort of map you will need to create an Infinispan
>>> cache to handle the mapping.
>>>
>>> When you mentioned an Undertow SPI what exactly did you have in mind? Some
>>> way to query the session manager based on session attributes?
>>>
>>
>> A Hack I thought of was to create an Http Session that is shared by all
>> requests and machines or clone the existing http session and change the
>> session id to an SSO session id provided by the IdP.  Undertow doesn't
>> have a way to provide your own session id though when creating sessions.
>> (Jetty doesn't either, only Tomcat/JBossWeb allow this).
>
> We don't have a documented way, but if you pass in a SessionConfig implementation that returns a constant value for findSessionId
> to the createSession method then this session id will be used for the new session.
>
> This is obviously a hack though, and I will look at adding a new method that supports this directly.
>
>>
>> Better extensions to Undertow session manager would be:
>> * Ability to associate an alias to an http session. i.e. an SSO session ID.
>> * or the ability to replace the http session id, with a new one.  i.e.
>> after authentication, replace the local http session id, with the SSO
>> session id
>
> I can do this one as well.
>
>> * Additionally, the ability to index http sessions (or session ids) by
>> principal or principal name.
>
> Would you still need this indexing if I give you control over the session ID?
>

Sometimes a logout request just has the principal, it doesn't have to 
have an SSO session id.  Would it be hard to add the ability to index 
the session with any arbitrary string key?  Of course, all this indexing 
is only useful and id replacement is only useful if any node in the 
cluster can lookup and invalidate a session.

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From sdouglas at redhat.com  Wed Sep 16 08:55:30 2015
From: sdouglas at redhat.com (Stuart Douglas)
Date: Wed, 16 Sep 2015 08:55:30 -0400 (EDT)
Subject: [undertow-dev] backchannel logout in cluster
In-Reply-To: <55F96385.7030809@redhat.com>
References: <55F6E779.4090301@redhat.com> <55F6EB56.1030700@redhat.com>
	<202624729.17173048.1442269367134.JavaMail.zimbra@redhat.com>
	<55F8195B.4040401@redhat.com>
	<1075409545.17629087.1442364543930.JavaMail.zimbra@redhat.com>
	<55F96385.7030809@redhat.com>
Message-ID: <1958094280.17839350.1442408130255.JavaMail.zimbra@redhat.com>

Adding Paul.

For our in memory session manager it is relatively simple. From a clustering POV though I think that this will end up being a case of Wildfly doing the same book keeping that you would do otherwise, although Paul is the expert.

Either way this will be an API change that needs to go into the next version of Undertow (so it will miss WF10, but may make EAP7).

Stuart



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stuart Douglas" <sdouglas at redhat.com>
> Cc: undertow-dev at lists.jboss.org
> Sent: Wednesday, 16 September, 2015 10:41:41 PM
> Subject: Re: [undertow-dev] backchannel logout in cluster
> 
> 
> 
> On 9/15/2015 8:49 PM, Stuart Douglas wrote:
> >
> >
> > ----- Original Message -----
> >> From: "Bill Burke" <bburke at redhat.com>
> >> To: "Stuart Douglas" <sdouglas at redhat.com>
> >> Cc: undertow-dev at lists.jboss.org
> >> Sent: Tuesday, 15 September, 2015 11:12:59 PM
> >> Subject: Re: [undertow-dev] backchannel logout in cluster
> >>
> >>
> >>
> >> On 9/14/2015 6:22 PM, Stuart Douglas wrote:
> >>> I don't think there is much Undertow can do here, because this is
> >>> clustered
> >>> it is basically out of Undertow's control.
> >>>
> >>> For a non clustered version you can just maintain your own map using
> >>> session listeners, however like you say for the clustered version if you
> >>> want to maintain this sort of map you will need to create an Infinispan
> >>> cache to handle the mapping.
> >>>
> >>> When you mentioned an Undertow SPI what exactly did you have in mind?
> >>> Some
> >>> way to query the session manager based on session attributes?
> >>>
> >>
> >> A Hack I thought of was to create an Http Session that is shared by all
> >> requests and machines or clone the existing http session and change the
> >> session id to an SSO session id provided by the IdP.  Undertow doesn't
> >> have a way to provide your own session id though when creating sessions.
> >> (Jetty doesn't either, only Tomcat/JBossWeb allow this).
> >
> > We don't have a documented way, but if you pass in a SessionConfig
> > implementation that returns a constant value for findSessionId
> > to the createSession method then this session id will be used for the new
> > session.
> >
> > This is obviously a hack though, and I will look at adding a new method
> > that supports this directly.
> >
> >>
> >> Better extensions to Undertow session manager would be:
> >> * Ability to associate an alias to an http session. i.e. an SSO session
> >> ID.
> >> * or the ability to replace the http session id, with a new one.  i.e.
> >> after authentication, replace the local http session id, with the SSO
> >> session id
> >
> > I can do this one as well.
> >
> >> * Additionally, the ability to index http sessions (or session ids) by
> >> principal or principal name.
> >
> > Would you still need this indexing if I give you control over the session
> > ID?
> >
> 
> Sometimes a logout request just has the principal, it doesn't have to
> have an SSO session id.  Would it be hard to add the ability to index
> the session with any arbitrary string key?  Of course, all this indexing
> is only useful and id replacement is only useful if any node in the
> cluster can lookup and invalidate a session.
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> 

From ralf_boogie_blues at bluewin.ch  Wed Sep 16 08:57:33 2015
From: ralf_boogie_blues at bluewin.ch (ralf_boogie_blues at bluewin.ch)
Date: Wed, 16 Sep 2015 12:57:33 +0000 (GMT)
Subject: [undertow-dev] Frontent Load Balancer with Mod-Cluster using a
	virtual IP address
Message-ID: <1995083.29605.1442408253820.JavaMail.webmail@bluewin.ch>

Hi
I trying to replace your Apache Httpd with mod_cluster load balancer with Undertow frontend modcluster as part of Wildfly 9.0.1.
It works fine when I define a 'real' IP address defined in /etc/hosts:
  127.0.0.1     localhost
  10.22.62.40  mdzhrnesir01.standard.six-group.net mdzhrnesir01
But this IP address 10.22.62.117 is not taken by untertow:
  ip addr
  .
  8: bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP
    link/ether 00:17:a4:77:f0:b6 brd ff:ff:ff:ff:ff:ff
    inet 10.22.62.40/24 brd 10.22.62.255 scope global bond0
    inet 10.22.62.117/24 scope global secondary bond0
I also faced to problem, that running the example presented by Stuart Douglas  doesn't work inside a docker container. Even I execute step by step.
Without digging into the source code, what are the criteria under which Undertow frontend modcluster accepts IP address(es)? 
Do you also have a proposal for configuring Undertow modcluster to listen to two interfaces? Say an internal IP address and an virtual external IP address?
I think with Apache, we defined 0.0.0.0 and then Apache with mod_cluster was listening on all interfaces, if I remember correctly.
Thanks a lot in advance
Ralf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20150916/263a2048/attachment-0001.html 

From bburke at redhat.com  Wed Sep 16 09:00:34 2015
From: bburke at redhat.com (Bill Burke)
Date: Wed, 16 Sep 2015 09:00:34 -0400
Subject: [undertow-dev] backchannel logout in cluster
In-Reply-To: <1958094280.17839350.1442408130255.JavaMail.zimbra@redhat.com>
References: <55F6E779.4090301@redhat.com> <55F6EB56.1030700@redhat.com>
	<202624729.17173048.1442269367134.JavaMail.zimbra@redhat.com>
	<55F8195B.4040401@redhat.com>
	<1075409545.17629087.1442364543930.JavaMail.zimbra@redhat.com>
	<55F96385.7030809@redhat.com>
	<1958094280.17839350.1442408130255.JavaMail.zimbra@redhat.com>
Message-ID: <55F967F2.6060604@redhat.com>

If its not in EAP7 then the change isn't worth it.

On 9/16/2015 8:55 AM, Stuart Douglas wrote:
> Adding Paul.
>
> For our in memory session manager it is relatively simple. From a clustering POV though I think that this will end up being a case of Wildfly doing the same book keeping that you would do otherwise, although Paul is the expert.
>
> Either way this will be an API change that needs to go into the next version of Undertow (so it will miss WF10, but may make EAP7).
>
> Stuart
>
>
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: "Stuart Douglas" <sdouglas at redhat.com>
>> Cc: undertow-dev at lists.jboss.org
>> Sent: Wednesday, 16 September, 2015 10:41:41 PM
>> Subject: Re: [undertow-dev] backchannel logout in cluster
>>
>>
>>
>> On 9/15/2015 8:49 PM, Stuart Douglas wrote:
>>>
>>>
>>> ----- Original Message -----
>>>> From: "Bill Burke" <bburke at redhat.com>
>>>> To: "Stuart Douglas" <sdouglas at redhat.com>
>>>> Cc: undertow-dev at lists.jboss.org
>>>> Sent: Tuesday, 15 September, 2015 11:12:59 PM
>>>> Subject: Re: [undertow-dev] backchannel logout in cluster
>>>>
>>>>
>>>>
>>>> On 9/14/2015 6:22 PM, Stuart Douglas wrote:
>>>>> I don't think there is much Undertow can do here, because this is
>>>>> clustered
>>>>> it is basically out of Undertow's control.
>>>>>
>>>>> For a non clustered version you can just maintain your own map using
>>>>> session listeners, however like you say for the clustered version if you
>>>>> want to maintain this sort of map you will need to create an Infinispan
>>>>> cache to handle the mapping.
>>>>>
>>>>> When you mentioned an Undertow SPI what exactly did you have in mind?
>>>>> Some
>>>>> way to query the session manager based on session attributes?
>>>>>
>>>>
>>>> A Hack I thought of was to create an Http Session that is shared by all
>>>> requests and machines or clone the existing http session and change the
>>>> session id to an SSO session id provided by the IdP.  Undertow doesn't
>>>> have a way to provide your own session id though when creating sessions.
>>>> (Jetty doesn't either, only Tomcat/JBossWeb allow this).
>>>
>>> We don't have a documented way, but if you pass in a SessionConfig
>>> implementation that returns a constant value for findSessionId
>>> to the createSession method then this session id will be used for the new
>>> session.
>>>
>>> This is obviously a hack though, and I will look at adding a new method
>>> that supports this directly.
>>>
>>>>
>>>> Better extensions to Undertow session manager would be:
>>>> * Ability to associate an alias to an http session. i.e. an SSO session
>>>> ID.
>>>> * or the ability to replace the http session id, with a new one.  i.e.
>>>> after authentication, replace the local http session id, with the SSO
>>>> session id
>>>
>>> I can do this one as well.
>>>
>>>> * Additionally, the ability to index http sessions (or session ids) by
>>>> principal or principal name.
>>>
>>> Would you still need this indexing if I give you control over the session
>>> ID?
>>>
>>
>> Sometimes a logout request just has the principal, it doesn't have to
>> have an SSO session id.  Would it be hard to add the ability to index
>> the session with any arbitrary string key?  Of course, all this indexing
>> is only useful and id replacement is only useful if any node in the
>> cluster can lookup and invalidate a session.
>>
>> --
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From arjan.tijms at gmail.com  Wed Sep 16 09:14:22 2015
From: arjan.tijms at gmail.com (arjan tijms)
Date: Wed, 16 Sep 2015 15:14:22 +0200
Subject: [undertow-dev] backchannel logout in cluster
In-Reply-To: <55F967F2.6060604@redhat.com>
References: <55F6E779.4090301@redhat.com> <55F6EB56.1030700@redhat.com>
	<202624729.17173048.1442269367134.JavaMail.zimbra@redhat.com>
	<55F8195B.4040401@redhat.com>
	<1075409545.17629087.1442364543930.JavaMail.zimbra@redhat.com>
	<55F96385.7030809@redhat.com>
	<1958094280.17839350.1442408130255.JavaMail.zimbra@redhat.com>
	<55F967F2.6060604@redhat.com>
Message-ID: <CAE=-AhD9o0b+VNpcH0M79gY7YRe4tCd4ds4WSDkMgN5AGFmk7w@mail.gmail.com>

Hi,

On Wed, Sep 16, 2015 at 3:00 PM, Bill Burke <bburke at redhat.com> wrote:
> If its not in EAP7 then the change isn't worth it.

Speaking of which, any tentative plan for an EAP7 release date? Given
the release date target of WF10 towards the end of this year, and
assuming EAP7 directly follows EAP7 (i.e. no WF11 before that), would
a mid 2016 release be realistic?

Arjan

p.s.

Following this thread to see if it's anything that the Security JSR
could help with, but as clustering itself is not specified in Java EE
this may be hard.

From chris.back at gmail.com  Wed Sep 16 14:50:30 2015
From: chris.back at gmail.com (Chris Back)
Date: Wed, 16 Sep 2015 18:50:30 +0000
Subject: [undertow-dev] Mostly IO, non-blocking workload best practice
In-Reply-To: <734220414.11551921.1430280970564.JavaMail.zimbra@redhat.com>
References: <CAFqH8G8oBLgkxUSRNBHKRRON0qspPUvgTG2ArB-PjP7o+pBp_g@mail.gmail.com>
	<734220414.11551921.1430280970564.JavaMail.zimbra@redhat.com>
Message-ID: <CAFqH8G9MA2jxU+DGKUZJ6Vg3vThTF3XiUrx4rJD9gh_yit0+Gg@mail.gmail.com>

I have included an example of the code I built to make sure all request
data has been read before passing on to my next handler. It is included in
the two attached files.

My questions are :
a) Does it look correct? Things seem to be working in practice, but I'd
like confirmation from people more experienced with undertow.
b) I am occasionally seeing requests that start in a non-io thread (i.e. if
I call isInIoThread() as the first call of my root HttpHandler it returns
false. Should that be possible?

Thanks,
Chris

On Tue, Apr 28, 2015 at 9:16 PM Stuart Douglas <sdouglas at redhat.com> wrote:

> The non blocking API for reading data is actually something we are looking
> at improving in the next version of Undertow.
>
> For now you need to use the XNIO request channel. For an example of how to
> use this look at io.undertow.util.StringReadChannelListener (you can
> actually just subclass this class).
>
> Basically the most efficient way to use the API is:
>
> - Get a pooled buffer from the connections buffer pool
> - keep calling StreamSinkChannel.read() to read the data
> - If read returns 0 register a read listener and then call resumeReads()
> and return. Your listener will be notified when more data is available.
> - When read returns -1 you are done
>
> Stuart
>
> ----- Original Message -----
> > From: "Chris Back" <chris.back at gmail.com>
> > To: undertow-dev at lists.jboss.org
> > Sent: Wednesday, 29 April, 2015 12:08:09 AM
> > Subject: [undertow-dev] Mostly IO, non-blocking workload best practice
> >
> > I am writing a server that will need to respond to lots of small web
> > requests. Most of the requests will come with a small POST payload.
> Based on
> > the contents of the payload, the server will either a) respond
> immediately,
> > or b) forward the request as is to one of a pool of backend servers,
> waiting
> > for a response and forwarding the response back to the client.
> >
> > It looks like given the existing undertow code, I have good examples of
> how
> > to forward requests to the backend. What isn't as clear is how to handle
> the
> > getting the POST data. Is there a way of doing that without blocking?
> >
> > Ideally, my handler flow would be:
> >
> > 1. Non-blocking request handler that makes sure all POST data is in.
> > 2. A non-blocking handler that decisions based on content of POST data to
> > 3a. Immediately return a response to the client (non-blocking).
> > or
> > 3b. Dispatch to the worker pool to forward request to backend server and
> > await response.
> >
> > 90% of my requests will go through path 3a, and I'd like that to be as
> quick
> > as possible. When the server decides a request should go through 3b, only
> > then should it go to the blocking worker pool.
> >
> > Am I viewing this correctly? What are my options? Based on this thread
> > http://lists.jboss.org/pipermail/undertow-dev/2015-January/001082.html
> > it seems like an option could be to get the request channel in step 1
> above?
> > Its not clear to me how that would work.
> >
> > Thanks,
> > Chris
> >
> > _______________________________________________
> > undertow-dev mailing list
> > undertow-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/undertow-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20150916/28c17550/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ReadCompleteHandler.java
Type: application/octet-stream
Size: 1938 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/undertow-dev/attachments/20150916/28c17550/attachment.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: DataReadListener.java
Type: application/octet-stream
Size: 2292 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/undertow-dev/attachments/20150916/28c17550/attachment-0001.obj 

From sdouglas at redhat.com  Thu Sep 17 18:25:30 2015
From: sdouglas at redhat.com (Stuart Douglas)
Date: Thu, 17 Sep 2015 18:25:30 -0400 (EDT)
Subject: [undertow-dev] Mostly IO, non-blocking workload best practice
In-Reply-To: <CAFqH8G9MA2jxU+DGKUZJ6Vg3vThTF3XiUrx4rJD9gh_yit0+Gg@mail.gmail.com>
References: <CAFqH8G8oBLgkxUSRNBHKRRON0qspPUvgTG2ArB-PjP7o+pBp_g@mail.gmail.com>
	<734220414.11551921.1430280970564.JavaMail.zimbra@redhat.com>
	<CAFqH8G9MA2jxU+DGKUZJ6Vg3vThTF3XiUrx4rJD9gh_yit0+Gg@mail.gmail.com>
Message-ID: <332449940.19093786.1442528730525.JavaMail.zimbra@redhat.com>

This does look correct. WRT question b) the only way this should be able to happen is if you are using HTTP pipelining combined with blocking IO (i.e. you have dispatched to the worker further down the chain). 

If this happens the root handler of the next request may start in a worker thread rather than an IO thread (this is an optimization designed to prevent a possible double dispatch back to the IO then back to the worker). In practice it does not matter, it is still perfectly fine to perform non-blocking IO from a worker threads. It seems odd that you would run into this though.

Also you asked about dispatching back to the IO thread, this is possible, you can just call dispatch and pass in the IOThread as your executor.

Stuart

----- Original Message -----
> From: "Chris Back" <chris.back at gmail.com>
> To: "Stuart Douglas" <sdouglas at redhat.com>
> Cc: undertow-dev at lists.jboss.org
> Sent: Thursday, 17 September, 2015 4:50:30 AM
> Subject: Re: [undertow-dev] Mostly IO, non-blocking workload best practice
> 
> I have included an example of the code I built to make sure all request
> data has been read before passing on to my next handler. It is included in
> the two attached files.
> 
> My questions are :
> a) Does it look correct? Things seem to be working in practice, but I'd
> like confirmation from people more experienced with undertow.
> b) I am occasionally seeing requests that start in a non-io thread (i.e. if
> I call isInIoThread() as the first call of my root HttpHandler it returns
> false. Should that be possible?
> 
> Thanks,
> Chris
> 
> On Tue, Apr 28, 2015 at 9:16 PM Stuart Douglas <sdouglas at redhat.com> wrote:
> 
> > The non blocking API for reading data is actually something we are looking
> > at improving in the next version of Undertow.
> >
> > For now you need to use the XNIO request channel. For an example of how to
> > use this look at io.undertow.util.StringReadChannelListener (you can
> > actually just subclass this class).
> >
> > Basically the most efficient way to use the API is:
> >
> > - Get a pooled buffer from the connections buffer pool
> > - keep calling StreamSinkChannel.read() to read the data
> > - If read returns 0 register a read listener and then call resumeReads()
> > and return. Your listener will be notified when more data is available.
> > - When read returns -1 you are done
> >
> > Stuart
> >
> > ----- Original Message -----
> > > From: "Chris Back" <chris.back at gmail.com>
> > > To: undertow-dev at lists.jboss.org
> > > Sent: Wednesday, 29 April, 2015 12:08:09 AM
> > > Subject: [undertow-dev] Mostly IO, non-blocking workload best practice
> > >
> > > I am writing a server that will need to respond to lots of small web
> > > requests. Most of the requests will come with a small POST payload.
> > Based on
> > > the contents of the payload, the server will either a) respond
> > immediately,
> > > or b) forward the request as is to one of a pool of backend servers,
> > waiting
> > > for a response and forwarding the response back to the client.
> > >
> > > It looks like given the existing undertow code, I have good examples of
> > how
> > > to forward requests to the backend. What isn't as clear is how to handle
> > the
> > > getting the POST data. Is there a way of doing that without blocking?
> > >
> > > Ideally, my handler flow would be:
> > >
> > > 1. Non-blocking request handler that makes sure all POST data is in.
> > > 2. A non-blocking handler that decisions based on content of POST data to
> > > 3a. Immediately return a response to the client (non-blocking).
> > > or
> > > 3b. Dispatch to the worker pool to forward request to backend server and
> > > await response.
> > >
> > > 90% of my requests will go through path 3a, and I'd like that to be as
> > quick
> > > as possible. When the server decides a request should go through 3b, only
> > > then should it go to the blocking worker pool.
> > >
> > > Am I viewing this correctly? What are my options? Based on this thread
> > > http://lists.jboss.org/pipermail/undertow-dev/2015-January/001082.html
> > > it seems like an option could be to get the request channel in step 1
> > above?
> > > Its not clear to me how that would work.
> > >
> > > Thanks,
> > > Chris
> > >
> > > _______________________________________________
> > > undertow-dev mailing list
> > > undertow-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/undertow-dev
> >
> 

From sdouglas at redhat.com  Thu Sep 17 19:46:04 2015
From: sdouglas at redhat.com (Stuart Douglas)
Date: Thu, 17 Sep 2015 19:46:04 -0400 (EDT)
Subject: [undertow-dev] Frontent Load Balancer with Mod-Cluster using
	a	virtual IP address
In-Reply-To: <1995083.29605.1442408253820.JavaMail.webmail@bluewin.ch>
References: <1995083.29605.1442408253820.JavaMail.webmail@bluewin.ch>
Message-ID: <1195580226.19131234.1442533564897.JavaMail.zimbra@redhat.com>

Are you using Wildfly or standalone Undertow? The procedure for configuring a listener is different for each. For Wildfly just add a socket binding to the interface you want to listen on then add a http-listener in the Undertow subsystem that references that binding.

For standalone Undertow simply call addListener() multiple times for each interface you want to listen on.

Stuart

----- Original Message -----
> From: "ralf boogie blues" <ralf_boogie_blues at bluewin.ch>
> To: undertow-dev at lists.jboss.org
> Sent: Wednesday, 16 September, 2015 10:57:33 PM
> Subject: [undertow-dev] Frontent Load Balancer with Mod-Cluster using a	virtual IP address
> 
> Hi
> 
> I trying to replace your Apache Httpd with mod_cluster load balancer with
> Undertow frontend modcluster as part of Wildfly 9.0.1.
> 
> It works fine when I define a 'real' IP address defined in /etc/hosts:
> 
> 127.0.0.1 localhost
> 10.22.62.40 mdzhrnesir01.standard.six-group.net mdzhrnesir01
> 
> 
> But this IP address 10.22.62.117 is not taken by untertow:
> 
> ip addr
> .
> 8: bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue
> state UP
> link/ether 00:17:a4:77:f0:b6 brd ff:ff:ff:ff:ff:ff
> inet 10.22.62.40/24 brd 10.22.62.255 scope global bond0
> inet 10.22.62.117/24 scope global secondary bond0
> 
> 
> I also faced to problem, that running the example presented by Stuart Douglas
> doesn't work inside a docker container. Even I execute step by step.
> 
> Without digging into the source code, what are the criteria under which
> Undertow frontend modcluster accepts IP address(es)?
> 
> Do you also have a proposal for configuring Undertow modcluster to listen to
> two interfaces? Say an internal IP address and an virtual external IP
> address?
> 
> I think with Apache, we defined 0.0.0.0 and then Apache with mod_cluster was
> listening on all interfaces, if I remember correctly.
> 
> Thanks a lot in advance
> Ralf
> 
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev

From devl.development at gmail.com  Fri Sep 18 07:26:51 2015
From: devl.development at gmail.com (Devl Devel)
Date: Fri, 18 Sep 2015 12:26:51 +0100
Subject: [undertow-dev] Some help on Reverse Proxy Server
In-Reply-To: <1628287686.17628326.1442364306472.JavaMail.zimbra@redhat.com>
References: <CAMQ+LQPoggDY=BLc4UqF4k_Efhne2Je27v=2+SkzZ9kzHn6Spg@mail.gmail.com>
	<793233036.16634511.1442193440707.JavaMail.zimbra@redhat.com>
	<CAMQ+LQPr1_x7yyr209Dyd-Dc0BGZhwY5gDjq_hapxoijrr936Q@mail.gmail.com>
	<1628287686.17628326.1442364306472.JavaMail.zimbra@redhat.com>
Message-ID: <CAMQ+LQPrpxKxcxAJH2KxjzZRWtHh9y-_gSO949Dv2-jf0KgEGQ@mail.gmail.com>

Thanks for the tip,

I tried adding the headers on the proxy and sslheaderhandler on the server
but now I get:

UT005028: Proxy request to /

java.io.IOException: UT001000: Connection closed

               at
io.undertow.client.http.HttpClientConnection$ClientReadListener.handleEvent(HttpClientConnection.java:415)

               at
io.undertow.client.http.HttpClientConnection$ClientReadListener.handleEvent(HttpClientConnection.java:372)

               at
org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)

               at
org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66)

               at
io.undertow.protocols.ssl.SslConduit$SslReadReadyHandler.readReady(SslConduit.java:1045)

               at
io.undertow.protocols.ssl.SslConduit$1.run(SslConduit.java:225)

               at org.xnio.nio.WorkerThread.safeRun(WorkerThread.java:560)

               at org.xnio.nio.WorkerThread.run(WorkerThread.java:462)


On the proxy when I make the request to the proxy form a browser. I take it
this means there's a problem on the back end? But when I get to the back
end directly it works fine. Any more tips would be appreciated.


Thanks

On Wed, Sep 16, 2015 at 1:45 AM, Stuart Douglas <sdouglas at redhat.com> wrote:

> If you want to use client-cert mode with a proxy you need to actually send
> the cert as a header (otherwise you would need a 1:1 mapping between front
> and back end connections).
>
> Basically on the backend server you need to have a
> io.undertow.server.handlers.SSLHeaderHandler installed, this will look for
> the headers and set up the appropriate SSL structures (don't install this
> handler on an internet facing server).
>
> In your proxy server you then need to add the following code:
>
>
>         proxyHandler.addRequestHeader(Headers.SSL_CLIENT_CERT,
> "%{SSL_CLIENT_CERT}");
>         proxyHandler.addRequestHeader(Headers.SSL_CIPHER, "%{SSL_CIPHER}");
>         proxyHandler.addRequestHeader(Headers.SSL_SESSION_ID,
> "%{SSL_SESSION_ID}");
>
> (I really should add a simpler way of doing this).
>
> Now the certificate information will be sent on every request as a header,
> and the backend server can deal with it as normal. This also means you
> don't have to use HTTPS for the connection to the backend server.
>
> Stuart
>
>
> ----- Original Message -----
> > From: "Devl Devel" <devl.development at gmail.com>
> > To: "Stuart Douglas" <sdouglas at redhat.com>
> > Cc: undertow-dev at lists.jboss.org
> > Sent: Wednesday, 16 September, 2015 12:59:55 AM
> > Subject: Re: [undertow-dev] Some help on Reverse Proxy Server
> >
> > Hi Stuart
> >
> > Thanks for this. I tried the example with a proxy server that has a valid
> > ssl context, byte buffer slice pool, undertow xnio ssl with worker, and
> > load balancing proxy client as per your example. Using 1.2.12.Final
> >
> > On the receiving webserver (which works fine with other https: and other
> > SSL requests) I have enabled SSLCLientMode.Required and other settings
> > similar to DefaultServer.  This works when I go direct to the webserver
> in
> > the browser - I can use it normally but when I use the proxy and issue a
> > https request I get:
> >
> > ERROR proxy - UT005028: Proxy request to / failed
> >
> > java.io.IOException: overflow
> >
> >                at
> > io.undertow.protocols.ssl.SslConduit.doWrap(SslConduit.java:801)
> >
> >                at
> > io.undertow.protocols.ssl.SslConduit.write(SslConduit.java:336)
> >
> >                at
> >
> io.undertow.client.http.HttpRequestConduit.processWrite(HttpRequestConduit.java:321)
> >
> >                at
> >
> io.undertow.client.http.HttpRequestConduit.flush(HttpRequestConduit.java:573)
> >
> >                at
> >
> io.undertow.conduits.AbstractFixedLengthStreamSinkConduit.flush(AbstractFixedLengthStreamSinkConduit.java:229)
> >
> >                at
> >
> org.xnio.conduits.ConduitStreamSinkChannel.flush(ConduitStreamSinkChannel.java:162)
> >
> >                at
> >
> io.undertow.client.http.HttpClientConnection.initiateRequest(HttpClientConnection.java:299)
> >
> >                at
> >
> io.undertow.client.http.HttpClientConnection.sendRequest(HttpClientConnection.java:228)
> >
> >                at
> >
> io.undertow.server.handlers.proxy.ProxyHandler$ProxyAction.run(ProxyHandler.java:502)
> >
> >                at
> > io.undertow.util.SameThreadExecutor.execute(SameThreadExecutor.java:35)
> >
> >                at
> >
> io.undertow.server.HttpServerExchange.dispatch(HttpServerExchange.java:759)
> >
> >                at
> >
> io.undertow.server.handlers.proxy.ProxyHandler$ProxyClientHandler.completed(ProxyHandler.java:269)
> >
> >                at
> >
> io.undertow.server.handlers.proxy.ProxyHandler$ProxyClientHandler.completed(ProxyHandler.java:245)
> >
> >                at
> >
> io.undertow.server.handlers.proxy.ProxyConnectionPool.connectionReady(ProxyConnectionPool.java:292)
> >
> >                at
> >
> io.undertow.server.handlers.proxy.ProxyConnectionPool.access$800(ProxyConnectionPool.java:54)
> >
> >                at
> >
> io.undertow.server.handlers.proxy.ProxyConnectionPool$1.completed(ProxyConnectionPool.java:245)
> >
> >                at
> >
> io.undertow.server.handlers.proxy.ProxyConnectionPool$1.completed(ProxyConnectionPool.java:233)
> >
> >                at
> >
> io.undertow.client.http.HttpClientProvider.handleConnected(HttpClientProvider.java:163)
> >
> >                at
> >
> io.undertow.client.http.HttpClientProvider.access$000(HttpClientProvider.java:50)
> >
> >                at
> >
> io.undertow.client.http.HttpClientProvider$2.handleEvent(HttpClientProvider.java:126)
> >
> >                at
> >
> io.undertow.client.http.HttpClientProvider$2.handleEvent(HttpClientProvider.java:123)
> >
> >                at
> > org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> >
> >                at
> >
> io.undertow.protocols.ssl.UndertowXnioSsl$StreamConnectionChannelListener.handleEvent(UndertowXnioSsl.java:312)
> >
> >                at
> >
> io.undertow.protocols.ssl.UndertowXnioSsl$StreamConnectionChannelListener.handleEvent(UndertowXnioSsl.java:294)
> >
> >                at
> > org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> >
> >                at
> >
> org.xnio.nio.WorkerThread$ConnectHandle.handleReady(WorkerThread.java:324)
> >
> >                at org.xnio.nio.WorkerThread.run(WorkerThread.java:539)
> >
> >
> >
> > Will the proxy forward the browser cert to the webserver or is there some
> > other cause? I cannot share any code but any pointers are appreciated.
> >
> >
> >
> > Thanks
> >
> > Devl
> >
> >
> >
> > On Mon, Sep 14, 2015 at 2:17 AM, Stuart Douglas <sdouglas at redhat.com>
> wrote:
> >
> > > And example of this can be found in this test:
> > >
> > >
> > >
> https://github.com/undertow-io/undertow/blob/master/core/src/test/java/io/undertow/server/handlers/proxy/LoadBalancingProxyHttpsTestCase.java
> > >
> > > Stuart
> > >
> > > ----- Original Message -----
> > > > From: "Devl Devel" <devl.development at gmail.com>
> > > > To: undertow-dev at lists.jboss.org
> > > > Sent: Saturday, 12 September, 2015 12:00:48 AM
> > > > Subject: [undertow-dev] Some help on Reverse Proxy Server
> > > >
> > > > At present the git example for Reverse Proxy is a non https/ssl
> example.
> > > >
> > > >
> > > >
> > >
> https://github.com/undertow-io/undertow/blob/master/examples/src/main/java/io/undertow/examples/reverseproxy/ReverseProxyServer.java
> > > >
> > > > Please can you help with an example using SSL and https?
> > > >
> > > > I take it the .addHost( new URI ( " http://localhost:8081 " ) method
> > > >
> > > > needs and XNioSSL object to work with https redirection? If so,
> please
> > > can
> > > > you provide an example of how to configure this?
> > > >
> > > > Thanks
> > > > Devl
> > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > undertow-dev mailing list
> > > > undertow-dev at lists.jboss.org
> > > > https://lists.jboss.org/mailman/listinfo/undertow-dev
> > >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20150918/62c50c7b/attachment.html 

From ralf_boogie_blues at bluewin.ch  Sun Sep 20 05:37:33 2015
From: ralf_boogie_blues at bluewin.ch (ralf_boogie_blues at bluewin.ch)
Date: Sun, 20 Sep 2015 09:37:33 +0000 (GMT+00:00)
Subject: [undertow-dev] Frontent Load Balancer with Mod-Cluster using
 a	virtual IP address
In-Reply-To: <1195580226.19131234.1442533564897.JavaMail.zimbra@redhat.com>
References: <1995083.29605.1442408253820.JavaMail.webmail@bluewin.ch>
	<1195580226.19131234.1442533564897.JavaMail.zimbra@redhat.com>
Message-ID: <10387605.5965.1442741853196.JavaMail.webmail@bluewin.ch>

Thanks a lot Stuart, you pointed me to the right direction. We are using Wildfly. I added a new interface and added a second socketBinding as you have described. That works nicely. 

Really cool, the interface can be configured to listen on a nic name too. This is exactly what I am looking for.

What I didn't manage is only to open the management console. What is the path for accessing the management console? I saw in some tests "/mod_cluster_manager" but I was not able to access the console with this path.

I think, it would make sense to update the official wildfly undertow load balancer documentation: https://docs.jboss.org/author/display/WFLY9/Using+Wildfly+as+a+Load+Balancer

Thanks again
Ralf


----Urspr?ngliche Nachricht----
Von : sdouglas at redhat.com
Datum : 18/09/2015 - 01:46 (WEDT)
An : ralf_boogie_blues at bluewin.ch
Cc : undertow-dev at lists.jboss.org
Betreff : Re: [undertow-dev] Frontent Load Balancer with Mod-Cluster using a	virtual IP address

Are you using Wildfly or standalone Undertow? The procedure for configuring a listener is different for each. For Wildfly just add a socket binding to the interface you want to listen on then add a http-listener in the Undertow subsystem that references that binding.

For standalone Undertow simply call addListener() multiple times for each interface you want to listen on.

Stuart

----- Original Message -----
> From: "ralf boogie blues" <ralf_boogie_blues at bluewin.ch>
> To: undertow-dev at lists.jboss.org
> Sent: Wednesday, 16 September, 2015 10:57:33 PM
> Subject: [undertow-dev] Frontent Load Balancer with Mod-Cluster using a	virtual IP address
> 
> Hi
> 
> I trying to replace your Apache Httpd with mod_cluster load balancer with
> Undertow frontend modcluster as part of Wildfly 9.0.1.
> 
> It works fine when I define a 'real' IP address defined in /etc/hosts:
> 
> 127.0.0.1 localhost
> 10.22.62.40 mdzhrnesir01.standard.six-group.net mdzhrnesir01
> 
> 
> But this IP address 10.22.62.117 is not taken by untertow:
> 
> ip addr
> .
> 8: bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue
> state UP
> link/ether 00:17:a4:77:f0:b6 brd ff:ff:ff:ff:ff:ff
> inet 10.22.62.40/24 brd 10.22.62.255 scope global bond0
> inet 10.22.62.117/24 scope global secondary bond0
> 
> 
> I also faced to problem, that running the example presented by Stuart Douglas
> doesn't work inside a docker container. Even I execute step by step.
> 
> Without digging into the source code, what are the criteria under which
> Undertow frontend modcluster accepts IP address(es)?
> 
> Do you also have a proposal for configuring Undertow modcluster to listen to
> two interfaces? Say an internal IP address and an virtual external IP
> address?
> 
> I think with Apache, we defined 0.0.0.0 and then Apache with mod_cluster was
> listening on all interfaces, if I remember correctly.
> 
> Thanks a lot in advance
> Ralf
> 
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev


From karm at redhat.com  Tue Sep 22 05:15:11 2015
From: karm at redhat.com (Michal Karm Babacek)
Date: Tue, 22 Sep 2015 05:15:11 -0400 (EDT)
Subject: [undertow-dev] Frontent Load Balancer with Mod-Cluster using
	a	virtual IP address
In-Reply-To: <10387605.5965.1442741853196.JavaMail.webmail@bluewin.ch>
References: <1995083.29605.1442408253820.JavaMail.webmail@bluewin.ch>
	<1195580226.19131234.1442533564897.JavaMail.zimbra@redhat.com>
	<10387605.5965.1442741853196.JavaMail.webmail@bluewin.ch>
Message-ID: <827151265.14904818.1442913311922.JavaMail.zimbra@redhat.com>

Dear Ralf,

there is no such page as /mod_cluster_manager with
Undertow mod_cluster proxy.

One uses JBoss CLI to retrieve runtime information
such as registered workers, their load and deployed contexts.

For instance:

/subsystem=undertow/configuration=filter/mod-cluster=modcluster:read-resource(include-runtime=true, recursive=true, recursive-depth=10)
{
    "outcome" => "success",
    "result" => {
        "advertise-frequency" => 10000,
        "advertise-path" => "/",
        "advertise-protocol" => "httpd",
        "advertise-socket-binding" => "mod-cluster-adv",
        "broken-node-timeout" => 10,
        "cached-connections-per-thread" => 5,
        "connection-idle-timeout" => 60,
        "connections-per-thread" => 10,
        "health-check-interval" => 10000,
        "management-access-predicate" => undefined,
        "management-socket-binding" => "http",
        "max-request-time" => -1,
        "request-queue-size" => 10,
        "security-key" => undefined,
        "security-realm" => undefined,
        "worker" => "default",
        "balancer" => {
            "qa_balancer" => {"node" => {"worker-2" => {
                "load" => 89,
                "status" => "NODE_UP",
                "context" => {"/clusterbench" => {
                    "requests" => 0,
                    "status" => "enabled"
                }}
            }}},
            "mycluster" => {"node" => {"worker-1" => {
                "load" => 87,
                "status" => "NODE_UP",
                "context" => {"/clusterbench" => {
                    "requests" => 0,
                    "status" => "enabled"
                }}
            }}}
        }
    }
}


Cheers
Karm

----- Original Message -----
> From: "ralf boogie blues" <ralf_boogie_blues at bluewin.ch>
> To: sdouglas at redhat.com
> Cc: undertow-dev at lists.jboss.org
> Sent: Sunday, September 20, 2015 11:37:33 AM
> Subject: Re: [undertow-dev] Frontent Load Balancer with Mod-Cluster using a	virtual IP address
> 
> Thanks a lot Stuart, you pointed me to the right direction. We are using
> Wildfly. I added a new interface and added a second socketBinding as you
> have described. That works nicely.
> 
> Really cool, the interface can be configured to listen on a nic name too.
> This is exactly what I am looking for.
> 
> What I didn't manage is only to open the management console. What is the path
> for accessing the management console? I saw in some tests
> "/mod_cluster_manager" but I was not able to access the console with this
> path.
> 
> I think, it would make sense to update the official wildfly undertow load
> balancer documentation:
> https://docs.jboss.org/author/display/WFLY9/Using+Wildfly+as+a+Load+Balancer
> 
> Thanks again
> Ralf
> 
> 
> ----Urspr?ngliche Nachricht----
> Von : sdouglas at redhat.com
> Datum : 18/09/2015 - 01:46 (WEDT)
> An : ralf_boogie_blues at bluewin.ch
> Cc : undertow-dev at lists.jboss.org
> Betreff : Re: [undertow-dev] Frontent Load Balancer with Mod-Cluster using a
> 	virtual IP address
> 
> Are you using Wildfly or standalone Undertow? The procedure for configuring a
> listener is different for each. For Wildfly just add a socket binding to the
> interface you want to listen on then add a http-listener in the Undertow
> subsystem that references that binding.
> 
> For standalone Undertow simply call addListener() multiple times for each
> interface you want to listen on.
> 
> Stuart
> 
> ----- Original Message -----
> > From: "ralf boogie blues" <ralf_boogie_blues at bluewin.ch>
> > To: undertow-dev at lists.jboss.org
> > Sent: Wednesday, 16 September, 2015 10:57:33 PM
> > Subject: [undertow-dev] Frontent Load Balancer with Mod-Cluster using a
> > 	virtual IP address
> > 
> > Hi
> > 
> > I trying to replace your Apache Httpd with mod_cluster load balancer with
> > Undertow frontend modcluster as part of Wildfly 9.0.1.
> > 
> > It works fine when I define a 'real' IP address defined in /etc/hosts:
> > 
> > 127.0.0.1 localhost
> > 10.22.62.40 mdzhrnesir01.standard.six-group.net mdzhrnesir01
> > 
> > 
> > But this IP address 10.22.62.117 is not taken by untertow:
> > 
> > ip addr
> > .
> > 8: bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue
> > state UP
> > link/ether 00:17:a4:77:f0:b6 brd ff:ff:ff:ff:ff:ff
> > inet 10.22.62.40/24 brd 10.22.62.255 scope global bond0
> > inet 10.22.62.117/24 scope global secondary bond0
> > 
> > 
> > I also faced to problem, that running the example presented by Stuart
> > Douglas
> > doesn't work inside a docker container. Even I execute step by step.
> > 
> > Without digging into the source code, what are the criteria under which
> > Undertow frontend modcluster accepts IP address(es)?
> > 
> > Do you also have a proposal for configuring Undertow modcluster to listen
> > to
> > two interfaces? Say an internal IP address and an virtual external IP
> > address?
> > 
> > I think with Apache, we defined 0.0.0.0 and then Apache with mod_cluster
> > was
> > listening on all interfaces, if I remember correctly.
> > 
> > Thanks a lot in advance
> > Ralf
> > 
> > _______________________________________________
> > undertow-dev mailing list
> > undertow-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/undertow-dev
> 
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev

-- 
Sent from my Hosaka Ono-Sendai Cyberspace 7

--
Michal Karm Babacek
? JBoss QE, Journeyman
Red Hat Czech | CEST

? +420 737 778 560 (cell)
? +420 532 294 547 (?forwarded?)
freenode: #wildfly #phoronix #fedora-devel
? mbabacek at redhat.com ? karm at redhat.com


From adriano at localhost8080.com.br  Sun Sep 27 18:44:50 2015
From: adriano at localhost8080.com.br (Adriano Schmidt)
Date: Sun, 27 Sep 2015 19:44:50 -0300
Subject: [undertow-dev] Javascript-Support-In-Wildfly Post
Message-ID: <CA+Pik=F6gj8k5VUOAhKRan_iWS4AbHAszTpv7SEMAVEEguJMyA@mail.gmail.com>

Hi, there is a code in this post that doesn't work:

http://wildfly.org/news/2015/08/10/Javascript-Support-In-Wildfly/

I'm talking about the code with ".alias('db'"

It is must change this line:
    return DB.select("select * from members");
to:
    return db.select("select * from member");

And the two "insert" used in this sample are using the same id... It is
must change one of them.

Kind Regards,
*Adriano Schmidt*
+55 (48) 9172-1216
Skype: schmidt.adriano
www.localhost8080.com.br
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20150927/711d3f7f/attachment.html