From eric.wittmann at redhat.com  Wed Feb  1 08:26:43 2017
From: eric.wittmann at redhat.com (Eric Wittmann)
Date: Wed, 1 Feb 2017 08:26:43 -0500
Subject: [Apiman-user] How to limit access for IP Address
In-Reply-To: <CAOFYJDtqHoZ-bojCvnsVMm3AqcAQWSU01ONiaK5enyNdpcH=8A@mail.gmail.com>
References: <CAOFYJDt8WRMKqR5uCjBeHZG8HhR8sa+Sm1f1ScFS_sxht=cVpw@mail.gmail.com>
	<CAP4n9Q8i_00M5ztbRejPORqc8RyUxTAQCZJsrQbGO_8L--011g@mail.gmail.com>
	<CAOFYJDtqHoZ-bojCvnsVMm3AqcAQWSU01ONiaK5enyNdpcH=8A@mail.gmail.com>
Message-ID: <CAP4n9Q-vZGSM7BiaaydD41EwhEAR-BkkW8b_wS_tx=KS5JF48g@mail.gmail.com>

Sounds good, thanks!  Here is the starting point for the Rate Limiting
policy implementation:

https://github.com/apiman/apiman/blob/master/gateway/engine/policies/src/main/java/io/apiman/gateway/engine/policies/RateLimitingPolicy.java

-Eric

On Tue, Jan 31, 2017 at 8:02 PM, Celso Agra <celso.agra at gmail.com> wrote:

> I'll take a look how to implement this feature as an enhacement of rate
> limiting policy. I believe this could be better than create a new plugin
>
> Thanks Eric!
>
> 2017-01-31 11:08 GMT-03:00 Eric Wittmann <eric.wittmann at redhat.com>:
>
>> Apologies for the delayed response.  Currently the rate limiting and
>> quota policies only operate on the authenticated User, the Client, or the
>> Api.  To support your use-case, you would either need to implement a custom
>> policy or enhance the current Rate Limiting policy.  I think the project
>> would benefit more from the latter approach, but that's of course up to
>> you!  :)
>>
>> -Eric
>>
>> On Thu, Jan 26, 2017 at 4:16 PM, Celso Agra <celso.agra at gmail.com> wrote:
>>
>>> All,
>>>
>>> I'd like to know if the Apiman has policies to restrict the number of
>>> access from specific IP Address. Such as Quota Policy or Rate Limiting
>>> Policy.
>>> Should I have to implement this Policy?
>>>
>>> Best Regards,
>>>
>>>
>>> --
>>> ---
>>> *Celso Agra*
>>>
>>> _______________________________________________
>>> Apiman-user mailing list
>>> Apiman-user at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/apiman-user
>>>
>>>
>>
>
>
> --
> ---
> *Celso Agra*
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20170201/e882ea76/attachment.html 

From sbalu27 at gmail.com  Thu Feb  2 11:56:37 2017
From: sbalu27 at gmail.com (Balu S)
Date: Thu, 2 Feb 2017 17:56:37 +0100
Subject: [Apiman-user] API policy response data handler
Message-ID: <CAEDnbHAh2HPm5evojoR4H7E3Wv+frVEDyHkwuNp6-tin3tzAkA@mail.gmail.com>

Hello,
I'm trying to parse the response using responseDataHandler() in the custom
policy. In cases, if the response from API is of certain content, I would
like the Apiman to consider as failure. But I don't find a way to throw
policy failure from responseDataHandler(). And I cannot achieve this in
doApply() as the ApiResponse object does not have "content" to parse.

Also, what I found is write(chunk) in the AbstractStream is called after
doApply, so I cannot set any attributes in it to fetch it in doApply() and
trigger doFailure().

For example, in below call, how to throw as policy failure after parsing
the contents ? Or how can I access response content even before write()
method.


*URLRewritingPolicy.java*

    @Override
    protected IReadWriteStream<ApiResponse> responseDataHandler(ApiResponse
response,
            IPolicyContext context, URLRewritingConfig policyConfiguration)
{
        if (policyConfiguration.isProcessResponseBody()) {
            return new
URLRewritingStream(context.getComponent(IBufferFactoryComponent.class),
response,
                    policyConfiguration.getFromRegex(),
policyConfiguration.getToReplacement());
        } else {
            return null;
        }
    }

*URLRewritingStream.java*

    /**
     * @see
io.apiman.gateway.engine.io.AbstractStream#write(io.apiman.gateway.engine.io.IApimanBuffer)
     */
    @Override
    public void write(IApimanBuffer chunk) {
        if (buffer == null) {
            buffer = bufferFactory.cloneBuffer(chunk);
        } else {
            buffer.append(chunk);
        }
        atEnd = false;
        processBuffer();
    }


Best regards
Balu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20170202/129e7905/attachment.html 

From marc.savy at redhat.com  Thu Feb  2 12:15:07 2017
From: marc.savy at redhat.com (Marc Savy)
Date: Thu, 2 Feb 2017 17:15:07 +0000
Subject: [Apiman-user] API policy response data handler
In-Reply-To: <CAEDnbHAh2HPm5evojoR4H7E3Wv+frVEDyHkwuNp6-tin3tzAkA@mail.gmail.com>
References: <CAEDnbHAh2HPm5evojoR4H7E3Wv+frVEDyHkwuNp6-tin3tzAkA@mail.gmail.com>
Message-ID: <CAA7j38+AU4HqeS_SkEVDZGB6JiZjpgFQgs=dnioAzad6-OcrMA@mail.gmail.com>

Hi,

Perhaps URLRewritingPolicy
https://github.com/apiman/apiman/blob/master/gateway/engine/policies/src/main/java/io/apiman/gateway/engine/policies/URLRewritingPolicy.java
be an informative place to start?

- Apiman streams data, so the client may be receiving data already by the
time you've determined you want to cancel (the connection is already
established; headers have been sent) - it's often too late to gracefully
cancel. You could try throwing an exception and seeing what happens (not
recommended practice!).

If that doesn't work, perhaps you can explain your use-case more clearly
and explicitly so we can see what the alternatives are?

- Policies are *static* instances, if you are assigning that buffer to the
object then it's as if you were writing "static Buffer  buffer" and
different requests will all share that variable (and thus swap it out
repeatedly!).

Regards,
Marc





On 2 February 2017 at 16:56, Balu S <sbalu27 at gmail.com> wrote:

> Hello,
> I'm trying to parse the response using responseDataHandler() in the custom
> policy. In cases, if the response from API is of certain content, I would
> like the Apiman to consider as failure. But I don't find a way to throw
> policy failure from responseDataHandler(). And I cannot achieve this in
> doApply() as the ApiResponse object does not have "content" to parse.
>
> Also, what I found is write(chunk) in the AbstractStream is called after
> doApply, so I cannot set any attributes in it to fetch it in doApply() and
> trigger doFailure().
>
> For example, in below call, how to throw as policy failure after parsing
> the contents ? Or how can I access response content even before write()
> method.
>
>
> *URLRewritingPolicy.java*
>
>     @Override
>     protected IReadWriteStream<ApiResponse> responseDataHandler(ApiResponse
> response,
>             IPolicyContext context, URLRewritingConfig
> policyConfiguration) {
>         if (policyConfiguration.isProcessResponseBody()) {
>             return new URLRewritingStream(context.getComponent(
> IBufferFactoryComponent.class), response,
>                     policyConfiguration.getFromRegex(),
> policyConfiguration.getToReplacement());
>         } else {
>             return null;
>         }
>     }
>
> *URLRewritingStream.java*
>
>     /**
>      * @see io.apiman.gateway.engine.io.AbstractStream#write(io.
> apiman.gateway.engine.io.IApimanBuffer)
>      */
>     @Override
>     public void write(IApimanBuffer chunk) {
>         if (buffer == null) {
>             buffer = bufferFactory.cloneBuffer(chunk);
>         } else {
>             buffer.append(chunk);
>         }
>         atEnd = false;
>         processBuffer();
>     }
>
>
> Best regards
> Balu
>
> _______________________________________________
> Apiman-user mailing list
> Apiman-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/apiman-user
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20170202/d677f92b/attachment-0001.html 

From sbalu27 at gmail.com  Thu Feb  2 12:40:12 2017
From: sbalu27 at gmail.com (Balu S)
Date: Thu, 2 Feb 2017 18:40:12 +0100
Subject: [Apiman-user] API policy response data handler
In-Reply-To: <CAA7j38+AU4HqeS_SkEVDZGB6JiZjpgFQgs=dnioAzad6-OcrMA@mail.gmail.com>
References: <CAEDnbHAh2HPm5evojoR4H7E3Wv+frVEDyHkwuNp6-tin3tzAkA@mail.gmail.com>
	<CAA7j38+AU4HqeS_SkEVDZGB6JiZjpgFQgs=dnioAzad6-OcrMA@mail.gmail.com>
Message-ID: <CAEDnbHDodcDtpWYoUS6kWRnS_hbZ=Ftt4dfmbFsKrLoKaZ6pBQ@mail.gmail.com>

Hi Marc,

I shall explain my use case. From our API call, we return error response
(in XML or JSON)  for 401, 500 and so on. However, Apiman metrics seems to
just consider them as good response (it is, as Apiman received the response
back) and show as successful response. So I have made custom policy to
intercept the response to know if it is failure and trigger the Policy
Failure. This is fairly simple and straight forward as the response code
will just do the purpose. But I want also to add some additional
information about the failure to Policy Failure. This additional
information is in the original error response which will be lost once
doFailure() happens. And no we don't want to those additional information
in some HTTP headers to pass around. Hence I implemented responseHandler()
to handle the response buffer and like you pointed out, it seems to be too
late to meddle the response.

So ideally, there are possible 2 solution

   - Apiman metrics can interpret the response as unsuccessful for such
error response from API call.
   - Handle the response buffer data before the write() call to response
outputstream.

Do you see any alternative solution?

Thanks
Balu

On Thu, Feb 2, 2017 at 6:15 PM, Marc Savy <marc.savy at redhat.com> wrote:

> Hi,
>
> Perhaps URLRewritingPolicy https://github.com/apiman/
> apiman/blob/master/gateway/engine/policies/src/main/java/
> io/apiman/gateway/engine/policies/URLRewritingPolicy.java be an
> informative place to start?
>
> - Apiman streams data, so the client may be receiving data already by the
> time you've determined you want to cancel (the connection is already
> established; headers have been sent) - it's often too late to gracefully
> cancel. You could try throwing an exception and seeing what happens (not
> recommended practice!).
>
> If that doesn't work, perhaps you can explain your use-case more clearly
> and explicitly so we can see what the alternatives are?
>
> - Policies are *static* instances, if you are assigning that buffer to the
> object then it's as if you were writing "static Buffer  buffer" and
> different requests will all share that variable (and thus swap it out
> repeatedly!).
>
> Regards,
> Marc
>
>
>
>
>
> On 2 February 2017 at 16:56, Balu S <sbalu27 at gmail.com> wrote:
>
>> Hello,
>> I'm trying to parse the response using responseDataHandler() in the
>> custom policy. In cases, if the response from API is of certain content, I
>> would like the Apiman to consider as failure. But I don't find a way to
>> throw policy failure from responseDataHandler(). And I cannot achieve this
>> in doApply() as the ApiResponse object does not have "content" to parse.
>>
>> Also, what I found is write(chunk) in the AbstractStream is called after
>> doApply, so I cannot set any attributes in it to fetch it in doApply() and
>> trigger doFailure().
>>
>> For example, in below call, how to throw as policy failure after parsing
>> the contents ? Or how can I access response content even before write()
>> method.
>>
>>
>> *URLRewritingPolicy.java*
>>
>>     @Override
>>     protected IReadWriteStream<ApiResponse> responseDataHandler(ApiResponse
>> response,
>>             IPolicyContext context, URLRewritingConfig
>> policyConfiguration) {
>>         if (policyConfiguration.isProcessResponseBody()) {
>>             return new URLRewritingStream(context.get
>> Component(IBufferFactoryComponent.class), response,
>>                     policyConfiguration.getFromRegex(),
>> policyConfiguration.getToReplacement());
>>         } else {
>>             return null;
>>         }
>>     }
>>
>> *URLRewritingStream.java*
>>
>>     /**
>>      * @see io.apiman.gateway.engine.io.AbstractStream#write(io.apiman.
>> gateway.engine.io.IApimanBuffer)
>>      */
>>     @Override
>>     public void write(IApimanBuffer chunk) {
>>         if (buffer == null) {
>>             buffer = bufferFactory.cloneBuffer(chunk);
>>         } else {
>>             buffer.append(chunk);
>>         }
>>         atEnd = false;
>>         processBuffer();
>>     }
>>
>>
>> Best regards
>> Balu
>>
>> _______________________________________________
>> Apiman-user mailing list
>> Apiman-user at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/apiman-user
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20170202/70667782/attachment.html 

From marc.savy at redhat.com  Thu Feb  2 13:02:01 2017
From: marc.savy at redhat.com (Marc Savy)
Date: Thu, 2 Feb 2017 18:02:01 +0000
Subject: [Apiman-user] API policy response data handler
In-Reply-To: <CAEDnbHDodcDtpWYoUS6kWRnS_hbZ=Ftt4dfmbFsKrLoKaZ6pBQ@mail.gmail.com>
References: <CAEDnbHAh2HPm5evojoR4H7E3Wv+frVEDyHkwuNp6-tin3tzAkA@mail.gmail.com>
	<CAA7j38+AU4HqeS_SkEVDZGB6JiZjpgFQgs=dnioAzad6-OcrMA@mail.gmail.com>
	<CAEDnbHDodcDtpWYoUS6kWRnS_hbZ=Ftt4dfmbFsKrLoKaZ6pBQ@mail.gmail.com>
Message-ID: <CAA7j38J=DLUMF7YTnor2FTVDhpOOAvnq3YpxjfdCJC_-WxeB5w@mail.gmail.com>

That sounds like metrics are going wrong, or perhaps you're misinterpreting
it  (adding Eric).

When you say your API returns an error, does it still return an appropriate
non-200 error code at the HTTP level? For instance, 500 or similar? That's
very important.

There's a difference between an error and a failure - have you checked both
of those fields to see whether they contain the information you're
expecting to see.

Certainly in my experience we *do* collect the metrics you're talking
about, unless I'm misunderstanding you.

On 2 February 2017 at 17:40, Balu S <sbalu27 at gmail.com> wrote:

> Hi Marc,
>
> I shall explain my use case. From our API call, we return error response
> (in XML or JSON)  for 401, 500 and so on. However, Apiman metrics seems to
> just consider them as good response (it is, as Apiman received the response
> back) and show as successful response. So I have made custom policy to
> intercept the response to know if it is failure and trigger the Policy
> Failure. This is fairly simple and straight forward as the response code
> will just do the purpose. But I want also to add some additional
> information about the failure to Policy Failure. This additional
> information is in the original error response which will be lost once
> doFailure() happens. And no we don't want to those additional information
> in some HTTP headers to pass around. Hence I implemented responseHandler()
> to handle the response buffer and like you pointed out, it seems to be too
> late to meddle the response.
>
> So ideally, there are possible 2 solution
>
>    - Apiman metrics can interpret the response as unsuccessful for such
> error response from API call.
>    - Handle the response buffer data before the write() call to response
> outputstream.
>
> Do you see any alternative solution?
>
> Thanks
> Balu
>
> On Thu, Feb 2, 2017 at 6:15 PM, Marc Savy <marc.savy at redhat.com> wrote:
>
>> Hi,
>>
>> Perhaps URLRewritingPolicy https://github.com/apiman/apim
>> an/blob/master/gateway/engine/policies/src/main/java/io/
>> apiman/gateway/engine/policies/URLRewritingPolicy.java be an informative
>> place to start?
>>
>> - Apiman streams data, so the client may be receiving data already by the
>> time you've determined you want to cancel (the connection is already
>> established; headers have been sent) - it's often too late to gracefully
>> cancel. You could try throwing an exception and seeing what happens (not
>> recommended practice!).
>>
>> If that doesn't work, perhaps you can explain your use-case more clearly
>> and explicitly so we can see what the alternatives are?
>>
>> - Policies are *static* instances, if you are assigning that buffer to
>> the object then it's as if you were writing "static Buffer  buffer" and
>> different requests will all share that variable (and thus swap it out
>> repeatedly!).
>>
>> Regards,
>> Marc
>>
>>
>>
>>
>>
>> On 2 February 2017 at 16:56, Balu S <sbalu27 at gmail.com> wrote:
>>
>>> Hello,
>>> I'm trying to parse the response using responseDataHandler() in the
>>> custom policy. In cases, if the response from API is of certain content, I
>>> would like the Apiman to consider as failure. But I don't find a way to
>>> throw policy failure from responseDataHandler(). And I cannot achieve this
>>> in doApply() as the ApiResponse object does not have "content" to parse.
>>>
>>> Also, what I found is write(chunk) in the AbstractStream is called after
>>> doApply, so I cannot set any attributes in it to fetch it in doApply() and
>>> trigger doFailure().
>>>
>>> For example, in below call, how to throw as policy failure after parsing
>>> the contents ? Or how can I access response content even before write()
>>> method.
>>>
>>>
>>> *URLRewritingPolicy.java*
>>>
>>>     @Override
>>>     protected IReadWriteStream<ApiResponse>
>>> responseDataHandler(ApiResponse response,
>>>             IPolicyContext context, URLRewritingConfig
>>> policyConfiguration) {
>>>         if (policyConfiguration.isProcessResponseBody()) {
>>>             return new URLRewritingStream(context.get
>>> Component(IBufferFactoryComponent.class), response,
>>>                     policyConfiguration.getFromRegex(),
>>> policyConfiguration.getToReplacement());
>>>         } else {
>>>             return null;
>>>         }
>>>     }
>>>
>>> *URLRewritingStream.java*
>>>
>>>     /**
>>>      * @see io.apiman.gateway.engine.io.AbstractStream#write(io.apiman.g
>>> ateway.engine.io.IApimanBuffer)
>>>      */
>>>     @Override
>>>     public void write(IApimanBuffer chunk) {
>>>         if (buffer == null) {
>>>             buffer = bufferFactory.cloneBuffer(chunk);
>>>         } else {
>>>             buffer.append(chunk);
>>>         }
>>>         atEnd = false;
>>>         processBuffer();
>>>     }
>>>
>>>
>>> Best regards
>>> Balu
>>>
>>> _______________________________________________
>>> Apiman-user mailing list
>>> Apiman-user at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/apiman-user
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20170202/1329467e/attachment.html 

From celso.agra at gmail.com  Thu Feb  2 16:23:04 2017
From: celso.agra at gmail.com (Celso Agra)
Date: Thu, 2 Feb 2017 18:23:04 -0300
Subject: [Apiman-user] How to change the URL location with URL Rewriting
	Policy
Message-ID: <CAOFYJDur-EBSi-zKKqFFPS3As3D7B6GhRzY=f-EAezp-=1voMw@mail.gmail.com>

All,

I'm trying to change the location path in browser with my nodeJS
application.
For some reason, the apiman does not allow me to change that.

So, I'm think to use the URL Rewriting Policy Configuration, but I'd like
to understand how it works.

Here's my nodeJS code:

req.url = config.redirect_site;
res.statusCode = 302;
res.location(config.redirect_site);
res.end();


Without APIman it works fine! Does anyone know how can I set a different
url with this policy or any other method in Apiman?

Thanks!

Best regards,

-- 
---
*Celso Agra*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20170202/b77e4b53/attachment-0001.html 

From eric.wittmann at redhat.com  Thu Feb  2 17:19:23 2017
From: eric.wittmann at redhat.com (Eric Wittmann)
Date: Thu, 2 Feb 2017 17:19:23 -0500
Subject: [Apiman-user] How to change the URL location with URL Rewriting
	Policy
In-Reply-To: <CAOFYJDur-EBSi-zKKqFFPS3As3D7B6GhRzY=f-EAezp-=1voMw@mail.gmail.com>
References: <CAOFYJDur-EBSi-zKKqFFPS3As3D7B6GhRzY=f-EAezp-=1voMw@mail.gmail.com>
Message-ID: <CAP4n9Q8=Sgbd5xVm4uhjVMJ78VcggDjeofLcOt155ou8NQ84bQ@mail.gmail.com>

What is the behavior you are seeing?  It's possible that the apiman gateway
itself is following the redirect.  Is that what's happening?

On Thu, Feb 2, 2017 at 4:23 PM, Celso Agra <celso.agra at gmail.com> wrote:

> All,
>
> I'm trying to change the location path in browser with my nodeJS
> application.
> For some reason, the apiman does not allow me to change that.
>
> So, I'm think to use the URL Rewriting Policy Configuration, but I'd like
> to understand how it works.
>
> Here's my nodeJS code:
>
> req.url = config.redirect_site;
> res.statusCode = 302;
> res.location(config.redirect_site);
> res.end();
>
>
> Without APIman it works fine! Does anyone know how can I set a different
> url with this policy or any other method in Apiman?
>
> Thanks!
>
> Best regards,
>
> --
> ---
> *Celso Agra*
>
> _______________________________________________
> Apiman-user mailing list
> Apiman-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/apiman-user
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20170202/589f0df5/attachment.html 

From celso.agra at gmail.com  Thu Feb  2 19:04:43 2017
From: celso.agra at gmail.com (Celso Agra)
Date: Thu, 2 Feb 2017 21:04:43 -0300
Subject: [Apiman-user] How to change the URL location with URL Rewriting
	Policy
In-Reply-To: <CAP4n9Q8=Sgbd5xVm4uhjVMJ78VcggDjeofLcOt155ou8NQ84bQ@mail.gmail.com>
References: <CAOFYJDur-EBSi-zKKqFFPS3As3D7B6GhRzY=f-EAezp-=1voMw@mail.gmail.com>
	<CAP4n9Q8=Sgbd5xVm4uhjVMJ78VcggDjeofLcOt155ou8NQ84bQ@mail.gmail.com>
Message-ID: <CAOFYJDsF3GYqjyys3ErwOiqkWfsv-Yhc=E3pWeq+tft80a-B1Q@mail.gmail.com>

Yeah! The Apiman is following the redirect.
If I do not use the apiman to invoke the http method, so, my system can
redirect to another url (such as the location in browser); But If I use the
apiman to invoke this method, so the location is not being changed


2017-02-02 19:19 GMT-03:00 Eric Wittmann <eric.wittmann at redhat.com>:

> What is the behavior you are seeing?  It's possible that the apiman
> gateway itself is following the redirect.  Is that what's happening?
>
> On Thu, Feb 2, 2017 at 4:23 PM, Celso Agra <celso.agra at gmail.com> wrote:
>
>> All,
>>
>> I'm trying to change the location path in browser with my nodeJS
>> application.
>> For some reason, the apiman does not allow me to change that.
>>
>> So, I'm think to use the URL Rewriting Policy Configuration, but I'd like
>> to understand how it works.
>>
>> Here's my nodeJS code:
>>
>> req.url = config.redirect_site;
>> res.statusCode = 302;
>> res.location(config.redirect_site);
>> res.end();
>>
>>
>> Without APIman it works fine! Does anyone know how can I set a different
>> url with this policy or any other method in Apiman?
>>
>> Thanks!
>>
>> Best regards,
>>
>> --
>> ---
>> *Celso Agra*
>>
>> _______________________________________________
>> Apiman-user mailing list
>> Apiman-user at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/apiman-user
>>
>>
>


-- 
---
*Celso Agra*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20170202/e6300863/attachment.html 

From eric.wittmann at redhat.com  Thu Feb  2 21:24:45 2017
From: eric.wittmann at redhat.com (Eric Wittmann)
Date: Thu, 2 Feb 2017 21:24:45 -0500
Subject: [Apiman-user] How to change the URL location with URL Rewriting
	Policy
In-Reply-To: <CAOFYJDsF3GYqjyys3ErwOiqkWfsv-Yhc=E3pWeq+tft80a-B1Q@mail.gmail.com>
References: <CAOFYJDur-EBSi-zKKqFFPS3As3D7B6GhRzY=f-EAezp-=1voMw@mail.gmail.com>
	<CAP4n9Q8=Sgbd5xVm4uhjVMJ78VcggDjeofLcOt155ou8NQ84bQ@mail.gmail.com>
	<CAOFYJDsF3GYqjyys3ErwOiqkWfsv-Yhc=E3pWeq+tft80a-B1Q@mail.gmail.com>
Message-ID: <CAP4n9Q_10g+=bheMKb4yBFUMUH6myKDhx61o+xw_JNe=8r6RMQ@mail.gmail.com>

There is a property defined in "apiman.properties" that you can change:

apiman-gateway.connector-factory.http.followRedirects

Change that property to "false" and try again. :)

-Eric

On Thu, Feb 2, 2017 at 7:04 PM, Celso Agra <celso.agra at gmail.com> wrote:

> Yeah! The Apiman is following the redirect.
> If I do not use the apiman to invoke the http method, so, my system can
> redirect to another url (such as the location in browser); But If I use the
> apiman to invoke this method, so the location is not being changed
>
>
> 2017-02-02 19:19 GMT-03:00 Eric Wittmann <eric.wittmann at redhat.com>:
>
>> What is the behavior you are seeing?  It's possible that the apiman
>> gateway itself is following the redirect.  Is that what's happening?
>>
>> On Thu, Feb 2, 2017 at 4:23 PM, Celso Agra <celso.agra at gmail.com> wrote:
>>
>>> All,
>>>
>>> I'm trying to change the location path in browser with my nodeJS
>>> application.
>>> For some reason, the apiman does not allow me to change that.
>>>
>>> So, I'm think to use the URL Rewriting Policy Configuration, but I'd
>>> like to understand how it works.
>>>
>>> Here's my nodeJS code:
>>>
>>> req.url = config.redirect_site;
>>> res.statusCode = 302;
>>> res.location(config.redirect_site);
>>> res.end();
>>>
>>>
>>> Without APIman it works fine! Does anyone know how can I set a different
>>> url with this policy or any other method in Apiman?
>>>
>>> Thanks!
>>>
>>> Best regards,
>>>
>>> --
>>> ---
>>> *Celso Agra*
>>>
>>> _______________________________________________
>>> Apiman-user mailing list
>>> Apiman-user at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/apiman-user
>>>
>>>
>>
>
>
> --
> ---
> *Celso Agra*
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20170202/609e6e97/attachment.html 

From eric.wittmann at redhat.com  Thu Feb  2 21:26:06 2017
From: eric.wittmann at redhat.com (Eric Wittmann)
Date: Thu, 2 Feb 2017 21:26:06 -0500
Subject: [Apiman-user] How to change the URL location with URL Rewriting
	Policy
In-Reply-To: <CAP4n9Q_10g+=bheMKb4yBFUMUH6myKDhx61o+xw_JNe=8r6RMQ@mail.gmail.com>
References: <CAOFYJDur-EBSi-zKKqFFPS3As3D7B6GhRzY=f-EAezp-=1voMw@mail.gmail.com>
	<CAP4n9Q8=Sgbd5xVm4uhjVMJ78VcggDjeofLcOt155ou8NQ84bQ@mail.gmail.com>
	<CAOFYJDsF3GYqjyys3ErwOiqkWfsv-Yhc=E3pWeq+tft80a-B1Q@mail.gmail.com>
	<CAP4n9Q_10g+=bheMKb4yBFUMUH6myKDhx61o+xw_JNe=8r6RMQ@mail.gmail.com>
Message-ID: <CAP4n9Q-2j9TWvtazTznAf5-RZy3kurTf07zw-mYsBcXDPs38Ow@mail.gmail.com>

This property:

https://github.com/apiman/apiman/blob/master/distro/wildfly9/src/main/resources/overlay/standalone/configuration/apiman.properties#L88

-Eric


On Thu, Feb 2, 2017 at 9:24 PM, Eric Wittmann <eric.wittmann at redhat.com>
wrote:

> There is a property defined in "apiman.properties" that you can change:
>
> apiman-gateway.connector-factory.http.followRedirects
>
> Change that property to "false" and try again. :)
>
> -Eric
>
> On Thu, Feb 2, 2017 at 7:04 PM, Celso Agra <celso.agra at gmail.com> wrote:
>
>> Yeah! The Apiman is following the redirect.
>> If I do not use the apiman to invoke the http method, so, my system can
>> redirect to another url (such as the location in browser); But If I use the
>> apiman to invoke this method, so the location is not being changed
>>
>>
>> 2017-02-02 19:19 GMT-03:00 Eric Wittmann <eric.wittmann at redhat.com>:
>>
>>> What is the behavior you are seeing?  It's possible that the apiman
>>> gateway itself is following the redirect.  Is that what's happening?
>>>
>>> On Thu, Feb 2, 2017 at 4:23 PM, Celso Agra <celso.agra at gmail.com> wrote:
>>>
>>>> All,
>>>>
>>>> I'm trying to change the location path in browser with my nodeJS
>>>> application.
>>>> For some reason, the apiman does not allow me to change that.
>>>>
>>>> So, I'm think to use the URL Rewriting Policy Configuration, but I'd
>>>> like to understand how it works.
>>>>
>>>> Here's my nodeJS code:
>>>>
>>>> req.url = config.redirect_site;
>>>> res.statusCode = 302;
>>>> res.location(config.redirect_site);
>>>> res.end();
>>>>
>>>>
>>>> Without APIman it works fine! Does anyone know how can I set a
>>>> different url with this policy or any other method in Apiman?
>>>>
>>>> Thanks!
>>>>
>>>> Best regards,
>>>>
>>>> --
>>>> ---
>>>> *Celso Agra*
>>>>
>>>> _______________________________________________
>>>> Apiman-user mailing list
>>>> Apiman-user at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/apiman-user
>>>>
>>>>
>>>
>>
>>
>> --
>> ---
>> *Celso Agra*
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20170202/b83bd0ad/attachment-0001.html 

From celso.agra at gmail.com  Thu Feb  2 21:28:50 2017
From: celso.agra at gmail.com (Celso Agra)
Date: Thu, 2 Feb 2017 23:28:50 -0300
Subject: [Apiman-user] How to change the URL location with URL Rewriting
	Policy
In-Reply-To: <CAP4n9Q-2j9TWvtazTznAf5-RZy3kurTf07zw-mYsBcXDPs38Ow@mail.gmail.com>
References: <CAOFYJDur-EBSi-zKKqFFPS3As3D7B6GhRzY=f-EAezp-=1voMw@mail.gmail.com>
	<CAP4n9Q8=Sgbd5xVm4uhjVMJ78VcggDjeofLcOt155ou8NQ84bQ@mail.gmail.com>
	<CAOFYJDsF3GYqjyys3ErwOiqkWfsv-Yhc=E3pWeq+tft80a-B1Q@mail.gmail.com>
	<CAP4n9Q_10g+=bheMKb4yBFUMUH6myKDhx61o+xw_JNe=8r6RMQ@mail.gmail.com>
	<CAP4n9Q-2j9TWvtazTznAf5-RZy3kurTf07zw-mYsBcXDPs38Ow@mail.gmail.com>
Message-ID: <CAOFYJDvohwS+WpR8pCxdaNmVCSjbb-F64d6bgBNejRsd3agPsA@mail.gmail.com>

Awesome!

I'll try that. Thanks, Eric!


2017-02-02 23:26 GMT-03:00 Eric Wittmann <eric.wittmann at redhat.com>:

> This property:
>
> https://github.com/apiman/apiman/blob/master/distro/
> wildfly9/src/main/resources/overlay/standalone/configuration/apiman.
> properties#L88
>
> -Eric
>
>
> On Thu, Feb 2, 2017 at 9:24 PM, Eric Wittmann <eric.wittmann at redhat.com>
> wrote:
>
>> There is a property defined in "apiman.properties" that you can change:
>>
>> apiman-gateway.connector-factory.http.followRedirects
>>
>> Change that property to "false" and try again. :)
>>
>> -Eric
>>
>> On Thu, Feb 2, 2017 at 7:04 PM, Celso Agra <celso.agra at gmail.com> wrote:
>>
>>> Yeah! The Apiman is following the redirect.
>>> If I do not use the apiman to invoke the http method, so, my system can
>>> redirect to another url (such as the location in browser); But If I use the
>>> apiman to invoke this method, so the location is not being changed
>>>
>>>
>>> 2017-02-02 19:19 GMT-03:00 Eric Wittmann <eric.wittmann at redhat.com>:
>>>
>>>> What is the behavior you are seeing?  It's possible that the apiman
>>>> gateway itself is following the redirect.  Is that what's happening?
>>>>
>>>> On Thu, Feb 2, 2017 at 4:23 PM, Celso Agra <celso.agra at gmail.com>
>>>> wrote:
>>>>
>>>>> All,
>>>>>
>>>>> I'm trying to change the location path in browser with my nodeJS
>>>>> application.
>>>>> For some reason, the apiman does not allow me to change that.
>>>>>
>>>>> So, I'm think to use the URL Rewriting Policy Configuration, but I'd
>>>>> like to understand how it works.
>>>>>
>>>>> Here's my nodeJS code:
>>>>>
>>>>> req.url = config.redirect_site;
>>>>> res.statusCode = 302;
>>>>> res.location(config.redirect_site);
>>>>> res.end();
>>>>>
>>>>>
>>>>> Without APIman it works fine! Does anyone know how can I set a
>>>>> different url with this policy or any other method in Apiman?
>>>>>
>>>>> Thanks!
>>>>>
>>>>> Best regards,
>>>>>
>>>>> --
>>>>> ---
>>>>> *Celso Agra*
>>>>>
>>>>> _______________________________________________
>>>>> Apiman-user mailing list
>>>>> Apiman-user at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/apiman-user
>>>>>
>>>>>
>>>>
>>>
>>>
>>> --
>>> ---
>>> *Celso Agra*
>>>
>>
>>
>


-- 
---
*Celso Agra*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20170202/e1a87486/attachment.html 

From sbalu27 at gmail.com  Fri Feb  3 04:50:40 2017
From: sbalu27 at gmail.com (Balu S)
Date: Fri, 3 Feb 2017 10:50:40 +0100
Subject: [Apiman-user] API policy response data handler
In-Reply-To: <CAP4n9Q-TzcZcoZx7_H0F_hvkhP+wAYeFz6Hyde=vC6H-eXJLow@mail.gmail.com>
References: <CAEDnbHAh2HPm5evojoR4H7E3Wv+frVEDyHkwuNp6-tin3tzAkA@mail.gmail.com>
	<CAA7j38+AU4HqeS_SkEVDZGB6JiZjpgFQgs=dnioAzad6-OcrMA@mail.gmail.com>
	<CAEDnbHDodcDtpWYoUS6kWRnS_hbZ=Ftt4dfmbFsKrLoKaZ6pBQ@mail.gmail.com>
	<CAA7j38J=DLUMF7YTnor2FTVDhpOOAvnq3YpxjfdCJC_-WxeB5w@mail.gmail.com>
	<CAA7j38+xmRdD75_Z2_gmWhejCsUFvwbsgftFW9Fq1PCXUbWyCg@mail.gmail.com>
	<CAP4n9Q-TzcZcoZx7_H0F_hvkhP+wAYeFz6Hyde=vC6H-eXJLow@mail.gmail.com>
Message-ID: <CAEDnbHCG530Jy8LkkrKP=S-sTB2DAG_VUi=YnhOSVSh=sEKrAQ@mail.gmail.com>

Thanks for your inputs.

Yes, I mean HTTP error codes (non-200) that are returned to client. For
example, when a request is missing query parameters and the API responds
with a "Bad request" (400) along with error XML. Here the error code is set
at HTTP level only and Apiman metrics should consider it as bad response
(in my opinion). Neither I do not see the Apiman source (HttpApiConnection)
interpreting the HTTP response using the HTTP code. But with the custom
policy, If I check for non-200 code and handle as failure, then metrics
shows them as error.

To clarify on my implementation with custom policy, I'm not trying to
change the HTTP error code based on the response, rather we are unpacking
the error response body and packing in different XML format as done by
Apiman. Is this not a valid scenario ? I think there could other scenarios
where one want to alter the response body. I agree there will be additional
cost to performance and memory, but can it be not done one demand basis
like how one can implement IDataPolicy to parse the response only if he
needs to.

Thanks
Balu





On Thu, Feb 2, 2017 at 10:31 PM, Eric Wittmann <eric.wittmann at redhat.com>
wrote:

> The bottom line here is that you cannot return a Policy Failure (or
> customize it) based on information in the response body.  The response is
> streamed from the back-end to the client, and at the time streaming begins,
> the response code and HTTP headers have already been sent.
>
> It sounds to me like you're asking for a feature where you can parse the
> response body *before* the policy's "apply" method is invoked.  We have
> such a feature for requests, but not for responses.  I suspect core changes
> to apiman would be required to enable that.  It seems like a reasonable
> request to me, as long as users of the feature understand the performance
> and memory requirements of enabling it.
>
> -Eric
>
>
> On Thu, Feb 2, 2017 at 1:03 PM, Marc Savy <marc.savy at redhat.com> wrote:
>
>> NB: This is distinct from the body you're setting which contains a
>> JSON/XML payload containing the error code. It's in the HTTP protocol
>> itself.
>>
>> On 2 February 2017 at 18:02, Marc Savy <marc.savy at redhat.com> wrote:
>>
>>> That sounds like metrics are going wrong, or perhaps you're
>>> misinterpreting it  (adding Eric).
>>>
>>> When you say your API returns an error, does it still return an
>>> appropriate non-200 error code at the HTTP level? For instance, 500 or
>>> similar? That's very important.
>>>
>>> There's a difference between an error and a failure - have you checked
>>> both of those fields to see whether they contain the information you're
>>> expecting to see.
>>>
>>> Certainly in my experience we *do* collect the metrics you're talking
>>> about, unless I'm misunderstanding you.
>>>
>>> On 2 February 2017 at 17:40, Balu S <sbalu27 at gmail.com> wrote:
>>>
>>>> Hi Marc,
>>>>
>>>> I shall explain my use case. From our API call, we return error
>>>> response (in XML or JSON)  for 401, 500 and so on. However, Apiman metrics
>>>> seems to just consider them as good response (it is, as Apiman received the
>>>> response back) and show as successful response. So I have made custom
>>>> policy to intercept the response to know if it is failure and trigger the
>>>> Policy Failure. This is fairly simple and straight forward as the response
>>>> code will just do the purpose. But I want also to add some additional
>>>> information about the failure to Policy Failure. This additional
>>>> information is in the original error response which will be lost once
>>>> doFailure() happens. And no we don't want to those additional information
>>>> in some HTTP headers to pass around. Hence I implemented responseHandler()
>>>> to handle the response buffer and like you pointed out, it seems to be too
>>>> late to meddle the response.
>>>>
>>>> So ideally, there are possible 2 solution
>>>>
>>>>    - Apiman metrics can interpret the response as unsuccessful for such
>>>> error response from API call.
>>>>    - Handle the response buffer data before the write() call to
>>>> response outputstream.
>>>>
>>>> Do you see any alternative solution?
>>>>
>>>> Thanks
>>>> Balu
>>>>
>>>> On Thu, Feb 2, 2017 at 6:15 PM, Marc Savy <marc.savy at redhat.com> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> Perhaps URLRewritingPolicy https://github.com/apiman/apim
>>>>> an/blob/master/gateway/engine/policies/src/main/java/io/apim
>>>>> an/gateway/engine/policies/URLRewritingPolicy.java be an informative
>>>>> place to start?
>>>>>
>>>>> - Apiman streams data, so the client may be receiving data already by
>>>>> the time you've determined you want to cancel (the connection is already
>>>>> established; headers have been sent) - it's often too late to gracefully
>>>>> cancel. You could try throwing an exception and seeing what happens (not
>>>>> recommended practice!).
>>>>>
>>>>> If that doesn't work, perhaps you can explain your use-case more
>>>>> clearly and explicitly so we can see what the alternatives are?
>>>>>
>>>>> - Policies are *static* instances, if you are assigning that buffer to
>>>>> the object then it's as if you were writing "static Buffer  buffer" and
>>>>> different requests will all share that variable (and thus swap it out
>>>>> repeatedly!).
>>>>>
>>>>> Regards,
>>>>> Marc
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 2 February 2017 at 16:56, Balu S <sbalu27 at gmail.com> wrote:
>>>>>
>>>>>> Hello,
>>>>>> I'm trying to parse the response using responseDataHandler() in the
>>>>>> custom policy. In cases, if the response from API is of certain content, I
>>>>>> would like the Apiman to consider as failure. But I don't find a way to
>>>>>> throw policy failure from responseDataHandler(). And I cannot achieve this
>>>>>> in doApply() as the ApiResponse object does not have "content" to parse.
>>>>>>
>>>>>> Also, what I found is write(chunk) in the AbstractStream is called
>>>>>> after doApply, so I cannot set any attributes in it to fetch it in
>>>>>> doApply() and trigger doFailure().
>>>>>>
>>>>>> For example, in below call, how to throw as policy failure after
>>>>>> parsing the contents ? Or how can I access response content even before
>>>>>> write() method.
>>>>>>
>>>>>>
>>>>>> *URLRewritingPolicy.java*
>>>>>>
>>>>>>     @Override
>>>>>>     protected IReadWriteStream<ApiResponse>
>>>>>> responseDataHandler(ApiResponse response,
>>>>>>             IPolicyContext context, URLRewritingConfig
>>>>>> policyConfiguration) {
>>>>>>         if (policyConfiguration.isProcessResponseBody()) {
>>>>>>             return new URLRewritingStream(context.get
>>>>>> Component(IBufferFactoryComponent.class), response,
>>>>>>                     policyConfiguration.getFromRegex(),
>>>>>> policyConfiguration.getToReplacement());
>>>>>>         } else {
>>>>>>             return null;
>>>>>>         }
>>>>>>     }
>>>>>>
>>>>>> *URLRewritingStream.java*
>>>>>>
>>>>>>     /**
>>>>>>      * @see io.apiman.gateway.engine.io.AbstractStream#write(io.
>>>>>> apiman.gateway.engine.io.IApimanBuffer)
>>>>>>      */
>>>>>>     @Override
>>>>>>     public void write(IApimanBuffer chunk) {
>>>>>>         if (buffer == null) {
>>>>>>             buffer = bufferFactory.cloneBuffer(chunk);
>>>>>>         } else {
>>>>>>             buffer.append(chunk);
>>>>>>         }
>>>>>>         atEnd = false;
>>>>>>         processBuffer();
>>>>>>     }
>>>>>>
>>>>>>
>>>>>> Best regards
>>>>>> Balu
>>>>>>
>>>>>> _______________________________________________
>>>>>> Apiman-user mailing list
>>>>>> Apiman-user at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/apiman-user
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20170203/ce7477a6/attachment-0001.html 

From sbalu27 at gmail.com  Fri Feb  3 05:27:17 2017
From: sbalu27 at gmail.com (Balu S)
Date: Fri, 3 Feb 2017 11:27:17 +0100
Subject: [Apiman-user] Logger exception
In-Reply-To: <CAA7j38J5AmtcjzT+-ST4aUB6HNiojEzVN0i2dW3b7skgdUOJMw@mail.gmail.com>
References: <CAEDnbHDmY=tTb+HO1VXQMqYcC42eje6zESs68bm1a20XYXdBsw@mail.gmail.com>
	<CAA7j38K8uDTB-0Uy355n6ka=EWvB-D4J0hkNUc8AyJwAsyp3rA@mail.gmail.com>
	<CAEDnbHDNfd0rRiuk7MqwBJdMxzM69bv=FeiP7-NRnxkhHMf9+w@mail.gmail.com>
	<CAA7j38J5AmtcjzT+-ST4aUB6HNiojEzVN0i2dW3b7skgdUOJMw@mail.gmail.com>
Message-ID: <CAEDnbHDTbXKADB6uPqPHT-G=8==SdK6i3Wnd3JstR3P-ozsm9A@mail.gmail.com>

Hi,

I have managed to build these 2 projects (apiman-common-logging-core and
/apiman-common-logging-slf4j) and add it as global jboss module to make
Apiman to use Slf4jLoggerFactory logger.

Does it not work out of box with just specifying Slf4jLoggerFactory in
apiman.properties?

On Tue, Jan 31, 2017 at 3:14 PM, Marc Savy <marc.savy at redhat.com> wrote:

> I'll try to look into it shortly and post back onto the ML.
>
> On 30 January 2017 at 16:16, Balu S <sbalu27 at gmail.com> wrote:
>
>> Hi Marc,
>> thanks for your quick response. Unfortunately it doesn't work.
>>
>> Although, what I am trying to achieve is to use "Slf4jLoggerFactory" and
>> it fails with same null pointer.
>>
>> 2017-01-30 17:12:59,911 ERROR [org.jboss.msc.service.fail] (ServerService
>> Thread Pool -- 64) MSC000001: Failed to start service
>> jboss.undertow.deployment.default-server.default-host./apiman-gateway:
>> org.jboss.msc.service.StartException in service
>> jboss.undertow.deployment.default-server.default-host./apiman-gateway:
>> java.lang.RuntimeException: java.lang.RuntimeException:
>> java.lang.NullPointerException
>> at org.wildfly.extension.undertow.deployment.UndertowDeployment
>> Service$1.run(UndertowDeploymentService.java:85)
>> at java.util.concurrent.Executors$RunnableAdapter.call(
>> Executors.java:511)
>> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPool
>> Executor.java:1142)
>> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoo
>> lExecutor.java:617)
>> at java.lang.Thread.run(Thread.java:745)
>> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
>> Caused by: java.lang.RuntimeException: java.lang.RuntimeException:
>> java.lang.NullPointerException
>> at io.undertow.servlet.core.DeploymentManagerImpl.deploy(Deploy
>> mentManagerImpl.java:236)
>> at org.wildfly.extension.undertow.deployment.UndertowDeployment
>> Service.startContext(UndertowDeploymentService.java:100)
>> at org.wildfly.extension.undertow.deployment.UndertowDeployment
>> Service$1.run(UndertowDeploymentService.java:82)
>> ... 6 more
>> Caused by: java.lang.RuntimeException: java.lang.NullPointerException
>> at io.apiman.gateway.engine.impl.ConfigDrivenEngineFactory.inst
>> antiate(ConfigDrivenEngineFactory.java:179)
>> at io.apiman.gateway.engine.impl.ConfigDrivenEngineFactory.crea
>> te(ConfigDrivenEngineFactory.java:163)
>> at io.apiman.gateway.engine.impl.ConfigDrivenEngineFactory.crea
>> teLoggerFactory(ConfigDrivenEngineFactory.java:152)
>> at io.apiman.gateway.engine.impl.AbstractEngineFactory.createEn
>> gine(AbstractEngineFactory.java:60)
>> at io.apiman.gateway.platforms.war.WarGateway.init(WarGateway.java:55)
>> at io.apiman.gateway.platforms.war.listeners.WarGatewayBootstra
>> pper.contextInitialized(WarGatewayBootstrapper.java:
>>
>> On Mon, Jan 30, 2017 at 5:07 PM, Marc Savy <marc.savy at redhat.com> wrote:
>>
>>> I think you want
>>> io.apiman.common.logging.DefaultDelegateFactory in that field rather
>>> than SystemOutLogger directly.
>>>
>>> Does that work?
>>>
>>> The name is probably confusing - it *was* the default one at some point.
>>>
>>>
>>>
>>> On 30 January 2017 at 15:57, Balu S <sbalu27 at gmail.com> wrote:
>>>
>>>> Hello,
>>>>
>>>> I'm trying to simply replace the NoOpLoggerFactory to SystemOutLogger
>>>> in apiman.properties and get below exception. It is quite strange as
>>>> SystemOutLogger  is infact implements IDelegateFactory.
>>>>
>>>> #apiman-gateway.logger-factory=io.apiman.common.logging.impl
>>>> .NoOpLoggerFactory
>>>> apiman-gateway.logger-factory=io.apiman.common.logging.impl.
>>>> SystemOutLogger
>>>>
>>>> Also, If I try to change to Slf4jLoggerFactory, then even
>>>> the Slf4jLoggerFactory.class is not found.
>>>>
>>>> Could you please advise if there is any reference to be added and
>>>> causes below error. Thanks
>>>>
>>>> .  Falling back to the Default. [No IDataEncrypter class configured.]
>>>> 16:50:52,028 ERROR [org.jboss.msc.service.fail] (ServerService Thread
>>>> Pool -- 69) MSC000001: Failed
>>>> to start service jboss.undertow.deployment.defa
>>>> ult-server.default-host./apiman-gateway-api: org.jbos
>>>> s.msc.service.StartException in service jboss.undertow.deployment.defa
>>>> ult-server.default-host./apima
>>>> n-gateway-api: java.lang.RuntimeException:
>>>> java.lang.ClassCastException: io.apiman.common.logging.impl.SystemOutLogger
>>>> cannot be cast to io.apiman.common.logging.IDelegateFactory
>>>>         at org.wildfly.extension.undertow.deployment.UndertowDeployment
>>>> Service$1.run(UndertowDeploym
>>>> entService.java:85)
>>>>         at java.util.concurrent.Executors$RunnableAdapter.call(Executor
>>>> s.java:511)
>>>>         at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>>>>         at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPool
>>>> Executor.java:1142)
>>>>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoo
>>>> lExecutor.java:617)
>>>>         at java.lang.Thread.run(Thread.java:745)
>>>>         at org.jboss.threads.JBossThread.run(JBossThread.java:320)
>>>> Caused by: java.lang.RuntimeException: java.lang.ClassCastException:
>>>> io.apiman.common.logging.impl.SystemOutLogger cannot be cast to
>>>> io.apiman.common.logging.IDelegateFactory
>>>>         at io.undertow.servlet.core.DeploymentManagerImpl.deploy(Deploy
>>>> mentManagerImpl.java:236)
>>>>         at org.wildfly.extension.undertow.deployment.UndertowDeployment
>>>> Service.startContext(Undertow
>>>> DeploymentService.java:100)
>>>>         at org.wildfly.extension.undertow.deployment.UndertowDeployment
>>>> Service$1.run(UndertowDeploym
>>>>
>>>>
>>>> regards
>>>> Balu
>>>>
>>>> _______________________________________________
>>>> Apiman-user mailing list
>>>> Apiman-user at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/apiman-user
>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20170203/072f05e7/attachment.html 

From marc.savy at redhat.com  Fri Feb  3 05:40:30 2017
From: marc.savy at redhat.com (Marc Savy)
Date: Fri, 3 Feb 2017 10:40:30 +0000
Subject: [Apiman-user] API policy response data handler
In-Reply-To: <CAEDnbHCG530Jy8LkkrKP=S-sTB2DAG_VUi=YnhOSVSh=sEKrAQ@mail.gmail.com>
References: <CAEDnbHAh2HPm5evojoR4H7E3Wv+frVEDyHkwuNp6-tin3tzAkA@mail.gmail.com>
	<CAA7j38+AU4HqeS_SkEVDZGB6JiZjpgFQgs=dnioAzad6-OcrMA@mail.gmail.com>
	<CAEDnbHDodcDtpWYoUS6kWRnS_hbZ=Ftt4dfmbFsKrLoKaZ6pBQ@mail.gmail.com>
	<CAA7j38J=DLUMF7YTnor2FTVDhpOOAvnq3YpxjfdCJC_-WxeB5w@mail.gmail.com>
	<CAA7j38+xmRdD75_Z2_gmWhejCsUFvwbsgftFW9Fq1PCXUbWyCg@mail.gmail.com>
	<CAP4n9Q-TzcZcoZx7_H0F_hvkhP+wAYeFz6Hyde=vC6H-eXJLow@mail.gmail.com>
	<CAEDnbHCG530Jy8LkkrKP=S-sTB2DAG_VUi=YnhOSVSh=sEKrAQ@mail.gmail.com>
Message-ID: <CAA7j38JGHgtt-ih3-t05jVFLLh8GUOYC0X2DKkKeY1FPt8R54A@mail.gmail.com>

Which metrics implementation are you using? The data you're talking about
should be in there; if it's not then there's a problem.


On 3 February 2017 at 09:50, Balu S <sbalu27 at gmail.com> wrote:

> Thanks for your inputs.
>
> Yes, I mean HTTP error codes (non-200) that are returned to client. For
> example, when a request is missing query parameters and the API responds
> with a "Bad request" (400) along with error XML. Here the error code is set
> at HTTP level only and Apiman metrics should consider it as bad response
> (in my opinion). Neither I do not see the Apiman source (HttpApiConnection)
> interpreting the HTTP response using the HTTP code. But with the custom
> policy, If I check for non-200 code and handle as failure, then metrics
> shows them as error.
>
> To clarify on my implementation with custom policy, I'm not trying to
> change the HTTP error code based on the response, rather we are unpacking
> the error response body and packing in different XML format as done by
> Apiman. Is this not a valid scenario ? I think there could other scenarios
> where one want to alter the response body. I agree there will be additional
> cost to performance and memory, but can it be not done one demand basis
> like how one can implement IDataPolicy to parse the response only if he
> needs to.
>
> Thanks
> Balu
>
>
>
>
>
> On Thu, Feb 2, 2017 at 10:31 PM, Eric Wittmann <eric.wittmann at redhat.com>
> wrote:
>
>> The bottom line here is that you cannot return a Policy Failure (or
>> customize it) based on information in the response body.  The response is
>> streamed from the back-end to the client, and at the time streaming begins,
>> the response code and HTTP headers have already been sent.
>>
>> It sounds to me like you're asking for a feature where you can parse the
>> response body *before* the policy's "apply" method is invoked.  We have
>> such a feature for requests, but not for responses.  I suspect core changes
>> to apiman would be required to enable that.  It seems like a reasonable
>> request to me, as long as users of the feature understand the performance
>> and memory requirements of enabling it.
>>
>> -Eric
>>
>>
>> On Thu, Feb 2, 2017 at 1:03 PM, Marc Savy <marc.savy at redhat.com> wrote:
>>
>>> NB: This is distinct from the body you're setting which contains a
>>> JSON/XML payload containing the error code. It's in the HTTP protocol
>>> itself.
>>>
>>> On 2 February 2017 at 18:02, Marc Savy <marc.savy at redhat.com> wrote:
>>>
>>>> That sounds like metrics are going wrong, or perhaps you're
>>>> misinterpreting it  (adding Eric).
>>>>
>>>> When you say your API returns an error, does it still return an
>>>> appropriate non-200 error code at the HTTP level? For instance, 500 or
>>>> similar? That's very important.
>>>>
>>>> There's a difference between an error and a failure - have you checked
>>>> both of those fields to see whether they contain the information you're
>>>> expecting to see.
>>>>
>>>> Certainly in my experience we *do* collect the metrics you're talking
>>>> about, unless I'm misunderstanding you.
>>>>
>>>> On 2 February 2017 at 17:40, Balu S <sbalu27 at gmail.com> wrote:
>>>>
>>>>> Hi Marc,
>>>>>
>>>>> I shall explain my use case. From our API call, we return error
>>>>> response (in XML or JSON)  for 401, 500 and so on. However, Apiman metrics
>>>>> seems to just consider them as good response (it is, as Apiman received the
>>>>> response back) and show as successful response. So I have made custom
>>>>> policy to intercept the response to know if it is failure and trigger the
>>>>> Policy Failure. This is fairly simple and straight forward as the response
>>>>> code will just do the purpose. But I want also to add some additional
>>>>> information about the failure to Policy Failure. This additional
>>>>> information is in the original error response which will be lost once
>>>>> doFailure() happens. And no we don't want to those additional information
>>>>> in some HTTP headers to pass around. Hence I implemented responseHandler()
>>>>> to handle the response buffer and like you pointed out, it seems to be too
>>>>> late to meddle the response.
>>>>>
>>>>> So ideally, there are possible 2 solution
>>>>>
>>>>>    - Apiman metrics can interpret the response as unsuccessful for
>>>>> such error response from API call.
>>>>>    - Handle the response buffer data before the write() call to
>>>>> response outputstream.
>>>>>
>>>>> Do you see any alternative solution?
>>>>>
>>>>> Thanks
>>>>> Balu
>>>>>
>>>>> On Thu, Feb 2, 2017 at 6:15 PM, Marc Savy <marc.savy at redhat.com>
>>>>> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> Perhaps URLRewritingPolicy https://github.com/apiman/apim
>>>>>> an/blob/master/gateway/engine/policies/src/main/java/io/apim
>>>>>> an/gateway/engine/policies/URLRewritingPolicy.java be an informative
>>>>>> place to start?
>>>>>>
>>>>>> - Apiman streams data, so the client may be receiving data already by
>>>>>> the time you've determined you want to cancel (the connection is already
>>>>>> established; headers have been sent) - it's often too late to gracefully
>>>>>> cancel. You could try throwing an exception and seeing what happens (not
>>>>>> recommended practice!).
>>>>>>
>>>>>> If that doesn't work, perhaps you can explain your use-case more
>>>>>> clearly and explicitly so we can see what the alternatives are?
>>>>>>
>>>>>> - Policies are *static* instances, if you are assigning that buffer
>>>>>> to the object then it's as if you were writing "static Buffer  buffer" and
>>>>>> different requests will all share that variable (and thus swap it out
>>>>>> repeatedly!).
>>>>>>
>>>>>> Regards,
>>>>>> Marc
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 2 February 2017 at 16:56, Balu S <sbalu27 at gmail.com> wrote:
>>>>>>
>>>>>>> Hello,
>>>>>>> I'm trying to parse the response using responseDataHandler() in the
>>>>>>> custom policy. In cases, if the response from API is of certain content, I
>>>>>>> would like the Apiman to consider as failure. But I don't find a way to
>>>>>>> throw policy failure from responseDataHandler(). And I cannot achieve this
>>>>>>> in doApply() as the ApiResponse object does not have "content" to parse.
>>>>>>>
>>>>>>> Also, what I found is write(chunk) in the AbstractStream is called
>>>>>>> after doApply, so I cannot set any attributes in it to fetch it in
>>>>>>> doApply() and trigger doFailure().
>>>>>>>
>>>>>>> For example, in below call, how to throw as policy failure after
>>>>>>> parsing the contents ? Or how can I access response content even before
>>>>>>> write() method.
>>>>>>>
>>>>>>>
>>>>>>> *URLRewritingPolicy.java*
>>>>>>>
>>>>>>>     @Override
>>>>>>>     protected IReadWriteStream<ApiResponse>
>>>>>>> responseDataHandler(ApiResponse response,
>>>>>>>             IPolicyContext context, URLRewritingConfig
>>>>>>> policyConfiguration) {
>>>>>>>         if (policyConfiguration.isProcessResponseBody()) {
>>>>>>>             return new URLRewritingStream(context.get
>>>>>>> Component(IBufferFactoryComponent.class), response,
>>>>>>>                     policyConfiguration.getFromRegex(),
>>>>>>> policyConfiguration.getToReplacement());
>>>>>>>         } else {
>>>>>>>             return null;
>>>>>>>         }
>>>>>>>     }
>>>>>>>
>>>>>>> *URLRewritingStream.java*
>>>>>>>
>>>>>>>     /**
>>>>>>>      * @see io.apiman.gateway.engine.io.AbstractStream#write(io.
>>>>>>> apiman.gateway.engine.io.IApimanBuffer)
>>>>>>>      */
>>>>>>>     @Override
>>>>>>>     public void write(IApimanBuffer chunk) {
>>>>>>>         if (buffer == null) {
>>>>>>>             buffer = bufferFactory.cloneBuffer(chunk);
>>>>>>>         } else {
>>>>>>>             buffer.append(chunk);
>>>>>>>         }
>>>>>>>         atEnd = false;
>>>>>>>         processBuffer();
>>>>>>>     }
>>>>>>>
>>>>>>>
>>>>>>> Best regards
>>>>>>> Balu
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Apiman-user mailing list
>>>>>>> Apiman-user at lists.jboss.org
>>>>>>> https://lists.jboss.org/mailman/listinfo/apiman-user
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20170203/6a72cfa7/attachment-0001.html 

From sbalu27 at gmail.com  Fri Feb  3 05:45:17 2017
From: sbalu27 at gmail.com (Balu S)
Date: Fri, 3 Feb 2017 11:45:17 +0100
Subject: [Apiman-user] API policy response data handler
In-Reply-To: <CAA7j38JGHgtt-ih3-t05jVFLLh8GUOYC0X2DKkKeY1FPt8R54A@mail.gmail.com>
References: <CAEDnbHAh2HPm5evojoR4H7E3Wv+frVEDyHkwuNp6-tin3tzAkA@mail.gmail.com>
	<CAA7j38+AU4HqeS_SkEVDZGB6JiZjpgFQgs=dnioAzad6-OcrMA@mail.gmail.com>
	<CAEDnbHDodcDtpWYoUS6kWRnS_hbZ=Ftt4dfmbFsKrLoKaZ6pBQ@mail.gmail.com>
	<CAA7j38J=DLUMF7YTnor2FTVDhpOOAvnq3YpxjfdCJC_-WxeB5w@mail.gmail.com>
	<CAA7j38+xmRdD75_Z2_gmWhejCsUFvwbsgftFW9Fq1PCXUbWyCg@mail.gmail.com>
	<CAP4n9Q-TzcZcoZx7_H0F_hvkhP+wAYeFz6Hyde=vC6H-eXJLow@mail.gmail.com>
	<CAEDnbHCG530Jy8LkkrKP=S-sTB2DAG_VUi=YnhOSVSh=sEKrAQ@mail.gmail.com>
	<CAA7j38JGHgtt-ih3-t05jVFLLh8GUOYC0X2DKkKeY1FPt8R54A@mail.gmail.com>
Message-ID: <CAEDnbHBsb2mGozHRHnry_ZekVQVkA8LdLQtzcC+N6-7NSvqfew@mail.gmail.com>

Its the default one ES.

# ---------------------------------------------------------------------
# Elasticsearch Metrics Settings
# ---------------------------------------------------------------------

apiman-gateway.metrics=io.apiman.gateway.engine.es.ESMetrics
apiman-gateway.metrics.client.type=jest
apiman-gateway.metrics.client.protocol=${apiman.es.protocol}
apiman-gateway.metrics.client.host=${apiman.es.host}
apiman-gateway.metrics.client.port=${apiman.es.port}
apiman-gateway.metrics.client.username=${apiman.es.username}
apiman-gateway.metrics.client.password=${apiman.es.password}
apiman-gateway.metrics.client.timeout=${apiman.es.timeout}
apiman-gateway.metrics.client.initialize=true

On Fri, Feb 3, 2017 at 11:40 AM, Marc Savy <marc.savy at redhat.com> wrote:

> Which metrics implementation are you using? The data you're talking about
> should be in there; if it's not then there's a problem.
>
>
> On 3 February 2017 at 09:50, Balu S <sbalu27 at gmail.com> wrote:
>
>> Thanks for your inputs.
>>
>> Yes, I mean HTTP error codes (non-200) that are returned to client. For
>> example, when a request is missing query parameters and the API responds
>> with a "Bad request" (400) along with error XML. Here the error code is set
>> at HTTP level only and Apiman metrics should consider it as bad response
>> (in my opinion). Neither I do not see the Apiman source (HttpApiConnection)
>> interpreting the HTTP response using the HTTP code. But with the custom
>> policy, If I check for non-200 code and handle as failure, then metrics
>> shows them as error.
>>
>> To clarify on my implementation with custom policy, I'm not trying to
>> change the HTTP error code based on the response, rather we are unpacking
>> the error response body and packing in different XML format as done by
>> Apiman. Is this not a valid scenario ? I think there could other scenarios
>> where one want to alter the response body. I agree there will be additional
>> cost to performance and memory, but can it be not done one demand basis
>> like how one can implement IDataPolicy to parse the response only if he
>> needs to.
>>
>> Thanks
>> Balu
>>
>>
>>
>>
>>
>> On Thu, Feb 2, 2017 at 10:31 PM, Eric Wittmann <eric.wittmann at redhat.com>
>> wrote:
>>
>>> The bottom line here is that you cannot return a Policy Failure (or
>>> customize it) based on information in the response body.  The response is
>>> streamed from the back-end to the client, and at the time streaming begins,
>>> the response code and HTTP headers have already been sent.
>>>
>>> It sounds to me like you're asking for a feature where you can parse the
>>> response body *before* the policy's "apply" method is invoked.  We have
>>> such a feature for requests, but not for responses.  I suspect core changes
>>> to apiman would be required to enable that.  It seems like a reasonable
>>> request to me, as long as users of the feature understand the performance
>>> and memory requirements of enabling it.
>>>
>>> -Eric
>>>
>>>
>>> On Thu, Feb 2, 2017 at 1:03 PM, Marc Savy <marc.savy at redhat.com> wrote:
>>>
>>>> NB: This is distinct from the body you're setting which contains a
>>>> JSON/XML payload containing the error code. It's in the HTTP protocol
>>>> itself.
>>>>
>>>> On 2 February 2017 at 18:02, Marc Savy <marc.savy at redhat.com> wrote:
>>>>
>>>>> That sounds like metrics are going wrong, or perhaps you're
>>>>> misinterpreting it  (adding Eric).
>>>>>
>>>>> When you say your API returns an error, does it still return an
>>>>> appropriate non-200 error code at the HTTP level? For instance, 500 or
>>>>> similar? That's very important.
>>>>>
>>>>> There's a difference between an error and a failure - have you checked
>>>>> both of those fields to see whether they contain the information you're
>>>>> expecting to see.
>>>>>
>>>>> Certainly in my experience we *do* collect the metrics you're talking
>>>>> about, unless I'm misunderstanding you.
>>>>>
>>>>> On 2 February 2017 at 17:40, Balu S <sbalu27 at gmail.com> wrote:
>>>>>
>>>>>> Hi Marc,
>>>>>>
>>>>>> I shall explain my use case. From our API call, we return error
>>>>>> response (in XML or JSON)  for 401, 500 and so on. However, Apiman metrics
>>>>>> seems to just consider them as good response (it is, as Apiman received the
>>>>>> response back) and show as successful response. So I have made custom
>>>>>> policy to intercept the response to know if it is failure and trigger the
>>>>>> Policy Failure. This is fairly simple and straight forward as the response
>>>>>> code will just do the purpose. But I want also to add some additional
>>>>>> information about the failure to Policy Failure. This additional
>>>>>> information is in the original error response which will be lost once
>>>>>> doFailure() happens. And no we don't want to those additional information
>>>>>> in some HTTP headers to pass around. Hence I implemented responseHandler()
>>>>>> to handle the response buffer and like you pointed out, it seems to be too
>>>>>> late to meddle the response.
>>>>>>
>>>>>> So ideally, there are possible 2 solution
>>>>>>
>>>>>>    - Apiman metrics can interpret the response as unsuccessful for
>>>>>> such error response from API call.
>>>>>>    - Handle the response buffer data before the write() call to
>>>>>> response outputstream.
>>>>>>
>>>>>> Do you see any alternative solution?
>>>>>>
>>>>>> Thanks
>>>>>> Balu
>>>>>>
>>>>>> On Thu, Feb 2, 2017 at 6:15 PM, Marc Savy <marc.savy at redhat.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> Perhaps URLRewritingPolicy https://github.com/apiman/apim
>>>>>>> an/blob/master/gateway/engine/policies/src/main/java/io/apim
>>>>>>> an/gateway/engine/policies/URLRewritingPolicy.java be an
>>>>>>> informative place to start?
>>>>>>>
>>>>>>> - Apiman streams data, so the client may be receiving data already
>>>>>>> by the time you've determined you want to cancel (the connection is already
>>>>>>> established; headers have been sent) - it's often too late to gracefully
>>>>>>> cancel. You could try throwing an exception and seeing what happens (not
>>>>>>> recommended practice!).
>>>>>>>
>>>>>>> If that doesn't work, perhaps you can explain your use-case more
>>>>>>> clearly and explicitly so we can see what the alternatives are?
>>>>>>>
>>>>>>> - Policies are *static* instances, if you are assigning that buffer
>>>>>>> to the object then it's as if you were writing "static Buffer  buffer" and
>>>>>>> different requests will all share that variable (and thus swap it out
>>>>>>> repeatedly!).
>>>>>>>
>>>>>>> Regards,
>>>>>>> Marc
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 2 February 2017 at 16:56, Balu S <sbalu27 at gmail.com> wrote:
>>>>>>>
>>>>>>>> Hello,
>>>>>>>> I'm trying to parse the response using responseDataHandler() in the
>>>>>>>> custom policy. In cases, if the response from API is of certain content, I
>>>>>>>> would like the Apiman to consider as failure. But I don't find a way to
>>>>>>>> throw policy failure from responseDataHandler(). And I cannot achieve this
>>>>>>>> in doApply() as the ApiResponse object does not have "content" to parse.
>>>>>>>>
>>>>>>>> Also, what I found is write(chunk) in the AbstractStream is called
>>>>>>>> after doApply, so I cannot set any attributes in it to fetch it in
>>>>>>>> doApply() and trigger doFailure().
>>>>>>>>
>>>>>>>> For example, in below call, how to throw as policy failure after
>>>>>>>> parsing the contents ? Or how can I access response content even before
>>>>>>>> write() method.
>>>>>>>>
>>>>>>>>
>>>>>>>> *URLRewritingPolicy.java*
>>>>>>>>
>>>>>>>>     @Override
>>>>>>>>     protected IReadWriteStream<ApiResponse>
>>>>>>>> responseDataHandler(ApiResponse response,
>>>>>>>>             IPolicyContext context, URLRewritingConfig
>>>>>>>> policyConfiguration) {
>>>>>>>>         if (policyConfiguration.isProcessResponseBody()) {
>>>>>>>>             return new URLRewritingStream(context.get
>>>>>>>> Component(IBufferFactoryComponent.class), response,
>>>>>>>>                     policyConfiguration.getFromRegex(),
>>>>>>>> policyConfiguration.getToReplacement());
>>>>>>>>         } else {
>>>>>>>>             return null;
>>>>>>>>         }
>>>>>>>>     }
>>>>>>>>
>>>>>>>> *URLRewritingStream.java*
>>>>>>>>
>>>>>>>>     /**
>>>>>>>>      * @see io.apiman.gateway.engine.io.AbstractStream#write(io.
>>>>>>>> apiman.gateway.engine.io.IApimanBuffer)
>>>>>>>>      */
>>>>>>>>     @Override
>>>>>>>>     public void write(IApimanBuffer chunk) {
>>>>>>>>         if (buffer == null) {
>>>>>>>>             buffer = bufferFactory.cloneBuffer(chunk);
>>>>>>>>         } else {
>>>>>>>>             buffer.append(chunk);
>>>>>>>>         }
>>>>>>>>         atEnd = false;
>>>>>>>>         processBuffer();
>>>>>>>>     }
>>>>>>>>
>>>>>>>>
>>>>>>>> Best regards
>>>>>>>> Balu
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Apiman-user mailing list
>>>>>>>> Apiman-user at lists.jboss.org
>>>>>>>> https://lists.jboss.org/mailman/listinfo/apiman-user
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20170203/9b974353/attachment.html 

From marc.savy at redhat.com  Fri Feb  3 06:21:52 2017
From: marc.savy at redhat.com (Marc Savy)
Date: Fri, 3 Feb 2017 11:21:52 +0000
Subject: [Apiman-user] API policy response data handler
In-Reply-To: <CAEDnbHBsb2mGozHRHnry_ZekVQVkA8LdLQtzcC+N6-7NSvqfew@mail.gmail.com>
References: <CAEDnbHAh2HPm5evojoR4H7E3Wv+frVEDyHkwuNp6-tin3tzAkA@mail.gmail.com>
	<CAA7j38+AU4HqeS_SkEVDZGB6JiZjpgFQgs=dnioAzad6-OcrMA@mail.gmail.com>
	<CAEDnbHDodcDtpWYoUS6kWRnS_hbZ=Ftt4dfmbFsKrLoKaZ6pBQ@mail.gmail.com>
	<CAA7j38J=DLUMF7YTnor2FTVDhpOOAvnq3YpxjfdCJC_-WxeB5w@mail.gmail.com>
	<CAA7j38+xmRdD75_Z2_gmWhejCsUFvwbsgftFW9Fq1PCXUbWyCg@mail.gmail.com>
	<CAP4n9Q-TzcZcoZx7_H0F_hvkhP+wAYeFz6Hyde=vC6H-eXJLow@mail.gmail.com>
	<CAEDnbHCG530Jy8LkkrKP=S-sTB2DAG_VUi=YnhOSVSh=sEKrAQ@mail.gmail.com>
	<CAA7j38JGHgtt-ih3-t05jVFLLh8GUOYC0X2DKkKeY1FPt8R54A@mail.gmail.com>
	<CAEDnbHBsb2mGozHRHnry_ZekVQVkA8LdLQtzcC+N6-7NSvqfew@mail.gmail.com>
Message-ID: <CAA7j38+Tfj3Sc2aH=o52ePLrqKHW=GtkGnWHmzXtT_1-A6DbZA@mail.gmail.com>

I think I understand what you're asking.

IIRC:

Error = an exception occurred within the gateway (e.g. could not connect to
backend).
Failure = a policy failure occurred.


If you're wanting to look at http exception codes, just look at the
'responseCode' field in the ES Metrics.

If you're wanting a "failed/not failed" determination then perhaps just
execute `responseCode/100 == 2` in your analysis? Or is this not possible
in your use-case?

On 3 February 2017 at 10:45, Balu S <sbalu27 at gmail.com> wrote:

> Its the default one ES.
>
> # ---------------------------------------------------------------------
> # Elasticsearch Metrics Settings
> # ---------------------------------------------------------------------
>
> apiman-gateway.metrics=io.apiman.gateway.engine.es.ESMetrics
> apiman-gateway.metrics.client.type=jest
> apiman-gateway.metrics.client.protocol=${apiman.es.protocol}
> apiman-gateway.metrics.client.host=${apiman.es.host}
> apiman-gateway.metrics.client.port=${apiman.es.port}
> apiman-gateway.metrics.client.username=${apiman.es.username}
> apiman-gateway.metrics.client.password=${apiman.es.password}
> apiman-gateway.metrics.client.timeout=${apiman.es.timeout}
> apiman-gateway.metrics.client.initialize=true
>
> On Fri, Feb 3, 2017 at 11:40 AM, Marc Savy <marc.savy at redhat.com> wrote:
>
>> Which metrics implementation are you using? The data you're talking about
>> should be in there; if it's not then there's a problem.
>>
>>
>> On 3 February 2017 at 09:50, Balu S <sbalu27 at gmail.com> wrote:
>>
>>> Thanks for your inputs.
>>>
>>> Yes, I mean HTTP error codes (non-200) that are returned to client. For
>>> example, when a request is missing query parameters and the API responds
>>> with a "Bad request" (400) along with error XML. Here the error code is set
>>> at HTTP level only and Apiman metrics should consider it as bad response
>>> (in my opinion). Neither I do not see the Apiman source (HttpApiConnection)
>>> interpreting the HTTP response using the HTTP code. But with the custom
>>> policy, If I check for non-200 code and handle as failure, then metrics
>>> shows them as error.
>>>
>>> To clarify on my implementation with custom policy, I'm not trying to
>>> change the HTTP error code based on the response, rather we are unpacking
>>> the error response body and packing in different XML format as done by
>>> Apiman. Is this not a valid scenario ? I think there could other scenarios
>>> where one want to alter the response body. I agree there will be additional
>>> cost to performance and memory, but can it be not done one demand basis
>>> like how one can implement IDataPolicy to parse the response only if he
>>> needs to.
>>>
>>> Thanks
>>> Balu
>>>
>>>
>>>
>>>
>>>
>>> On Thu, Feb 2, 2017 at 10:31 PM, Eric Wittmann <eric.wittmann at redhat.com
>>> > wrote:
>>>
>>>> The bottom line here is that you cannot return a Policy Failure (or
>>>> customize it) based on information in the response body.  The response is
>>>> streamed from the back-end to the client, and at the time streaming begins,
>>>> the response code and HTTP headers have already been sent.
>>>>
>>>> It sounds to me like you're asking for a feature where you can parse
>>>> the response body *before* the policy's "apply" method is invoked.  We have
>>>> such a feature for requests, but not for responses.  I suspect core changes
>>>> to apiman would be required to enable that.  It seems like a reasonable
>>>> request to me, as long as users of the feature understand the performance
>>>> and memory requirements of enabling it.
>>>>
>>>> -Eric
>>>>
>>>>
>>>> On Thu, Feb 2, 2017 at 1:03 PM, Marc Savy <marc.savy at redhat.com> wrote:
>>>>
>>>>> NB: This is distinct from the body you're setting which contains a
>>>>> JSON/XML payload containing the error code. It's in the HTTP protocol
>>>>> itself.
>>>>>
>>>>> On 2 February 2017 at 18:02, Marc Savy <marc.savy at redhat.com> wrote:
>>>>>
>>>>>> That sounds like metrics are going wrong, or perhaps you're
>>>>>> misinterpreting it  (adding Eric).
>>>>>>
>>>>>> When you say your API returns an error, does it still return an
>>>>>> appropriate non-200 error code at the HTTP level? For instance, 500 or
>>>>>> similar? That's very important.
>>>>>>
>>>>>> There's a difference between an error and a failure - have you
>>>>>> checked both of those fields to see whether they contain the information
>>>>>> you're expecting to see.
>>>>>>
>>>>>> Certainly in my experience we *do* collect the metrics you're talking
>>>>>> about, unless I'm misunderstanding you.
>>>>>>
>>>>>> On 2 February 2017 at 17:40, Balu S <sbalu27 at gmail.com> wrote:
>>>>>>
>>>>>>> Hi Marc,
>>>>>>>
>>>>>>> I shall explain my use case. From our API call, we return error
>>>>>>> response (in XML or JSON)  for 401, 500 and so on. However, Apiman metrics
>>>>>>> seems to just consider them as good response (it is, as Apiman received the
>>>>>>> response back) and show as successful response. So I have made custom
>>>>>>> policy to intercept the response to know if it is failure and trigger the
>>>>>>> Policy Failure. This is fairly simple and straight forward as the response
>>>>>>> code will just do the purpose. But I want also to add some additional
>>>>>>> information about the failure to Policy Failure. This additional
>>>>>>> information is in the original error response which will be lost once
>>>>>>> doFailure() happens. And no we don't want to those additional information
>>>>>>> in some HTTP headers to pass around. Hence I implemented responseHandler()
>>>>>>> to handle the response buffer and like you pointed out, it seems to be too
>>>>>>> late to meddle the response.
>>>>>>>
>>>>>>> So ideally, there are possible 2 solution
>>>>>>>
>>>>>>>    - Apiman metrics can interpret the response as unsuccessful for
>>>>>>> such error response from API call.
>>>>>>>    - Handle the response buffer data before the write() call to
>>>>>>> response outputstream.
>>>>>>>
>>>>>>> Do you see any alternative solution?
>>>>>>>
>>>>>>> Thanks
>>>>>>> Balu
>>>>>>>
>>>>>>> On Thu, Feb 2, 2017 at 6:15 PM, Marc Savy <marc.savy at redhat.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> Perhaps URLRewritingPolicy https://github.com/apiman/apim
>>>>>>>> an/blob/master/gateway/engine/policies/src/main/java/io/apim
>>>>>>>> an/gateway/engine/policies/URLRewritingPolicy.java be an
>>>>>>>> informative place to start?
>>>>>>>>
>>>>>>>> - Apiman streams data, so the client may be receiving data already
>>>>>>>> by the time you've determined you want to cancel (the connection is already
>>>>>>>> established; headers have been sent) - it's often too late to gracefully
>>>>>>>> cancel. You could try throwing an exception and seeing what happens (not
>>>>>>>> recommended practice!).
>>>>>>>>
>>>>>>>> If that doesn't work, perhaps you can explain your use-case more
>>>>>>>> clearly and explicitly so we can see what the alternatives are?
>>>>>>>>
>>>>>>>> - Policies are *static* instances, if you are assigning that buffer
>>>>>>>> to the object then it's as if you were writing "static Buffer  buffer" and
>>>>>>>> different requests will all share that variable (and thus swap it out
>>>>>>>> repeatedly!).
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Marc
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 2 February 2017 at 16:56, Balu S <sbalu27 at gmail.com> wrote:
>>>>>>>>
>>>>>>>>> Hello,
>>>>>>>>> I'm trying to parse the response using responseDataHandler() in
>>>>>>>>> the custom policy. In cases, if the response from API is of certain
>>>>>>>>> content, I would like the Apiman to consider as failure. But I don't find a
>>>>>>>>> way to throw policy failure from responseDataHandler(). And I cannot
>>>>>>>>> achieve this in doApply() as the ApiResponse object does not have "content"
>>>>>>>>> to parse.
>>>>>>>>>
>>>>>>>>> Also, what I found is write(chunk) in the AbstractStream is called
>>>>>>>>> after doApply, so I cannot set any attributes in it to fetch it in
>>>>>>>>> doApply() and trigger doFailure().
>>>>>>>>>
>>>>>>>>> For example, in below call, how to throw as policy failure after
>>>>>>>>> parsing the contents ? Or how can I access response content even before
>>>>>>>>> write() method.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> *URLRewritingPolicy.java*
>>>>>>>>>
>>>>>>>>>     @Override
>>>>>>>>>     protected IReadWriteStream<ApiResponse>
>>>>>>>>> responseDataHandler(ApiResponse response,
>>>>>>>>>             IPolicyContext context, URLRewritingConfig
>>>>>>>>> policyConfiguration) {
>>>>>>>>>         if (policyConfiguration.isProcessResponseBody()) {
>>>>>>>>>             return new URLRewritingStream(context.get
>>>>>>>>> Component(IBufferFactoryComponent.class), response,
>>>>>>>>>                     policyConfiguration.getFromRegex(),
>>>>>>>>> policyConfiguration.getToReplacement());
>>>>>>>>>         } else {
>>>>>>>>>             return null;
>>>>>>>>>         }
>>>>>>>>>     }
>>>>>>>>>
>>>>>>>>> *URLRewritingStream.java*
>>>>>>>>>
>>>>>>>>>     /**
>>>>>>>>>      * @see io.apiman.gateway.engine.io.AbstractStream#write(io.
>>>>>>>>> apiman.gateway.engine.io.IApimanBuffer)
>>>>>>>>>      */
>>>>>>>>>     @Override
>>>>>>>>>     public void write(IApimanBuffer chunk) {
>>>>>>>>>         if (buffer == null) {
>>>>>>>>>             buffer = bufferFactory.cloneBuffer(chunk);
>>>>>>>>>         } else {
>>>>>>>>>             buffer.append(chunk);
>>>>>>>>>         }
>>>>>>>>>         atEnd = false;
>>>>>>>>>         processBuffer();
>>>>>>>>>     }
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Best regards
>>>>>>>>> Balu
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> Apiman-user mailing list
>>>>>>>>> Apiman-user at lists.jboss.org
>>>>>>>>> https://lists.jboss.org/mailman/listinfo/apiman-user
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20170203/0aad649e/attachment-0001.html 

From sbalu27 at gmail.com  Fri Feb  3 06:38:00 2017
From: sbalu27 at gmail.com (Balu S)
Date: Fri, 3 Feb 2017 12:38:00 +0100
Subject: [Apiman-user] API policy response data handler
In-Reply-To: <CAA7j38+Tfj3Sc2aH=o52ePLrqKHW=GtkGnWHmzXtT_1-A6DbZA@mail.gmail.com>
References: <CAEDnbHAh2HPm5evojoR4H7E3Wv+frVEDyHkwuNp6-tin3tzAkA@mail.gmail.com>
	<CAA7j38+AU4HqeS_SkEVDZGB6JiZjpgFQgs=dnioAzad6-OcrMA@mail.gmail.com>
	<CAEDnbHDodcDtpWYoUS6kWRnS_hbZ=Ftt4dfmbFsKrLoKaZ6pBQ@mail.gmail.com>
	<CAA7j38J=DLUMF7YTnor2FTVDhpOOAvnq3YpxjfdCJC_-WxeB5w@mail.gmail.com>
	<CAA7j38+xmRdD75_Z2_gmWhejCsUFvwbsgftFW9Fq1PCXUbWyCg@mail.gmail.com>
	<CAP4n9Q-TzcZcoZx7_H0F_hvkhP+wAYeFz6Hyde=vC6H-eXJLow@mail.gmail.com>
	<CAEDnbHCG530Jy8LkkrKP=S-sTB2DAG_VUi=YnhOSVSh=sEKrAQ@mail.gmail.com>
	<CAA7j38JGHgtt-ih3-t05jVFLLh8GUOYC0X2DKkKeY1FPt8R54A@mail.gmail.com>
	<CAEDnbHBsb2mGozHRHnry_ZekVQVkA8LdLQtzcC+N6-7NSvqfew@mail.gmail.com>
	<CAA7j38+Tfj3Sc2aH=o52ePLrqKHW=GtkGnWHmzXtT_1-A6DbZA@mail.gmail.com>
Message-ID: <CAEDnbHAH=QwK06J75JJW5JBSVKY24YEZt_C9YxqrJnJ4KTmwOQ@mail.gmail.com>

sorry, I don't understand what you wrote.

I would like Apiman metrics to consider the HTTP response (>=400) as
failure/error (whatever that is appropriate) and indicate in below charts.



[image: Inline image 1]

On Fri, Feb 3, 2017 at 12:21 PM, Marc Savy <marc.savy at redhat.com> wrote:

> I think I understand what you're asking.
>
> IIRC:
>
> Error = an exception occurred within the gateway (e.g. could not connect
> to backend).
> Failure = a policy failure occurred.
>
>
> If you're wanting to look at http exception codes, just look at the
> 'responseCode' field in the ES Metrics.
>
> If you're wanting a "failed/not failed" determination then perhaps just
> execute `responseCode/100 == 2` in your analysis? Or is this not possible
> in your use-case?
>
> On 3 February 2017 at 10:45, Balu S <sbalu27 at gmail.com> wrote:
>
>> Its the default one ES.
>>
>> # ---------------------------------------------------------------------
>> # Elasticsearch Metrics Settings
>> # ---------------------------------------------------------------------
>>
>> apiman-gateway.metrics=io.apiman.gateway.engine.es.ESMetrics
>> apiman-gateway.metrics.client.type=jest
>> apiman-gateway.metrics.client.protocol=${apiman.es.protocol}
>> apiman-gateway.metrics.client.host=${apiman.es.host}
>> apiman-gateway.metrics.client.port=${apiman.es.port}
>> apiman-gateway.metrics.client.username=${apiman.es.username}
>> apiman-gateway.metrics.client.password=${apiman.es.password}
>> apiman-gateway.metrics.client.timeout=${apiman.es.timeout}
>> apiman-gateway.metrics.client.initialize=true
>>
>> On Fri, Feb 3, 2017 at 11:40 AM, Marc Savy <marc.savy at redhat.com> wrote:
>>
>>> Which metrics implementation are you using? The data you're talking
>>> about should be in there; if it's not then there's a problem.
>>>
>>>
>>> On 3 February 2017 at 09:50, Balu S <sbalu27 at gmail.com> wrote:
>>>
>>>> Thanks for your inputs.
>>>>
>>>> Yes, I mean HTTP error codes (non-200) that are returned to client. For
>>>> example, when a request is missing query parameters and the API responds
>>>> with a "Bad request" (400) along with error XML. Here the error code is set
>>>> at HTTP level only and Apiman metrics should consider it as bad response
>>>> (in my opinion). Neither I do not see the Apiman source (HttpApiConnection)
>>>> interpreting the HTTP response using the HTTP code. But with the custom
>>>> policy, If I check for non-200 code and handle as failure, then metrics
>>>> shows them as error.
>>>>
>>>> To clarify on my implementation with custom policy, I'm not trying to
>>>> change the HTTP error code based on the response, rather we are unpacking
>>>> the error response body and packing in different XML format as done by
>>>> Apiman. Is this not a valid scenario ? I think there could other scenarios
>>>> where one want to alter the response body. I agree there will be additional
>>>> cost to performance and memory, but can it be not done one demand basis
>>>> like how one can implement IDataPolicy to parse the response only if he
>>>> needs to.
>>>>
>>>> Thanks
>>>> Balu
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Thu, Feb 2, 2017 at 10:31 PM, Eric Wittmann <
>>>> eric.wittmann at redhat.com> wrote:
>>>>
>>>>> The bottom line here is that you cannot return a Policy Failure (or
>>>>> customize it) based on information in the response body.  The response is
>>>>> streamed from the back-end to the client, and at the time streaming begins,
>>>>> the response code and HTTP headers have already been sent.
>>>>>
>>>>> It sounds to me like you're asking for a feature where you can parse
>>>>> the response body *before* the policy's "apply" method is invoked.  We have
>>>>> such a feature for requests, but not for responses.  I suspect core changes
>>>>> to apiman would be required to enable that.  It seems like a reasonable
>>>>> request to me, as long as users of the feature understand the performance
>>>>> and memory requirements of enabling it.
>>>>>
>>>>> -Eric
>>>>>
>>>>>
>>>>> On Thu, Feb 2, 2017 at 1:03 PM, Marc Savy <marc.savy at redhat.com>
>>>>> wrote:
>>>>>
>>>>>> NB: This is distinct from the body you're setting which contains a
>>>>>> JSON/XML payload containing the error code. It's in the HTTP protocol
>>>>>> itself.
>>>>>>
>>>>>> On 2 February 2017 at 18:02, Marc Savy <marc.savy at redhat.com> wrote:
>>>>>>
>>>>>>> That sounds like metrics are going wrong, or perhaps you're
>>>>>>> misinterpreting it  (adding Eric).
>>>>>>>
>>>>>>> When you say your API returns an error, does it still return an
>>>>>>> appropriate non-200 error code at the HTTP level? For instance, 500 or
>>>>>>> similar? That's very important.
>>>>>>>
>>>>>>> There's a difference between an error and a failure - have you
>>>>>>> checked both of those fields to see whether they contain the information
>>>>>>> you're expecting to see.
>>>>>>>
>>>>>>> Certainly in my experience we *do* collect the metrics you're
>>>>>>> talking about, unless I'm misunderstanding you.
>>>>>>>
>>>>>>> On 2 February 2017 at 17:40, Balu S <sbalu27 at gmail.com> wrote:
>>>>>>>
>>>>>>>> Hi Marc,
>>>>>>>>
>>>>>>>> I shall explain my use case. From our API call, we return error
>>>>>>>> response (in XML or JSON)  for 401, 500 and so on. However, Apiman metrics
>>>>>>>> seems to just consider them as good response (it is, as Apiman received the
>>>>>>>> response back) and show as successful response. So I have made custom
>>>>>>>> policy to intercept the response to know if it is failure and trigger the
>>>>>>>> Policy Failure. This is fairly simple and straight forward as the response
>>>>>>>> code will just do the purpose. But I want also to add some additional
>>>>>>>> information about the failure to Policy Failure. This additional
>>>>>>>> information is in the original error response which will be lost once
>>>>>>>> doFailure() happens. And no we don't want to those additional information
>>>>>>>> in some HTTP headers to pass around. Hence I implemented responseHandler()
>>>>>>>> to handle the response buffer and like you pointed out, it seems to be too
>>>>>>>> late to meddle the response.
>>>>>>>>
>>>>>>>> So ideally, there are possible 2 solution
>>>>>>>>
>>>>>>>>    - Apiman metrics can interpret the response as unsuccessful for
>>>>>>>> such error response from API call.
>>>>>>>>    - Handle the response buffer data before the write() call to
>>>>>>>> response outputstream.
>>>>>>>>
>>>>>>>> Do you see any alternative solution?
>>>>>>>>
>>>>>>>> Thanks
>>>>>>>> Balu
>>>>>>>>
>>>>>>>> On Thu, Feb 2, 2017 at 6:15 PM, Marc Savy <marc.savy at redhat.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> Perhaps URLRewritingPolicy https://github.com/apiman/apim
>>>>>>>>> an/blob/master/gateway/engine/policies/src/main/java/io/apim
>>>>>>>>> an/gateway/engine/policies/URLRewritingPolicy.java be an
>>>>>>>>> informative place to start?
>>>>>>>>>
>>>>>>>>> - Apiman streams data, so the client may be receiving data already
>>>>>>>>> by the time you've determined you want to cancel (the connection is already
>>>>>>>>> established; headers have been sent) - it's often too late to gracefully
>>>>>>>>> cancel. You could try throwing an exception and seeing what happens (not
>>>>>>>>> recommended practice!).
>>>>>>>>>
>>>>>>>>> If that doesn't work, perhaps you can explain your use-case more
>>>>>>>>> clearly and explicitly so we can see what the alternatives are?
>>>>>>>>>
>>>>>>>>> - Policies are *static* instances, if you are assigning that
>>>>>>>>> buffer to the object then it's as if you were writing "static Buffer
>>>>>>>>>  buffer" and different requests will all share that variable (and thus swap
>>>>>>>>> it out repeatedly!).
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>> Marc
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 2 February 2017 at 16:56, Balu S <sbalu27 at gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>> Hello,
>>>>>>>>>> I'm trying to parse the response using responseDataHandler() in
>>>>>>>>>> the custom policy. In cases, if the response from API is of certain
>>>>>>>>>> content, I would like the Apiman to consider as failure. But I don't find a
>>>>>>>>>> way to throw policy failure from responseDataHandler(). And I cannot
>>>>>>>>>> achieve this in doApply() as the ApiResponse object does not have "content"
>>>>>>>>>> to parse.
>>>>>>>>>>
>>>>>>>>>> Also, what I found is write(chunk) in the AbstractStream is
>>>>>>>>>> called after doApply, so I cannot set any attributes in it to fetch it in
>>>>>>>>>> doApply() and trigger doFailure().
>>>>>>>>>>
>>>>>>>>>> For example, in below call, how to throw as policy failure after
>>>>>>>>>> parsing the contents ? Or how can I access response content even before
>>>>>>>>>> write() method.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> *URLRewritingPolicy.java*
>>>>>>>>>>
>>>>>>>>>>     @Override
>>>>>>>>>>     protected IReadWriteStream<ApiResponse>
>>>>>>>>>> responseDataHandler(ApiResponse response,
>>>>>>>>>>             IPolicyContext context, URLRewritingConfig
>>>>>>>>>> policyConfiguration) {
>>>>>>>>>>         if (policyConfiguration.isProcessResponseBody()) {
>>>>>>>>>>             return new URLRewritingStream(context.get
>>>>>>>>>> Component(IBufferFactoryComponent.class), response,
>>>>>>>>>>                     policyConfiguration.getFromRegex(),
>>>>>>>>>> policyConfiguration.getToReplacement());
>>>>>>>>>>         } else {
>>>>>>>>>>             return null;
>>>>>>>>>>         }
>>>>>>>>>>     }
>>>>>>>>>>
>>>>>>>>>> *URLRewritingStream.java*
>>>>>>>>>>
>>>>>>>>>>     /**
>>>>>>>>>>      * @see io.apiman.gateway.engine.io.AbstractStream#write(io.
>>>>>>>>>> apiman.gateway.engine.io.IApimanBuffer)
>>>>>>>>>>      */
>>>>>>>>>>     @Override
>>>>>>>>>>     public void write(IApimanBuffer chunk) {
>>>>>>>>>>         if (buffer == null) {
>>>>>>>>>>             buffer = bufferFactory.cloneBuffer(chunk);
>>>>>>>>>>         } else {
>>>>>>>>>>             buffer.append(chunk);
>>>>>>>>>>         }
>>>>>>>>>>         atEnd = false;
>>>>>>>>>>         processBuffer();
>>>>>>>>>>     }
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Best regards
>>>>>>>>>> Balu
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> Apiman-user mailing list
>>>>>>>>>> Apiman-user at lists.jboss.org
>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/apiman-user
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20170203/2b485b29/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 54197 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/apiman-user/attachments/20170203/2b485b29/attachment-0001.png 

From marc.savy at redhat.com  Fri Feb  3 06:48:00 2017
From: marc.savy at redhat.com (Marc Savy)
Date: Fri, 3 Feb 2017 11:48:00 +0000
Subject: [Apiman-user] API policy response data handler
In-Reply-To: <CAEDnbHAH=QwK06J75JJW5JBSVKY24YEZt_C9YxqrJnJ4KTmwOQ@mail.gmail.com>
References: <CAEDnbHAh2HPm5evojoR4H7E3Wv+frVEDyHkwuNp6-tin3tzAkA@mail.gmail.com>
	<CAA7j38+AU4HqeS_SkEVDZGB6JiZjpgFQgs=dnioAzad6-OcrMA@mail.gmail.com>
	<CAEDnbHDodcDtpWYoUS6kWRnS_hbZ=Ftt4dfmbFsKrLoKaZ6pBQ@mail.gmail.com>
	<CAA7j38J=DLUMF7YTnor2FTVDhpOOAvnq3YpxjfdCJC_-WxeB5w@mail.gmail.com>
	<CAA7j38+xmRdD75_Z2_gmWhejCsUFvwbsgftFW9Fq1PCXUbWyCg@mail.gmail.com>
	<CAP4n9Q-TzcZcoZx7_H0F_hvkhP+wAYeFz6Hyde=vC6H-eXJLow@mail.gmail.com>
	<CAEDnbHCG530Jy8LkkrKP=S-sTB2DAG_VUi=YnhOSVSh=sEKrAQ@mail.gmail.com>
	<CAA7j38JGHgtt-ih3-t05jVFLLh8GUOYC0X2DKkKeY1FPt8R54A@mail.gmail.com>
	<CAEDnbHBsb2mGozHRHnry_ZekVQVkA8LdLQtzcC+N6-7NSvqfew@mail.gmail.com>
	<CAA7j38+Tfj3Sc2aH=o52ePLrqKHW=GtkGnWHmzXtT_1-A6DbZA@mail.gmail.com>
	<CAEDnbHAH=QwK06J75JJW5JBSVKY24YEZt_C9YxqrJnJ4KTmwOQ@mail.gmail.com>
Message-ID: <CAA7j38+iwrU-rN5TBLtjvpC0kmrLhsZDRskiM2QFJ-cetPW_3w@mail.gmail.com>

Aha, you're specifically talking about the apiman UI - I had thought from
the context that you were using an external tool like Grafana.

I'll let Eric respond as he implemented that code.

On 3 February 2017 at 11:38, Balu S <sbalu27 at gmail.com> wrote:

> sorry, I don't understand what you wrote.
>
> I would like Apiman metrics to consider the HTTP response (>=400) as
> failure/error (whatever that is appropriate) and indicate in below charts.
>
>
>
> [image: Inline image 1]
>
> On Fri, Feb 3, 2017 at 12:21 PM, Marc Savy <marc.savy at redhat.com> wrote:
>
>> I think I understand what you're asking.
>>
>> IIRC:
>>
>> Error = an exception occurred within the gateway (e.g. could not connect
>> to backend).
>> Failure = a policy failure occurred.
>>
>>
>> If you're wanting to look at http exception codes, just look at the
>> 'responseCode' field in the ES Metrics.
>>
>> If you're wanting a "failed/not failed" determination then perhaps just
>> execute `responseCode/100 == 2` in your analysis? Or is this not possible
>> in your use-case?
>>
>> On 3 February 2017 at 10:45, Balu S <sbalu27 at gmail.com> wrote:
>>
>>> Its the default one ES.
>>>
>>> # ---------------------------------------------------------------------
>>> # Elasticsearch Metrics Settings
>>> # ---------------------------------------------------------------------
>>>
>>> apiman-gateway.metrics=io.apiman.gateway.engine.es.ESMetrics
>>> apiman-gateway.metrics.client.type=jest
>>> apiman-gateway.metrics.client.protocol=${apiman.es.protocol}
>>> apiman-gateway.metrics.client.host=${apiman.es.host}
>>> apiman-gateway.metrics.client.port=${apiman.es.port}
>>> apiman-gateway.metrics.client.username=${apiman.es.username}
>>> apiman-gateway.metrics.client.password=${apiman.es.password}
>>> apiman-gateway.metrics.client.timeout=${apiman.es.timeout}
>>> apiman-gateway.metrics.client.initialize=true
>>>
>>> On Fri, Feb 3, 2017 at 11:40 AM, Marc Savy <marc.savy at redhat.com> wrote:
>>>
>>>> Which metrics implementation are you using? The data you're talking
>>>> about should be in there; if it's not then there's a problem.
>>>>
>>>>
>>>> On 3 February 2017 at 09:50, Balu S <sbalu27 at gmail.com> wrote:
>>>>
>>>>> Thanks for your inputs.
>>>>>
>>>>> Yes, I mean HTTP error codes (non-200) that are returned to client.
>>>>> For example, when a request is missing query parameters and the API
>>>>> responds with a "Bad request" (400) along with error XML. Here the error
>>>>> code is set at HTTP level only and Apiman metrics should consider it as bad
>>>>> response (in my opinion). Neither I do not see the Apiman source
>>>>> (HttpApiConnection) interpreting the HTTP response using the HTTP code. But
>>>>> with the custom policy, If I check for non-200 code and handle as failure,
>>>>> then metrics shows them as error.
>>>>>
>>>>> To clarify on my implementation with custom policy, I'm not trying to
>>>>> change the HTTP error code based on the response, rather we are unpacking
>>>>> the error response body and packing in different XML format as done by
>>>>> Apiman. Is this not a valid scenario ? I think there could other scenarios
>>>>> where one want to alter the response body. I agree there will be additional
>>>>> cost to performance and memory, but can it be not done one demand basis
>>>>> like how one can implement IDataPolicy to parse the response only if he
>>>>> needs to.
>>>>>
>>>>> Thanks
>>>>> Balu
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Thu, Feb 2, 2017 at 10:31 PM, Eric Wittmann <
>>>>> eric.wittmann at redhat.com> wrote:
>>>>>
>>>>>> The bottom line here is that you cannot return a Policy Failure (or
>>>>>> customize it) based on information in the response body.  The response is
>>>>>> streamed from the back-end to the client, and at the time streaming begins,
>>>>>> the response code and HTTP headers have already been sent.
>>>>>>
>>>>>> It sounds to me like you're asking for a feature where you can parse
>>>>>> the response body *before* the policy's "apply" method is invoked.  We have
>>>>>> such a feature for requests, but not for responses.  I suspect core changes
>>>>>> to apiman would be required to enable that.  It seems like a reasonable
>>>>>> request to me, as long as users of the feature understand the performance
>>>>>> and memory requirements of enabling it.
>>>>>>
>>>>>> -Eric
>>>>>>
>>>>>>
>>>>>> On Thu, Feb 2, 2017 at 1:03 PM, Marc Savy <marc.savy at redhat.com>
>>>>>> wrote:
>>>>>>
>>>>>>> NB: This is distinct from the body you're setting which contains a
>>>>>>> JSON/XML payload containing the error code. It's in the HTTP protocol
>>>>>>> itself.
>>>>>>>
>>>>>>> On 2 February 2017 at 18:02, Marc Savy <marc.savy at redhat.com> wrote:
>>>>>>>
>>>>>>>> That sounds like metrics are going wrong, or perhaps you're
>>>>>>>> misinterpreting it  (adding Eric).
>>>>>>>>
>>>>>>>> When you say your API returns an error, does it still return an
>>>>>>>> appropriate non-200 error code at the HTTP level? For instance, 500 or
>>>>>>>> similar? That's very important.
>>>>>>>>
>>>>>>>> There's a difference between an error and a failure - have you
>>>>>>>> checked both of those fields to see whether they contain the information
>>>>>>>> you're expecting to see.
>>>>>>>>
>>>>>>>> Certainly in my experience we *do* collect the metrics you're
>>>>>>>> talking about, unless I'm misunderstanding you.
>>>>>>>>
>>>>>>>> On 2 February 2017 at 17:40, Balu S <sbalu27 at gmail.com> wrote:
>>>>>>>>
>>>>>>>>> Hi Marc,
>>>>>>>>>
>>>>>>>>> I shall explain my use case. From our API call, we return error
>>>>>>>>> response (in XML or JSON)  for 401, 500 and so on. However, Apiman metrics
>>>>>>>>> seems to just consider them as good response (it is, as Apiman received the
>>>>>>>>> response back) and show as successful response. So I have made custom
>>>>>>>>> policy to intercept the response to know if it is failure and trigger the
>>>>>>>>> Policy Failure. This is fairly simple and straight forward as the response
>>>>>>>>> code will just do the purpose. But I want also to add some additional
>>>>>>>>> information about the failure to Policy Failure. This additional
>>>>>>>>> information is in the original error response which will be lost once
>>>>>>>>> doFailure() happens. And no we don't want to those additional information
>>>>>>>>> in some HTTP headers to pass around. Hence I implemented responseHandler()
>>>>>>>>> to handle the response buffer and like you pointed out, it seems to be too
>>>>>>>>> late to meddle the response.
>>>>>>>>>
>>>>>>>>> So ideally, there are possible 2 solution
>>>>>>>>>
>>>>>>>>>    - Apiman metrics can interpret the response as unsuccessful for
>>>>>>>>> such error response from API call.
>>>>>>>>>    - Handle the response buffer data before the write() call to
>>>>>>>>> response outputstream.
>>>>>>>>>
>>>>>>>>> Do you see any alternative solution?
>>>>>>>>>
>>>>>>>>> Thanks
>>>>>>>>> Balu
>>>>>>>>>
>>>>>>>>> On Thu, Feb 2, 2017 at 6:15 PM, Marc Savy <marc.savy at redhat.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> Perhaps URLRewritingPolicy https://github.com/apiman/apim
>>>>>>>>>> an/blob/master/gateway/engine/policies/src/main/java/io/apim
>>>>>>>>>> an/gateway/engine/policies/URLRewritingPolicy.java be an
>>>>>>>>>> informative place to start?
>>>>>>>>>>
>>>>>>>>>> - Apiman streams data, so the client may be receiving data
>>>>>>>>>> already by the time you've determined you want to cancel (the connection is
>>>>>>>>>> already established; headers have been sent) - it's often too late to
>>>>>>>>>> gracefully cancel. You could try throwing an exception and seeing what
>>>>>>>>>> happens (not recommended practice!).
>>>>>>>>>>
>>>>>>>>>> If that doesn't work, perhaps you can explain your use-case more
>>>>>>>>>> clearly and explicitly so we can see what the alternatives are?
>>>>>>>>>>
>>>>>>>>>> - Policies are *static* instances, if you are assigning that
>>>>>>>>>> buffer to the object then it's as if you were writing "static Buffer
>>>>>>>>>>  buffer" and different requests will all share that variable (and thus swap
>>>>>>>>>> it out repeatedly!).
>>>>>>>>>>
>>>>>>>>>> Regards,
>>>>>>>>>> Marc
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 2 February 2017 at 16:56, Balu S <sbalu27 at gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> Hello,
>>>>>>>>>>> I'm trying to parse the response using responseDataHandler() in
>>>>>>>>>>> the custom policy. In cases, if the response from API is of certain
>>>>>>>>>>> content, I would like the Apiman to consider as failure. But I don't find a
>>>>>>>>>>> way to throw policy failure from responseDataHandler(). And I cannot
>>>>>>>>>>> achieve this in doApply() as the ApiResponse object does not have "content"
>>>>>>>>>>> to parse.
>>>>>>>>>>>
>>>>>>>>>>> Also, what I found is write(chunk) in the AbstractStream is
>>>>>>>>>>> called after doApply, so I cannot set any attributes in it to fetch it in
>>>>>>>>>>> doApply() and trigger doFailure().
>>>>>>>>>>>
>>>>>>>>>>> For example, in below call, how to throw as policy failure after
>>>>>>>>>>> parsing the contents ? Or how can I access response content even before
>>>>>>>>>>> write() method.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> *URLRewritingPolicy.java*
>>>>>>>>>>>
>>>>>>>>>>>     @Override
>>>>>>>>>>>     protected IReadWriteStream<ApiResponse>
>>>>>>>>>>> responseDataHandler(ApiResponse response,
>>>>>>>>>>>             IPolicyContext context, URLRewritingConfig
>>>>>>>>>>> policyConfiguration) {
>>>>>>>>>>>         if (policyConfiguration.isProcessResponseBody()) {
>>>>>>>>>>>             return new URLRewritingStream(context.get
>>>>>>>>>>> Component(IBufferFactoryComponent.class), response,
>>>>>>>>>>>                     policyConfiguration.getFromRegex(),
>>>>>>>>>>> policyConfiguration.getToReplacement());
>>>>>>>>>>>         } else {
>>>>>>>>>>>             return null;
>>>>>>>>>>>         }
>>>>>>>>>>>     }
>>>>>>>>>>>
>>>>>>>>>>> *URLRewritingStream.java*
>>>>>>>>>>>
>>>>>>>>>>>     /**
>>>>>>>>>>>      * @see io.apiman.gateway.engine.io.AbstractStream#write(io.
>>>>>>>>>>> apiman.gateway.engine.io.IApimanBuffer)
>>>>>>>>>>>      */
>>>>>>>>>>>     @Override
>>>>>>>>>>>     public void write(IApimanBuffer chunk) {
>>>>>>>>>>>         if (buffer == null) {
>>>>>>>>>>>             buffer = bufferFactory.cloneBuffer(chunk);
>>>>>>>>>>>         } else {
>>>>>>>>>>>             buffer.append(chunk);
>>>>>>>>>>>         }
>>>>>>>>>>>         atEnd = false;
>>>>>>>>>>>         processBuffer();
>>>>>>>>>>>     }
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Best regards
>>>>>>>>>>> Balu
>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> Apiman-user mailing list
>>>>>>>>>>> Apiman-user at lists.jboss.org
>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/apiman-user
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20170203/306f9c05/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 54197 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/apiman-user/attachments/20170203/306f9c05/attachment-0001.png 

From eric.wittmann at redhat.com  Fri Feb  3 16:31:56 2017
From: eric.wittmann at redhat.com (Eric Wittmann)
Date: Fri, 3 Feb 2017 16:31:56 -0500
Subject: [Apiman-user] API policy response data handler
In-Reply-To: <CAA7j38+iwrU-rN5TBLtjvpC0kmrLhsZDRskiM2QFJ-cetPW_3w@mail.gmail.com>
References: <CAEDnbHAh2HPm5evojoR4H7E3Wv+frVEDyHkwuNp6-tin3tzAkA@mail.gmail.com>
	<CAA7j38+AU4HqeS_SkEVDZGB6JiZjpgFQgs=dnioAzad6-OcrMA@mail.gmail.com>
	<CAEDnbHDodcDtpWYoUS6kWRnS_hbZ=Ftt4dfmbFsKrLoKaZ6pBQ@mail.gmail.com>
	<CAA7j38J=DLUMF7YTnor2FTVDhpOOAvnq3YpxjfdCJC_-WxeB5w@mail.gmail.com>
	<CAA7j38+xmRdD75_Z2_gmWhejCsUFvwbsgftFW9Fq1PCXUbWyCg@mail.gmail.com>
	<CAP4n9Q-TzcZcoZx7_H0F_hvkhP+wAYeFz6Hyde=vC6H-eXJLow@mail.gmail.com>
	<CAEDnbHCG530Jy8LkkrKP=S-sTB2DAG_VUi=YnhOSVSh=sEKrAQ@mail.gmail.com>
	<CAA7j38JGHgtt-ih3-t05jVFLLh8GUOYC0X2DKkKeY1FPt8R54A@mail.gmail.com>
	<CAEDnbHBsb2mGozHRHnry_ZekVQVkA8LdLQtzcC+N6-7NSvqfew@mail.gmail.com>
	<CAA7j38+Tfj3Sc2aH=o52ePLrqKHW=GtkGnWHmzXtT_1-A6DbZA@mail.gmail.com>
	<CAEDnbHAH=QwK06J75JJW5JBSVKY24YEZt_C9YxqrJnJ4KTmwOQ@mail.gmail.com>
	<CAA7j38+iwrU-rN5TBLtjvpC0kmrLhsZDRskiM2QFJ-cetPW_3w@mail.gmail.com>
Message-ID: <CAP4n9Q-+tWhBHFb=+F5HzhnsEcY3kRqpEsUfky0rrDug=5qLfQ@mail.gmail.com>

So I think at least one aspect of this is solvable.  You can modify the
request metric data directly in a custom policy.  You can access and modify
the request metric like this:

{code}
    protected void doApply(ApiResponse response, IPolicyContext context, C
config, IPolicyChain<ApiResponse> chain) {
     RequestMetric metric = context.getAttribute("apiman.request-metric",
null);
    metric.setFailure(true);
    metric.setFailureCode(12345);
    metric.setFailureReason("Backend API failed for a reason!"";
        chain.doApply(response);
    }
{code}

That will allow you to make sure the metrics information is correct for
your use-case.  The policy context (and thus the request metric object) is
also available to data policies:

https://github.com/apiman/apiman/blob/master/gateway/engine/core/src/main/java/io/apiman/gateway/engine/policy/IDataPolicy.java#L53-L54

Does that make sense?  Is there more to your use-case?

-Eric


On Fri, Feb 3, 2017 at 6:48 AM, Marc Savy <marc.savy at redhat.com> wrote:

> Aha, you're specifically talking about the apiman UI - I had thought from
> the context that you were using an external tool like Grafana.
>
> I'll let Eric respond as he implemented that code.
>
> On 3 February 2017 at 11:38, Balu S <sbalu27 at gmail.com> wrote:
>
>> sorry, I don't understand what you wrote.
>>
>> I would like Apiman metrics to consider the HTTP response (>=400) as
>> failure/error (whatever that is appropriate) and indicate in below charts.
>>
>>
>>
>> [image: Inline image 1]
>>
>> On Fri, Feb 3, 2017 at 12:21 PM, Marc Savy <marc.savy at redhat.com> wrote:
>>
>>> I think I understand what you're asking.
>>>
>>> IIRC:
>>>
>>> Error = an exception occurred within the gateway (e.g. could not connect
>>> to backend).
>>> Failure = a policy failure occurred.
>>>
>>>
>>> If you're wanting to look at http exception codes, just look at the
>>> 'responseCode' field in the ES Metrics.
>>>
>>> If you're wanting a "failed/not failed" determination then perhaps just
>>> execute `responseCode/100 == 2` in your analysis? Or is this not possible
>>> in your use-case?
>>>
>>> On 3 February 2017 at 10:45, Balu S <sbalu27 at gmail.com> wrote:
>>>
>>>> Its the default one ES.
>>>>
>>>> # ---------------------------------------------------------------------
>>>> # Elasticsearch Metrics Settings
>>>> # ---------------------------------------------------------------------
>>>>
>>>> apiman-gateway.metrics=io.apiman.gateway.engine.es.ESMetrics
>>>> apiman-gateway.metrics.client.type=jest
>>>> apiman-gateway.metrics.client.protocol=${apiman.es.protocol}
>>>> apiman-gateway.metrics.client.host=${apiman.es.host}
>>>> apiman-gateway.metrics.client.port=${apiman.es.port}
>>>> apiman-gateway.metrics.client.username=${apiman.es.username}
>>>> apiman-gateway.metrics.client.password=${apiman.es.password}
>>>> apiman-gateway.metrics.client.timeout=${apiman.es.timeout}
>>>> apiman-gateway.metrics.client.initialize=true
>>>>
>>>> On Fri, Feb 3, 2017 at 11:40 AM, Marc Savy <marc.savy at redhat.com>
>>>> wrote:
>>>>
>>>>> Which metrics implementation are you using? The data you're talking
>>>>> about should be in there; if it's not then there's a problem.
>>>>>
>>>>>
>>>>> On 3 February 2017 at 09:50, Balu S <sbalu27 at gmail.com> wrote:
>>>>>
>>>>>> Thanks for your inputs.
>>>>>>
>>>>>> Yes, I mean HTTP error codes (non-200) that are returned to client.
>>>>>> For example, when a request is missing query parameters and the API
>>>>>> responds with a "Bad request" (400) along with error XML. Here the error
>>>>>> code is set at HTTP level only and Apiman metrics should consider it as bad
>>>>>> response (in my opinion). Neither I do not see the Apiman source
>>>>>> (HttpApiConnection) interpreting the HTTP response using the HTTP code. But
>>>>>> with the custom policy, If I check for non-200 code and handle as failure,
>>>>>> then metrics shows them as error.
>>>>>>
>>>>>> To clarify on my implementation with custom policy, I'm not trying to
>>>>>> change the HTTP error code based on the response, rather we are unpacking
>>>>>> the error response body and packing in different XML format as done by
>>>>>> Apiman. Is this not a valid scenario ? I think there could other scenarios
>>>>>> where one want to alter the response body. I agree there will be additional
>>>>>> cost to performance and memory, but can it be not done one demand basis
>>>>>> like how one can implement IDataPolicy to parse the response only if he
>>>>>> needs to.
>>>>>>
>>>>>> Thanks
>>>>>> Balu
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Thu, Feb 2, 2017 at 10:31 PM, Eric Wittmann <
>>>>>> eric.wittmann at redhat.com> wrote:
>>>>>>
>>>>>>> The bottom line here is that you cannot return a Policy Failure (or
>>>>>>> customize it) based on information in the response body.  The response is
>>>>>>> streamed from the back-end to the client, and at the time streaming begins,
>>>>>>> the response code and HTTP headers have already been sent.
>>>>>>>
>>>>>>> It sounds to me like you're asking for a feature where you can parse
>>>>>>> the response body *before* the policy's "apply" method is invoked.  We have
>>>>>>> such a feature for requests, but not for responses.  I suspect core changes
>>>>>>> to apiman would be required to enable that.  It seems like a reasonable
>>>>>>> request to me, as long as users of the feature understand the performance
>>>>>>> and memory requirements of enabling it.
>>>>>>>
>>>>>>> -Eric
>>>>>>>
>>>>>>>
>>>>>>> On Thu, Feb 2, 2017 at 1:03 PM, Marc Savy <marc.savy at redhat.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> NB: This is distinct from the body you're setting which contains a
>>>>>>>> JSON/XML payload containing the error code. It's in the HTTP protocol
>>>>>>>> itself.
>>>>>>>>
>>>>>>>> On 2 February 2017 at 18:02, Marc Savy <marc.savy at redhat.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> That sounds like metrics are going wrong, or perhaps you're
>>>>>>>>> misinterpreting it  (adding Eric).
>>>>>>>>>
>>>>>>>>> When you say your API returns an error, does it still return an
>>>>>>>>> appropriate non-200 error code at the HTTP level? For instance, 500 or
>>>>>>>>> similar? That's very important.
>>>>>>>>>
>>>>>>>>> There's a difference between an error and a failure - have you
>>>>>>>>> checked both of those fields to see whether they contain the information
>>>>>>>>> you're expecting to see.
>>>>>>>>>
>>>>>>>>> Certainly in my experience we *do* collect the metrics you're
>>>>>>>>> talking about, unless I'm misunderstanding you.
>>>>>>>>>
>>>>>>>>> On 2 February 2017 at 17:40, Balu S <sbalu27 at gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>> Hi Marc,
>>>>>>>>>>
>>>>>>>>>> I shall explain my use case. From our API call, we return error
>>>>>>>>>> response (in XML or JSON)  for 401, 500 and so on. However, Apiman metrics
>>>>>>>>>> seems to just consider them as good response (it is, as Apiman received the
>>>>>>>>>> response back) and show as successful response. So I have made custom
>>>>>>>>>> policy to intercept the response to know if it is failure and trigger the
>>>>>>>>>> Policy Failure. This is fairly simple and straight forward as the response
>>>>>>>>>> code will just do the purpose. But I want also to add some additional
>>>>>>>>>> information about the failure to Policy Failure. This additional
>>>>>>>>>> information is in the original error response which will be lost once
>>>>>>>>>> doFailure() happens. And no we don't want to those additional information
>>>>>>>>>> in some HTTP headers to pass around. Hence I implemented responseHandler()
>>>>>>>>>> to handle the response buffer and like you pointed out, it seems to be too
>>>>>>>>>> late to meddle the response.
>>>>>>>>>>
>>>>>>>>>> So ideally, there are possible 2 solution
>>>>>>>>>>
>>>>>>>>>>    - Apiman metrics can interpret the response as unsuccessful
>>>>>>>>>> for such error response from API call.
>>>>>>>>>>    - Handle the response buffer data before the write() call to
>>>>>>>>>> response outputstream.
>>>>>>>>>>
>>>>>>>>>> Do you see any alternative solution?
>>>>>>>>>>
>>>>>>>>>> Thanks
>>>>>>>>>> Balu
>>>>>>>>>>
>>>>>>>>>> On Thu, Feb 2, 2017 at 6:15 PM, Marc Savy <marc.savy at redhat.com>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>> Perhaps URLRewritingPolicy https://github.com/apiman/apim
>>>>>>>>>>> an/blob/master/gateway/engine/policies/src/main/java/io/apim
>>>>>>>>>>> an/gateway/engine/policies/URLRewritingPolicy.java be an
>>>>>>>>>>> informative place to start?
>>>>>>>>>>>
>>>>>>>>>>> - Apiman streams data, so the client may be receiving data
>>>>>>>>>>> already by the time you've determined you want to cancel (the connection is
>>>>>>>>>>> already established; headers have been sent) - it's often too late to
>>>>>>>>>>> gracefully cancel. You could try throwing an exception and seeing what
>>>>>>>>>>> happens (not recommended practice!).
>>>>>>>>>>>
>>>>>>>>>>> If that doesn't work, perhaps you can explain your use-case more
>>>>>>>>>>> clearly and explicitly so we can see what the alternatives are?
>>>>>>>>>>>
>>>>>>>>>>> - Policies are *static* instances, if you are assigning that
>>>>>>>>>>> buffer to the object then it's as if you were writing "static Buffer
>>>>>>>>>>>  buffer" and different requests will all share that variable (and thus swap
>>>>>>>>>>> it out repeatedly!).
>>>>>>>>>>>
>>>>>>>>>>> Regards,
>>>>>>>>>>> Marc
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 2 February 2017 at 16:56, Balu S <sbalu27 at gmail.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Hello,
>>>>>>>>>>>> I'm trying to parse the response using responseDataHandler() in
>>>>>>>>>>>> the custom policy. In cases, if the response from API is of certain
>>>>>>>>>>>> content, I would like the Apiman to consider as failure. But I don't find a
>>>>>>>>>>>> way to throw policy failure from responseDataHandler(). And I cannot
>>>>>>>>>>>> achieve this in doApply() as the ApiResponse object does not have "content"
>>>>>>>>>>>> to parse.
>>>>>>>>>>>>
>>>>>>>>>>>> Also, what I found is write(chunk) in the AbstractStream is
>>>>>>>>>>>> called after doApply, so I cannot set any attributes in it to fetch it in
>>>>>>>>>>>> doApply() and trigger doFailure().
>>>>>>>>>>>>
>>>>>>>>>>>> For example, in below call, how to throw as policy failure
>>>>>>>>>>>> after parsing the contents ? Or how can I access response content even
>>>>>>>>>>>> before write() method.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> *URLRewritingPolicy.java*
>>>>>>>>>>>>
>>>>>>>>>>>>     @Override
>>>>>>>>>>>>     protected IReadWriteStream<ApiResponse>
>>>>>>>>>>>> responseDataHandler(ApiResponse response,
>>>>>>>>>>>>             IPolicyContext context, URLRewritingConfig
>>>>>>>>>>>> policyConfiguration) {
>>>>>>>>>>>>         if (policyConfiguration.isProcessResponseBody()) {
>>>>>>>>>>>>             return new URLRewritingStream(context.get
>>>>>>>>>>>> Component(IBufferFactoryComponent.class), response,
>>>>>>>>>>>>                     policyConfiguration.getFromRegex(),
>>>>>>>>>>>> policyConfiguration.getToReplacement());
>>>>>>>>>>>>         } else {
>>>>>>>>>>>>             return null;
>>>>>>>>>>>>         }
>>>>>>>>>>>>     }
>>>>>>>>>>>>
>>>>>>>>>>>> *URLRewritingStream.java*
>>>>>>>>>>>>
>>>>>>>>>>>>     /**
>>>>>>>>>>>>      * @see io.apiman.gateway.engine.io.Ab
>>>>>>>>>>>> stractStream#write(io.apiman.gateway.engine.io.IApimanBuffer)
>>>>>>>>>>>>      */
>>>>>>>>>>>>     @Override
>>>>>>>>>>>>     public void write(IApimanBuffer chunk) {
>>>>>>>>>>>>         if (buffer == null) {
>>>>>>>>>>>>             buffer = bufferFactory.cloneBuffer(chunk);
>>>>>>>>>>>>         } else {
>>>>>>>>>>>>             buffer.append(chunk);
>>>>>>>>>>>>         }
>>>>>>>>>>>>         atEnd = false;
>>>>>>>>>>>>         processBuffer();
>>>>>>>>>>>>     }
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Best regards
>>>>>>>>>>>> Balu
>>>>>>>>>>>>
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> Apiman-user mailing list
>>>>>>>>>>>> Apiman-user at lists.jboss.org
>>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/apiman-user
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20170203/13d49f1a/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 54197 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/apiman-user/attachments/20170203/13d49f1a/attachment-0001.png 

From sbalu27 at gmail.com  Sat Feb  4 15:00:40 2017
From: sbalu27 at gmail.com (Balu S)
Date: Sat, 4 Feb 2017 21:00:40 +0100
Subject: [Apiman-user] API policy response data handler
In-Reply-To: <CAP4n9Q-+tWhBHFb=+F5HzhnsEcY3kRqpEsUfky0rrDug=5qLfQ@mail.gmail.com>
References: <CAEDnbHAh2HPm5evojoR4H7E3Wv+frVEDyHkwuNp6-tin3tzAkA@mail.gmail.com>
	<CAA7j38+AU4HqeS_SkEVDZGB6JiZjpgFQgs=dnioAzad6-OcrMA@mail.gmail.com>
	<CAEDnbHDodcDtpWYoUS6kWRnS_hbZ=Ftt4dfmbFsKrLoKaZ6pBQ@mail.gmail.com>
	<CAA7j38J=DLUMF7YTnor2FTVDhpOOAvnq3YpxjfdCJC_-WxeB5w@mail.gmail.com>
	<CAA7j38+xmRdD75_Z2_gmWhejCsUFvwbsgftFW9Fq1PCXUbWyCg@mail.gmail.com>
	<CAP4n9Q-TzcZcoZx7_H0F_hvkhP+wAYeFz6Hyde=vC6H-eXJLow@mail.gmail.com>
	<CAEDnbHCG530Jy8LkkrKP=S-sTB2DAG_VUi=YnhOSVSh=sEKrAQ@mail.gmail.com>
	<CAA7j38JGHgtt-ih3-t05jVFLLh8GUOYC0X2DKkKeY1FPt8R54A@mail.gmail.com>
	<CAEDnbHBsb2mGozHRHnry_ZekVQVkA8LdLQtzcC+N6-7NSvqfew@mail.gmail.com>
	<CAA7j38+Tfj3Sc2aH=o52ePLrqKHW=GtkGnWHmzXtT_1-A6DbZA@mail.gmail.com>
	<CAEDnbHAH=QwK06J75JJW5JBSVKY24YEZt_C9YxqrJnJ4KTmwOQ@mail.gmail.com>
	<CAA7j38+iwrU-rN5TBLtjvpC0kmrLhsZDRskiM2QFJ-cetPW_3w@mail.gmail.com>
	<CAP4n9Q-+tWhBHFb=+F5HzhnsEcY3kRqpEsUfky0rrDug=5qLfQ@mail.gmail.com>
Message-ID: <CAEDnbHAT-+ZjLM=mwm_nzRn_kU77AdirNGVNG6U-eohExEvKDw@mail.gmail.com>

Hi Eric,
yes that looks promising solution for us. I shall try and come back.Thanks

regards
Balu

On Fri, Feb 3, 2017 at 10:31 PM, Eric Wittmann <eric.wittmann at redhat.com>
wrote:

> So I think at least one aspect of this is solvable.  You can modify the
> request metric data directly in a custom policy.  You can access and modify
> the request metric like this:
>
> {code}
>     protected void doApply(ApiResponse response, IPolicyContext context, C
> config, IPolicyChain<ApiResponse> chain) {
>      RequestMetric metric = context.getAttribute("apiman.request-metric",
> null);
>     metric.setFailure(true);
>     metric.setFailureCode(12345);
>     metric.setFailureReason("Backend API failed for a reason!"";
>         chain.doApply(response);
>     }
> {code}
>
> That will allow you to make sure the metrics information is correct for
> your use-case.  The policy context (and thus the request metric object) is
> also available to data policies:
>
> https://github.com/apiman/apiman/blob/master/gateway/
> engine/core/src/main/java/io/apiman/gateway/engine/policy/
> IDataPolicy.java#L53-L54
>
> Does that make sense?  Is there more to your use-case?
>
> -Eric
>
>
> On Fri, Feb 3, 2017 at 6:48 AM, Marc Savy <marc.savy at redhat.com> wrote:
>
>> Aha, you're specifically talking about the apiman UI - I had thought from
>> the context that you were using an external tool like Grafana.
>>
>> I'll let Eric respond as he implemented that code.
>>
>> On 3 February 2017 at 11:38, Balu S <sbalu27 at gmail.com> wrote:
>>
>>> sorry, I don't understand what you wrote.
>>>
>>> I would like Apiman metrics to consider the HTTP response (>=400) as
>>> failure/error (whatever that is appropriate) and indicate in below charts.
>>>
>>>
>>>
>>> [image: Inline image 1]
>>>
>>> On Fri, Feb 3, 2017 at 12:21 PM, Marc Savy <marc.savy at redhat.com> wrote:
>>>
>>>> I think I understand what you're asking.
>>>>
>>>> IIRC:
>>>>
>>>> Error = an exception occurred within the gateway (e.g. could not
>>>> connect to backend).
>>>> Failure = a policy failure occurred.
>>>>
>>>>
>>>> If you're wanting to look at http exception codes, just look at the
>>>> 'responseCode' field in the ES Metrics.
>>>>
>>>> If you're wanting a "failed/not failed" determination then perhaps just
>>>> execute `responseCode/100 == 2` in your analysis? Or is this not possible
>>>> in your use-case?
>>>>
>>>> On 3 February 2017 at 10:45, Balu S <sbalu27 at gmail.com> wrote:
>>>>
>>>>> Its the default one ES.
>>>>>
>>>>> # ------------------------------------------------------------
>>>>> ---------
>>>>> # Elasticsearch Metrics Settings
>>>>> # ------------------------------------------------------------
>>>>> ---------
>>>>>
>>>>> apiman-gateway.metrics=io.apiman.gateway.engine.es.ESMetrics
>>>>> apiman-gateway.metrics.client.type=jest
>>>>> apiman-gateway.metrics.client.protocol=${apiman.es.protocol}
>>>>> apiman-gateway.metrics.client.host=${apiman.es.host}
>>>>> apiman-gateway.metrics.client.port=${apiman.es.port}
>>>>> apiman-gateway.metrics.client.username=${apiman.es.username}
>>>>> apiman-gateway.metrics.client.password=${apiman.es.password}
>>>>> apiman-gateway.metrics.client.timeout=${apiman.es.timeout}
>>>>> apiman-gateway.metrics.client.initialize=true
>>>>>
>>>>> On Fri, Feb 3, 2017 at 11:40 AM, Marc Savy <marc.savy at redhat.com>
>>>>> wrote:
>>>>>
>>>>>> Which metrics implementation are you using? The data you're talking
>>>>>> about should be in there; if it's not then there's a problem.
>>>>>>
>>>>>>
>>>>>> On 3 February 2017 at 09:50, Balu S <sbalu27 at gmail.com> wrote:
>>>>>>
>>>>>>> Thanks for your inputs.
>>>>>>>
>>>>>>> Yes, I mean HTTP error codes (non-200) that are returned to client.
>>>>>>> For example, when a request is missing query parameters and the API
>>>>>>> responds with a "Bad request" (400) along with error XML. Here the error
>>>>>>> code is set at HTTP level only and Apiman metrics should consider it as bad
>>>>>>> response (in my opinion). Neither I do not see the Apiman source
>>>>>>> (HttpApiConnection) interpreting the HTTP response using the HTTP code. But
>>>>>>> with the custom policy, If I check for non-200 code and handle as failure,
>>>>>>> then metrics shows them as error.
>>>>>>>
>>>>>>> To clarify on my implementation with custom policy, I'm not trying
>>>>>>> to change the HTTP error code based on the response, rather we are
>>>>>>> unpacking the error response body and packing in different XML format as
>>>>>>> done by Apiman. Is this not a valid scenario ? I think there could other
>>>>>>> scenarios where one want to alter the response body. I agree there will be
>>>>>>> additional cost to performance and memory, but can it be not done one
>>>>>>> demand basis like how one can implement IDataPolicy to parse the response
>>>>>>> only if he needs to.
>>>>>>>
>>>>>>> Thanks
>>>>>>> Balu
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Thu, Feb 2, 2017 at 10:31 PM, Eric Wittmann <
>>>>>>> eric.wittmann at redhat.com> wrote:
>>>>>>>
>>>>>>>> The bottom line here is that you cannot return a Policy Failure (or
>>>>>>>> customize it) based on information in the response body.  The response is
>>>>>>>> streamed from the back-end to the client, and at the time streaming begins,
>>>>>>>> the response code and HTTP headers have already been sent.
>>>>>>>>
>>>>>>>> It sounds to me like you're asking for a feature where you can
>>>>>>>> parse the response body *before* the policy's "apply" method is invoked.
>>>>>>>> We have such a feature for requests, but not for responses.  I suspect core
>>>>>>>> changes to apiman would be required to enable that.  It seems like a
>>>>>>>> reasonable request to me, as long as users of the feature understand the
>>>>>>>> performance and memory requirements of enabling it.
>>>>>>>>
>>>>>>>> -Eric
>>>>>>>>
>>>>>>>>
>>>>>>>> On Thu, Feb 2, 2017 at 1:03 PM, Marc Savy <marc.savy at redhat.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> NB: This is distinct from the body you're setting which contains a
>>>>>>>>> JSON/XML payload containing the error code. It's in the HTTP protocol
>>>>>>>>> itself.
>>>>>>>>>
>>>>>>>>> On 2 February 2017 at 18:02, Marc Savy <marc.savy at redhat.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> That sounds like metrics are going wrong, or perhaps you're
>>>>>>>>>> misinterpreting it  (adding Eric).
>>>>>>>>>>
>>>>>>>>>> When you say your API returns an error, does it still return an
>>>>>>>>>> appropriate non-200 error code at the HTTP level? For instance, 500 or
>>>>>>>>>> similar? That's very important.
>>>>>>>>>>
>>>>>>>>>> There's a difference between an error and a failure - have you
>>>>>>>>>> checked both of those fields to see whether they contain the information
>>>>>>>>>> you're expecting to see.
>>>>>>>>>>
>>>>>>>>>> Certainly in my experience we *do* collect the metrics you're
>>>>>>>>>> talking about, unless I'm misunderstanding you.
>>>>>>>>>>
>>>>>>>>>> On 2 February 2017 at 17:40, Balu S <sbalu27 at gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi Marc,
>>>>>>>>>>>
>>>>>>>>>>> I shall explain my use case. From our API call, we return error
>>>>>>>>>>> response (in XML or JSON)  for 401, 500 and so on. However, Apiman metrics
>>>>>>>>>>> seems to just consider them as good response (it is, as Apiman received the
>>>>>>>>>>> response back) and show as successful response. So I have made custom
>>>>>>>>>>> policy to intercept the response to know if it is failure and trigger the
>>>>>>>>>>> Policy Failure. This is fairly simple and straight forward as the response
>>>>>>>>>>> code will just do the purpose. But I want also to add some additional
>>>>>>>>>>> information about the failure to Policy Failure. This additional
>>>>>>>>>>> information is in the original error response which will be lost once
>>>>>>>>>>> doFailure() happens. And no we don't want to those additional information
>>>>>>>>>>> in some HTTP headers to pass around. Hence I implemented responseHandler()
>>>>>>>>>>> to handle the response buffer and like you pointed out, it seems to be too
>>>>>>>>>>> late to meddle the response.
>>>>>>>>>>>
>>>>>>>>>>> So ideally, there are possible 2 solution
>>>>>>>>>>>
>>>>>>>>>>>    - Apiman metrics can interpret the response as unsuccessful
>>>>>>>>>>> for such error response from API call.
>>>>>>>>>>>    - Handle the response buffer data before the write() call to
>>>>>>>>>>> response outputstream.
>>>>>>>>>>>
>>>>>>>>>>> Do you see any alternative solution?
>>>>>>>>>>>
>>>>>>>>>>> Thanks
>>>>>>>>>>> Balu
>>>>>>>>>>>
>>>>>>>>>>> On Thu, Feb 2, 2017 at 6:15 PM, Marc Savy <marc.savy at redhat.com>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Hi,
>>>>>>>>>>>>
>>>>>>>>>>>> Perhaps URLRewritingPolicy https://github.com/apiman/apim
>>>>>>>>>>>> an/blob/master/gateway/engine/policies/src/main/java/io/apim
>>>>>>>>>>>> an/gateway/engine/policies/URLRewritingPolicy.java be an
>>>>>>>>>>>> informative place to start?
>>>>>>>>>>>>
>>>>>>>>>>>> - Apiman streams data, so the client may be receiving data
>>>>>>>>>>>> already by the time you've determined you want to cancel (the connection is
>>>>>>>>>>>> already established; headers have been sent) - it's often too late to
>>>>>>>>>>>> gracefully cancel. You could try throwing an exception and seeing what
>>>>>>>>>>>> happens (not recommended practice!).
>>>>>>>>>>>>
>>>>>>>>>>>> If that doesn't work, perhaps you can explain your use-case
>>>>>>>>>>>> more clearly and explicitly so we can see what the alternatives are?
>>>>>>>>>>>>
>>>>>>>>>>>> - Policies are *static* instances, if you are assigning that
>>>>>>>>>>>> buffer to the object then it's as if you were writing "static Buffer
>>>>>>>>>>>>  buffer" and different requests will all share that variable (and thus swap
>>>>>>>>>>>> it out repeatedly!).
>>>>>>>>>>>>
>>>>>>>>>>>> Regards,
>>>>>>>>>>>> Marc
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On 2 February 2017 at 16:56, Balu S <sbalu27 at gmail.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Hello,
>>>>>>>>>>>>> I'm trying to parse the response using responseDataHandler()
>>>>>>>>>>>>> in the custom policy. In cases, if the response from API is of certain
>>>>>>>>>>>>> content, I would like the Apiman to consider as failure. But I don't find a
>>>>>>>>>>>>> way to throw policy failure from responseDataHandler(). And I cannot
>>>>>>>>>>>>> achieve this in doApply() as the ApiResponse object does not have "content"
>>>>>>>>>>>>> to parse.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Also, what I found is write(chunk) in the AbstractStream is
>>>>>>>>>>>>> called after doApply, so I cannot set any attributes in it to fetch it in
>>>>>>>>>>>>> doApply() and trigger doFailure().
>>>>>>>>>>>>>
>>>>>>>>>>>>> For example, in below call, how to throw as policy failure
>>>>>>>>>>>>> after parsing the contents ? Or how can I access response content even
>>>>>>>>>>>>> before write() method.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> *URLRewritingPolicy.java*
>>>>>>>>>>>>>
>>>>>>>>>>>>>     @Override
>>>>>>>>>>>>>     protected IReadWriteStream<ApiResponse>
>>>>>>>>>>>>> responseDataHandler(ApiResponse response,
>>>>>>>>>>>>>             IPolicyContext context, URLRewritingConfig
>>>>>>>>>>>>> policyConfiguration) {
>>>>>>>>>>>>>         if (policyConfiguration.isProcessResponseBody()) {
>>>>>>>>>>>>>             return new URLRewritingStream(context.get
>>>>>>>>>>>>> Component(IBufferFactoryComponent.class), response,
>>>>>>>>>>>>>                     policyConfiguration.getFromRegex(),
>>>>>>>>>>>>> policyConfiguration.getToReplacement());
>>>>>>>>>>>>>         } else {
>>>>>>>>>>>>>             return null;
>>>>>>>>>>>>>         }
>>>>>>>>>>>>>     }
>>>>>>>>>>>>>
>>>>>>>>>>>>> *URLRewritingStream.java*
>>>>>>>>>>>>>
>>>>>>>>>>>>>     /**
>>>>>>>>>>>>>      * @see io.apiman.gateway.engine.io.Ab
>>>>>>>>>>>>> stractStream#write(io.apiman.gateway.engine.io.IApimanBuffer)
>>>>>>>>>>>>>      */
>>>>>>>>>>>>>     @Override
>>>>>>>>>>>>>     public void write(IApimanBuffer chunk) {
>>>>>>>>>>>>>         if (buffer == null) {
>>>>>>>>>>>>>             buffer = bufferFactory.cloneBuffer(chunk);
>>>>>>>>>>>>>         } else {
>>>>>>>>>>>>>             buffer.append(chunk);
>>>>>>>>>>>>>         }
>>>>>>>>>>>>>         atEnd = false;
>>>>>>>>>>>>>         processBuffer();
>>>>>>>>>>>>>     }
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Best regards
>>>>>>>>>>>>> Balu
>>>>>>>>>>>>>
>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>> Apiman-user mailing list
>>>>>>>>>>>>> Apiman-user at lists.jboss.org
>>>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/apiman-user
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20170204/9e1d82ad/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 54197 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/apiman-user/attachments/20170204/9e1d82ad/attachment-0001.png 

From Manvendra.Rai at ril.com  Mon Feb  6 07:24:36 2017
From: Manvendra.Rai at ril.com (Manvendra.Rai at ril.com)
Date: Mon, 6 Feb 2017 12:24:36 +0000
Subject: [Apiman-user] APIMAN Best Practice for Response Critical APIs
Message-ID: <6f6dc2e901ae42adbda9e6b35fb8aafa@SIDC1EXMBX23.in.ril.com>

Hello All,
We are using APIMAN for very response time critical APIs like - Upload API for uploading picture, videos etc.. to AWS S3. We don't want to upload files directly to S3 as there are few custom authentication & auth(via Redis In-Memory DB/Cache) checks we perform via our custom plugins in APIMAN. While, our APIs run OK without APIMAN, we see response time degrading considerably with APIMAN. What could be some of the best practices we should follow for performance tuning?

We tried WildFly & Tomcat, though latter comparatively performed better, overall response time didn't improve much.

Thanks,
Manav
"Confidentiality Warning: This message and any attachments are intended only for the use of the intended recipient(s). 
are confidential and may be privileged. If you are not the intended recipient. you are hereby notified that any 
review. re-transmission. conversion to hard copy. copying. circulation or other use of this message and any attachments is 
strictly prohibited. If you are not the intended recipient. please notify the sender immediately by return email. 
and delete this message and any attachments from your system.

Virus Warning: Although the company has taken reasonable precautions to ensure no viruses are present in this email. 
The company cannot accept responsibility for any loss or damage arising from the use of this email or attachment."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20170206/b5d21959/attachment.html 

From marc.savy at redhat.com  Mon Feb  6 08:04:25 2017
From: marc.savy at redhat.com (Marc Savy)
Date: Mon, 6 Feb 2017 13:04:25 +0000
Subject: [Apiman-user] APIMAN Best Practice for Response Critical APIs
In-Reply-To: <6f6dc2e901ae42adbda9e6b35fb8aafa@SIDC1EXMBX23.in.ril.com>
References: <6f6dc2e901ae42adbda9e6b35fb8aafa@SIDC1EXMBX23.in.ril.com>
Message-ID: <CAA7j38KrtR3P6RtRBKXt45DffwzF4ohg7KFT57nQMu1FyTO4-Q@mail.gmail.com>

Just to kick off the conversation:

Have you:
- Measured the time it takes to do your custom auth calls? Just to quantify
what the effect of the policy is. For example you could print out
timestamps, and/or compare to a deployment with no custom policies set.
- Tweaked JVM memory settings and/or GC?
- Increased the thread-pool sizes?


On 6 February 2017 at 12:24, <Manvendra.Rai at ril.com> wrote:

> Hello All,
>
> We are using APIMAN for very response time critical APIs like - Upload API
> for uploading picture, videos etc.. to AWS S3. We don't want to upload
> files directly to S3 as there are few custom authentication & auth(via
> Redis In-Memory DB/Cache) checks we perform via our custom plugins in
> APIMAN. While, our APIs run OK without APIMAN, we see response time
> degrading considerably with APIMAN. What could be some of the best
> practices we should follow for performance tuning?
>
>
>
> We tried WildFly & Tomcat, though latter comparatively performed better,
> overall response time didn?t improve much.
>
>
>
> Thanks,
>
> Manav
>
>
> "*Confidentiality Warning*: This message and any attachments are intended
> only for the use of the intended recipient(s), are confidential and may be
> privileged. If you are not the intended recipient, you are hereby notified
> that any review, re-transmission, conversion to hard copy, copying,
> circulation or other use of this message and any attachments is strictly
> prohibited. If you are not the intended recipient, please notify the sender
> immediately by return email and delete this message and any attachments
> from your system.
>
> *Virus Warning:* Although the company has taken reasonable precautions to
> ensure no viruses are present in this email. The company cannot accept
> responsibility for any loss or damage arising from the use of this email or
> attachment."
>
> _______________________________________________
> Apiman-user mailing list
> Apiman-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/apiman-user
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20170206/05bf9b83/attachment.html 

From marc.savy at redhat.com  Mon Feb  6 09:22:04 2017
From: marc.savy at redhat.com (Marc Savy)
Date: Mon, 6 Feb 2017 14:22:04 +0000
Subject: [Apiman-user] APIMAN Best Practice for Response Critical APIs
In-Reply-To: <CAA7j38KrtR3P6RtRBKXt45DffwzF4ohg7KFT57nQMu1FyTO4-Q@mail.gmail.com>
References: <6f6dc2e901ae42adbda9e6b35fb8aafa@SIDC1EXMBX23.in.ril.com>
	<CAA7j38KrtR3P6RtRBKXt45DffwzF4ohg7KFT57nQMu1FyTO4-Q@mail.gmail.com>
Message-ID: <CAA7j38L+kUKqPjJEke7xTs3ZdwO0XhwpLWoeQkpfGb1oFKKzVQ@mail.gmail.com>

Also, as a suggestion coming from another conversation between Eric and
Ram, you might want to check performance with metrics disabled - the
current ESMetrics implementation may not be coping under high load.

apiman-gateway.metrics=io.apiman.gateway.engine.impl.InMemoryMetrics
apiman-manager-ui.metrics.enable=false

We'll look at optimising it; shouldn't be difficult.



On 6 February 2017 at 13:04, Marc Savy <marc.savy at redhat.com> wrote:

> Just to kick off the conversation:
>
> Have you:
> - Measured the time it takes to do your custom auth calls? Just to
> quantify what the effect of the policy is. For example you could print out
> timestamps, and/or compare to a deployment with no custom policies set.
> - Tweaked JVM memory settings and/or GC?
> - Increased the thread-pool sizes?
>
>
> On 6 February 2017 at 12:24, <Manvendra.Rai at ril.com> wrote:
>
>> Hello All,
>>
>> We are using APIMAN for very response time critical APIs like - Upload
>> API for uploading picture, videos etc.. to AWS S3. We don't want to upload
>> files directly to S3 as there are few custom authentication & auth(via
>> Redis In-Memory DB/Cache) checks we perform via our custom plugins in
>> APIMAN. While, our APIs run OK without APIMAN, we see response time
>> degrading considerably with APIMAN. What could be some of the best
>> practices we should follow for performance tuning?
>>
>>
>>
>> We tried WildFly & Tomcat, though latter comparatively performed better,
>> overall response time didn?t improve much.
>>
>>
>>
>> Thanks,
>>
>> Manav
>>
>>
>> "*Confidentiality Warning*: This message and any attachments are
>> intended only for the use of the intended recipient(s), are confidential
>> and may be privileged. If you are not the intended recipient, you are
>> hereby notified that any review, re-transmission, conversion to hard copy,
>> copying, circulation or other use of this message and any attachments is
>> strictly prohibited. If you are not the intended recipient, please notify
>> the sender immediately by return email and delete this message and any
>> attachments from your system.
>>
>> *Virus Warning:* Although the company has taken reasonable precautions
>> to ensure no viruses are present in this email. The company cannot accept
>> responsibility for any loss or damage arising from the use of this email or
>> attachment."
>>
>> _______________________________________________
>> Apiman-user mailing list
>> Apiman-user at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/apiman-user
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20170206/6013fb9e/attachment.html 

From Manvendra.Rai at ril.com  Mon Feb  6 09:23:43 2017
From: Manvendra.Rai at ril.com (Manvendra.Rai at ril.com)
Date: Mon, 6 Feb 2017 14:23:43 +0000
Subject: [Apiman-user] APIMAN Best Practice for Response Critical APIs
In-Reply-To: <CAA7j38KrtR3P6RtRBKXt45DffwzF4ohg7KFT57nQMu1FyTO4-Q@mail.gmail.com>
References: <6f6dc2e901ae42adbda9e6b35fb8aafa@SIDC1EXMBX23.in.ril.com>
	<CAA7j38KrtR3P6RtRBKXt45DffwzF4ohg7KFT57nQMu1FyTO4-Q@mail.gmail.com>
Message-ID: <7e1be515d4b243db997896bf924e0983@SIDC1EXMBX23.in.ril.com>

Hi Marc,

- Measured the time it takes to do your custom auth calls? Just to quantify what the effect of the policy is. For example you could print out timestamps, and/or compare to a deployment with no custom policies set.
[Manav] ? There calls are very fast, we did test it, as there is a Redis backend. I tested it.

- Tweaked JVM memory settings and/or GC?
[Manav] ? Well said, we tried it to find the best setting.
- Increased the thread-pool sizes?
[Manav] ? Well said, we tried it to find the best setting.


One straight question, can Elastic Search be a bottleneck? Will there be difference if we use RDS instead of Elastic Search? How heavy metrics calls to ES?

Thanks,
Manav

From: Marc Savy [mailto:marc.savy at redhat.com]
Sent: 06 February 2017 18:34
To: Manvendra Rai
Cc: apiman-user at lists.jboss.org
Subject: Re: [Apiman-user] APIMAN Best Practice for Response Critical APIs

Just to kick off the conversation:

Have you:
- Measured the time it takes to do your custom auth calls? Just to quantify what the effect of the policy is. For example you could print out timestamps, and/or compare to a deployment with no custom policies set.
- Tweaked JVM memory settings and/or GC?
- Increased the thread-pool sizes?


On 6 February 2017 at 12:24, <Manvendra.Rai at ril.com<mailto:Manvendra.Rai at ril.com>> wrote:
Hello All,
We are using APIMAN for very response time critical APIs like - Upload API for uploading picture, videos etc.. to AWS S3. We don't want to upload files directly to S3 as there are few custom authentication & auth(via Redis In-Memory DB/Cache) checks we perform via our custom plugins in APIMAN. While, our APIs run OK without APIMAN, we see response time degrading considerably with APIMAN. What could be some of the best practices we should follow for performance tuning?

We tried WildFly & Tomcat, though latter comparatively performed better, overall response time didn?t improve much.

Thanks,
Manav

"Confidentiality Warning: This message and any attachments are intended only for the use of the intended recipient(s), are confidential and may be privileged. If you are not the intended recipient, you are hereby notified that any review, re-transmission, conversion to hard copy, copying, circulation or other use of this message and any attachments is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email and delete this message and any attachments from your system.

Virus Warning: Although the company has taken reasonable precautions to ensure no viruses are present in this email. The company cannot accept responsibility for any loss or damage arising from the use of this email or attachment."

_______________________________________________
Apiman-user mailing list
Apiman-user at lists.jboss.org<mailto:Apiman-user at lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/apiman-user

"Confidentiality Warning: This message and any attachments are intended only for the use of the intended recipient(s). 
are confidential and may be privileged. If you are not the intended recipient. you are hereby notified that any 
review. re-transmission. conversion to hard copy. copying. circulation or other use of this message and any attachments is 
strictly prohibited. If you are not the intended recipient. please notify the sender immediately by return email. 
and delete this message and any attachments from your system.

Virus Warning: Although the company has taken reasonable precautions to ensure no viruses are present in this email. 
The company cannot accept responsibility for any loss or damage arising from the use of this email or attachment."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20170206/8217b7bc/attachment-0001.html 

From Manvendra.Rai at ril.com  Mon Feb  6 09:26:56 2017
From: Manvendra.Rai at ril.com (Manvendra.Rai at ril.com)
Date: Mon, 6 Feb 2017 14:26:56 +0000
Subject: [Apiman-user] APIMAN Best Practice for Response Critical APIs
In-Reply-To: <CAA7j38L+kUKqPjJEke7xTs3ZdwO0XhwpLWoeQkpfGb1oFKKzVQ@mail.gmail.com>
References: <6f6dc2e901ae42adbda9e6b35fb8aafa@SIDC1EXMBX23.in.ril.com>
	<CAA7j38KrtR3P6RtRBKXt45DffwzF4ohg7KFT57nQMu1FyTO4-Q@mail.gmail.com>
	<CAA7j38L+kUKqPjJEke7xTs3ZdwO0XhwpLWoeQkpfGb1oFKKzVQ@mail.gmail.com>
Message-ID: <a7dc8ce4a0a84dc6a6772b4cb50e9578@SIDC1EXMBX23.in.ril.com>

Right, we have this testing going right away here.

From: Marc Savy [mailto:marc.savy at redhat.com]
Sent: 06 February 2017 19:52
To: Manvendra Rai
Cc: apiman-user at lists.jboss.org
Subject: Re: [Apiman-user] APIMAN Best Practice for Response Critical APIs

Also, as a suggestion coming from another conversation between Eric and Ram, you might want to check performance with metrics disabled - the current ESMetrics implementation may not be coping under high load.

apiman-gateway.metrics=io.apiman.gateway.engine.impl.InMemoryMetrics
apiman-manager-ui.metrics.enable=false

We'll look at optimising it; shouldn't be difficult.



On 6 February 2017 at 13:04, Marc Savy <marc.savy at redhat.com<mailto:marc.savy at redhat.com>> wrote:
Just to kick off the conversation:

Have you:
- Measured the time it takes to do your custom auth calls? Just to quantify what the effect of the policy is. For example you could print out timestamps, and/or compare to a deployment with no custom policies set.
- Tweaked JVM memory settings and/or GC?
- Increased the thread-pool sizes?


On 6 February 2017 at 12:24, <Manvendra.Rai at ril.com<mailto:Manvendra.Rai at ril.com>> wrote:
Hello All,
We are using APIMAN for very response time critical APIs like - Upload API for uploading picture, videos etc.. to AWS S3. We don't want to upload files directly to S3 as there are few custom authentication & auth(via Redis In-Memory DB/Cache) checks we perform via our custom plugins in APIMAN. While, our APIs run OK without APIMAN, we see response time degrading considerably with APIMAN. What could be some of the best practices we should follow for performance tuning?

We tried WildFly & Tomcat, though latter comparatively performed better, overall response time didn?t improve much.

Thanks,
Manav

"Confidentiality Warning: This message and any attachments are intended only for the use of the intended recipient(s), are confidential and may be privileged. If you are not the intended recipient, you are hereby notified that any review, re-transmission, conversion to hard copy, copying, circulation or other use of this message and any attachments is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email and delete this message and any attachments from your system.

Virus Warning: Although the company has taken reasonable precautions to ensure no viruses are present in this email. The company cannot accept responsibility for any loss or damage arising from the use of this email or attachment."

_______________________________________________
Apiman-user mailing list
Apiman-user at lists.jboss.org<mailto:Apiman-user at lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/apiman-user


"Confidentiality Warning: This message and any attachments are intended only for the use of the intended recipient(s). 
are confidential and may be privileged. If you are not the intended recipient. you are hereby notified that any 
review. re-transmission. conversion to hard copy. copying. circulation or other use of this message and any attachments is 
strictly prohibited. If you are not the intended recipient. please notify the sender immediately by return email. 
and delete this message and any attachments from your system.

Virus Warning: Although the company has taken reasonable precautions to ensure no viruses are present in this email. 
The company cannot accept responsibility for any loss or damage arising from the use of this email or attachment."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20170206/a8af69f7/attachment.html 

From marc.savy at redhat.com  Mon Feb  6 10:33:08 2017
From: marc.savy at redhat.com (Marc Savy)
Date: Mon, 6 Feb 2017 15:33:08 +0000
Subject: [Apiman-user] Logger exception
In-Reply-To: <CAEDnbHDTbXKADB6uPqPHT-G=8==SdK6i3Wnd3JstR3P-ozsm9A@mail.gmail.com>
References: <CAEDnbHDmY=tTb+HO1VXQMqYcC42eje6zESs68bm1a20XYXdBsw@mail.gmail.com>
	<CAA7j38K8uDTB-0Uy355n6ka=EWvB-D4J0hkNUc8AyJwAsyp3rA@mail.gmail.com>
	<CAEDnbHDNfd0rRiuk7MqwBJdMxzM69bv=FeiP7-NRnxkhHMf9+w@mail.gmail.com>
	<CAA7j38J5AmtcjzT+-ST4aUB6HNiojEzVN0i2dW3b7skgdUOJMw@mail.gmail.com>
	<CAEDnbHDTbXKADB6uPqPHT-G=8==SdK6i3Wnd3JstR3P-ozsm9A@mail.gmail.com>
Message-ID: <CAA7j38L+Wt7yWfXPiAbv6ULeAYx0ozsL7n800KBOjg=AJ+vtDg@mail.gmail.com>

The default logger seems to work fine for me, e.g.

apiman-gateway.logger-factory=io.apiman.common.logging.
DefaultDelegateFactory

Double check you didn't accidentally null the entry out by overwriting it
later in your config.

For SLF4J, the WAR implementation doesn't have the logger on the classpath
by default. You can do it manually, but it's a bit of a hassle and is only
a small addition, so I've added it and it will be in the next release:

https://github.com/apiman/apiman/pull/532

On 3 February 2017 at 10:27, Balu S <sbalu27 at gmail.com> wrote:

> Hi,
>
> I have managed to build these 2 projects (apiman-common-logging-core and
> /apiman-common-logging-slf4j) and add it as global jboss module to make
> Apiman to use Slf4jLoggerFactory logger.
>
> Does it not work out of box with just specifying Slf4jLoggerFactory in
> apiman.properties?
>
> On Tue, Jan 31, 2017 at 3:14 PM, Marc Savy <marc.savy at redhat.com> wrote:
>
>> I'll try to look into it shortly and post back onto the ML.
>>
>> On 30 January 2017 at 16:16, Balu S <sbalu27 at gmail.com> wrote:
>>
>>> Hi Marc,
>>> thanks for your quick response. Unfortunately it doesn't work.
>>>
>>> Although, what I am trying to achieve is to use "Slf4jLoggerFactory" and
>>> it fails with same null pointer.
>>>
>>> 2017-01-30 17:12:59,911 ERROR [org.jboss.msc.service.fail]
>>> (ServerService Thread Pool -- 64) MSC000001: Failed to start service
>>> jboss.undertow.deployment.default-server.default-host./apiman-gateway:
>>> org.jboss.msc.service.StartException in service
>>> jboss.undertow.deployment.default-server.default-host./apiman-gateway:
>>> java.lang.RuntimeException: java.lang.RuntimeException:
>>> java.lang.NullPointerException
>>> at org.wildfly.extension.undertow.deployment.UndertowDeployment
>>> Service$1.run(UndertowDeploymentService.java:85)
>>> at java.util.concurrent.Executors$RunnableAdapter.call(Executor
>>> s.java:511)
>>> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>>> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPool
>>> Executor.java:1142)
>>> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoo
>>> lExecutor.java:617)
>>> at java.lang.Thread.run(Thread.java:745)
>>> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
>>> Caused by: java.lang.RuntimeException: java.lang.RuntimeException:
>>> java.lang.NullPointerException
>>> at io.undertow.servlet.core.DeploymentManagerImpl.deploy(Deploy
>>> mentManagerImpl.java:236)
>>> at org.wildfly.extension.undertow.deployment.UndertowDeployment
>>> Service.startContext(UndertowDeploymentService.java:100)
>>> at org.wildfly.extension.undertow.deployment.UndertowDeployment
>>> Service$1.run(UndertowDeploymentService.java:82)
>>> ... 6 more
>>> Caused by: java.lang.RuntimeException: java.lang.NullPointerException
>>> at io.apiman.gateway.engine.impl.ConfigDrivenEngineFactory.inst
>>> antiate(ConfigDrivenEngineFactory.java:179)
>>> at io.apiman.gateway.engine.impl.ConfigDrivenEngineFactory.crea
>>> te(ConfigDrivenEngineFactory.java:163)
>>> at io.apiman.gateway.engine.impl.ConfigDrivenEngineFactory.crea
>>> teLoggerFactory(ConfigDrivenEngineFactory.java:152)
>>> at io.apiman.gateway.engine.impl.AbstractEngineFactory.createEn
>>> gine(AbstractEngineFactory.java:60)
>>> at io.apiman.gateway.platforms.war.WarGateway.init(WarGateway.java:55)
>>> at io.apiman.gateway.platforms.war.listeners.WarGatewayBootstra
>>> pper.contextInitialized(WarGatewayBootstrapper.java:
>>>
>>> On Mon, Jan 30, 2017 at 5:07 PM, Marc Savy <marc.savy at redhat.com> wrote:
>>>
>>>> I think you want
>>>> io.apiman.common.logging.DefaultDelegateFactory in that field rather
>>>> than SystemOutLogger directly.
>>>>
>>>> Does that work?
>>>>
>>>> The name is probably confusing - it *was* the default one at some point.
>>>>
>>>>
>>>>
>>>> On 30 January 2017 at 15:57, Balu S <sbalu27 at gmail.com> wrote:
>>>>
>>>>> Hello,
>>>>>
>>>>> I'm trying to simply replace the NoOpLoggerFactory to SystemOutLogger
>>>>> in apiman.properties and get below exception. It is quite strange as
>>>>> SystemOutLogger  is infact implements IDelegateFactory.
>>>>>
>>>>> #apiman-gateway.logger-factory=io.apiman.common.logging.impl
>>>>> .NoOpLoggerFactory
>>>>> apiman-gateway.logger-factory=io.apiman.common.logging.impl.
>>>>> SystemOutLogger
>>>>>
>>>>> Also, If I try to change to Slf4jLoggerFactory, then even
>>>>> the Slf4jLoggerFactory.class is not found.
>>>>>
>>>>> Could you please advise if there is any reference to be added and
>>>>> causes below error. Thanks
>>>>>
>>>>> .  Falling back to the Default. [No IDataEncrypter class configured.]
>>>>> 16:50:52,028 ERROR [org.jboss.msc.service.fail] (ServerService Thread
>>>>> Pool -- 69) MSC000001: Failed
>>>>> to start service jboss.undertow.deployment.defa
>>>>> ult-server.default-host./apiman-gateway-api: org.jbos
>>>>> s.msc.service.StartException in service jboss.undertow.deployment.defa
>>>>> ult-server.default-host./apima
>>>>> n-gateway-api: java.lang.RuntimeException:
>>>>> java.lang.ClassCastException: io.apiman.common.logging.impl.SystemOutLogger
>>>>> cannot be cast to io.apiman.common.logging.IDelegateFactory
>>>>>         at org.wildfly.extension.undertow
>>>>> .deployment.UndertowDeploymentService$1.run(UndertowDeploym
>>>>> entService.java:85)
>>>>>         at java.util.concurrent.Executors
>>>>> $RunnableAdapter.call(Executors.java:511)
>>>>>         at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>>>>>         at java.util.concurrent.ThreadPoo
>>>>> lExecutor.runWorker(ThreadPoolExecutor.java:1142)
>>>>>         at java.util.concurrent.ThreadPoo
>>>>> lExecutor$Worker.run(ThreadPoolExecutor.java:617)
>>>>>         at java.lang.Thread.run(Thread.java:745)
>>>>>         at org.jboss.threads.JBossThread.run(JBossThread.java:320)
>>>>> Caused by: java.lang.RuntimeException: java.lang.ClassCastException:
>>>>> io.apiman.common.logging.impl.SystemOutLogger cannot be cast to
>>>>> io.apiman.common.logging.IDelegateFactory
>>>>>         at io.undertow.servlet.core.Deplo
>>>>> ymentManagerImpl.deploy(DeploymentManagerImpl.java:236)
>>>>>         at org.wildfly.extension.undertow
>>>>> .deployment.UndertowDeploymentService.startContext(Undertow
>>>>> DeploymentService.java:100)
>>>>>         at org.wildfly.extension.undertow
>>>>> .deployment.UndertowDeploymentService$1.run(UndertowDeploym
>>>>>
>>>>>
>>>>> regards
>>>>> Balu
>>>>>
>>>>> _______________________________________________
>>>>> Apiman-user mailing list
>>>>> Apiman-user at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/apiman-user
>>>>>
>>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20170206/1e85aa36/attachment-0001.html 

From sbalu27 at gmail.com  Tue Feb  7 04:50:22 2017
From: sbalu27 at gmail.com (Balu S)
Date: Tue, 7 Feb 2017 10:50:22 +0100
Subject: [Apiman-user] Logger exception
In-Reply-To: <CAA7j38L+Wt7yWfXPiAbv6ULeAYx0ozsL7n800KBOjg=AJ+vtDg@mail.gmail.com>
References: <CAEDnbHDmY=tTb+HO1VXQMqYcC42eje6zESs68bm1a20XYXdBsw@mail.gmail.com>
	<CAA7j38K8uDTB-0Uy355n6ka=EWvB-D4J0hkNUc8AyJwAsyp3rA@mail.gmail.com>
	<CAEDnbHDNfd0rRiuk7MqwBJdMxzM69bv=FeiP7-NRnxkhHMf9+w@mail.gmail.com>
	<CAA7j38J5AmtcjzT+-ST4aUB6HNiojEzVN0i2dW3b7skgdUOJMw@mail.gmail.com>
	<CAEDnbHDTbXKADB6uPqPHT-G=8==SdK6i3Wnd3JstR3P-ozsm9A@mail.gmail.com>
	<CAA7j38L+Wt7yWfXPiAbv6ULeAYx0ozsL7n800KBOjg=AJ+vtDg@mail.gmail.com>
Message-ID: <CAEDnbHBbzsNBcvyzLZffa-A4o4wxy4-BwO42maCzTPa2uzQUMg@mail.gmail.com>

Great, I will check that.

On Mon, Feb 6, 2017 at 4:33 PM, Marc Savy <marc.savy at redhat.com> wrote:

> The default logger seems to work fine for me, e.g.
>
> apiman-gateway.logger-factory=io.apiman.common.logging.Defau
> ltDelegateFactory
>
> Double check you didn't accidentally null the entry out by overwriting it
> later in your config.
>
> For SLF4J, the WAR implementation doesn't have the logger on the classpath
> by default. You can do it manually, but it's a bit of a hassle and is only
> a small addition, so I've added it and it will be in the next release:
>
> https://github.com/apiman/apiman/pull/532
>
> On 3 February 2017 at 10:27, Balu S <sbalu27 at gmail.com> wrote:
>
>> Hi,
>>
>> I have managed to build these 2 projects (apiman-common-logging-core and
>> /apiman-common-logging-slf4j) and add it as global jboss module to make
>> Apiman to use Slf4jLoggerFactory logger.
>>
>> Does it not work out of box with just specifying Slf4jLoggerFactory in
>> apiman.properties?
>>
>> On Tue, Jan 31, 2017 at 3:14 PM, Marc Savy <marc.savy at redhat.com> wrote:
>>
>>> I'll try to look into it shortly and post back onto the ML.
>>>
>>> On 30 January 2017 at 16:16, Balu S <sbalu27 at gmail.com> wrote:
>>>
>>>> Hi Marc,
>>>> thanks for your quick response. Unfortunately it doesn't work.
>>>>
>>>> Although, what I am trying to achieve is to use "Slf4jLoggerFactory"
>>>> and it fails with same null pointer.
>>>>
>>>> 2017-01-30 17:12:59,911 ERROR [org.jboss.msc.service.fail]
>>>> (ServerService Thread Pool -- 64) MSC000001: Failed to start service
>>>> jboss.undertow.deployment.default-server.default-host./apiman-gateway:
>>>> org.jboss.msc.service.StartException in service
>>>> jboss.undertow.deployment.default-server.default-host./apiman-gateway:
>>>> java.lang.RuntimeException: java.lang.RuntimeException:
>>>> java.lang.NullPointerException
>>>> at org.wildfly.extension.undertow.deployment.UndertowDeployment
>>>> Service$1.run(UndertowDeploymentService.java:85)
>>>> at java.util.concurrent.Executors$RunnableAdapter.call(Executor
>>>> s.java:511)
>>>> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>>>> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPool
>>>> Executor.java:1142)
>>>> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoo
>>>> lExecutor.java:617)
>>>> at java.lang.Thread.run(Thread.java:745)
>>>> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
>>>> Caused by: java.lang.RuntimeException: java.lang.RuntimeException:
>>>> java.lang.NullPointerException
>>>> at io.undertow.servlet.core.DeploymentManagerImpl.deploy(Deploy
>>>> mentManagerImpl.java:236)
>>>> at org.wildfly.extension.undertow.deployment.UndertowDeployment
>>>> Service.startContext(UndertowDeploymentService.java:100)
>>>> at org.wildfly.extension.undertow.deployment.UndertowDeployment
>>>> Service$1.run(UndertowDeploymentService.java:82)
>>>> ... 6 more
>>>> Caused by: java.lang.RuntimeException: java.lang.NullPointerException
>>>> at io.apiman.gateway.engine.impl.ConfigDrivenEngineFactory.inst
>>>> antiate(ConfigDrivenEngineFactory.java:179)
>>>> at io.apiman.gateway.engine.impl.ConfigDrivenEngineFactory.crea
>>>> te(ConfigDrivenEngineFactory.java:163)
>>>> at io.apiman.gateway.engine.impl.ConfigDrivenEngineFactory.crea
>>>> teLoggerFactory(ConfigDrivenEngineFactory.java:152)
>>>> at io.apiman.gateway.engine.impl.AbstractEngineFactory.createEn
>>>> gine(AbstractEngineFactory.java:60)
>>>> at io.apiman.gateway.platforms.war.WarGateway.init(WarGateway.java:55)
>>>> at io.apiman.gateway.platforms.war.listeners.WarGatewayBootstra
>>>> pper.contextInitialized(WarGatewayBootstrapper.java:
>>>>
>>>> On Mon, Jan 30, 2017 at 5:07 PM, Marc Savy <marc.savy at redhat.com>
>>>> wrote:
>>>>
>>>>> I think you want
>>>>> io.apiman.common.logging.DefaultDelegateFactory in that field rather
>>>>> than SystemOutLogger directly.
>>>>>
>>>>> Does that work?
>>>>>
>>>>> The name is probably confusing - it *was* the default one at some
>>>>> point.
>>>>>
>>>>>
>>>>>
>>>>> On 30 January 2017 at 15:57, Balu S <sbalu27 at gmail.com> wrote:
>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> I'm trying to simply replace the NoOpLoggerFactory to SystemOutLogger
>>>>>> in apiman.properties and get below exception. It is quite strange as
>>>>>> SystemOutLogger  is infact implements IDelegateFactory.
>>>>>>
>>>>>> #apiman-gateway.logger-factory=io.apiman.common.logging.impl
>>>>>> .NoOpLoggerFactory
>>>>>> apiman-gateway.logger-factory=io.apiman.common.logging.impl.
>>>>>> SystemOutLogger
>>>>>>
>>>>>> Also, If I try to change to Slf4jLoggerFactory, then even
>>>>>> the Slf4jLoggerFactory.class is not found.
>>>>>>
>>>>>> Could you please advise if there is any reference to be added and
>>>>>> causes below error. Thanks
>>>>>>
>>>>>> .  Falling back to the Default. [No IDataEncrypter class configured.]
>>>>>> 16:50:52,028 ERROR [org.jboss.msc.service.fail] (ServerService Thread
>>>>>> Pool -- 69) MSC000001: Failed
>>>>>> to start service jboss.undertow.deployment.defa
>>>>>> ult-server.default-host./apiman-gateway-api: org.jbos
>>>>>> s.msc.service.StartException in service jboss.undertow.deployment.defa
>>>>>> ult-server.default-host./apima
>>>>>> n-gateway-api: java.lang.RuntimeException:
>>>>>> java.lang.ClassCastException: io.apiman.common.logging.impl.SystemOutLogger
>>>>>> cannot be cast to io.apiman.common.logging.IDelegateFactory
>>>>>>         at org.wildfly.extension.undertow
>>>>>> .deployment.UndertowDeploymentService$1.run(UndertowDeploym
>>>>>> entService.java:85)
>>>>>>         at java.util.concurrent.Executors
>>>>>> $RunnableAdapter.call(Executors.java:511)
>>>>>>         at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>>>>>>         at java.util.concurrent.ThreadPoo
>>>>>> lExecutor.runWorker(ThreadPoolExecutor.java:1142)
>>>>>>         at java.util.concurrent.ThreadPoo
>>>>>> lExecutor$Worker.run(ThreadPoolExecutor.java:617)
>>>>>>         at java.lang.Thread.run(Thread.java:745)
>>>>>>         at org.jboss.threads.JBossThread.run(JBossThread.java:320)
>>>>>> Caused by: java.lang.RuntimeException: java.lang.ClassCastException:
>>>>>> io.apiman.common.logging.impl.SystemOutLogger cannot be cast to
>>>>>> io.apiman.common.logging.IDelegateFactory
>>>>>>         at io.undertow.servlet.core.Deplo
>>>>>> ymentManagerImpl.deploy(DeploymentManagerImpl.java:236)
>>>>>>         at org.wildfly.extension.undertow
>>>>>> .deployment.UndertowDeploymentService.startContext(Undertow
>>>>>> DeploymentService.java:100)
>>>>>>         at org.wildfly.extension.undertow
>>>>>> .deployment.UndertowDeploymentService$1.run(UndertowDeploym
>>>>>>
>>>>>>
>>>>>> regards
>>>>>> Balu
>>>>>>
>>>>>> _______________________________________________
>>>>>> Apiman-user mailing list
>>>>>> Apiman-user at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/apiman-user
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20170207/9b0efc1f/attachment.html 

From marc.savy at redhat.com  Tue Feb  7 05:52:32 2017
From: marc.savy at redhat.com (Marc Savy)
Date: Tue, 7 Feb 2017 10:52:32 +0000
Subject: [Apiman-user] Logger exception
In-Reply-To: <CAEDnbHBbzsNBcvyzLZffa-A4o4wxy4-BwO42maCzTPa2uzQUMg@mail.gmail.com>
References: <CAEDnbHDmY=tTb+HO1VXQMqYcC42eje6zESs68bm1a20XYXdBsw@mail.gmail.com>
	<CAA7j38K8uDTB-0Uy355n6ka=EWvB-D4J0hkNUc8AyJwAsyp3rA@mail.gmail.com>
	<CAEDnbHDNfd0rRiuk7MqwBJdMxzM69bv=FeiP7-NRnxkhHMf9+w@mail.gmail.com>
	<CAA7j38J5AmtcjzT+-ST4aUB6HNiojEzVN0i2dW3b7skgdUOJMw@mail.gmail.com>
	<CAEDnbHDTbXKADB6uPqPHT-G=8==SdK6i3Wnd3JstR3P-ozsm9A@mail.gmail.com>
	<CAA7j38L+Wt7yWfXPiAbv6ULeAYx0ozsL7n800KBOjg=AJ+vtDg@mail.gmail.com>
	<CAEDnbHBbzsNBcvyzLZffa-A4o4wxy4-BwO42maCzTPa2uzQUMg@mail.gmail.com>
Message-ID: <CAA7j38JGsDAtEHBYT1N7iouBNP82ttpuNryjHL48fPWS5P_29A@mail.gmail.com>

FWIW, I do *not* suggest using the SystemOutLogger/DefaultDelegateFactory
if you require decent performance - it's completely synchronous and will
slow things down substantially.

I'd suggest SLF4J + a well-configured JBoss Logging setup.

On 7 February 2017 at 09:50, Balu S <sbalu27 at gmail.com> wrote:

> Great, I will check that.
>
> On Mon, Feb 6, 2017 at 4:33 PM, Marc Savy <marc.savy at redhat.com> wrote:
>
>> The default logger seems to work fine for me, e.g.
>>
>> apiman-gateway.logger-factory=io.apiman.common.logging.Defau
>> ltDelegateFactory
>>
>> Double check you didn't accidentally null the entry out by overwriting it
>> later in your config.
>>
>> For SLF4J, the WAR implementation doesn't have the logger on the
>> classpath by default. You can do it manually, but it's a bit of a hassle
>> and is only a small addition, so I've added it and it will be in the next
>> release:
>>
>> https://github.com/apiman/apiman/pull/532
>>
>> On 3 February 2017 at 10:27, Balu S <sbalu27 at gmail.com> wrote:
>>
>>> Hi,
>>>
>>> I have managed to build these 2 projects (apiman-common-logging-core and
>>> /apiman-common-logging-slf4j) and add it as global jboss module to make
>>> Apiman to use Slf4jLoggerFactory logger.
>>>
>>> Does it not work out of box with just specifying Slf4jLoggerFactory in
>>> apiman.properties?
>>>
>>> On Tue, Jan 31, 2017 at 3:14 PM, Marc Savy <marc.savy at redhat.com> wrote:
>>>
>>>> I'll try to look into it shortly and post back onto the ML.
>>>>
>>>> On 30 January 2017 at 16:16, Balu S <sbalu27 at gmail.com> wrote:
>>>>
>>>>> Hi Marc,
>>>>> thanks for your quick response. Unfortunately it doesn't work.
>>>>>
>>>>> Although, what I am trying to achieve is to use "Slf4jLoggerFactory"
>>>>> and it fails with same null pointer.
>>>>>
>>>>> 2017-01-30 17:12:59,911 ERROR [org.jboss.msc.service.fail]
>>>>> (ServerService Thread Pool -- 64) MSC000001: Failed to start service
>>>>> jboss.undertow.deployment.default-server.default-host./apiman-gateway:
>>>>> org.jboss.msc.service.StartException in service
>>>>> jboss.undertow.deployment.default-server.default-host./apiman-gateway:
>>>>> java.lang.RuntimeException: java.lang.RuntimeException:
>>>>> java.lang.NullPointerException
>>>>> at org.wildfly.extension.undertow.deployment.UndertowDeployment
>>>>> Service$1.run(UndertowDeploymentService.java:85)
>>>>> at java.util.concurrent.Executors$RunnableAdapter.call(Executor
>>>>> s.java:511)
>>>>> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>>>>> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPool
>>>>> Executor.java:1142)
>>>>> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoo
>>>>> lExecutor.java:617)
>>>>> at java.lang.Thread.run(Thread.java:745)
>>>>> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
>>>>> Caused by: java.lang.RuntimeException: java.lang.RuntimeException:
>>>>> java.lang.NullPointerException
>>>>> at io.undertow.servlet.core.DeploymentManagerImpl.deploy(Deploy
>>>>> mentManagerImpl.java:236)
>>>>> at org.wildfly.extension.undertow.deployment.UndertowDeployment
>>>>> Service.startContext(UndertowDeploymentService.java:100)
>>>>> at org.wildfly.extension.undertow.deployment.UndertowDeployment
>>>>> Service$1.run(UndertowDeploymentService.java:82)
>>>>> ... 6 more
>>>>> Caused by: java.lang.RuntimeException: java.lang.NullPointerException
>>>>> at io.apiman.gateway.engine.impl.ConfigDrivenEngineFactory.inst
>>>>> antiate(ConfigDrivenEngineFactory.java:179)
>>>>> at io.apiman.gateway.engine.impl.ConfigDrivenEngineFactory.crea
>>>>> te(ConfigDrivenEngineFactory.java:163)
>>>>> at io.apiman.gateway.engine.impl.ConfigDrivenEngineFactory.crea
>>>>> teLoggerFactory(ConfigDrivenEngineFactory.java:152)
>>>>> at io.apiman.gateway.engine.impl.AbstractEngineFactory.createEn
>>>>> gine(AbstractEngineFactory.java:60)
>>>>> at io.apiman.gateway.platforms.war.WarGateway.init(WarGateway.java:55)
>>>>> at io.apiman.gateway.platforms.war.listeners.WarGatewayBootstra
>>>>> pper.contextInitialized(WarGatewayBootstrapper.java:
>>>>>
>>>>> On Mon, Jan 30, 2017 at 5:07 PM, Marc Savy <marc.savy at redhat.com>
>>>>> wrote:
>>>>>
>>>>>> I think you want
>>>>>> io.apiman.common.logging.DefaultDelegateFactory in that field rather
>>>>>> than SystemOutLogger directly.
>>>>>>
>>>>>> Does that work?
>>>>>>
>>>>>> The name is probably confusing - it *was* the default one at some
>>>>>> point.
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 30 January 2017 at 15:57, Balu S <sbalu27 at gmail.com> wrote:
>>>>>>
>>>>>>> Hello,
>>>>>>>
>>>>>>> I'm trying to simply replace the NoOpLoggerFactory to
>>>>>>> SystemOutLogger in apiman.properties and get below exception. It is quite
>>>>>>> strange as SystemOutLogger  is infact implements IDelegateFactory.
>>>>>>>
>>>>>>> #apiman-gateway.logger-factory=io.apiman.common.logging.impl
>>>>>>> .NoOpLoggerFactory
>>>>>>> apiman-gateway.logger-factory=io.apiman.common.logging.impl.
>>>>>>> SystemOutLogger
>>>>>>>
>>>>>>> Also, If I try to change to Slf4jLoggerFactory, then even
>>>>>>> the Slf4jLoggerFactory.class is not found.
>>>>>>>
>>>>>>> Could you please advise if there is any reference to be added and
>>>>>>> causes below error. Thanks
>>>>>>>
>>>>>>> .  Falling back to the Default. [No IDataEncrypter class configured.]
>>>>>>> 16:50:52,028 ERROR [org.jboss.msc.service.fail] (ServerService
>>>>>>> Thread Pool -- 69) MSC000001: Failed
>>>>>>> to start service jboss.undertow.deployment.defa
>>>>>>> ult-server.default-host./apiman-gateway-api: org.jbos
>>>>>>> s.msc.service.StartException in service
>>>>>>> jboss.undertow.deployment.default-server.default-host./apima
>>>>>>> n-gateway-api: java.lang.RuntimeException:
>>>>>>> java.lang.ClassCastException: io.apiman.common.logging.impl.SystemOutLogger
>>>>>>> cannot be cast to io.apiman.common.logging.IDelegateFactory
>>>>>>>         at org.wildfly.extension.undertow
>>>>>>> .deployment.UndertowDeploymentService$1.run(UndertowDeploym
>>>>>>> entService.java:85)
>>>>>>>         at java.util.concurrent.Executors
>>>>>>> $RunnableAdapter.call(Executors.java:511)
>>>>>>>         at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>>>>>>>         at java.util.concurrent.ThreadPoo
>>>>>>> lExecutor.runWorker(ThreadPoolExecutor.java:1142)
>>>>>>>         at java.util.concurrent.ThreadPoo
>>>>>>> lExecutor$Worker.run(ThreadPoolExecutor.java:617)
>>>>>>>         at java.lang.Thread.run(Thread.java:745)
>>>>>>>         at org.jboss.threads.JBossThread.run(JBossThread.java:320)
>>>>>>> Caused by: java.lang.RuntimeException: java.lang.ClassCastException:
>>>>>>> io.apiman.common.logging.impl.SystemOutLogger cannot be cast to
>>>>>>> io.apiman.common.logging.IDelegateFactory
>>>>>>>         at io.undertow.servlet.core.Deplo
>>>>>>> ymentManagerImpl.deploy(DeploymentManagerImpl.java:236)
>>>>>>>         at org.wildfly.extension.undertow
>>>>>>> .deployment.UndertowDeploymentService.startContext(Undertow
>>>>>>> DeploymentService.java:100)
>>>>>>>         at org.wildfly.extension.undertow
>>>>>>> .deployment.UndertowDeploymentService$1.run(UndertowDeploym
>>>>>>>
>>>>>>>
>>>>>>> regards
>>>>>>> Balu
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Apiman-user mailing list
>>>>>>> Apiman-user at lists.jboss.org
>>>>>>> https://lists.jboss.org/mailman/listinfo/apiman-user
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20170207/e53499cf/attachment-0001.html 

From Ram.Tanna at ril.com  Tue Feb  7 07:55:50 2017
From: Ram.Tanna at ril.com (Ram.Tanna at ril.com)
Date: Tue, 7 Feb 2017 12:55:50 +0000
Subject: [Apiman-user] APIMAN configuration for high-load application
Message-ID: <D4BFC1C6.1D0D%ram.tanna@ril.com>

Dear Team,

We are using APIMAN in our application which would have 40k concurrent requests.

There would be around 7000 requests/second. Out of which 2500 requests are for uploading and downloading a file with payload size of 512 KB/request. Other request will have payload of 50 to 80 KB.

Folks who are using apiman in their system, can please share your experience.

What would be the best configuration for such high-load application ?


Thanks and Regards,
Ram Tanna








"Confidentiality Warning: This message and any attachments are intended only for the use of the intended recipient(s). 
are confidential and may be privileged. If you are not the intended recipient. you are hereby notified that any 
review. re-transmission. conversion to hard copy. copying. circulation or other use of this message and any attachments is 
strictly prohibited. If you are not the intended recipient. please notify the sender immediately by return email. 
and delete this message and any attachments from your system.

Virus Warning: Although the company has taken reasonable precautions to ensure no viruses are present in this email. 
The company cannot accept responsibility for any loss or damage arising from the use of this email or attachment."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20170207/41b232fa/attachment.html 

From marc.savy at redhat.com  Tue Feb  7 08:09:08 2017
From: marc.savy at redhat.com (Marc Savy)
Date: Tue, 7 Feb 2017 13:09:08 +0000
Subject: [Apiman-user] APIMAN configuration for high-load application
In-Reply-To: <D4BFC1C6.1D0D%ram.tanna@ril.com>
References: <D4BFC1C6.1D0D%ram.tanna@ril.com>
Message-ID: <CAA7j38Kthovb_+_M1T2sZfcmjQfkFZ9qSJwNdtfd5+ZaKdPQxg@mail.gmail.com>

Hi,

Can you share a bit of information about your setup?

For instance, if you share apiman.properties with any sensitive information
taken out.

This sounds like it could be a good candidate for trying our Vert.x-based
gateway. I've been working a lot on it lately - it might be worth trying
out in a test deployment. However, I'd need to know more about your
existing setup, as the bottleneck might be elsewhere.

Regards,
Marc

On 7 February 2017 at 12:55, <Ram.Tanna at ril.com> wrote:

> Dear Team,
>
> We are using APIMAN in our application which would have 40k concurrent
> requests.
>
> There would be around 7000 requests/second. Out of which 2500 requests are
> for uploading and downloading a file with payload size of 512 KB/request.
> Other request will have payload of 50 to 80 KB.
>
> Folks who are using apiman in their system, can please share your
> experience.
>
> What would be the best configuration for such high-load application ?
>
>
> Thanks and Regards,
> Ram Tanna
>
>
>
>
>
>
>
>
>
> "*Confidentiality Warning*: This message and any attachments are intended
> only for the use of the intended recipient(s), are confidential and may be
> privileged. If you are not the intended recipient, you are hereby notified
> that any review, re-transmission, conversion to hard copy, copying,
> circulation or other use of this message and any attachments is strictly
> prohibited. If you are not the intended recipient, please notify the sender
> immediately by return email and delete this message and any attachments
> from your system.
>
> *Virus Warning:* Although the company has taken reasonable precautions to
> ensure no viruses are present in this email. The company cannot accept
> responsibility for any loss or damage arising from the use of this email or
> attachment."
>
> _______________________________________________
> Apiman-user mailing list
> Apiman-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/apiman-user
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20170207/1fae01d2/attachment.html 

From Ram.Tanna at ril.com  Tue Feb  7 09:09:33 2017
From: Ram.Tanna at ril.com (Ram.Tanna at ril.com)
Date: Tue, 7 Feb 2017 14:09:33 +0000
Subject: [Apiman-user] APIMAN configuration for high-load application
In-Reply-To: <CAA7j38Kthovb_+_M1T2sZfcmjQfkFZ9qSJwNdtfd5+ZaKdPQxg@mail.gmail.com>
References: <D4BFC1C6.1D0D%ram.tanna@ril.com>
	<CAA7j38Kthovb_+_M1T2sZfcmjQfkFZ9qSJwNdtfd5+ZaKdPQxg@mail.gmail.com>
Message-ID: <D4BFCB75.1D20%ram.tanna@ril.com>

Hi Marc,

We haven't done any major changes in the default configuration and in property file.

Trying out Vert.x-based gateway would not be feasible at this moment as we are into the production phase, and we want to achieve best output from minimal modifications.

Regards,
Ram Tanna



From: Marc Savy <marc.savy at redhat.com<mailto:marc.savy at redhat.com>>
Date: Tuesday, 7 February 2017 at 6:39 PM
To: Ram <ram.tanna at ril.com<mailto:ram.tanna at ril.com>>
Cc: "apiman-user at lists.jboss.org<mailto:apiman-user at lists.jboss.org>" <apiman-user at lists.jboss.org<mailto:apiman-user at lists.jboss.org>>, Manvendra Rai <manvendra.rai at ril.com<mailto:manvendra.rai at ril.com>>, Anshul Agrawal <Anshul.Agrawal at ril.com<mailto:Anshul.Agrawal at ril.com>>, "ram_tanna3 at yahoo.in<mailto:ram_tanna3 at yahoo.in>" <ram_tanna3 at yahoo.in<mailto:ram_tanna3 at yahoo.in>>
Subject: Re: [Apiman-user] APIMAN configuration for high-load application

Hi,

Can you share a bit of information about your setup?

For instance, if you share apiman.properties with any sensitive information taken out.

This sounds like it could be a good candidate for trying our Vert.x-based gateway. I've been working a lot on it lately - it might be worth trying out in a test deployment. However, I'd need to know more about your existing setup, as the bottleneck might be elsewhere.

Regards,
Marc

On 7 February 2017 at 12:55, <Ram.Tanna at ril.com<mailto:Ram.Tanna at ril.com>> wrote:
Dear Team,

We are using APIMAN in our application which would have 40k concurrent requests.

There would be around 7000 requests/second. Out of which 2500 requests are for uploading and downloading a file with payload size of 512 KB/request. Other request will have payload of 50 to 80 KB.

Folks who are using apiman in their system, can please share your experience.

What would be the best configuration for such high-load application ?


Thanks and Regards,
Ram Tanna









"Confidentiality Warning: This message and any attachments are intended only for the use of the intended recipient(s), are confidential and may be privileged. If you are not the intended recipient, you are hereby notified that any review, re-transmission, conversion to hard copy, copying, circulation or other use of this message and any attachments is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email and delete this message and any attachments from your system.

Virus Warning: Although the company has taken reasonable precautions to ensure no viruses are present in this email. The company cannot accept responsibility for any loss or damage arising from the use of this email or attachment."

_______________________________________________
Apiman-user mailing list
Apiman-user at lists.jboss.org<mailto:Apiman-user at lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/apiman-user


"Confidentiality Warning: This message and any attachments are intended only for the use of the intended recipient(s). 
are confidential and may be privileged. If you are not the intended recipient. you are hereby notified that any 
review. re-transmission. conversion to hard copy. copying. circulation or other use of this message and any attachments is 
strictly prohibited. If you are not the intended recipient. please notify the sender immediately by return email. 
and delete this message and any attachments from your system.

Virus Warning: Although the company has taken reasonable precautions to ensure no viruses are present in this email. 
The company cannot accept responsibility for any loss or damage arising from the use of this email or attachment."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20170207/d5df461e/attachment.html 

From marc.savy at redhat.com  Tue Feb  7 09:26:51 2017
From: marc.savy at redhat.com (Marc Savy)
Date: Tue, 7 Feb 2017 14:26:51 +0000
Subject: [Apiman-user] APIMAN configuration for high-load application
In-Reply-To: <D4BFCB75.1D20%ram.tanna@ril.com>
References: <D4BFC1C6.1D0D%ram.tanna@ril.com>
	<CAA7j38Kthovb_+_M1T2sZfcmjQfkFZ9qSJwNdtfd5+ZaKdPQxg@mail.gmail.com>
	<D4BFCB75.1D20%ram.tanna@ril.com>
Message-ID: <CAA7j38Jxa8GbXFRdJ-R_1VMZmmNDfyonZx6t3+HjXnV1bfCvKA@mail.gmail.com>

Hi,

Check out Harry Trinta's contributions to this thread:
https://lists.jboss.org/pipermail/apiman-user/2017-January/000758.html

Have you done any profiling and observed any particular bottlenecks?

Regards,
Marc

On 7 February 2017 at 14:09, <Ram.Tanna at ril.com> wrote:

> Hi Marc,
>
> We haven?t done any major changes in the default configuration and in
> property file.
>
> Trying out Vert.x-based gateway would not be feasible at this moment as we
> are into the production phase, and we want to achieve best output from
> minimal modifications.
>
> Regards,
> Ram Tanna
>
>
>
> From: Marc Savy <marc.savy at redhat.com>
> Date: Tuesday, 7 February 2017 at 6:39 PM
> To: Ram <ram.tanna at ril.com>
> Cc: "apiman-user at lists.jboss.org" <apiman-user at lists.jboss.org>,
> Manvendra Rai <manvendra.rai at ril.com>, Anshul Agrawal <
> Anshul.Agrawal at ril.com>, "ram_tanna3 at yahoo.in" <ram_tanna3 at yahoo.in>
> Subject: Re: [Apiman-user] APIMAN configuration for high-load application
>
> Hi,
>
> Can you share a bit of information about your setup?
>
> For instance, if you share apiman.properties with any sensitive
> information taken out.
>
> This sounds like it could be a good candidate for trying our Vert.x-based
> gateway. I've been working a lot on it lately - it might be worth trying
> out in a test deployment. However, I'd need to know more about your
> existing setup, as the bottleneck might be elsewhere.
>
> Regards,
> Marc
>
> On 7 February 2017 at 12:55, <Ram.Tanna at ril.com> wrote:
>
>> Dear Team,
>>
>> We are using APIMAN in our application which would have 40k concurrent
>> requests.
>>
>> There would be around 7000 requests/second. Out of which 2500 requests
>> are for uploading and downloading a file with payload size of 512
>> KB/request. Other request will have payload of 50 to 80 KB.
>>
>> Folks who are using apiman in their system, can please share your
>> experience.
>>
>> What would be the best configuration for such high-load application ?
>>
>>
>> Thanks and Regards,
>> Ram Tanna
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> "*Confidentiality Warning*: This message and any attachments are
>> intended only for the use of the intended recipient(s), are confidential
>> and may be privileged. If you are not the intended recipient, you are
>> hereby notified that any review, re-transmission, conversion to hard copy,
>> copying, circulation or other use of this message and any attachments is
>> strictly prohibited. If you are not the intended recipient, please notify
>> the sender immediately by return email and delete this message and any
>> attachments from your system.
>>
>> *Virus Warning:* Although the company has taken reasonable precautions
>> to ensure no viruses are present in this email. The company cannot accept
>> responsibility for any loss or damage arising from the use of this email or
>> attachment."
>>
>> _______________________________________________
>> Apiman-user mailing list
>> Apiman-user at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/apiman-user
>>
>>
>
> "*Confidentiality Warning*: This message and any attachments are intended
> only for the use of the intended recipient(s), are confidential and may be
> privileged. If you are not the intended recipient, you are hereby notified
> that any review, re-transmission, conversion to hard copy, copying,
> circulation or other use of this message and any attachments is strictly
> prohibited. If you are not the intended recipient, please notify the sender
> immediately by return email and delete this message and any attachments
> from your system.
>
> *Virus Warning:* Although the company has taken reasonable precautions to
> ensure no viruses are present in this email. The company cannot accept
> responsibility for any loss or damage arising from the use of this email or
> attachment."
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20170207/c7d5c0bf/attachment-0001.html 

From sbalu27 at gmail.com  Tue Feb  7 11:02:17 2017
From: sbalu27 at gmail.com (Balu S)
Date: Tue, 7 Feb 2017 17:02:17 +0100
Subject: [Apiman-user] version migration
Message-ID: <CAEDnbHAYPhRGYttUF5TLpXwpFnUfq-htkXcPFFyyLCj8Ecd3Rg@mail.gmail.com>

Hello,
I would like to move to 1.2.10/1.2.9 version from 1.2.8 version in the
existing wildfly installation. As I have already configured  organizations,
API and ClientApps in existing installation and want to keep it safe from
being overwritten.

I can think of following options for migration, but not sure this would
work.

option 1:
-  Export the apiman data
-  unzip the 1.2.10 overlay zip
- Import the data using admin user

option 2:
 - replace only the wars taken from overlay zip to the wildfly /deployment
directory


Does unzip apiman overlay overwrites the configuration data ? What is the
ideal way ? Could you please advise ?

regards
Balu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20170207/631cf3da/attachment.html 

From marc.savy at redhat.com  Thu Feb  9 07:46:22 2017
From: marc.savy at redhat.com (Marc Savy)
Date: Thu, 9 Feb 2017 12:46:22 +0000
Subject: [Apiman-user] APIMAN configuration for high-load application
In-Reply-To: <CAA7j38Jxa8GbXFRdJ-R_1VMZmmNDfyonZx6t3+HjXnV1bfCvKA@mail.gmail.com>
References: <D4BFC1C6.1D0D%ram.tanna@ril.com>
	<CAA7j38Kthovb_+_M1T2sZfcmjQfkFZ9qSJwNdtfd5+ZaKdPQxg@mail.gmail.com>
	<D4BFCB75.1D20%ram.tanna@ril.com>
	<CAA7j38Jxa8GbXFRdJ-R_1VMZmmNDfyonZx6t3+HjXnV1bfCvKA@mail.gmail.com>
Message-ID: <CAA7j38+yj5oSs3aNSJQ4OG1pJRJ3ssnf2tcU3Rpuigv25N4+1A@mail.gmail.com>

Any useful findings?

On 7 February 2017 at 14:26, Marc Savy <marc.savy at redhat.com> wrote:

> Hi,
>
> Check out Harry Trinta's contributions to this thread:
> https://lists.jboss.org/pipermail/apiman-user/2017-January/000758.html
>
> Have you done any profiling and observed any particular bottlenecks?
>
> Regards,
> Marc
>
> On 7 February 2017 at 14:09, <Ram.Tanna at ril.com> wrote:
>
>> Hi Marc,
>>
>> We haven?t done any major changes in the default configuration and in
>> property file.
>>
>> Trying out Vert.x-based gateway would not be feasible at this moment as
>> we are into the production phase, and we want to achieve best output from
>> minimal modifications.
>>
>> Regards,
>> Ram Tanna
>>
>>
>>
>> From: Marc Savy <marc.savy at redhat.com>
>> Date: Tuesday, 7 February 2017 at 6:39 PM
>> To: Ram <ram.tanna at ril.com>
>> Cc: "apiman-user at lists.jboss.org" <apiman-user at lists.jboss.org>,
>> Manvendra Rai <manvendra.rai at ril.com>, Anshul Agrawal <
>> Anshul.Agrawal at ril.com>, "ram_tanna3 at yahoo.in" <ram_tanna3 at yahoo.in>
>> Subject: Re: [Apiman-user] APIMAN configuration for high-load application
>>
>> Hi,
>>
>> Can you share a bit of information about your setup?
>>
>> For instance, if you share apiman.properties with any sensitive
>> information taken out.
>>
>> This sounds like it could be a good candidate for trying our Vert.x-based
>> gateway. I've been working a lot on it lately - it might be worth trying
>> out in a test deployment. However, I'd need to know more about your
>> existing setup, as the bottleneck might be elsewhere.
>>
>> Regards,
>> Marc
>>
>> On 7 February 2017 at 12:55, <Ram.Tanna at ril.com> wrote:
>>
>>> Dear Team,
>>>
>>> We are using APIMAN in our application which would have 40k concurrent
>>> requests.
>>>
>>> There would be around 7000 requests/second. Out of which 2500 requests
>>> are for uploading and downloading a file with payload size of 512
>>> KB/request. Other request will have payload of 50 to 80 KB.
>>>
>>> Folks who are using apiman in their system, can please share your
>>> experience.
>>>
>>> What would be the best configuration for such high-load application ?
>>>
>>>
>>> Thanks and Regards,
>>> Ram Tanna
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> "*Confidentiality Warning*: This message and any attachments are
>>> intended only for the use of the intended recipient(s), are confidential
>>> and may be privileged. If you are not the intended recipient, you are
>>> hereby notified that any review, re-transmission, conversion to hard copy,
>>> copying, circulation or other use of this message and any attachments is
>>> strictly prohibited. If you are not the intended recipient, please notify
>>> the sender immediately by return email and delete this message and any
>>> attachments from your system.
>>>
>>> *Virus Warning:* Although the company has taken reasonable precautions
>>> to ensure no viruses are present in this email. The company cannot accept
>>> responsibility for any loss or damage arising from the use of this email or
>>> attachment."
>>>
>>> _______________________________________________
>>> Apiman-user mailing list
>>> Apiman-user at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/apiman-user
>>>
>>>
>>
>> "*Confidentiality Warning*: This message and any attachments are
>> intended only for the use of the intended recipient(s), are confidential
>> and may be privileged. If you are not the intended recipient, you are
>> hereby notified that any review, re-transmission, conversion to hard copy,
>> copying, circulation or other use of this message and any attachments is
>> strictly prohibited. If you are not the intended recipient, please notify
>> the sender immediately by return email and delete this message and any
>> attachments from your system.
>>
>> *Virus Warning:* Although the company has taken reasonable precautions
>> to ensure no viruses are present in this email. The company cannot accept
>> responsibility for any loss or damage arising from the use of this email or
>> attachment."
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20170209/1acb9250/attachment.html 

From eric.wittmann at redhat.com  Fri Feb 10 15:16:27 2017
From: eric.wittmann at redhat.com (Eric Wittmann)
Date: Fri, 10 Feb 2017 15:16:27 -0500
Subject: [Apiman-user] version migration
In-Reply-To: <CAEDnbHAYPhRGYttUF5TLpXwpFnUfq-htkXcPFFyyLCj8Ecd3Rg@mail.gmail.com>
References: <CAEDnbHAYPhRGYttUF5TLpXwpFnUfq-htkXcPFFyyLCj8Ecd3Rg@mail.gmail.com>
Message-ID: <CAP4n9Q_o=GTZ34SqdeDXVGQu9y5dioMpAjbQtoq2FOVuWUqNfQ@mail.gmail.com>

Hi Balu.

Apologies for the delay in responding.  Apiman is designed for option #1 -
export the data, install a fresh copy of 1.2.10, then import the data.

I recommend cloning your environment and trying out this approach in (for
example) DEV before doing it in production.  But the export/import process
is designed to facilitate this approach.

Regards,

Eric


On Tue, Feb 7, 2017 at 11:02 AM, Balu S <sbalu27 at gmail.com> wrote:

> Hello,
> I would like to move to 1.2.10/1.2.9 version from 1.2.8 version in the
> existing wildfly installation. As I have already configured  organizations,
> API and ClientApps in existing installation and want to keep it safe from
> being overwritten.
>
> I can think of following options for migration, but not sure this would
> work.
>
> option 1:
> -  Export the apiman data
> -  unzip the 1.2.10 overlay zip
> - Import the data using admin user
>
> option 2:
>  - replace only the wars taken from overlay zip to the wildfly /deployment
> directory
>
>
> Does unzip apiman overlay overwrites the configuration data ? What is the
> ideal way ? Could you please advise ?
>
> regards
> Balu
>
> _______________________________________________
> Apiman-user mailing list
> Apiman-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/apiman-user
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20170210/5cde5207/attachment.html 

From marc.savy at redhat.com  Tue Feb 14 12:40:04 2017
From: marc.savy at redhat.com (Marc Savy)
Date: Tue, 14 Feb 2017 17:40:04 +0000
Subject: [Apiman-user] APIMAN configuration for high-load application
In-Reply-To: <CAA7j38+yj5oSs3aNSJQ4OG1pJRJ3ssnf2tcU3Rpuigv25N4+1A@mail.gmail.com>
References: <D4BFC1C6.1D0D%ram.tanna@ril.com>
	<CAA7j38Kthovb_+_M1T2sZfcmjQfkFZ9qSJwNdtfd5+ZaKdPQxg@mail.gmail.com>
	<D4BFCB75.1D20%ram.tanna@ril.com>
	<CAA7j38Jxa8GbXFRdJ-R_1VMZmmNDfyonZx6t3+HjXnV1bfCvKA@mail.gmail.com>
	<CAA7j38+yj5oSs3aNSJQ4OG1pJRJ3ssnf2tcU3Rpuigv25N4+1A@mail.gmail.com>
Message-ID: <CAA7j38+O1VUuYt94LEKBqxUtZPv23bLZO3UoNV4yb_AhpRSu2g@mail.gmail.com>

Another thought. In your WF10 standalone.xml you can try substantially
boosting up the number of connections that Undertow allows:

See:

<request-limit name="limit-connections" max-concurrent-requests="15000"
queue-size="100"/>

An example is in the <filters> section of the following undertow config:

https://github.com/wildfly/wildfly/blob/master/undertow/
src/test/resources/org/wildfly/extension/undertow/undertow-3.1.xml



On 9 February 2017 at 12:46, Marc Savy <marc.savy at redhat.com> wrote:

> Any useful findings?
>
> On 7 February 2017 at 14:26, Marc Savy <marc.savy at redhat.com> wrote:
>
>> Hi,
>>
>> Check out Harry Trinta's contributions to this thread:
>> https://lists.jboss.org/pipermail/apiman-user/2017-January/000758.html
>>
>> Have you done any profiling and observed any particular bottlenecks?
>>
>> Regards,
>> Marc
>>
>> On 7 February 2017 at 14:09, <Ram.Tanna at ril.com> wrote:
>>
>>> Hi Marc,
>>>
>>> We haven?t done any major changes in the default configuration and in
>>> property file.
>>>
>>> Trying out Vert.x-based gateway would not be feasible at this moment as
>>> we are into the production phase, and we want to achieve best output from
>>> minimal modifications.
>>>
>>> Regards,
>>> Ram Tanna
>>>
>>>
>>>
>>> From: Marc Savy <marc.savy at redhat.com>
>>> Date: Tuesday, 7 February 2017 at 6:39 PM
>>> To: Ram <ram.tanna at ril.com>
>>> Cc: "apiman-user at lists.jboss.org" <apiman-user at lists.jboss.org>,
>>> Manvendra Rai <manvendra.rai at ril.com>, Anshul Agrawal <
>>> Anshul.Agrawal at ril.com>, "ram_tanna3 at yahoo.in" <ram_tanna3 at yahoo.in>
>>> Subject: Re: [Apiman-user] APIMAN configuration for high-load
>>> application
>>>
>>> Hi,
>>>
>>> Can you share a bit of information about your setup?
>>>
>>> For instance, if you share apiman.properties with any sensitive
>>> information taken out.
>>>
>>> This sounds like it could be a good candidate for trying our
>>> Vert.x-based gateway. I've been working a lot on it lately - it might be
>>> worth trying out in a test deployment. However, I'd need to know more about
>>> your existing setup, as the bottleneck might be elsewhere.
>>>
>>> Regards,
>>> Marc
>>>
>>> On 7 February 2017 at 12:55, <Ram.Tanna at ril.com> wrote:
>>>
>>>> Dear Team,
>>>>
>>>> We are using APIMAN in our application which would have 40k concurrent
>>>> requests.
>>>>
>>>> There would be around 7000 requests/second. Out of which 2500 requests
>>>> are for uploading and downloading a file with payload size of 512
>>>> KB/request. Other request will have payload of 50 to 80 KB.
>>>>
>>>> Folks who are using apiman in their system, can please share your
>>>> experience.
>>>>
>>>> What would be the best configuration for such high-load application ?
>>>>
>>>>
>>>> Thanks and Regards,
>>>> Ram Tanna
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> "*Confidentiality Warning*: This message and any attachments are
>>>> intended only for the use of the intended recipient(s), are confidential
>>>> and may be privileged. If you are not the intended recipient, you are
>>>> hereby notified that any review, re-transmission, conversion to hard copy,
>>>> copying, circulation or other use of this message and any attachments is
>>>> strictly prohibited. If you are not the intended recipient, please notify
>>>> the sender immediately by return email and delete this message and any
>>>> attachments from your system.
>>>>
>>>> *Virus Warning:* Although the company has taken reasonable precautions
>>>> to ensure no viruses are present in this email. The company cannot accept
>>>> responsibility for any loss or damage arising from the use of this email or
>>>> attachment."
>>>>
>>>> _______________________________________________
>>>> Apiman-user mailing list
>>>> Apiman-user at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/apiman-user
>>>>
>>>>
>>>
>>> "*Confidentiality Warning*: This message and any attachments are
>>> intended only for the use of the intended recipient(s), are confidential
>>> and may be privileged. If you are not the intended recipient, you are
>>> hereby notified that any review, re-transmission, conversion to hard copy,
>>> copying, circulation or other use of this message and any attachments is
>>> strictly prohibited. If you are not the intended recipient, please notify
>>> the sender immediately by return email and delete this message and any
>>> attachments from your system.
>>>
>>> *Virus Warning:* Although the company has taken reasonable precautions
>>> to ensure no viruses are present in this email. The company cannot accept
>>> responsibility for any loss or damage arising from the use of this email or
>>> attachment."
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20170214/f7348c69/attachment-0001.html 

From marc.savy at redhat.com  Tue Feb 14 13:38:26 2017
From: marc.savy at redhat.com (Marc Savy)
Date: Tue, 14 Feb 2017 18:38:26 +0000
Subject: [Apiman-user] APIMAN configuration for high-load application
In-Reply-To: <CAA7j38+O1VUuYt94LEKBqxUtZPv23bLZO3UoNV4yb_AhpRSu2g@mail.gmail.com>
References: <D4BFC1C6.1D0D%ram.tanna@ril.com>
	<CAA7j38Kthovb_+_M1T2sZfcmjQfkFZ9qSJwNdtfd5+ZaKdPQxg@mail.gmail.com>
	<D4BFCB75.1D20%ram.tanna@ril.com>
	<CAA7j38Jxa8GbXFRdJ-R_1VMZmmNDfyonZx6t3+HjXnV1bfCvKA@mail.gmail.com>
	<CAA7j38+yj5oSs3aNSJQ4OG1pJRJ3ssnf2tcU3Rpuigv25N4+1A@mail.gmail.com>
	<CAA7j38+O1VUuYt94LEKBqxUtZPv23bLZO3UoNV4yb_AhpRSu2g@mail.gmail.com>
Message-ID: <CAA7j38K7Wnb+ZzYbx+qwxRYP6zHAfvCq-rD9Ss4uHn7SoFQWmw@mail.gmail.com>

Further to this, I've found that the threadpool between the gateway and the
API can become exhausted. Bump it up using the following environment
variable:

-Dhttp.maxConnections=100

# Just an example, tweak as you see fit...

JAVA_OPTS="-Xmx4g" ./bin/standalone.sh -Dhttp.maxConnections=100

On 14 February 2017 at 17:40, Marc Savy <marc.savy at redhat.com> wrote:

> Another thought. In your WF10 standalone.xml you can try substantially
> boosting up the number of connections that Undertow allows:
>
> See:
>
> <request-limit name="limit-connections" max-concurrent-requests="15000"
> queue-size="100"/>
>
> An example is in the <filters> section of the following undertow config:
>
> https://github.com/wildfly/wildfly/blob/master/undertow/src/
> test/resources/org/wildfly/extension/undertow/undertow-3.1.xml
>
>
>
> On 9 February 2017 at 12:46, Marc Savy <marc.savy at redhat.com> wrote:
>
>> Any useful findings?
>>
>> On 7 February 2017 at 14:26, Marc Savy <marc.savy at redhat.com> wrote:
>>
>>> Hi,
>>>
>>> Check out Harry Trinta's contributions to this thread:
>>> https://lists.jboss.org/pipermail/apiman-user/2017-January/000758.html
>>>
>>> Have you done any profiling and observed any particular bottlenecks?
>>>
>>> Regards,
>>> Marc
>>>
>>> On 7 February 2017 at 14:09, <Ram.Tanna at ril.com> wrote:
>>>
>>>> Hi Marc,
>>>>
>>>> We haven?t done any major changes in the default configuration and in
>>>> property file.
>>>>
>>>> Trying out Vert.x-based gateway would not be feasible at this moment as
>>>> we are into the production phase, and we want to achieve best output from
>>>> minimal modifications.
>>>>
>>>> Regards,
>>>> Ram Tanna
>>>>
>>>>
>>>>
>>>> From: Marc Savy <marc.savy at redhat.com>
>>>> Date: Tuesday, 7 February 2017 at 6:39 PM
>>>> To: Ram <ram.tanna at ril.com>
>>>> Cc: "apiman-user at lists.jboss.org" <apiman-user at lists.jboss.org>,
>>>> Manvendra Rai <manvendra.rai at ril.com>, Anshul Agrawal <
>>>> Anshul.Agrawal at ril.com>, "ram_tanna3 at yahoo.in" <ram_tanna3 at yahoo.in>
>>>> Subject: Re: [Apiman-user] APIMAN configuration for high-load
>>>> application
>>>>
>>>> Hi,
>>>>
>>>> Can you share a bit of information about your setup?
>>>>
>>>> For instance, if you share apiman.properties with any sensitive
>>>> information taken out.
>>>>
>>>> This sounds like it could be a good candidate for trying our
>>>> Vert.x-based gateway. I've been working a lot on it lately - it might be
>>>> worth trying out in a test deployment. However, I'd need to know more about
>>>> your existing setup, as the bottleneck might be elsewhere.
>>>>
>>>> Regards,
>>>> Marc
>>>>
>>>> On 7 February 2017 at 12:55, <Ram.Tanna at ril.com> wrote:
>>>>
>>>>> Dear Team,
>>>>>
>>>>> We are using APIMAN in our application which would have 40k concurrent
>>>>> requests.
>>>>>
>>>>> There would be around 7000 requests/second. Out of which 2500 requests
>>>>> are for uploading and downloading a file with payload size of 512
>>>>> KB/request. Other request will have payload of 50 to 80 KB.
>>>>>
>>>>> Folks who are using apiman in their system, can please share your
>>>>> experience.
>>>>>
>>>>> What would be the best configuration for such high-load application ?
>>>>>
>>>>>
>>>>> Thanks and Regards,
>>>>> Ram Tanna
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> "*Confidentiality Warning*: This message and any attachments are
>>>>> intended only for the use of the intended recipient(s), are confidential
>>>>> and may be privileged. If you are not the intended recipient, you are
>>>>> hereby notified that any review, re-transmission, conversion to hard copy,
>>>>> copying, circulation or other use of this message and any attachments is
>>>>> strictly prohibited. If you are not the intended recipient, please notify
>>>>> the sender immediately by return email and delete this message and any
>>>>> attachments from your system.
>>>>>
>>>>> *Virus Warning:* Although the company has taken reasonable
>>>>> precautions to ensure no viruses are present in this email. The company
>>>>> cannot accept responsibility for any loss or damage arising from the use of
>>>>> this email or attachment."
>>>>>
>>>>> _______________________________________________
>>>>> Apiman-user mailing list
>>>>> Apiman-user at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/apiman-user
>>>>>
>>>>>
>>>>
>>>> "*Confidentiality Warning*: This message and any attachments are
>>>> intended only for the use of the intended recipient(s), are confidential
>>>> and may be privileged. If you are not the intended recipient, you are
>>>> hereby notified that any review, re-transmission, conversion to hard copy,
>>>> copying, circulation or other use of this message and any attachments is
>>>> strictly prohibited. If you are not the intended recipient, please notify
>>>> the sender immediately by return email and delete this message and any
>>>> attachments from your system.
>>>>
>>>> *Virus Warning:* Although the company has taken reasonable precautions
>>>> to ensure no viruses are present in this email. The company cannot accept
>>>> responsibility for any loss or damage arising from the use of this email or
>>>> attachment."
>>>>
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20170214/81eda651/attachment.html 

From Ram.Tanna at ril.com  Wed Feb 15 02:13:12 2017
From: Ram.Tanna at ril.com (Ram.Tanna at ril.com)
Date: Wed, 15 Feb 2017 07:13:12 +0000
Subject: [Apiman-user] APIMAN configuration for high-load application
In-Reply-To: <CAA7j38K7Wnb+ZzYbx+qwxRYP6zHAfvCq-rD9Ss4uHn7SoFQWmw@mail.gmail.com>
References: <D4BFC1C6.1D0D%ram.tanna@ril.com>
	<CAA7j38Kthovb_+_M1T2sZfcmjQfkFZ9qSJwNdtfd5+ZaKdPQxg@mail.gmail.com>
	<D4BFCB75.1D20%ram.tanna@ril.com>
	<CAA7j38Jxa8GbXFRdJ-R_1VMZmmNDfyonZx6t3+HjXnV1bfCvKA@mail.gmail.com>
	<CAA7j38+yj5oSs3aNSJQ4OG1pJRJ3ssnf2tcU3Rpuigv25N4+1A@mail.gmail.com>
	<CAA7j38+O1VUuYt94LEKBqxUtZPv23bLZO3UoNV4yb_AhpRSu2g@mail.gmail.com>
	<CAA7j38K7Wnb+ZzYbx+qwxRYP6zHAfvCq-rD9Ss4uHn7SoFQWmw@mail.gmail.com>
Message-ID: <D4C9FCFB.2242%ram.tanna@ril.com>

Hey Marc,

Thank you for the contribution.

I will make mentioned changes, and share the result with you.

Regards,
Ram Tanna

From: Marc Savy <marc.savy at redhat.com<mailto:marc.savy at redhat.com>>
Date: Wednesday, 15 February 2017 at 12:08 AM
To: Ram <ram.tanna at ril.com<mailto:ram.tanna at ril.com>>
Cc: "apiman-user at lists.jboss.org<mailto:apiman-user at lists.jboss.org>" <apiman-user at lists.jboss.org<mailto:apiman-user at lists.jboss.org>>, Manvendra Rai <manvendra.rai at ril.com<mailto:manvendra.rai at ril.com>>, "ram_tanna3 at yahoo.in<mailto:ram_tanna3 at yahoo.in>" <ram_tanna3 at yahoo.in<mailto:ram_tanna3 at yahoo.in>>
Subject: Re: [Apiman-user] APIMAN configuration for high-load application

Further to this, I've found that the threadpool between the gateway and the API can become exhausted. Bump it up using the following environment variable:

-Dhttp.maxConnections=100

# Just an example, tweak as you see fit...

JAVA_OPTS="-Xmx4g" ./bin/standalone.sh -Dhttp.maxConnections=100

On 14 February 2017 at 17:40, Marc Savy <marc.savy at redhat.com<mailto:marc.savy at redhat.com>> wrote:
Another thought. In your WF10 standalone.xml you can try substantially boosting up the number of connections that Undertow allows:

See:

<request-limit name="limit-connections" max-concurrent-requests="15000" queue-size="100"/>

An example is in the <filters> section of the following undertow config:

https://github.com/wildfly/wildfly/blob/master/undertow/src/test/resources/org/wildfly/extension/undertow/undertow-3.1.xml



On 9 February 2017 at 12:46, Marc Savy <marc.savy at redhat.com<mailto:marc.savy at redhat.com>> wrote:
Any useful findings?

On 7 February 2017 at 14:26, Marc Savy <marc.savy at redhat.com<mailto:marc.savy at redhat.com>> wrote:
Hi,

Check out Harry Trinta's contributions to this thread: https://lists.jboss.org/pipermail/apiman-user/2017-January/000758.html

Have you done any profiling and observed any particular bottlenecks?

Regards,
Marc

On 7 February 2017 at 14:09, <Ram.Tanna at ril.com<mailto:Ram.Tanna at ril.com>> wrote:
Hi Marc,

We haven't done any major changes in the default configuration and in property file.

Trying out Vert.x-based gateway would not be feasible at this moment as we are into the production phase, and we want to achieve best output from minimal modifications.

Regards,
Ram Tanna



From: Marc Savy <marc.savy at redhat.com<mailto:marc.savy at redhat.com>>
Date: Tuesday, 7 February 2017 at 6:39 PM
To: Ram <ram.tanna at ril.com<mailto:ram.tanna at ril.com>>
Cc: "apiman-user at lists.jboss.org<mailto:apiman-user at lists.jboss.org>" <apiman-user at lists.jboss.org<mailto:apiman-user at lists.jboss.org>>, Manvendra Rai <manvendra.rai at ril.com<mailto:manvendra.rai at ril.com>>, Anshul Agrawal <Anshul.Agrawal at ril.com<mailto:Anshul.Agrawal at ril.com>>, "ram_tanna3 at yahoo.in<mailto:ram_tanna3 at yahoo.in>" <ram_tanna3 at yahoo.in<mailto:ram_tanna3 at yahoo.in>>
Subject: Re: [Apiman-user] APIMAN configuration for high-load application

Hi,

Can you share a bit of information about your setup?

For instance, if you share apiman.properties with any sensitive information taken out.

This sounds like it could be a good candidate for trying our Vert.x-based gateway. I've been working a lot on it lately - it might be worth trying out in a test deployment. However, I'd need to know more about your existing setup, as the bottleneck might be elsewhere.

Regards,
Marc

On 7 February 2017 at 12:55, <Ram.Tanna at ril.com<mailto:Ram.Tanna at ril.com>> wrote:
Dear Team,

We are using APIMAN in our application which would have 40k concurrent requests.

There would be around 7000 requests/second. Out of which 2500 requests are for uploading and downloading a file with payload size of 512 KB/request. Other request will have payload of 50 to 80 KB.

Folks who are using apiman in their system, can please share your experience.

What would be the best configuration for such high-load application ?


Thanks and Regards,
Ram Tanna









"Confidentiality Warning: This message and any attachments are intended only for the use of the intended recipient(s), are confidential and may be privileged. If you are not the intended recipient, you are hereby notified that any review, re-transmission, conversion to hard copy, copying, circulation or other use of this message and any attachments is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email and delete this message and any attachments from your system.

Virus Warning: Although the company has taken reasonable precautions to ensure no viruses are present in this email. The company cannot accept responsibility for any loss or damage arising from the use of this email or attachment."

_______________________________________________
Apiman-user mailing list
Apiman-user at lists.jboss.org<mailto:Apiman-user at lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/apiman-user



"Confidentiality Warning: This message and any attachments are intended only for the use of the intended recipient(s), are confidential and may be privileged. If you are not the intended recipient, you are hereby notified that any review, re-transmission, conversion to hard copy, copying, circulation or other use of this message and any attachments is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email and delete this message and any attachments from your system.

Virus Warning: Although the company has taken reasonable precautions to ensure no viruses are present in this email. The company cannot accept responsibility for any loss or damage arising from the use of this email or attachment."




"Confidentiality Warning: This message and any attachments are intended only for the use of the intended recipient(s). 
are confidential and may be privileged. If you are not the intended recipient. you are hereby notified that any 
review. re-transmission. conversion to hard copy. copying. circulation or other use of this message and any attachments is 
strictly prohibited. If you are not the intended recipient. please notify the sender immediately by return email. 
and delete this message and any attachments from your system.

Virus Warning: Although the company has taken reasonable precautions to ensure no viruses are present in this email. 
The company cannot accept responsibility for any loss or damage arising from the use of this email or attachment."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20170215/96098db5/attachment-0001.html 

From sbalu27 at gmail.com  Thu Feb 16 05:34:02 2017
From: sbalu27 at gmail.com (Balu S)
Date: Thu, 16 Feb 2017 11:34:02 +0100
Subject: [Apiman-user] duplicate response on Connetor timeout
Message-ID: <CAEDnbHD3J7DDNc6L22=5_S5MkjOfxYUwWzFuo2UQEcvdc0-zqw@mail.gmail.com>

Hello,
I have found that if the HTTPConnector times out without receiving the
response from the backend API, then somewhere down the line it generates 2
error responses and this is evident from the metrics as it show 2 failures
as supposed to 1 failure for the single request.

So there are 2 issues,
  - firstly the returned error response contains 2 error XMLs appended to
each other and sent to the browser and hence not a valid XML.
  - The metrics also shows as 2 failure response for single request.

?
I have been looking the sources but without the way to debug within running
application, it quite hard to follow the flow.

This can be easily simulated with setting very low timeouts (2 secs for ex)
in apiman.properties.

apiman-gateway.connector-factory.http.timeouts.read=2
apiman-gateway.connector-factory.http.timeouts.write=2

Could you please look at the issue and also If you could guide me how to
setup debugging environment, then I can try to fix that as well.

regards
Balu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20170216/193924a8/attachment.html 

From sbalu27 at gmail.com  Thu Feb 16 05:38:17 2017
From: sbalu27 at gmail.com (Balu S)
Date: Thu, 16 Feb 2017 11:38:17 +0100
Subject: [Apiman-user] duplicate response on Connetor timeout
In-Reply-To: <CAEDnbHD3J7DDNc6L22=5_S5MkjOfxYUwWzFuo2UQEcvdc0-zqw@mail.gmail.com>
References: <CAEDnbHD3J7DDNc6L22=5_S5MkjOfxYUwWzFuo2UQEcvdc0-zqw@mail.gmail.com>
Message-ID: <CAEDnbHAukJmiVZEa8Z901muZ1n03-qAo-C24UdT0nbM9sJGC1A@mail.gmail.com>

[image: Inline image 1]

On Thu, Feb 16, 2017 at 11:34 AM, Balu S <sbalu27 at gmail.com> wrote:

> Hello,
> I have found that if the HTTPConnector times out without receiving the
> response from the backend API, then somewhere down the line it generates 2
> error responses and this is evident from the metrics as it show 2 failures
> as supposed to 1 failure for the single request.
>
> So there are 2 issues,
>   - firstly the returned error response contains 2 error XMLs appended to
> each other and sent to the browser and hence not a valid XML.
>   - The metrics also shows as 2 failure response for single request.
>
> ?
> I have been looking the sources but without the way to debug within
> running application, it quite hard to follow the flow.
>
> This can be easily simulated with setting very low timeouts (2 secs for
> ex) in apiman.properties.
>
> apiman-gateway.connector-factory.http.timeouts.read=2
> apiman-gateway.connector-factory.http.timeouts.write=2
>
> Could you please look at the issue and also If you could guide me how to
> setup debugging environment, then I can try to fix that as well.
>
> regards
> Balu
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20170216/cd198dd7/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 29503 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/apiman-user/attachments/20170216/cd198dd7/attachment-0001.png 

From marc.savy at redhat.com  Thu Feb 16 06:05:09 2017
From: marc.savy at redhat.com (Marc Savy)
Date: Thu, 16 Feb 2017 11:05:09 +0000
Subject: [Apiman-user] duplicate response on Connetor timeout
In-Reply-To: <CAEDnbHD3J7DDNc6L22=5_S5MkjOfxYUwWzFuo2UQEcvdc0-zqw@mail.gmail.com>
References: <CAEDnbHD3J7DDNc6L22=5_S5MkjOfxYUwWzFuo2UQEcvdc0-zqw@mail.gmail.com>
Message-ID: <CAA7j38+5N90rcCBd73fHciOP-bU_PL2QinA1uRRs_pN_Tv=ATg@mail.gmail.com>

With regards to debugging:

I assume you are using the Servlet/WAR gateway with WildFly?

If so, I suggest you consult the WF debugging guides -- but, in short, you
can start up the application server with --debug and connect to it remotely
from  your debugger (e.g. Eclipse, IntelliJ, etc).

https://tools.jboss.org/blog/2015-03-17-debugging-an-externally-launched-wildfly.html

Regards,
Marc

On 16 February 2017 at 10:34, Balu S <sbalu27 at gmail.com> wrote:

> Hello,
> I have found that if the HTTPConnector times out without receiving the
> response from the backend API, then somewhere down the line it generates 2
> error responses and this is evident from the metrics as it show 2 failures
> as supposed to 1 failure for the single request.
>
> So there are 2 issues,
>   - firstly the returned error response contains 2 error XMLs appended to
> each other and sent to the browser and hence not a valid XML.
>   - The metrics also shows as 2 failure response for single request.
>
> ?
> I have been looking the sources but without the way to debug within
> running application, it quite hard to follow the flow.
>
> This can be easily simulated with setting very low timeouts (2 secs for
> ex) in apiman.properties.
>
> apiman-gateway.connector-factory.http.timeouts.read=2
> apiman-gateway.connector-factory.http.timeouts.write=2
>
> Could you please look at the issue and also If you could guide me how to
> setup debugging environment, then I can try to fix that as well.
>
> regards
> Balu
>
> _______________________________________________
> Apiman-user mailing list
> Apiman-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/apiman-user
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20170216/25c57b67/attachment.html 

From sbalu27 at gmail.com  Thu Feb 16 06:14:07 2017
From: sbalu27 at gmail.com (Balu S)
Date: Thu, 16 Feb 2017 12:14:07 +0100
Subject: [Apiman-user] duplicate response on Connetor timeout
In-Reply-To: <CAA7j38+5N90rcCBd73fHciOP-bU_PL2QinA1uRRs_pN_Tv=ATg@mail.gmail.com>
References: <CAEDnbHD3J7DDNc6L22=5_S5MkjOfxYUwWzFuo2UQEcvdc0-zqw@mail.gmail.com>
	<CAA7j38+5N90rcCBd73fHciOP-bU_PL2QinA1uRRs_pN_Tv=ATg@mail.gmail.com>
Message-ID: <CAEDnbHD1dV6qemThE05R0Yst7hnsd_Q4T+EpuOxHQmEjHy6VUQ@mail.gmail.com>

Thanks Marc. yes it is Servlet/Wildfly setup.

The problem with my setup is am behind proxy so using the overlay zip (on
top of local wildfly installtion) generated from outside machine. So cannot
build the apiman sources from within eclipse. I shall try.

On Thu, Feb 16, 2017 at 12:05 PM, Marc Savy <marc.savy at redhat.com> wrote:

> With regards to debugging:
>
> I assume you are using the Servlet/WAR gateway with WildFly?
>
> If so, I suggest you consult the WF debugging guides -- but, in short, you
> can start up the application server with --debug and connect to it remotely
> from  your debugger (e.g. Eclipse, IntelliJ, etc).
>
> https://tools.jboss.org/blog/2015-03-17-debugging-an-
> externally-launched-wildfly.html
>
> Regards,
> Marc
>
> On 16 February 2017 at 10:34, Balu S <sbalu27 at gmail.com> wrote:
>
>> Hello,
>> I have found that if the HTTPConnector times out without receiving the
>> response from the backend API, then somewhere down the line it generates 2
>> error responses and this is evident from the metrics as it show 2 failures
>> as supposed to 1 failure for the single request.
>>
>> So there are 2 issues,
>>   - firstly the returned error response contains 2 error XMLs appended to
>> each other and sent to the browser and hence not a valid XML.
>>   - The metrics also shows as 2 failure response for single request.
>>
>> ?
>> I have been looking the sources but without the way to debug within
>> running application, it quite hard to follow the flow.
>>
>> This can be easily simulated with setting very low timeouts (2 secs for
>> ex) in apiman.properties.
>>
>> apiman-gateway.connector-factory.http.timeouts.read=2
>> apiman-gateway.connector-factory.http.timeouts.write=2
>>
>> Could you please look at the issue and also If you could guide me how to
>> setup debugging environment, then I can try to fix that as well.
>>
>> regards
>> Balu
>>
>> _______________________________________________
>> Apiman-user mailing list
>> Apiman-user at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/apiman-user
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20170216/b2849f7e/attachment.html 

From marc.savy at redhat.com  Thu Feb 16 08:04:20 2017
From: marc.savy at redhat.com (Marc Savy)
Date: Thu, 16 Feb 2017 13:04:20 +0000
Subject: [Apiman-user] duplicate response on Connetor timeout
In-Reply-To: <CAEDnbHD1dV6qemThE05R0Yst7hnsd_Q4T+EpuOxHQmEjHy6VUQ@mail.gmail.com>
References: <CAEDnbHD3J7DDNc6L22=5_S5MkjOfxYUwWzFuo2UQEcvdc0-zqw@mail.gmail.com>
	<CAA7j38+5N90rcCBd73fHciOP-bU_PL2QinA1uRRs_pN_Tv=ATg@mail.gmail.com>
	<CAEDnbHD1dV6qemThE05R0Yst7hnsd_Q4T+EpuOxHQmEjHy6VUQ@mail.gmail.com>
Message-ID: <CAA7j38L8hy5wGjgsF++-V2-YC4sec_+HntafonFfOPOHZTdJFw@mail.gmail.com>

You may want to consider running apiman locally on your development machine
when doing debugging/reproducer work. This particular issue should be
simple to reproduce locally, I should think.

On 16 February 2017 at 11:14, Balu S <sbalu27 at gmail.com> wrote:

> Thanks Marc. yes it is Servlet/Wildfly setup.
>
> The problem with my setup is am behind proxy so using the overlay zip (on
> top of local wildfly installtion) generated from outside machine. So cannot
> build the apiman sources from within eclipse. I shall try.
>
> On Thu, Feb 16, 2017 at 12:05 PM, Marc Savy <marc.savy at redhat.com> wrote:
>
>> With regards to debugging:
>>
>> I assume you are using the Servlet/WAR gateway with WildFly?
>>
>> If so, I suggest you consult the WF debugging guides -- but, in short,
>> you can start up the application server with --debug and connect to it
>> remotely from  your debugger (e.g. Eclipse, IntelliJ, etc).
>>
>> https://tools.jboss.org/blog/2015-03-17-debugging-an-externa
>> lly-launched-wildfly.html
>>
>> Regards,
>> Marc
>>
>> On 16 February 2017 at 10:34, Balu S <sbalu27 at gmail.com> wrote:
>>
>>> Hello,
>>> I have found that if the HTTPConnector times out without receiving the
>>> response from the backend API, then somewhere down the line it generates 2
>>> error responses and this is evident from the metrics as it show 2 failures
>>> as supposed to 1 failure for the single request.
>>>
>>> So there are 2 issues,
>>>   - firstly the returned error response contains 2 error XMLs appended
>>> to each other and sent to the browser and hence not a valid XML.
>>>   - The metrics also shows as 2 failure response for single request.
>>>
>>> ?
>>> I have been looking the sources but without the way to debug within
>>> running application, it quite hard to follow the flow.
>>>
>>> This can be easily simulated with setting very low timeouts (2 secs for
>>> ex) in apiman.properties.
>>>
>>> apiman-gateway.connector-factory.http.timeouts.read=2
>>> apiman-gateway.connector-factory.http.timeouts.write=2
>>>
>>> Could you please look at the issue and also If you could guide me how to
>>> setup debugging environment, then I can try to fix that as well.
>>>
>>> regards
>>> Balu
>>>
>>> _______________________________________________
>>> Apiman-user mailing list
>>> Apiman-user at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/apiman-user
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20170216/e4ac4305/attachment.html 

From sbalu27 at gmail.com  Fri Feb 17 09:53:46 2017
From: sbalu27 at gmail.com (Balu S)
Date: Fri, 17 Feb 2017 15:53:46 +0100
Subject: [Apiman-user] duplicate response on Connetor timeout
In-Reply-To: <CAA7j38L8hy5wGjgsF++-V2-YC4sec_+HntafonFfOPOHZTdJFw@mail.gmail.com>
References: <CAEDnbHD3J7DDNc6L22=5_S5MkjOfxYUwWzFuo2UQEcvdc0-zqw@mail.gmail.com>
	<CAA7j38+5N90rcCBd73fHciOP-bU_PL2QinA1uRRs_pN_Tv=ATg@mail.gmail.com>
	<CAEDnbHD1dV6qemThE05R0Yst7hnsd_Q4T+EpuOxHQmEjHy6VUQ@mail.gmail.com>
	<CAA7j38L8hy5wGjgsF++-V2-YC4sec_+HntafonFfOPOHZTdJFw@mail.gmail.com>
Message-ID: <CAEDnbHCh9HVZEGUnjd68o3PG1mTKQCWpoYNpowDLf-MOsF+8bw@mail.gmail.com>

I will have to use this machine where it can connect to API. The problem is
there is "npm install" during the build process as am behind proxy it fails
during the execution.

What does the npm install do in apimanager-ui-war..How do I skip it  ?

regards
Balu

On Thu, Feb 16, 2017 at 2:04 PM, Marc Savy <marc.savy at redhat.com> wrote:

> You may want to consider running apiman locally on your development
> machine when doing debugging/reproducer work. This particular issue should
> be simple to reproduce locally, I should think.
>
> On 16 February 2017 at 11:14, Balu S <sbalu27 at gmail.com> wrote:
>
>> Thanks Marc. yes it is Servlet/Wildfly setup.
>>
>> The problem with my setup is am behind proxy so using the overlay zip (on
>> top of local wildfly installtion) generated from outside machine. So cannot
>> build the apiman sources from within eclipse. I shall try.
>>
>> On Thu, Feb 16, 2017 at 12:05 PM, Marc Savy <marc.savy at redhat.com> wrote:
>>
>>> With regards to debugging:
>>>
>>> I assume you are using the Servlet/WAR gateway with WildFly?
>>>
>>> If so, I suggest you consult the WF debugging guides -- but, in short,
>>> you can start up the application server with --debug and connect to it
>>> remotely from  your debugger (e.g. Eclipse, IntelliJ, etc).
>>>
>>> https://tools.jboss.org/blog/2015-03-17-debugging-an-externa
>>> lly-launched-wildfly.html
>>>
>>> Regards,
>>> Marc
>>>
>>> On 16 February 2017 at 10:34, Balu S <sbalu27 at gmail.com> wrote:
>>>
>>>> Hello,
>>>> I have found that if the HTTPConnector times out without receiving the
>>>> response from the backend API, then somewhere down the line it generates 2
>>>> error responses and this is evident from the metrics as it show 2 failures
>>>> as supposed to 1 failure for the single request.
>>>>
>>>> So there are 2 issues,
>>>>   - firstly the returned error response contains 2 error XMLs appended
>>>> to each other and sent to the browser and hence not a valid XML.
>>>>   - The metrics also shows as 2 failure response for single request.
>>>>
>>>> ?
>>>> I have been looking the sources but without the way to debug within
>>>> running application, it quite hard to follow the flow.
>>>>
>>>> This can be easily simulated with setting very low timeouts (2 secs for
>>>> ex) in apiman.properties.
>>>>
>>>> apiman-gateway.connector-factory.http.timeouts.read=2
>>>> apiman-gateway.connector-factory.http.timeouts.write=2
>>>>
>>>> Could you please look at the issue and also If you could guide me how
>>>> to setup debugging environment, then I can try to fix that as well.
>>>>
>>>> regards
>>>> Balu
>>>>
>>>> _______________________________________________
>>>> Apiman-user mailing list
>>>> Apiman-user at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/apiman-user
>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20170217/ec4c9f92/attachment-0001.html 

From marc.savy at redhat.com  Fri Feb 17 10:12:04 2017
From: marc.savy at redhat.com (Marc Savy)
Date: Fri, 17 Feb 2017 15:12:04 +0000
Subject: [Apiman-user] duplicate response on Connetor timeout
In-Reply-To: <CAEDnbHCh9HVZEGUnjd68o3PG1mTKQCWpoYNpowDLf-MOsF+8bw@mail.gmail.com>
References: <CAEDnbHD3J7DDNc6L22=5_S5MkjOfxYUwWzFuo2UQEcvdc0-zqw@mail.gmail.com>
	<CAA7j38+5N90rcCBd73fHciOP-bU_PL2QinA1uRRs_pN_Tv=ATg@mail.gmail.com>
	<CAEDnbHD1dV6qemThE05R0Yst7hnsd_Q4T+EpuOxHQmEjHy6VUQ@mail.gmail.com>
	<CAA7j38L8hy5wGjgsF++-V2-YC4sec_+HntafonFfOPOHZTdJFw@mail.gmail.com>
	<CAEDnbHCh9HVZEGUnjd68o3PG1mTKQCWpoYNpowDLf-MOsF+8bw@mail.gmail.com>
Message-ID: <CAA7j38Lg3SH95MJxmFSZ7LaUOm21VufA-jrOXzTqVYcJOfuDeQ@mail.gmail.com>

Hi,

http://stackoverflow.com/a/27177197/2766538

i.e.

mvn clean install -pl
\!io.apiman:apiman-manager-ui,\!io.apiman:apiman-manager-ui-war




On 17 February 2017 at 14:53, Balu S <sbalu27 at gmail.com> wrote:

> I will have to use this machine where it can connect to API. The problem
> is there is "npm install" during the build process as am behind proxy it
> fails during the execution.
>
> What does the npm install do in apimanager-ui-war..How do I skip it  ?
>
> regards
> Balu
>
> On Thu, Feb 16, 2017 at 2:04 PM, Marc Savy <marc.savy at redhat.com> wrote:
>
>> You may want to consider running apiman locally on your development
>> machine when doing debugging/reproducer work. This particular issue should
>> be simple to reproduce locally, I should think.
>>
>> On 16 February 2017 at 11:14, Balu S <sbalu27 at gmail.com> wrote:
>>
>>> Thanks Marc. yes it is Servlet/Wildfly setup.
>>>
>>> The problem with my setup is am behind proxy so using the overlay zip
>>> (on top of local wildfly installtion) generated from outside machine. So
>>> cannot build the apiman sources from within eclipse. I shall try.
>>>
>>> On Thu, Feb 16, 2017 at 12:05 PM, Marc Savy <marc.savy at redhat.com>
>>> wrote:
>>>
>>>> With regards to debugging:
>>>>
>>>> I assume you are using the Servlet/WAR gateway with WildFly?
>>>>
>>>> If so, I suggest you consult the WF debugging guides -- but, in short,
>>>> you can start up the application server with --debug and connect to it
>>>> remotely from  your debugger (e.g. Eclipse, IntelliJ, etc).
>>>>
>>>> https://tools.jboss.org/blog/2015-03-17-debugging-an-externa
>>>> lly-launched-wildfly.html
>>>>
>>>> Regards,
>>>> Marc
>>>>
>>>> On 16 February 2017 at 10:34, Balu S <sbalu27 at gmail.com> wrote:
>>>>
>>>>> Hello,
>>>>> I have found that if the HTTPConnector times out without receiving the
>>>>> response from the backend API, then somewhere down the line it generates 2
>>>>> error responses and this is evident from the metrics as it show 2 failures
>>>>> as supposed to 1 failure for the single request.
>>>>>
>>>>> So there are 2 issues,
>>>>>   - firstly the returned error response contains 2 error XMLs appended
>>>>> to each other and sent to the browser and hence not a valid XML.
>>>>>   - The metrics also shows as 2 failure response for single request.
>>>>>
>>>>> ?
>>>>> I have been looking the sources but without the way to debug within
>>>>> running application, it quite hard to follow the flow.
>>>>>
>>>>> This can be easily simulated with setting very low timeouts (2 secs
>>>>> for ex) in apiman.properties.
>>>>>
>>>>> apiman-gateway.connector-factory.http.timeouts.read=2
>>>>> apiman-gateway.connector-factory.http.timeouts.write=2
>>>>>
>>>>> Could you please look at the issue and also If you could guide me how
>>>>> to setup debugging environment, then I can try to fix that as well.
>>>>>
>>>>> regards
>>>>> Balu
>>>>>
>>>>> _______________________________________________
>>>>> Apiman-user mailing list
>>>>> Apiman-user at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/apiman-user
>>>>>
>>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20170217/d3fd5cc0/attachment.html 

From marc.savy at redhat.com  Fri Feb 17 12:23:56 2017
From: marc.savy at redhat.com (Marc Savy)
Date: Fri, 17 Feb 2017 17:23:56 +0000
Subject: [Apiman-user] duplicate response on Connetor timeout
In-Reply-To: <CAEDnbHCh9HVZEGUnjd68o3PG1mTKQCWpoYNpowDLf-MOsF+8bw@mail.gmail.com>
References: <CAEDnbHD3J7DDNc6L22=5_S5MkjOfxYUwWzFuo2UQEcvdc0-zqw@mail.gmail.com>
	<CAA7j38+5N90rcCBd73fHciOP-bU_PL2QinA1uRRs_pN_Tv=ATg@mail.gmail.com>
	<CAEDnbHD1dV6qemThE05R0Yst7hnsd_Q4T+EpuOxHQmEjHy6VUQ@mail.gmail.com>
	<CAA7j38L8hy5wGjgsF++-V2-YC4sec_+HntafonFfOPOHZTdJFw@mail.gmail.com>
	<CAEDnbHCh9HVZEGUnjd68o3PG1mTKQCWpoYNpowDLf-MOsF+8bw@mail.gmail.com>
Message-ID: <CAA7j38JGyYFxjq8D9P_tdecjbhPtUWrDN6Fqzb94DT4um+EqQw@mail.gmail.com>

If you want to build apiman quickly you can use (NB: skips tests which
don't presently work when run in parallel):

- mvn clean install -DskipTests=true -Dmvn.skip.test=true -T1C

On 17 February 2017 at 14:53, Balu S <sbalu27 at gmail.com> wrote:

> I will have to use this machine where it can connect to API. The problem
> is there is "npm install" during the build process as am behind proxy it
> fails during the execution.
>
> What does the npm install do in apimanager-ui-war..How do I skip it  ?
>
> regards
> Balu
>
> On Thu, Feb 16, 2017 at 2:04 PM, Marc Savy <marc.savy at redhat.com> wrote:
>
>> You may want to consider running apiman locally on your development
>> machine when doing debugging/reproducer work. This particular issue should
>> be simple to reproduce locally, I should think.
>>
>> On 16 February 2017 at 11:14, Balu S <sbalu27 at gmail.com> wrote:
>>
>>> Thanks Marc. yes it is Servlet/Wildfly setup.
>>>
>>> The problem with my setup is am behind proxy so using the overlay zip
>>> (on top of local wildfly installtion) generated from outside machine. So
>>> cannot build the apiman sources from within eclipse. I shall try.
>>>
>>> On Thu, Feb 16, 2017 at 12:05 PM, Marc Savy <marc.savy at redhat.com>
>>> wrote:
>>>
>>>> With regards to debugging:
>>>>
>>>> I assume you are using the Servlet/WAR gateway with WildFly?
>>>>
>>>> If so, I suggest you consult the WF debugging guides -- but, in short,
>>>> you can start up the application server with --debug and connect to it
>>>> remotely from  your debugger (e.g. Eclipse, IntelliJ, etc).
>>>>
>>>> https://tools.jboss.org/blog/2015-03-17-debugging-an-externa
>>>> lly-launched-wildfly.html
>>>>
>>>> Regards,
>>>> Marc
>>>>
>>>> On 16 February 2017 at 10:34, Balu S <sbalu27 at gmail.com> wrote:
>>>>
>>>>> Hello,
>>>>> I have found that if the HTTPConnector times out without receiving the
>>>>> response from the backend API, then somewhere down the line it generates 2
>>>>> error responses and this is evident from the metrics as it show 2 failures
>>>>> as supposed to 1 failure for the single request.
>>>>>
>>>>> So there are 2 issues,
>>>>>   - firstly the returned error response contains 2 error XMLs appended
>>>>> to each other and sent to the browser and hence not a valid XML.
>>>>>   - The metrics also shows as 2 failure response for single request.
>>>>>
>>>>> ?
>>>>> I have been looking the sources but without the way to debug within
>>>>> running application, it quite hard to follow the flow.
>>>>>
>>>>> This can be easily simulated with setting very low timeouts (2 secs
>>>>> for ex) in apiman.properties.
>>>>>
>>>>> apiman-gateway.connector-factory.http.timeouts.read=2
>>>>> apiman-gateway.connector-factory.http.timeouts.write=2
>>>>>
>>>>> Could you please look at the issue and also If you could guide me how
>>>>> to setup debugging environment, then I can try to fix that as well.
>>>>>
>>>>> regards
>>>>> Balu
>>>>>
>>>>> _______________________________________________
>>>>> Apiman-user mailing list
>>>>> Apiman-user at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/apiman-user
>>>>>
>>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20170217/3eb2b75d/attachment.html 

From marc.savy at redhat.com  Tue Feb 21 14:06:22 2017
From: marc.savy at redhat.com (Marc Savy)
Date: Tue, 21 Feb 2017 19:06:22 +0000
Subject: [Apiman-user] duplicate response on Connetor timeout
In-Reply-To: <CAA7j38JGyYFxjq8D9P_tdecjbhPtUWrDN6Fqzb94DT4um+EqQw@mail.gmail.com>
References: <CAEDnbHD3J7DDNc6L22=5_S5MkjOfxYUwWzFuo2UQEcvdc0-zqw@mail.gmail.com>
	<CAA7j38+5N90rcCBd73fHciOP-bU_PL2QinA1uRRs_pN_Tv=ATg@mail.gmail.com>
	<CAEDnbHD1dV6qemThE05R0Yst7hnsd_Q4T+EpuOxHQmEjHy6VUQ@mail.gmail.com>
	<CAA7j38L8hy5wGjgsF++-V2-YC4sec_+HntafonFfOPOHZTdJFw@mail.gmail.com>
	<CAEDnbHCh9HVZEGUnjd68o3PG1mTKQCWpoYNpowDLf-MOsF+8bw@mail.gmail.com>
	<CAA7j38JGyYFxjq8D9P_tdecjbhPtUWrDN6Fqzb94DT4um+EqQw@mail.gmail.com>
Message-ID: <CAA7j38JkSQ1FUVxqhgpcdy+9AJX9j-dQLzzK39WkFr+HXAx4=A@mail.gmail.com>

I fixed this on master. It only affects the Servlet version (Vert.x was OK).

On 17 February 2017 at 17:23, Marc Savy <marc.savy at redhat.com> wrote:

> If you want to build apiman quickly you can use (NB: skips tests which
> don't presently work when run in parallel):
>
> - mvn clean install -DskipTests=true -Dmvn.skip.test=true -T1C
>
> On 17 February 2017 at 14:53, Balu S <sbalu27 at gmail.com> wrote:
>
>> I will have to use this machine where it can connect to API. The problem
>> is there is "npm install" during the build process as am behind proxy it
>> fails during the execution.
>>
>> What does the npm install do in apimanager-ui-war..How do I skip it  ?
>>
>> regards
>> Balu
>>
>> On Thu, Feb 16, 2017 at 2:04 PM, Marc Savy <marc.savy at redhat.com> wrote:
>>
>>> You may want to consider running apiman locally on your development
>>> machine when doing debugging/reproducer work. This particular issue should
>>> be simple to reproduce locally, I should think.
>>>
>>> On 16 February 2017 at 11:14, Balu S <sbalu27 at gmail.com> wrote:
>>>
>>>> Thanks Marc. yes it is Servlet/Wildfly setup.
>>>>
>>>> The problem with my setup is am behind proxy so using the overlay zip
>>>> (on top of local wildfly installtion) generated from outside machine. So
>>>> cannot build the apiman sources from within eclipse. I shall try.
>>>>
>>>> On Thu, Feb 16, 2017 at 12:05 PM, Marc Savy <marc.savy at redhat.com>
>>>> wrote:
>>>>
>>>>> With regards to debugging:
>>>>>
>>>>> I assume you are using the Servlet/WAR gateway with WildFly?
>>>>>
>>>>> If so, I suggest you consult the WF debugging guides -- but, in short,
>>>>> you can start up the application server with --debug and connect to it
>>>>> remotely from  your debugger (e.g. Eclipse, IntelliJ, etc).
>>>>>
>>>>> https://tools.jboss.org/blog/2015-03-17-debugging-an-externa
>>>>> lly-launched-wildfly.html
>>>>>
>>>>> Regards,
>>>>> Marc
>>>>>
>>>>> On 16 February 2017 at 10:34, Balu S <sbalu27 at gmail.com> wrote:
>>>>>
>>>>>> Hello,
>>>>>> I have found that if the HTTPConnector times out without receiving
>>>>>> the response from the backend API, then somewhere down the line it
>>>>>> generates 2 error responses and this is evident from the metrics as it show
>>>>>> 2 failures as supposed to 1 failure for the single request.
>>>>>>
>>>>>> So there are 2 issues,
>>>>>>   - firstly the returned error response contains 2 error XMLs
>>>>>> appended to each other and sent to the browser and hence not a valid XML.
>>>>>>   - The metrics also shows as 2 failure response for single request.
>>>>>>
>>>>>> ?
>>>>>> I have been looking the sources but without the way to debug within
>>>>>> running application, it quite hard to follow the flow.
>>>>>>
>>>>>> This can be easily simulated with setting very low timeouts (2 secs
>>>>>> for ex) in apiman.properties.
>>>>>>
>>>>>> apiman-gateway.connector-factory.http.timeouts.read=2
>>>>>> apiman-gateway.connector-factory.http.timeouts.write=2
>>>>>>
>>>>>> Could you please look at the issue and also If you could guide me how
>>>>>> to setup debugging environment, then I can try to fix that as well.
>>>>>>
>>>>>> regards
>>>>>> Balu
>>>>>>
>>>>>> _______________________________________________
>>>>>> Apiman-user mailing list
>>>>>> Apiman-user at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/apiman-user
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20170221/29d2b54f/attachment-0001.html 

From sbalu27 at gmail.com  Wed Feb 22 04:13:39 2017
From: sbalu27 at gmail.com (Balu S)
Date: Wed, 22 Feb 2017 10:13:39 +0100
Subject: [Apiman-user] duplicate response on Connetor timeout
In-Reply-To: <CAA7j38JkSQ1FUVxqhgpcdy+9AJX9j-dQLzzK39WkFr+HXAx4=A@mail.gmail.com>
References: <CAEDnbHD3J7DDNc6L22=5_S5MkjOfxYUwWzFuo2UQEcvdc0-zqw@mail.gmail.com>
	<CAA7j38+5N90rcCBd73fHciOP-bU_PL2QinA1uRRs_pN_Tv=ATg@mail.gmail.com>
	<CAEDnbHD1dV6qemThE05R0Yst7hnsd_Q4T+EpuOxHQmEjHy6VUQ@mail.gmail.com>
	<CAA7j38L8hy5wGjgsF++-V2-YC4sec_+HntafonFfOPOHZTdJFw@mail.gmail.com>
	<CAEDnbHCh9HVZEGUnjd68o3PG1mTKQCWpoYNpowDLf-MOsF+8bw@mail.gmail.com>
	<CAA7j38JGyYFxjq8D9P_tdecjbhPtUWrDN6Fqzb94DT4um+EqQw@mail.gmail.com>
	<CAA7j38JkSQ1FUVxqhgpcdy+9AJX9j-dQLzzK39WkFr+HXAx4=A@mail.gmail.com>
Message-ID: <CAEDnbHCYjPSddaq8Hm0mRTXvYDwDRwoxO20ggupQFgnYNeuqTQ@mail.gmail.com>

great! I shall check.
Thank you very much.


On Tue, Feb 21, 2017 at 8:06 PM, Marc Savy <marc.savy at redhat.com> wrote:

> I fixed this on master. It only affects the Servlet version (Vert.x was
> OK).
>
> On 17 February 2017 at 17:23, Marc Savy <marc.savy at redhat.com> wrote:
>
>> If you want to build apiman quickly you can use (NB: skips tests which
>> don't presently work when run in parallel):
>>
>> - mvn clean install -DskipTests=true -Dmvn.skip.test=true -T1C
>>
>> On 17 February 2017 at 14:53, Balu S <sbalu27 at gmail.com> wrote:
>>
>>> I will have to use this machine where it can connect to API. The problem
>>> is there is "npm install" during the build process as am behind proxy it
>>> fails during the execution.
>>>
>>> What does the npm install do in apimanager-ui-war..How do I skip it  ?
>>>
>>> regards
>>> Balu
>>>
>>> On Thu, Feb 16, 2017 at 2:04 PM, Marc Savy <marc.savy at redhat.com> wrote:
>>>
>>>> You may want to consider running apiman locally on your development
>>>> machine when doing debugging/reproducer work. This particular issue should
>>>> be simple to reproduce locally, I should think.
>>>>
>>>> On 16 February 2017 at 11:14, Balu S <sbalu27 at gmail.com> wrote:
>>>>
>>>>> Thanks Marc. yes it is Servlet/Wildfly setup.
>>>>>
>>>>> The problem with my setup is am behind proxy so using the overlay zip
>>>>> (on top of local wildfly installtion) generated from outside machine. So
>>>>> cannot build the apiman sources from within eclipse. I shall try.
>>>>>
>>>>> On Thu, Feb 16, 2017 at 12:05 PM, Marc Savy <marc.savy at redhat.com>
>>>>> wrote:
>>>>>
>>>>>> With regards to debugging:
>>>>>>
>>>>>> I assume you are using the Servlet/WAR gateway with WildFly?
>>>>>>
>>>>>> If so, I suggest you consult the WF debugging guides -- but, in
>>>>>> short, you can start up the application server with --debug and connect to
>>>>>> it remotely from  your debugger (e.g. Eclipse, IntelliJ, etc).
>>>>>>
>>>>>> https://tools.jboss.org/blog/2015-03-17-debugging-an-externa
>>>>>> lly-launched-wildfly.html
>>>>>>
>>>>>> Regards,
>>>>>> Marc
>>>>>>
>>>>>> On 16 February 2017 at 10:34, Balu S <sbalu27 at gmail.com> wrote:
>>>>>>
>>>>>>> Hello,
>>>>>>> I have found that if the HTTPConnector times out without receiving
>>>>>>> the response from the backend API, then somewhere down the line it
>>>>>>> generates 2 error responses and this is evident from the metrics as it show
>>>>>>> 2 failures as supposed to 1 failure for the single request.
>>>>>>>
>>>>>>> So there are 2 issues,
>>>>>>>   - firstly the returned error response contains 2 error XMLs
>>>>>>> appended to each other and sent to the browser and hence not a valid XML.
>>>>>>>   - The metrics also shows as 2 failure response for single request.
>>>>>>>
>>>>>>> ?
>>>>>>> I have been looking the sources but without the way to debug within
>>>>>>> running application, it quite hard to follow the flow.
>>>>>>>
>>>>>>> This can be easily simulated with setting very low timeouts (2 secs
>>>>>>> for ex) in apiman.properties.
>>>>>>>
>>>>>>> apiman-gateway.connector-factory.http.timeouts.read=2
>>>>>>> apiman-gateway.connector-factory.http.timeouts.write=2
>>>>>>>
>>>>>>> Could you please look at the issue and also If you could guide me
>>>>>>> how to setup debugging environment, then I can try to fix that as well.
>>>>>>>
>>>>>>> regards
>>>>>>> Balu
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Apiman-user mailing list
>>>>>>> Apiman-user at lists.jboss.org
>>>>>>> https://lists.jboss.org/mailman/listinfo/apiman-user
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20170222/ce4c2042/attachment.html