0
votes

I'm struggling to configure and deploy to CloudHub an app with multiple Global HTTP Connectors and a REST component.

My application has two flows: one polls an RSS feed for news and posts a json representation of that feed to an http inbound endpoint in the same app (endpoint resides on second flow). The second flow receives that post, does some magic, including persisting the item to storage, and then notifies via an http outbound endpoint an external node.js web app to push the item via web sockets to active clients.

I have tried what feels like dozens of different configurations involving a variety of HTTP Global Connectors and http in and outbound endpoints, but I can't get everything to work. I currently have:

  1. A Polling HTTP Connector
    • An HTTP endpoint referencing above polling http connector to get RSS Feed
  2. One Global Connector (we'll call HTTP_ONE) to receive messages at localhost:${http.port}
    • An http oubound endpoint configured referencing HTTP_ONE and configured to post an activity to /api/v1/activity
    • An http inbound endpoint configured to receive messages for /api/v1 and a Jersey controller sitting just behind this endpoint which takes /activity.
  3. Another Global Connector (HTTP_TWO) with an external host set as the proxy host name (e.g. somehost.somewhere.com).
    • An http outbound endpoint configured to post messages to somehost.somewhere.com

On my localhost, I've had to use various properties to allow for all of this activity on multiple ports on my laptop.

On CloudHub, I'm using localhost and ${http.port} everywhere except in the oubound endpoint that calls to an external web service.

I can get one flow or the other working, but not both.... My problem seems to be with the posting a given news item from the RSS feed to the Inbound HTTP Endpoint. It is sending the post to http://localhost:80/api/v1/activity, but the connector says that no such path exists (it only lists /api/v1 as an option), which makes me think that the call is not getting as far as the Jersey Controller which sits behind the Global Connector and the http inbound endpoint for /api/v1/activity. Is this behavior an inherent flaw in using the REST Component and multiple global http connectors? Also, why do we have to reference a Global HTTP Connector when making an outbound call? Why can't we use the default HTTP Connector? (Maybe the last two questions should go in a subsequent post...)

Here's most of the relevant config for the two flows:

Global Connectors

<http:polling-connector name="PollingHttpConnector" pollingFrequency="60000" doc:name="HTTP Polling" clientSoTimeout="10000" cookieSpec="netscape" receiveBacklog="0" receiveBufferSize="0" sendBufferSize="0" serverSoTimeout="10000" socketSoLinger="0" validateConnections="true"/>
<http:connector name="EduStream_HTTP" cookieSpec="netscape" validateConnections="true" sendBufferSize="0" receiveBufferSize="0" receiveBacklog="0" clientSoTimeout="10000" serverSoTimeout="10000" socketSoLinger="0" proxyHostname="${edustream.host}"  doc:name="HTTP\HTTPS" proxyPort="80"/>
<http:connector name="EduStreamESB_HTTP" cookieSpec="netscape" validateConnections="true" sendBufferSize="0" receiveBufferSize="0" receiveBacklog="0" clientSoTimeout="10000" serverSoTimeout="10000" socketSoLinger="0" proxyHostname="localhost" proxyPort="${http.port}" doc:name="HTTP\HTTPS"/>

News RSS Feed Flow

<flow name="ucdNewsConsumer" doc:name="ucdNewsConsumer">
    <http:inbound-endpoint address="http://news.ucdavis.edu/xml/getnews.php/rss/category/General%20Interest" 
        connector-ref="PollingHttpConnector" doc:name="HTTP" exchange-pattern="one-way"/>
    <rss:feed-splitter/>
    <rss:entry-last-updated-filter/>  
    <component class="edu.ucdavis.edustream.esb.news.rss.EntryReceiver" doc:name="Java"/>
    <logger message="#[payload]" level="INFO" doc:name="Logger"/>
    <http:outbound-endpoint exchange-pattern="request-response" host="localhost" port="${http.port}" path="api/v1/activity"    doc:name="HTTP"  mimeType="application/json" connector-ref="EduStreamESB_HTTP" />
    <logger message="Payload is: #[payload] Inbound Headers:  #[headers:INBOUND:*] Outbound Headers:  #[headers:OUTBOUND:*] Exception is:  #[exception]" level="INFO" doc:name="Logger"/>
</flow>

Activity Publication Service -- Core Flow

<flow name="edustreamesbFlow1" doc:name="edustreamesbFlow1">
    <http:inbound-endpoint exchange-pattern="request-response" host="localhost" port="${http.port}" doc:name="HTTP" contentType="application/json" mimeType="application/json" path="api/v1" connector-ref="EduStreamESB_HTTP"/>
    <jersey:resources doc:name="REST">
        <component class="edu.ucdavis.edustream.esb.activity.restapi.ActivityController"/>
    </jersey:resources>
    <component class="edu.ucdavis.edustream.esb.activity.restapi.JerseyResponseTransformer" doc:name="JerseyRespTrans"/>

    <flow-ref name="PublishActivity" doc:name="Publish Activity"/>         
</flow>
<sub-flow name="PublishActivity" doc:name="PublishActivity">
    <component doc:name="ActivityService">
        <spring-object bean="activityService"/>
    </component>
    <logger message="#[payload] #[message]" level="INFO" doc:name="Logger"/>
    <http:outbound-endpoint exchange-pattern="request-response" host="${edustream.host}" port="80" path="api/v1/activity" mimeType="application/json" contentType="application/json" doc:name="HTTP" connector-ref="EduStream_HTTP"/>
</sub-flow>
1
Why using HTTP for communication within the same app?David Dossot
The core flow requires a REST API for external clients. I'm just reusing that endpoint for other flows that feed the same type of messages within the app to the core flow. I have considered using a VM Transport for all messages to the core flow that are generated from within the same Mule app, but I guess I'm still stuck on trying to understand why this can't be done with HTTP...GarySharpe

1 Answers

1
votes

I do not get why proxyHostname and proxyPort are configured on both EduStream_HTTP and EduStreamESB_HTTP connectors while the HTTP endpoints from these connectors target the same host/port as their destination address. This doesn't make any sense to me.

Are you really sure you need to use proxies?

For EduStreamESB_HTTP the answer is clearly no: you're calling CloudHub from CloudHub, so no need for a proxy.

For EduStreamESB_HTTP, maybe... but that still seems very strange.