SstHttpClient error when target endpoint is not available

What VA version are you using?

Best, 

BTW, the error you are getting is SstInvalidAddressError(EHOSTNOTFOUND (11001): Host not found  ?

The error I'm getting is 'SstEndpointUnreachableError(ECONNREFUSED (10061): Connection refused)' when the target endpoint server is not running.  I guess I can handle the exception and try to get the SstError from argument 2 of the signal, but I just thought that if it can consistently return either the SstError or raise an exception, that would make checking for error conditions easier.

On Tuesday, December 11, 2018 at 12:43:12 PM UTC-6, Mariano Martinez Peck wrote:

BTW, the error you are getting is SstInvalidAddressError(EHOSTNOTFOUND (11001): Host not found  ?

Best regards,
--

SstXmlResourceReader>>#readResourceFor: to allow logging of the error when ExError occurs.

SstXmlResourceReader>>#fetch: to avoid sending #header to what may be an SstError, and also allow logging if it is an SstError.

thanks,

On Wednesday, December 12, 2018 at 6:43:33 AM UTC-6, Mariano Martinez Peck wrote:

On Tue, Dec 11, 2018 at 7:35 PM Tom Kao <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="Rt4NlgE1CQAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">tom...@...> wrote:

We are using VA 7.5.2, but we copied over the SstHttpsCommunications app from VA9.1.

The error I'm getting is 'SstEndpointUnreachableError(ECONNREFUSED (10061): Connection refused)' when the target endpoint server is not running.  I guess I can handle the exception and try to get the SstError from argument 2 of the signal, but I just thought that if it can consistently return either the SstError or raise an exception, that would make checking for error conditions easier.

Thanks Tom for the report. We will discuss it with the team. Your thought came in a timely moment because we are currently (to be included in 9.2) doing a pass over the SstHttpClient and friends...basically we are:

1) Adding support for redirects

2) Adding support for PUT, DELETE, and other HTTP methods/verbs

3) Adding  Server Name Indication (SNI) support to HTTPS

4) Increased a lot our unit testing coverage on them

5) Internal code cleanup and refactors

 

We will let you know our thoughts in your matter.  

Best regards,

--

Mariano Martinez Peck
Software Engineer, Instantiations Inc.
<a href="javascript:" target="_blank" gdf-obfuscated-mailto="Rt4NlgE1CQAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">mp...@...

[SstError new raise] 

   when: SstConstants::ExSstNonFatalError

   do: [:ex| Transcript show: ex asString. ex exitWith: <return object>].

where <return object> could be things like

ex arguments last

or

nil

There should be some other examples in the image that you can look at if you browse refs to ExSstNonFatalError

- Seth

On Thursday, December 13, 2018 at 10:37:30 AM UTC-5, Tom Kao wrote:

It seems I cannot catch and handle this exception with when:do:.  SstError>>raise raises ExSstNonFatalError exception for all SstError and that exception is not resumable.  How can errors be handled to my program can contibue when an SstError occurs?  

thanks,

On Wednesday, December 12, 2018 at 6:43:33 AM UTC-6, Mariano Martinez Peck wrote:

On Tue, Dec 11, 2018 at 7:35 PM Tom Kao <[hidden email]> wrote:

We are using VA 7.5.2, but we copied over the SstHttpsCommunications app from VA9.1.

The error I'm getting is 'SstEndpointUnreachableError(ECONNREFUSED (10061): Connection refused)' when the target endpoint server is not running.  I guess I can handle the exception and try to get the SstError from argument 2 of the signal, but I just thought that if it can consistently return either the SstError or raise an exception, that would make checking for error conditions easier.

Thanks Tom for the report. We will discuss it with the team. Your thought came in a timely moment because we are currently (to be included in 9.2) doing a pass over the SstHttpClient and friends...basically we are:

1) Adding support for redirects

2) Adding support for PUT, DELETE, and other HTTP methods/verbs

3) Adding  Server Name Indication (SNI) support to HTTPS

4) Increased a lot our unit testing coverage on them

5) Internal code cleanup and refactors

 

We will let you know our thoughts in your matter.  

Best regards,

--

Mariano Martinez Peck
Software Engineer, Instantiations Inc.
[hidden email]

My patches are more in the area of SOAP.

If anything goes wrong in a SOAP deploy, you tend to get the exception signaled by AbtXmlResourceReader>>#resolveEntity:systemId:baseURI:.  All that means is that something went wrong, but you have no idea what.

 

The typical cause is SstXmlResourceReader>>#readResourceFor: getting a signal with some useful information, but nothing is done with that – and the method just answers nil.  I've patched it to dump some information on the signal.  (I mentioned the problem on INST62068 & INST61930, as well as a potential problem that #fetchMessage doesn’t check for errors from #startUp which I haven’t patched.)  By the way, another method we have patched is #fetch: in that class, where #fetchMessage could answer an SstError, which doesn’t understand #header sent there – so if #fetchMessage answers an SstError, our code tires to log what it says.