7:01 a.m.
Thanks. Also along this line, we intermittently get a connection error
like:
{"statusCode":500,"data":"{\"responseCode\":500,\"message\":null,\"trace\":\"io.apiman.gateway.engine.beans.exceptions.RequestAbortedException\\n\\tat
io.apiman.gateway.engine.impl.ApiRequestExecutorImpl$3.abort(ApiRequestExecutorImpl.java:721)\\n\\tat
io.apiman.gateway.platforms.servlet.GatewayServlet$2.handle(GatewayServlet.java:173)\\n\\tat
io.apiman.gateway.platforms.servlet.GatewayServlet$2.handle(GatewayServlet.java:160)\\n\\tat
io.apiman.gateway.engine.impl.ApiRequestExecutorImpl.handleStream(ApiRequestExecutorImpl.java:693)\\n\\tat
io.apiman.gateway.engine.impl.ApiRequestExecutorImpl.lambda$null$3(ApiRequestExecutorImpl.java:268)\\n\\tat
io.apiman.gateway.engine.policy.Chain.handleHead(Chain.java:211)\\n\\tat
io.apiman.gateway.engine.policy.Chain.doApply(Chain.java:150)\\n\\tat
even though the service is available. I saw another message about setting
some Wildfly subsystems configuration parameters for IO, but we still
encounter this, and have to restart the gateway. Any idea what's
happening, or suggestions on how to diagnose it?
Thanks,
Scott
On Fri, May 5, 2017 at 6:48 AM Marc Savy <marc.savy(a)redhat.com> wrote:
Thanks for the feedback. I'll create an issue for this and look
to improve
the behaviour further for the next release.
On 4 May 2017 at 22:28, Scott Elliott <scottpelliott(a)gmail.com> wrote:
> I tested the 1.3.0 EAP7 overlay. At least there's a message now:
>
> { "responseCode": 500, "message",
> "io.apiman.gateway.engine.beans.exceptions.ConnectionException: Not
> connected.", ...
>
> Then a stack trace.
>
>
> On Thu, May 4, 2017 at 3:41 PM Eric Wittmann <eric.wittmann(a)redhat.com>
> wrote:
>
>> +1 good point. Can you perhaps open a JIRA ticket? That would be super
>> helpful and would allow you to automatically track progress on the issue.
>>
>> -Eric
>>
>> On Thu, May 4, 2017 at 1:48 PM, Scott Elliott <scottpelliott(a)gmail.com>
>> wrote:
>>
>>> Right now, when the APIMAN gateway cannot connect to the API
>>> implementation's endpoint, the response code is 500, the message is
null,
>>> and there is a stack trace. It's not a very useful response for the
>>> caller, and it's not really an internal problem with the gateway. It
would
>>> be better if another response code were used (502? 503?) and a useful
>>> message were returned instead of a stack trace.
>>>
>>> _______________________________________________
>>> Apiman-user mailing list
>>> Apiman-user(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/apiman-user
>>>
>>>
> _______________________________________________
> Apiman-user mailing list
> Apiman-user(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/apiman-user
>
>