Issue with HTTP upgrade for remote naming on OpenShit?

classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

Issue with HTTP upgrade for remote naming on OpenShit?

Jeff Mesnil
Hi,

Now we have an OpenShift cartridge for WildFly 8.0.0.Final (hanks Farah!), I’m adding instructions to the JMS quickstarts to deploy them on OpenShift.

The helloworld-mdb is working fine but I have an issue with the helloworld-jms one[1].

In this quick start, the Java client makes a lookup to JNDI to retrieve the JMS resources.

The quickstart uses the “http-remoting://localhost:8080” as the JNDI provider URL for a local WildFly server.

When I host WildFly on OpenShift, that URL should translate to http-remoting://<app>-<namespace>.rhcloud.com:80 (in my case http-remoting://helloworldjms-jmesnil.rhcloud.com:80)
However this does not work:


$ mvn clean compile exec:java -Djava.naming.provider.url=http-remoting://helloworldjms-jmesnil.rhcloud.com:80

Feb 17, 2014 3:28:46 PM org.xnio.Xnio <clinit>
INFO: XNIO version 3.2.0.Final
Feb 17, 2014 3:28:46 PM org.xnio.nio.NioXnio <clinit>
INFO: XNIO NIO Implementation Version 3.2.0.Final
Feb 17, 2014 3:28:46 PM org.jboss.remoting3.EndpointImpl <clinit>
INFO: JBoss Remoting version 4.0.0.Final
Feb 17, 2014 3:28:46 PM org.jboss.as.quickstarts.jms.HelloWorldJMSClient main
INFO: Attempting to acquire connection factory "jms/RemoteConnectionFactory"
Feb 17, 2014 3:28:47 PM org.jboss.as.quickstarts.jms.HelloWorldJMSClient main
SEVERE: Failed to connect to any server. Servers tried: [http-remoting://helloworldjms-jmesnil.rhcloud.com:80 (java.io.IOException: Invalid response code 200)]

Remote naming is correctly complaining that the HTTP Upgrade handshake responded with a 200 OK instead of a 100 Continue.
Indeed, the deployed WildFly server does not upgrade my connection. You can check by hand using curl:

$ curl -v http://helloworldjms-jmesnil.rhcloud.com -H 'Connection:upgrade' -H 'Upgrade:jboss-remoting' -H 'Sec-JbossRemoting-Key: Xj8ZjttC3aixB1bAZ9w39A=='
...
* Connected to helloworldjms-jmesnil.rhcloud.com (50.17.25.239) port 80 (#0)
> GET / HTTP/1.1
> User-Agent: curl/7.30.0
> Host: helloworldjms-jmesnil.rhcloud.com
> Accept: */*
> Connection:upgrade
> Upgrade:jboss-remoting
> Sec-JbossRemoting-Key: Xj8ZjttC3aixB1bAZ9w39A==
>
< HTTP/1.1 200 OK
< Date: Mon, 17 Feb 2014 14:23:37 GMT
* Server Wildfly 8 is not blacklisted
< Server: Wildfly 8
< Last-Modified: Mon, 17 Feb 2014 14:20:22 GMT
< X-Powered-By: Undertow 1
< Content-Type: text/html
< Content-Length: 41708
< Vary: Accept-Encoding

[Home Page content follows]

The undertow’s http-listener is the default one;

    <http-listener name="default" socket-binding="http" proxy-address-forwarding="true”/>

I tried removing the proxy-address-forwarding attribute but that did not change anything.

Has someone managed to use remote naming with WildFly on OpenShift?
Am I missing something obvious to make it run?

jeff

[1] https://github.com/jmesnil/quickstart/blob/helloworld-jms-openshift/helloworld-jms/README.md#build-and-deploy-the-quickstart---to-openshift
--
Jeff Mesnil
JBoss, a division of Red Hat
http://jmesnil.net/


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Issue with HTTP upgrade for remote naming on OpenShit?

Stuart Douglas
The relevant config item should be in the remoting subsystem:


       <http-connector name="http-remoting-connector" connector-ref="default" security-realm="ApplicationRealm"/>

This is the bit that registers the HTTP upgrade handler with Undertow.

Stuart


On Mon, Feb 17, 2014 at 8:12 PM, Jeff Mesnil <[hidden email]> wrote:
Hi,

Now we have an OpenShift cartridge for WildFly 8.0.0.Final (hanks Farah!), I’m adding instructions to the JMS quickstarts to deploy them on OpenShift.

The helloworld-mdb is working fine but I have an issue with the helloworld-jms one[1].

In this quick start, the Java client makes a lookup to JNDI to retrieve the JMS resources.

The quickstart uses the “http-remoting://localhost:8080” as the JNDI provider URL for a local WildFly server.

When I host WildFly on OpenShift, that URL should translate to http-remoting://<app>-<namespace>.rhcloud.com:80 (in my case http-remoting://helloworldjms-jmesnil.rhcloud.com:80)
However this does not work:


$ mvn clean compile exec:java -Djava.naming.provider.url=http-remoting://helloworldjms-jmesnil.rhcloud.com:80

Feb 17, 2014 3:28:46 PM org.xnio.Xnio <clinit>
INFO: XNIO version 3.2.0.Final
Feb 17, 2014 3:28:46 PM org.xnio.nio.NioXnio <clinit>
INFO: XNIO NIO Implementation Version 3.2.0.Final
Feb 17, 2014 3:28:46 PM org.jboss.remoting3.EndpointImpl <clinit>
INFO: JBoss Remoting version 4.0.0.Final
Feb 17, 2014 3:28:46 PM org.jboss.as.quickstarts.jms.HelloWorldJMSClient main
INFO: Attempting to acquire connection factory "jms/RemoteConnectionFactory"
Feb 17, 2014 3:28:47 PM org.jboss.as.quickstarts.jms.HelloWorldJMSClient main
SEVERE: Failed to connect to any server. Servers tried: [http-remoting://helloworldjms-jmesnil.rhcloud.com:80 (java.io.IOException: Invalid response code 200)]

Remote naming is correctly complaining that the HTTP Upgrade handshake responded with a 200 OK instead of a 100 Continue.
Indeed, the deployed WildFly server does not upgrade my connection. You can check by hand using curl:

$ curl -v http://helloworldjms-jmesnil.rhcloud.com -H 'Connection:upgrade' -H 'Upgrade:jboss-remoting' -H 'Sec-JbossRemoting-Key: Xj8ZjttC3aixB1bAZ9w39A=='
...
* Connected to helloworldjms-jmesnil.rhcloud.com (50.17.25.239) port 80 (#0)
> GET / HTTP/1.1
> User-Agent: curl/7.30.0
> Host: helloworldjms-jmesnil.rhcloud.com
> Accept: */*
> Connection:upgrade
> Upgrade:jboss-remoting
> Sec-JbossRemoting-Key: Xj8ZjttC3aixB1bAZ9w39A==
>
< HTTP/1.1 200 OK
< Date: Mon, 17 Feb 2014 14:23:37 GMT
* Server Wildfly 8 is not blacklisted
< Server: Wildfly 8
< Last-Modified: Mon, 17 Feb 2014 14:20:22 GMT
< X-Powered-By: Undertow 1
< Content-Type: text/html
< Content-Length: 41708
< Vary: Accept-Encoding

[Home Page content follows]

The undertow’s http-listener is the default one;

    <http-listener name="default" socket-binding="http" proxy-address-forwarding="true”/>

I tried removing the proxy-address-forwarding attribute but that did not change anything.

Has someone managed to use remote naming with WildFly on OpenShift?
Am I missing something obvious to make it run?

jeff

[1] https://github.com/jmesnil/quickstart/blob/helloworld-jms-openshift/helloworld-jms/README.md#build-and-deploy-the-quickstart---to-openshift
--
Jeff Mesnil
JBoss, a division of Red Hat
http://jmesnil.net/


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Issue with HTTP upgrade for remote naming on OpenShift?

Darran Lofthouse
Just correcting the subject line.

On 17/02/14 15:09, Stuart Douglas wrote:

> The relevant config item should be in the remoting subsystem:
>
>
>         <http-connector name="http-remoting-connector"
> connector-ref="default" security-realm="ApplicationRealm"/>
>
> This is the bit that registers the HTTP upgrade handler with Undertow.
>
> Stuart
>
>
> On Mon, Feb 17, 2014 at 8:12 PM, Jeff Mesnil <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     Hi,
>
>     Now we have an OpenShift cartridge for WildFly 8.0.0.Final (hanks
>     Farah!), I’m adding instructions to the JMS quickstarts to deploy
>     them on OpenShift.
>
>     The helloworld-mdb is working fine but I have an issue with the
>     helloworld-jms one[1].
>
>     In this quick start, the Java client makes a lookup to JNDI to
>     retrieve the JMS resources.
>
>     The quickstart uses the “http-remoting://localhost:8080” as the JNDI
>     provider URL for a local WildFly server.
>
>     When I host WildFly on OpenShift, that URL should translate to
>     http-remoting://<app>-<namespace>.rhcloud.com:80
>     <http://rhcloud.com:80> (in my case
>     http-remoting://helloworldjms-jmesnil.rhcloud.com:80
>     <http://helloworldjms-jmesnil.rhcloud.com:80>)
>     However this does not work:
>
>
>     $ mvn clean compile exec:java
>     -Djava.naming.provider.url=http-remoting://helloworldjms-jmesnil.rhcloud.com:80
>     <http://helloworldjms-jmesnil.rhcloud.com:80>
>     …
>     Feb 17, 2014 3:28:46 PM org.xnio.Xnio <clinit>
>     INFO: XNIO version 3.2.0.Final
>     Feb 17, 2014 3:28:46 PM org.xnio.nio.NioXnio <clinit>
>     INFO: XNIO NIO Implementation Version 3.2.0.Final
>     Feb 17, 2014 3:28:46 PM org.jboss.remoting3.EndpointImpl <clinit>
>     INFO: JBoss Remoting version 4.0.0.Final
>     Feb 17, 2014 3:28:46 PM
>     org.jboss.as.quickstarts.jms.HelloWorldJMSClient main
>     INFO: Attempting to acquire connection factory
>     "jms/RemoteConnectionFactory"
>     Feb 17, 2014 3:28:47 PM
>     org.jboss.as.quickstarts.jms.HelloWorldJMSClient main
>     SEVERE: Failed to connect to any server. Servers tried:
>     [http-remoting://helloworldjms-jmesnil.rhcloud.com:80
>     <http://helloworldjms-jmesnil.rhcloud.com:80> (java.io.IOException:
>     Invalid response code 200)]
>
>     Remote naming is correctly complaining that the HTTP Upgrade
>     handshake responded with a 200 OK instead of a 100 Continue.
>     Indeed, the deployed WildFly server does not upgrade my connection.
>     You can check by hand using curl:
>
>     $ curl -v http://helloworldjms-jmesnil.rhcloud.com -H
>     'Connection:upgrade' -H 'Upgrade:jboss-remoting' -H
>     'Sec-JbossRemoting-Key: Xj8ZjttC3aixB1bAZ9w39A=='
>     ...
>     * Connected to helloworldjms-jmesnil.rhcloud.com
>     <http://helloworldjms-jmesnil.rhcloud.com> (50.17.25.239) port 80 (#0)
>      > GET / HTTP/1.1
>      > User-Agent: curl/7.30.0
>      > Host: helloworldjms-jmesnil.rhcloud.com
>     <http://helloworldjms-jmesnil.rhcloud.com>
>      > Accept: */*
>      > Connection:upgrade
>      > Upgrade:jboss-remoting
>      > Sec-JbossRemoting-Key: Xj8ZjttC3aixB1bAZ9w39A==
>      >
>     < HTTP/1.1 200 OK
>     < Date: Mon, 17 Feb 2014 14:23:37 GMT
>     * Server Wildfly 8 is not blacklisted
>     < Server: Wildfly 8
>     < Last-Modified: Mon, 17 Feb 2014 14:20:22 GMT
>     < X-Powered-By: Undertow 1
>     < Content-Type: text/html
>     < Content-Length: 41708
>     < Vary: Accept-Encoding
>     …
>     [Home Page content follows]
>
>     The undertow’s http-listener is the default one;
>
>          <http-listener name="default" socket-binding="http"
>     proxy-address-forwarding="true”/>
>
>     I tried removing the proxy-address-forwarding attribute but that did
>     not change anything.
>
>     Has someone managed to use remote naming with WildFly on OpenShift?
>     Am I missing something obvious to make it run?
>
>     jeff
>
>     [1]
>     https://github.com/jmesnil/quickstart/blob/helloworld-jms-openshift/helloworld-jms/README.md#build-and-deploy-the-quickstart---to-openshift
>     --
>     Jeff Mesnil
>     JBoss, a division of Red Hat
>     http://jmesnil.net/
>
>
>     _______________________________________________
>     wildfly-dev mailing list
>     [hidden email] <mailto:[hidden email]>
>     https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
>
>
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Issue with HTTP upgrade for remote naming on OpenShift?

Jeff Mesnil
Oups, my bad!

Thanks darran :)

On 17 Feb 2014, at 16:12, Darran Lofthouse <[hidden email]> wrote:

> Just correcting the subject line.
>
> On 17/02/14 15:09, Stuart Douglas wrote:
>> The relevant config item should be in the remoting subsystem:
>>
>>
>>        <http-connector name="http-remoting-connector"
>> connector-ref="default" security-realm="ApplicationRealm"/>
>>
>> This is the bit that registers the HTTP upgrade handler with Undertow.
>>
>> Stuart
>>
>>
>> On Mon, Feb 17, 2014 at 8:12 PM, Jeff Mesnil <[hidden email]
>> <mailto:[hidden email]>> wrote:
>>
>>    Hi,
>>
>>    Now we have an OpenShift cartridge for WildFly 8.0.0.Final (hanks
>>    Farah!), I’m adding instructions to the JMS quickstarts to deploy
>>    them on OpenShift.
>>
>>    The helloworld-mdb is working fine but I have an issue with the
>>    helloworld-jms one[1].
>>
>>    In this quick start, the Java client makes a lookup to JNDI to
>>    retrieve the JMS resources.
>>
>>    The quickstart uses the “http-remoting://localhost:8080” as the JNDI
>>    provider URL for a local WildFly server.
>>
>>    When I host WildFly on OpenShift, that URL should translate to
>>    http-remoting://<app>-<namespace>.rhcloud.com:80
>>    <http://rhcloud.com:80> (in my case
>>    http-remoting://helloworldjms-jmesnil.rhcloud.com:80
>>    <http://helloworldjms-jmesnil.rhcloud.com:80>)
>>    However this does not work:
>>
>>
>>    $ mvn clean compile exec:java
>>    -Djava.naming.provider.url=http-remoting://helloworldjms-jmesnil.rhcloud.com:80
>>    <http://helloworldjms-jmesnil.rhcloud.com:80>
>>    …
>>    Feb 17, 2014 3:28:46 PM org.xnio.Xnio <clinit>
>>    INFO: XNIO version 3.2.0.Final
>>    Feb 17, 2014 3:28:46 PM org.xnio.nio.NioXnio <clinit>
>>    INFO: XNIO NIO Implementation Version 3.2.0.Final
>>    Feb 17, 2014 3:28:46 PM org.jboss.remoting3.EndpointImpl <clinit>
>>    INFO: JBoss Remoting version 4.0.0.Final
>>    Feb 17, 2014 3:28:46 PM
>>    org.jboss.as.quickstarts.jms.HelloWorldJMSClient main
>>    INFO: Attempting to acquire connection factory
>>    "jms/RemoteConnectionFactory"
>>    Feb 17, 2014 3:28:47 PM
>>    org.jboss.as.quickstarts.jms.HelloWorldJMSClient main
>>    SEVERE: Failed to connect to any server. Servers tried:
>>    [http-remoting://helloworldjms-jmesnil.rhcloud.com:80
>>    <http://helloworldjms-jmesnil.rhcloud.com:80> (java.io.IOException:
>>    Invalid response code 200)]
>>
>>    Remote naming is correctly complaining that the HTTP Upgrade
>>    handshake responded with a 200 OK instead of a 100 Continue.
>>    Indeed, the deployed WildFly server does not upgrade my connection.
>>    You can check by hand using curl:
>>
>>    $ curl -v http://helloworldjms-jmesnil.rhcloud.com -H
>>    'Connection:upgrade' -H 'Upgrade:jboss-remoting' -H
>>    'Sec-JbossRemoting-Key: Xj8ZjttC3aixB1bAZ9w39A=='
>>    ...
>>    * Connected to helloworldjms-jmesnil.rhcloud.com
>>    <http://helloworldjms-jmesnil.rhcloud.com> (50.17.25.239) port 80 (#0)
>>> GET / HTTP/1.1
>>> User-Agent: curl/7.30.0
>>> Host: helloworldjms-jmesnil.rhcloud.com
>>    <http://helloworldjms-jmesnil.rhcloud.com>
>>> Accept: */*
>>> Connection:upgrade
>>> Upgrade:jboss-remoting
>>> Sec-JbossRemoting-Key: Xj8ZjttC3aixB1bAZ9w39A==
>>>
>>    < HTTP/1.1 200 OK
>>    < Date: Mon, 17 Feb 2014 14:23:37 GMT
>>    * Server Wildfly 8 is not blacklisted
>>    < Server: Wildfly 8
>>    < Last-Modified: Mon, 17 Feb 2014 14:20:22 GMT
>>    < X-Powered-By: Undertow 1
>>    < Content-Type: text/html
>>    < Content-Length: 41708
>>    < Vary: Accept-Encoding
>>    …
>>    [Home Page content follows]
>>
>>    The undertow’s http-listener is the default one;
>>
>>         <http-listener name="default" socket-binding="http"
>>    proxy-address-forwarding="true”/>
>>
>>    I tried removing the proxy-address-forwarding attribute but that did
>>    not change anything.
>>
>>    Has someone managed to use remote naming with WildFly on OpenShift?
>>    Am I missing something obvious to make it run?
>>
>>    jeff
>>
>>    [1]
>>    https://github.com/jmesnil/quickstart/blob/helloworld-jms-openshift/helloworld-jms/README.md#build-and-deploy-the-quickstart---to-openshift
>>    --
>>    Jeff Mesnil
>>    JBoss, a division of Red Hat
>>    http://jmesnil.net/
>>
>>
>>    _______________________________________________
>>    wildfly-dev mailing list
>>    [hidden email] <mailto:[hidden email]>
>>    https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>>
>>
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

--
Jeff Mesnil
JBoss, a division of Red Hat
http://jmesnil.net/


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Issue with HTTP upgrade for remote naming on OpenShift?

Jeff Mesnil
In reply to this post by Stuart Douglas

On 17 Feb 2014, at 16:09, Stuart Douglas <[hidden email]> wrote:

> The relevant config item should be in the remoting subsystem:
>
>
>        <http-connector name="http-remoting-connector" connector-ref="default" security-realm="ApplicationRealm"/>
>
> This is the bit that registers the HTTP upgrade handler with Undertow.

The remoting configuration does include it: https://github.com/jmesnil/helloworldjms/blob/master/.openshift/config/standalone.xml#L332

FWIW I started from the standalone.xml configuration bundled with the wildfly 8 cartridge and added the bits for the messaging subsystem.

jeff

--
Jeff Mesnil
JBoss, a division of Red Hat
http://jmesnil.net/


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Issue with HTTP upgrade for remote naming on OpenShit?

Bill Burke
In reply to this post by Jeff Mesnil
I'm glad I'm not the only one who has mistyped OpenShit.

On 2/17/2014 9:42 AM, Jeff Mesnil wrote:

> Hi,
>
> Now we have an OpenShift cartridge for WildFly 8.0.0.Final (hanks Farah!), I’m adding instructions to the JMS quickstarts to deploy them on OpenShift.
>
> The helloworld-mdb is working fine but I have an issue with the helloworld-jms one[1].
>
> In this quick start, the Java client makes a lookup to JNDI to retrieve the JMS resources.
>
> The quickstart uses the “http-remoting://localhost:8080” as the JNDI provider URL for a local WildFly server.
>
> When I host WildFly on OpenShift, that URL should translate to http-remoting://<app>-<namespace>.rhcloud.com:80 (in my case http-remoting://helloworldjms-jmesnil.rhcloud.com:80)
> However this does not work:
>
>
> $ mvn clean compile exec:java -Djava.naming.provider.url=http-remoting://helloworldjms-jmesnil.rhcloud.com:80
> …
> Feb 17, 2014 3:28:46 PM org.xnio.Xnio <clinit>
> INFO: XNIO version 3.2.0.Final
> Feb 17, 2014 3:28:46 PM org.xnio.nio.NioXnio <clinit>
> INFO: XNIO NIO Implementation Version 3.2.0.Final
> Feb 17, 2014 3:28:46 PM org.jboss.remoting3.EndpointImpl <clinit>
> INFO: JBoss Remoting version 4.0.0.Final
> Feb 17, 2014 3:28:46 PM org.jboss.as.quickstarts.jms.HelloWorldJMSClient main
> INFO: Attempting to acquire connection factory "jms/RemoteConnectionFactory"
> Feb 17, 2014 3:28:47 PM org.jboss.as.quickstarts.jms.HelloWorldJMSClient main
> SEVERE: Failed to connect to any server. Servers tried: [http-remoting://helloworldjms-jmesnil.rhcloud.com:80 (java.io.IOException: Invalid response code 200)]
>
> Remote naming is correctly complaining that the HTTP Upgrade handshake responded with a 200 OK instead of a 100 Continue.
> Indeed, the deployed WildFly server does not upgrade my connection. You can check by hand using curl:
>
> $ curl -v http://helloworldjms-jmesnil.rhcloud.com -H 'Connection:upgrade' -H 'Upgrade:jboss-remoting' -H 'Sec-JbossRemoting-Key: Xj8ZjttC3aixB1bAZ9w39A=='
> ...
> * Connected to helloworldjms-jmesnil.rhcloud.com (50.17.25.239) port 80 (#0)
>> GET / HTTP/1.1
>> User-Agent: curl/7.30.0
>> Host: helloworldjms-jmesnil.rhcloud.com
>> Accept: */*
>> Connection:upgrade
>> Upgrade:jboss-remoting
>> Sec-JbossRemoting-Key: Xj8ZjttC3aixB1bAZ9w39A==
>>
> < HTTP/1.1 200 OK
> < Date: Mon, 17 Feb 2014 14:23:37 GMT
> * Server Wildfly 8 is not blacklisted
> < Server: Wildfly 8
> < Last-Modified: Mon, 17 Feb 2014 14:20:22 GMT
> < X-Powered-By: Undertow 1
> < Content-Type: text/html
> < Content-Length: 41708
> < Vary: Accept-Encoding
> …
> [Home Page content follows]
>
> The undertow’s http-listener is the default one;
>
>      <http-listener name="default" socket-binding="http" proxy-address-forwarding="true”/>
>
> I tried removing the proxy-address-forwarding attribute but that did not change anything.
>
> Has someone managed to use remote naming with WildFly on OpenShift?
> Am I missing something obvious to make it run?
>
> jeff
>
> [1] https://github.com/jmesnil/quickstart/blob/helloworld-jms-openshift/helloworld-jms/README.md#build-and-deploy-the-quickstart---to-openshift
>

--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Issue with HTTP upgrade for remote naming on OpenShit?

Tomaž Cerar-2
In reply to this post by Stuart Douglas
Looks like this is issue with openshift itself.

there is proxy in front of gear and that proxy does not know how to do http upgrade.
For web sockets there is special exception to make this work on different port.

see:
I will do some more digging to see if we can use some hack/workaround to make it work.

--
tomaz



On Mon, Feb 17, 2014 at 4:09 PM, Stuart Douglas <[hidden email]> wrote:
The relevant config item should be in the remoting subsystem:


       <http-connector name="http-remoting-connector" connector-ref="default" security-realm="ApplicationRealm"/>

This is the bit that registers the HTTP upgrade handler with Undertow.

Stuart


On Mon, Feb 17, 2014 at 8:12 PM, Jeff Mesnil <[hidden email]> wrote:
Hi,

Now we have an OpenShift cartridge for WildFly 8.0.0.Final (hanks Farah!), I’m adding instructions to the JMS quickstarts to deploy them on OpenShift.

The helloworld-mdb is working fine but I have an issue with the helloworld-jms one[1].

In this quick start, the Java client makes a lookup to JNDI to retrieve the JMS resources.

The quickstart uses the “http-remoting://localhost:8080” as the JNDI provider URL for a local WildFly server.

When I host WildFly on OpenShift, that URL should translate to http-remoting://<app>-<namespace>.rhcloud.com:80 (in my case http-remoting://helloworldjms-jmesnil.rhcloud.com:80)
However this does not work:


$ mvn clean compile exec:java -Djava.naming.provider.url=http-remoting://helloworldjms-jmesnil.rhcloud.com:80

Feb 17, 2014 3:28:46 PM org.xnio.Xnio <clinit>
INFO: XNIO version 3.2.0.Final
Feb 17, 2014 3:28:46 PM org.xnio.nio.NioXnio <clinit>
INFO: XNIO NIO Implementation Version 3.2.0.Final
Feb 17, 2014 3:28:46 PM org.jboss.remoting3.EndpointImpl <clinit>
INFO: JBoss Remoting version 4.0.0.Final
Feb 17, 2014 3:28:46 PM org.jboss.as.quickstarts.jms.HelloWorldJMSClient main
INFO: Attempting to acquire connection factory "jms/RemoteConnectionFactory"
Feb 17, 2014 3:28:47 PM org.jboss.as.quickstarts.jms.HelloWorldJMSClient main
SEVERE: Failed to connect to any server. Servers tried: [http-remoting://helloworldjms-jmesnil.rhcloud.com:80 (java.io.IOException: Invalid response code 200)]

Remote naming is correctly complaining that the HTTP Upgrade handshake responded with a 200 OK instead of a 100 Continue.
Indeed, the deployed WildFly server does not upgrade my connection. You can check by hand using curl:

$ curl -v http://helloworldjms-jmesnil.rhcloud.com -H 'Connection:upgrade' -H 'Upgrade:jboss-remoting' -H 'Sec-JbossRemoting-Key: Xj8ZjttC3aixB1bAZ9w39A=='
...
* Connected to helloworldjms-jmesnil.rhcloud.com (50.17.25.239) port 80 (#0)
> GET / HTTP/1.1
> User-Agent: curl/7.30.0
> Host: helloworldjms-jmesnil.rhcloud.com
> Accept: */*
> Connection:upgrade
> Upgrade:jboss-remoting
> Sec-JbossRemoting-Key: Xj8ZjttC3aixB1bAZ9w39A==
>
< HTTP/1.1 200 OK
< Date: Mon, 17 Feb 2014 14:23:37 GMT
* Server Wildfly 8 is not blacklisted
< Server: Wildfly 8
< Last-Modified: Mon, 17 Feb 2014 14:20:22 GMT
< X-Powered-By: Undertow 1
< Content-Type: text/html
< Content-Length: 41708
< Vary: Accept-Encoding

[Home Page content follows]

The undertow’s http-listener is the default one;

    <http-listener name="default" socket-binding="http" proxy-address-forwarding="true”/>

I tried removing the proxy-address-forwarding attribute but that did not change anything.

Has someone managed to use remote naming with WildFly on OpenShift?
Am I missing something obvious to make it run?

jeff

[1] https://github.com/jmesnil/quickstart/blob/helloworld-jms-openshift/helloworld-jms/README.md#build-and-deploy-the-quickstart---to-openshift
--
Jeff Mesnil
JBoss, a division of Red Hat
http://jmesnil.net/


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Issue with HTTP upgrade for remote naming on OpenShit?

jtgreene
Administrator
Farah mentions port forwards in here blog. I suppose this is the only solution currently.

https://community.jboss.org/people/fjuma/blog/2014/02/14/wildfly-8-final-on-openshift


On Feb 18, 2014, at 2:40 PM, Tomaž Cerar <[hidden email]> wrote:

> Looks like this is issue with openshift itself.
>
> there is proxy in front of gear and that proxy does not know how to do http upgrade.
> For web sockets there is special exception to make this work on different port.
>
> see:
> https://www.openshift.com/content/at-least-one-port-for-external-use-excluding-8080-please
> https://www.openshift.com/blogs/paas-websockets
> https://www.openshift.com/content/websockets-on-port-80-and-443
> https://bugzilla.redhat.com/show_bug.cgi?id=978597
>
> I will do some more digging to see if we can use some hack/workaround to make it work.
>
> --
> tomaz
>
>
>
> On Mon, Feb 17, 2014 at 4:09 PM, Stuart Douglas <[hidden email]> wrote:
> The relevant config item should be in the remoting subsystem:
>
>
>        <http-connector name="http-remoting-connector" connector-ref="default" security-realm="ApplicationRealm"/>
>
> This is the bit that registers the HTTP upgrade handler with Undertow.
>
> Stuart
>
>
> On Mon, Feb 17, 2014 at 8:12 PM, Jeff Mesnil <[hidden email]> wrote:
> Hi,
>
> Now we have an OpenShift cartridge for WildFly 8.0.0.Final (hanks Farah!), I’m adding instructions to the JMS quickstarts to deploy them on OpenShift.
>
> The helloworld-mdb is working fine but I have an issue with the helloworld-jms one[1].
>
> In this quick start, the Java client makes a lookup to JNDI to retrieve the JMS resources.
>
> The quickstart uses the “http-remoting://localhost:8080” as the JNDI provider URL for a local WildFly server.
>
> When I host WildFly on OpenShift, that URL should translate to http-remoting://<app>-<namespace>.rhcloud.com:80 (in my case http-remoting://helloworldjms-jmesnil.rhcloud.com:80)
> However this does not work:
>
>
> $ mvn clean compile exec:java -Djava.naming.provider.url=http-remoting://helloworldjms-jmesnil.rhcloud.com:80
> …
> Feb 17, 2014 3:28:46 PM org.xnio.Xnio <clinit>
> INFO: XNIO version 3.2.0.Final
> Feb 17, 2014 3:28:46 PM org.xnio.nio.NioXnio <clinit>
> INFO: XNIO NIO Implementation Version 3.2.0.Final
> Feb 17, 2014 3:28:46 PM org.jboss.remoting3.EndpointImpl <clinit>
> INFO: JBoss Remoting version 4.0.0.Final
> Feb 17, 2014 3:28:46 PM org.jboss.as.quickstarts.jms.HelloWorldJMSClient main
> INFO: Attempting to acquire connection factory "jms/RemoteConnectionFactory"
> Feb 17, 2014 3:28:47 PM org.jboss.as.quickstarts.jms.HelloWorldJMSClient main
> SEVERE: Failed to connect to any server. Servers tried: [http-remoting://helloworldjms-jmesnil.rhcloud.com:80 (java.io.IOException: Invalid response code 200)]
>
> Remote naming is correctly complaining that the HTTP Upgrade handshake responded with a 200 OK instead of a 100 Continue.
> Indeed, the deployed WildFly server does not upgrade my connection. You can check by hand using curl:
>
> $ curl -v http://helloworldjms-jmesnil.rhcloud.com -H 'Connection:upgrade' -H 'Upgrade:jboss-remoting' -H 'Sec-JbossRemoting-Key: Xj8ZjttC3aixB1bAZ9w39A=='
> ...
> * Connected to helloworldjms-jmesnil.rhcloud.com (50.17.25.239) port 80 (#0)
> > GET / HTTP/1.1
> > User-Agent: curl/7.30.0
> > Host: helloworldjms-jmesnil.rhcloud.com
> > Accept: */*
> > Connection:upgrade
> > Upgrade:jboss-remoting
> > Sec-JbossRemoting-Key: Xj8ZjttC3aixB1bAZ9w39A==
> >
> < HTTP/1.1 200 OK
> < Date: Mon, 17 Feb 2014 14:23:37 GMT
> * Server Wildfly 8 is not blacklisted
> < Server: Wildfly 8
> < Last-Modified: Mon, 17 Feb 2014 14:20:22 GMT
> < X-Powered-By: Undertow 1
> < Content-Type: text/html
> < Content-Length: 41708
> < Vary: Accept-Encoding
> …
> [Home Page content follows]
>
> The undertow’s http-listener is the default one;
>
>     <http-listener name="default" socket-binding="http" proxy-address-forwarding="true”/>
>
> I tried removing the proxy-address-forwarding attribute but that did not change anything.
>
> Has someone managed to use remote naming with WildFly on OpenShift?
> Am I missing something obvious to make it run?
>
> jeff
>
> [1] https://github.com/jmesnil/quickstart/blob/helloworld-jms-openshift/helloworld-jms/README.md#build-and-deploy-the-quickstart---to-openshift
> --
> Jeff Mesnil
> JBoss, a division of Red Hat
> http://jmesnil.net/
>
>
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Issue with HTTP upgrade for remote naming on OpenShit?

Farah Juma
I'm looking into this as well to see if there's a way to make this work. When using port forwarding, I'm finding that an error still occurs:

INFO: JBoss Remoting version 4.0.0.Final
Feb 18, 2014 4:09:23 PM org.jboss.as.quickstarts.jms.HelloWorldJMSClient main
INFO: Attempting to acquire connection factory "jms/RemoteConnectionFactory"
Feb 18, 2014 4:09:23 PM org.jboss.as.quickstarts.jms.HelloWorldJMSClient main
INFO: Found connection factory "jms/RemoteConnectionFactory" in JNDI
Feb 18, 2014 4:09:23 PM org.jboss.as.quickstarts.jms.HelloWorldJMSClient main
INFO: Attempting to acquire destination "jms/queue/test"
Feb 18, 2014 4:09:23 PM org.jboss.as.quickstarts.jms.HelloWorldJMSClient main
INFO: Found destination "jms/queue/test" in JNDI
Feb 18, 2014 4:09:24 PM org.jboss.as.quickstarts.jms.HelloWorldJMSClient main
SEVERE: Failed to create session factory
Feb 18, 2014 4:09:24 PM org.jboss.naming.remote.protocol.v1.RemoteNamingStoreV1$MessageReceiver handleEnd
ERROR: Channel end notification received, closing channel Channel ID cba05e7a (outbound) of Remoting connection 2e3ed883 to null


Farah

----- Original Message -----

> From: "Jason Greene" <[hidden email]>
> To: "Tomaž Cerar" <[hidden email]>
> Cc: "Stuart Douglas" <[hidden email]>, "WildFly Dev" <[hidden email]>, "Farah Juma"
> <[hidden email]>
> Sent: Tuesday, February 18, 2014 3:58:49 PM
> Subject: Re: [wildfly-dev] Issue with HTTP upgrade for remote naming on OpenShit?
>
> Farah mentions port forwards in here blog. I suppose this is the only
> solution currently.
>
> https://community.jboss.org/people/fjuma/blog/2014/02/14/wildfly-8-final-on-openshift
>
>
> On Feb 18, 2014, at 2:40 PM, Tomaž Cerar <[hidden email]> wrote:
>
> > Looks like this is issue with openshift itself.
> >
> > there is proxy in front of gear and that proxy does not know how to do http
> > upgrade.
> > For web sockets there is special exception to make this work on different
> > port.
> >
> > see:
> > https://www.openshift.com/content/at-least-one-port-for-external-use-excluding-8080-please
> > https://www.openshift.com/blogs/paas-websockets
> > https://www.openshift.com/content/websockets-on-port-80-and-443
> > https://bugzilla.redhat.com/show_bug.cgi?id=978597
> >
> > I will do some more digging to see if we can use some hack/workaround to
> > make it work.
> >
> > --
> > tomaz
> >
> >
> >
> > On Mon, Feb 17, 2014 at 4:09 PM, Stuart Douglas
> > <[hidden email]> wrote:
> > The relevant config item should be in the remoting subsystem:
> >
> >
> >        <http-connector name="http-remoting-connector"
> >        connector-ref="default" security-realm="ApplicationRealm"/>
> >
> > This is the bit that registers the HTTP upgrade handler with Undertow.
> >
> > Stuart
> >
> >
> > On Mon, Feb 17, 2014 at 8:12 PM, Jeff Mesnil <[hidden email]> wrote:
> > Hi,
> >
> > Now we have an OpenShift cartridge for WildFly 8.0.0.Final (hanks Farah!),
> > I’m adding instructions to the JMS quickstarts to deploy them on
> > OpenShift.
> >
> > The helloworld-mdb is working fine but I have an issue with the
> > helloworld-jms one[1].
> >
> > In this quick start, the Java client makes a lookup to JNDI to retrieve the
> > JMS resources.
> >
> > The quickstart uses the “http-remoting://localhost:8080” as the JNDI
> > provider URL for a local WildFly server.
> >
> > When I host WildFly on OpenShift, that URL should translate to
> > http-remoting://<app>-<namespace>.rhcloud.com:80 (in my case
> > http-remoting://helloworldjms-jmesnil.rhcloud.com:80)
> > However this does not work:
> >
> >
> > $ mvn clean compile exec:java
> > -Djava.naming.provider.url=http-remoting://helloworldjms-jmesnil.rhcloud.com:80
> > …
> > Feb 17, 2014 3:28:46 PM org.xnio.Xnio <clinit>
> > INFO: XNIO version 3.2.0.Final
> > Feb 17, 2014 3:28:46 PM org.xnio.nio.NioXnio <clinit>
> > INFO: XNIO NIO Implementation Version 3.2.0.Final
> > Feb 17, 2014 3:28:46 PM org.jboss.remoting3.EndpointImpl <clinit>
> > INFO: JBoss Remoting version 4.0.0.Final
> > Feb 17, 2014 3:28:46 PM org.jboss.as.quickstarts.jms.HelloWorldJMSClient
> > main
> > INFO: Attempting to acquire connection factory
> > "jms/RemoteConnectionFactory"
> > Feb 17, 2014 3:28:47 PM org.jboss.as.quickstarts.jms.HelloWorldJMSClient
> > main
> > SEVERE: Failed to connect to any server. Servers tried:
> > [http-remoting://helloworldjms-jmesnil.rhcloud.com:80
> > (java.io.IOException: Invalid response code 200)]
> >
> > Remote naming is correctly complaining that the HTTP Upgrade handshake
> > responded with a 200 OK instead of a 100 Continue.
> > Indeed, the deployed WildFly server does not upgrade my connection. You can
> > check by hand using curl:
> >
> > $ curl -v http://helloworldjms-jmesnil.rhcloud.com -H 'Connection:upgrade'
> > -H 'Upgrade:jboss-remoting' -H 'Sec-JbossRemoting-Key:
> > Xj8ZjttC3aixB1bAZ9w39A=='
> > ...
> > * Connected to helloworldjms-jmesnil.rhcloud.com (50.17.25.239) port 80
> > (#0)
> > > GET / HTTP/1.1
> > > User-Agent: curl/7.30.0
> > > Host: helloworldjms-jmesnil.rhcloud.com
> > > Accept: */*
> > > Connection:upgrade
> > > Upgrade:jboss-remoting
> > > Sec-JbossRemoting-Key: Xj8ZjttC3aixB1bAZ9w39A==
> > >
> > < HTTP/1.1 200 OK
> > < Date: Mon, 17 Feb 2014 14:23:37 GMT
> > * Server Wildfly 8 is not blacklisted
> > < Server: Wildfly 8
> > < Last-Modified: Mon, 17 Feb 2014 14:20:22 GMT
> > < X-Powered-By: Undertow 1
> > < Content-Type: text/html
> > < Content-Length: 41708
> > < Vary: Accept-Encoding
> > …
> > [Home Page content follows]
> >
> > The undertow’s http-listener is the default one;
> >
> >     <http-listener name="default" socket-binding="http"
> >     proxy-address-forwarding="true”/>
> >
> > I tried removing the proxy-address-forwarding attribute but that did not
> > change anything.
> >
> > Has someone managed to use remote naming with WildFly on OpenShift?
> > Am I missing something obvious to make it run?
> >
> > jeff
> >
> > [1]
> > https://github.com/jmesnil/quickstart/blob/helloworld-jms-openshift/helloworld-jms/README.md#build-and-deploy-the-quickstart---to-openshift
> > --
> > Jeff Mesnil
> > JBoss, a division of Red Hat
> > http://jmesnil.net/
> >
> >
> > _______________________________________________
> > wildfly-dev mailing list
> > [hidden email]
> > https://lists.jboss.org/mailman/listinfo/wildfly-dev
> >
> >
> > _______________________________________________
> > wildfly-dev mailing list
> > [hidden email]
> > https://lists.jboss.org/mailman/listinfo/wildfly-dev
> >
> > _______________________________________________
> > wildfly-dev mailing list
> > [hidden email]
> > https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
> --
> Jason T. Greene
> WildFly Lead / JBoss EAP Platform Architect
> JBoss, a division of Red Hat
>
>

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Issue with HTTP upgrade for remote naming on OpenShift?

Jeff Mesnil

On 18 Feb 2014, at 22:19, Farah Juma <[hidden email]> wrote:

> I'm looking into this as well to see if there's a way to make this work. When using port forwarding, I'm finding that an error still occurs:

At this stage, port forwarding works. Thanks Farah.

The remaining issue is the way HornetQ configures its connectors.

HornetQ connectors are the bits that are retrieved using JNDI and contains the informations to connect to the HornetQ server (embedded with WildFly in our case).
The ugly ugly part of it is that the connector must know the host of the server to connect to.
In WildFly, we resolve the socket-binding (http in this case) to get this address[1]. When using OpenShift, the HornetQ connectors will use the OpenShift server address (127.5.118.129).
If I use port forwarding, the remote naming will work and I will retrieve a connector that wants to connect to 127.5.118.129 from my local machine and this does not work.

The HornetQ team has some features planned for the cloud. I’ll let them know about this.

[1] https://github.com/wildfly/wildfly/blob/master/messaging/src/main/java/org/jboss/as/messaging/HornetQService.java#L181

--
Jeff Mesnil
JBoss, a division of Red Hat
http://jmesnil.net/


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Issue with HTTP upgrade for remote naming on OpenShift?

Jason T. Greene
The JMS 2 direct connect should work though right? If so maybe we should convert the QuickStart?

Sent from my iPhone

> On Feb 19, 2014, at 2:15 AM, Jeff Mesnil <[hidden email]> wrote:
>
>
>> On 18 Feb 2014, at 22:19, Farah Juma <[hidden email]> wrote:
>>
>> I'm looking into this as well to see if there's a way to make this work. When using port forwarding, I'm finding that an error still occurs:
>
> At this stage, port forwarding works. Thanks Farah.
>
> The remaining issue is the way HornetQ configures its connectors.
>
> HornetQ connectors are the bits that are retrieved using JNDI and contains the informations to connect to the HornetQ server (embedded with WildFly in our case).
> The ugly ugly part of it is that the connector must know the host of the server to connect to.
> In WildFly, we resolve the socket-binding (http in this case) to get this address[1]. When using OpenShift, the HornetQ connectors will use the OpenShift server address (127.5.118.129).
> If I use port forwarding, the remote naming will work and I will retrieve a connector that wants to connect to 127.5.118.129 from my local machine and this does not work.
>
> The HornetQ team has some features planned for the cloud. I’ll let them know about this.
>
> [1] https://github.com/wildfly/wildfly/blob/master/messaging/src/main/java/org/jboss/as/messaging/HornetQService.java#L181
>
> --
> Jeff Mesnil
> JBoss, a division of Red Hat
> http://jmesnil.net/
>

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Issue with HTTP upgrade for remote naming on OpenShift?

Brian Stansberry
In reply to this post by Jeff Mesnil
The outbound-socket-binding config doesn't allow this to be configured
correctly, using the correct address?

I saw your WFLY-2963 patch and I can sort of imagine how it might help
in some odd scenario, but it seems that if the messaging subsystem
config could store the correct value, the outbound-socket-binding itself
could store the correct value.

On 2/19/14, 2:15 AM, Jeff Mesnil wrote:

>
> On 18 Feb 2014, at 22:19, Farah Juma <[hidden email]> wrote:
>
>> I'm looking into this as well to see if there's a way to make this work. When using port forwarding, I'm finding that an error still occurs:
>
> At this stage, port forwarding works. Thanks Farah.
>
> The remaining issue is the way HornetQ configures its connectors.
>
> HornetQ connectors are the bits that are retrieved using JNDI and contains the informations to connect to the HornetQ server (embedded with WildFly in our case).
> The ugly ugly part of it is that the connector must know the host of the server to connect to.
> In WildFly, we resolve the socket-binding (http in this case) to get this address[1]. When using OpenShift, the HornetQ connectors will use the OpenShift server address (127.5.118.129).
> If I use port forwarding, the remote naming will work and I will retrieve a connector that wants to connect to 127.5.118.129 from my local machine and this does not work.
>
> The HornetQ team has some features planned for the cloud. I’ll let them know about this.
>
> [1] https://github.com/wildfly/wildfly/blob/master/messaging/src/main/java/org/jboss/as/messaging/HornetQService.java#L181
>


--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Outbound Socket host resolution

Jeff Mesnil
[changing the subject as HTTP upgrade is not part of the discussion]

On 19 Feb 2014, at 15:52, Brian Stansberry <[hidden email]> wrote:

> The outbound-socket-binding config doesn't allow this to be configured
> correctly, using the correct address?

Yes you’re right, I overlooked it.
 By convenience, the messaging subsystem allows to use a socket-binding to configure the connector but the correct way is to use an outbound-socket-binding (and it lets specify the host).
(I’ve closed WFLY-2963 as we don’t need it).

Since I am using port-forwarding around the openshift proxy issue, I configure the messaging connector with an outbound-socket to connect to 127.0.0.1 (that’s is then forwarded to the OpenShift server).
With that tweak, the quickstart works but it’s ugly.

However, I wonder if that’ll also work when we would not need to use port-forwarding.

In that case, I would just need to add an outbound-socket-binding with the DNS name of my app (helloworldjms2-jmesnil.rhcloud.com).
Looking at OutboundSocketBinding, its getDestinationAddress() method returns a /resolved/ InetAddress, not the name that’s set in the management model.
And the OpenShift server returns a different resolved IP address for this domain name than my local machine:

[openshift] helloworldjms2-jmesnil.rhcloud.com -> 10.235.52.32
[localhost] helloworldjms2-jmesnil.rhcloud.com -> 23.22.246.120

When my client on my local machine will try to connect to the server, it will use the 10.235.52.32 IP address that’s not reachable instead 23.22.246.120.

For my use case to work, I would need to get the “raw” destination address (whatever the user specified in the management model) and not let the server resolve the address (the address will be resolved by the client).
Is that a valid use case or am I missing something obvious?

jeff

--
Jeff Mesnil
JBoss, a division of Red Hat
http://jmesnil.net/


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Outbound Socket host resolution

Brian Stansberry
On 2/19/14, 9:19 AM, Jeff Mesnil wrote:

> [changing the subject as HTTP upgrade is not part of the discussion]
>
> On 19 Feb 2014, at 15:52, Brian Stansberry <[hidden email]> wrote:
>
>> The outbound-socket-binding config doesn't allow this to be configured
>> correctly, using the correct address?
>
> Yes you’re right, I overlooked it.
>   By convenience, the messaging subsystem allows to use a socket-binding to configure the connector but the correct way is to use an outbound-socket-binding (and it lets specify the host).
> (I’ve closed WFLY-2963 as we don’t need it).
>
> Since I am using port-forwarding around the openshift proxy issue, I configure the messaging connector with an outbound-socket to connect to 127.0.0.1 (that’s is then forwarded to the OpenShift server).
> With that tweak, the quickstart works but it’s ugly.
>
> However, I wonder if that’ll also work when we would not need to use port-forwarding.
>
> In that case, I would just need to add an outbound-socket-binding with the DNS name of my app (helloworldjms2-jmesnil.rhcloud.com).
> Looking at OutboundSocketBinding, its getDestinationAddress() method returns a /resolved/ InetAddress, not the name that’s set in the management model.
> And the OpenShift server returns a different resolved IP address for this domain name than my local machine:
>
> [openshift] helloworldjms2-jmesnil.rhcloud.com -> 10.235.52.32
> [localhost] helloworldjms2-jmesnil.rhcloud.com -> 23.22.246.120
>
> When my client on my local machine will try to connect to the server, it will use the 10.235.52.32 IP address that’s not reachable instead 23.22.246.120.
>
> For my use case to work, I would need to get the “raw” destination address (whatever the user specified in the management model) and not let the server resolve the address (the address will be resolved by the client).
> Is that a valid use case or am I missing something obvious?
>

I think OutboundSocketBinding needs to add a getter for the
unresolvedDestinationAddress string. Which getter a caller uses would
depend on their use case; i.e. whether they want a locally resolved
address. There are some uses that AFAIK are purely internal, e.g.
org.jboss.as.clustering.infinispan.subsystem.CacheAdd, so we shouldn't
abandon the resolved address getter. Plus that would be an incompatible
change.

I propose adding
OutboundSocketBinding.getUnresolvedDestinationAddress(), deprecating the
current getDestinationAddress() and adding a new
getResolvedDestinationAddress(). The latter is just a clearer name for
the same function.



--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Outbound Socket host resolution

Jeff Mesnil

On 19 Feb 2014, at 16:30, Brian Stansberry <[hidden email]> wrote:

> On 2/19/14, 9:19 AM, Jeff Mesnil wrote:
>> [changing the subject as HTTP upgrade is not part of the discussion]
>>
>> On 19 Feb 2014, at 15:52, Brian Stansberry <[hidden email]> wrote:
>>
>>> The outbound-socket-binding config doesn't allow this to be configured
>>> correctly, using the correct address?
>>
>> Yes you’re right, I overlooked it.
>>  By convenience, the messaging subsystem allows to use a socket-binding to configure the connector but the correct way is to use an outbound-socket-binding (and it lets specify the host).
>> (I’ve closed WFLY-2963 as we don’t need it).
>>
>> Since I am using port-forwarding around the openshift proxy issue, I configure the messaging connector with an outbound-socket to connect to 127.0.0.1 (that’s is then forwarded to the OpenShift server).
>> With that tweak, the quickstart works but it’s ugly.
>>
>> However, I wonder if that’ll also work when we would not need to use port-forwarding.
>>
>> In that case, I would just need to add an outbound-socket-binding with the DNS name of my app (helloworldjms2-jmesnil.rhcloud.com).
>> Looking at OutboundSocketBinding, its getDestinationAddress() method returns a /resolved/ InetAddress, not the name that’s set in the management model.
>> And the OpenShift server returns a different resolved IP address for this domain name than my local machine:
>>
>> [openshift] helloworldjms2-jmesnil.rhcloud.com -> 10.235.52.32
>> [localhost] helloworldjms2-jmesnil.rhcloud.com -> 23.22.246.120
>>
>> When my client on my local machine will try to connect to the server, it will use the 10.235.52.32 IP address that’s not reachable instead 23.22.246.120.
>>
>> For my use case to work, I would need to get the “raw” destination address (whatever the user specified in the management model) and not let the server resolve the address (the address will be resolved by the client).
>> Is that a valid use case or am I missing something obvious?
>>
>
> I think OutboundSocketBinding needs to add a getter for the unresolvedDestinationAddress string. Which getter a caller uses would depend on their use case; i.e. whether they want a locally resolved address. There are some uses that AFAIK are purely internal, e.g. org.jboss.as.clustering.infinispan.subsystem.CacheAdd, so we shouldn't abandon the resolved address getter. Plus that would be an incompatible change.
>
> I propose adding OutboundSocketBinding.getUnresolvedDestinationAddress(), deprecating the current getDestinationAddress() and adding a new getResolvedDestinationAddress(). The latter is just a clearer name for the same function.

https://issues.jboss.org/browse/WFLY-2966

jeff

--
Jeff Mesnil
JBoss, a division of Red Hat
http://jmesnil.net/


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Issue with HTTP upgrade for remote naming on OpenShift?

Jeff Mesnil
In reply to this post by Jeff Mesnil
I’ve spent some time running WildFly on OpenShift and playing with it.

* I’ve added a quickstart using WebSocket API[1] and it works fine on OpenShift.
=> note however that OpenShift requires to use a different port for WebSocket (8000) than for HTTP (80) even though both are mapped to WildFly’s 8080 internal port.

* OpenShift does not support custom protocols for HTTP upgrade beside web socket[2][3]
=> all the quick starts using remote naming, EJB, JMS from external clients will not work unless port-forwarding is enabled.

jeff

[1] https://github.com/wildfly/quickstart/tree/master/helloworld-websocket
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1071862
[3] https://trello.com/c/swGjabeH

jeff
 
On 19 Feb 2014, at 09:15, Jeff Mesnil <[hidden email]> wrote:

>
> On 18 Feb 2014, at 22:19, Farah Juma <[hidden email]> wrote:
>
>> I'm looking into this as well to see if there's a way to make this work. When using port forwarding, I'm finding that an error still occurs:
>
> At this stage, port forwarding works. Thanks Farah.
>
> The remaining issue is the way HornetQ configures its connectors.
>
> HornetQ connectors are the bits that are retrieved using JNDI and contains the informations to connect to the HornetQ server (embedded with WildFly in our case).
> The ugly ugly part of it is that the connector must know the host of the server to connect to.
> In WildFly, we resolve the socket-binding (http in this case) to get this address[1]. When using OpenShift, the HornetQ connectors will use the OpenShift server address (127.5.118.129).
> If I use port forwarding, the remote naming will work and I will retrieve a connector that wants to connect to 127.5.118.129 from my local machine and this does not work.
>
> The HornetQ team has some features planned for the cloud. I’ll let them know about this.
>
> [1] https://github.com/wildfly/wildfly/blob/master/messaging/src/main/java/org/jboss/as/messaging/HornetQService.java#L181
>
> --
> Jeff Mesnil
> JBoss, a division of Red Hat
> http://jmesnil.net/
>
>
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

--
Jeff Mesnil
JBoss, a division of Red Hat
http://jmesnil.net/


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Issue with HTTP upgrade for remote naming on OpenShift?

Jason T. Greene
Thanks for looking into it.

We should start a discussion with the openshift team on that.

> On Mar 5, 2014, at 4:31 AM, Jeff Mesnil <[hidden email]> wrote:
>
> I’ve spent some time running WildFly on OpenShift and playing with it.
>
> * I’ve added a quickstart using WebSocket API[1] and it works fine on OpenShift.
> => note however that OpenShift requires to use a different port for WebSocket (8000) than for HTTP (80) even though both are mapped to WildFly’s 8080 internal port.
>
> * OpenShift does not support custom protocols for HTTP upgrade beside web socket[2][3]
> => all the quick starts using remote naming, EJB, JMS from external clients will not work unless port-forwarding is enabled.
>
> jeff
>
> [1] https://github.com/wildfly/quickstart/tree/master/helloworld-websocket
> [2] https://bugzilla.redhat.com/show_bug.cgi?id=1071862
> [3] https://trello.com/c/swGjabeH
>
> jeff
>
>> On 19 Feb 2014, at 09:15, Jeff Mesnil <[hidden email]> wrote:
>>
>>
>>> On 18 Feb 2014, at 22:19, Farah Juma <[hidden email]> wrote:
>>>
>>> I'm looking into this as well to see if there's a way to make this work. When using port forwarding, I'm finding that an error still occurs:
>>
>> At this stage, port forwarding works. Thanks Farah.
>>
>> The remaining issue is the way HornetQ configures its connectors.
>>
>> HornetQ connectors are the bits that are retrieved using JNDI and contains the informations to connect to the HornetQ server (embedded with WildFly in our case).
>> The ugly ugly part of it is that the connector must know the host of the server to connect to.
>> In WildFly, we resolve the socket-binding (http in this case) to get this address[1]. When using OpenShift, the HornetQ connectors will use the OpenShift server address (127.5.118.129).
>> If I use port forwarding, the remote naming will work and I will retrieve a connector that wants to connect to 127.5.118.129 from my local machine and this does not work.
>>
>> The HornetQ team has some features planned for the cloud. I’ll let them know about this.
>>
>> [1] https://github.com/wildfly/wildfly/blob/master/messaging/src/main/java/org/jboss/as/messaging/HornetQService.java#L181
>>
>> --
>> Jeff Mesnil
>> JBoss, a division of Red Hat
>> http://jmesnil.net/
>>
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
> --
> Jeff Mesnil
> JBoss, a division of Red Hat
> http://jmesnil.net/
>
>
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev