0

Running EI 6.1.1 ESB Profile on Windows Server 2012 with JDK 1.8.0_121

Strange issue this ! :

I have an API which calls a backend service in the 'normal' way with an Endpoint which calls a proxy service (running on the same ESB server) which then proxies the request back to the back-end system. All of this is internal network only.

If I deploy the Endpoint as part of the CAR file to the production server , the endpoint essentially behaves almost as if it's not there. No errors are logged and somehow the payload intended to be sent out through the endpoint is being returned to the client through the API as a response.(not sure quite how yet as no fault sequences are called and no errors logged)

The proxy service it is bound to never gets hit (have checked by placing a full log mediator as 1st mediator in proxy) and the endpoint is not showing any failure or suspended state.

If I create the endpoint using the identical XML through the admin console then everything works as it should. UNTIL the ESB profile is restarted. After a restart it behaves as described above.

I have discovered that in either of the above cases - if I go to edit the endpoint through the admin console , MAKE NO CHANGES and immediately save it - then everything works again - obviously until the next ESB Profile restart.

Here's the Endpoint concerned:

<endpoint xmlns="http://ws.apache.org/ns/synapse" name="Sworks">
   <wsdl uri="http://intapi.mycompany.co.uk/services/SworksPxy?wsdl" service="SworksPxy" port="SworksPxyHttpSoap11Endpoint">
      <suspendOnFailure>
         <progressionFactor>1.0</progressionFactor>
      </suspendOnFailure>
      <markForSuspension>
         <retriesBeforeSuspension>0</retriesBeforeSuspension>
         <retryDelay>0</retryDelay>
      </markForSuspension>
   </wsdl>
</endpoint>

Any help much appreciated. Obviously this is frustrating as it means our application fails each time the server gets rebooted or ESB profile restarted until someone can go in through the console and EDIT/SAVE the endpoint.

UPDATE: This seems to be something to do with the endpoint and it's target residing on the same ESB server. if I deploy the carbon application unmodified to my local runtime environment (through eclipse) - all works as it should. The endpoint is then still referencing the proxy service on the production server. If I update the endpoint to point to the proxy service deployed on the local runtime environment they failure behaviour is reproduced. Again - an Edit/Save fixes it.

  • Any more Ideas? My server reboots weekly to apply updates and unless someone remembers to edit and save the endpoint our inventory management API stops working! – will valintine Apr 17 '18 at 15:28
  • I now realise that this is occuring only on proxy endpoints which target DSS endpoints running on the same server. I still have no fix or workaround to teh issue but I believe it is now essentially the same issue as reported here : https://stackoverflow.com/questions/21910190/wso2-esb-proxy-service-does-not-start-if-target-is-unavailable/59881591#59881591 – will valintine Jan 23 '20 at 15:15

1 Answers1

0

Can you check whether the endpoint is created on file system or not ? <WSO2_HOME>/repository/deployment/server/synapse-configs/default/endpoints , If the endpoint is there then delete the endpoint , remove the CAR file and restart the server, then apply the CAR file after restarting the server and then check

amg_amit
  • 495
  • 1
  • 3
  • 9
  • Hi, thanks for your response. Yes the endpoint was in the file system at that location so I deleted that, deleted the endpoint from the admin console (it was currently not deployed as part of the CAR) and removed the CAR. Then I ran a graceful restart, rebuilt the CAR to include the Endpoint and added it back to the server. The endpoint does not exist on the filesystem now. However - the issue remains - the endpoint does not work until I go to edit through the admin console and immediately Save'. The endpoint still does not appear in the filesystem. (expected as it's part of the CAR now?) – will valintine Apr 04 '18 at 14:10
  • See my update to the OP - if the endpoint and proxy are not on the same ESB server - the issue does not occur. – will valintine Apr 04 '18 at 15:43