From marc.savy at redhat.com Mon Jan 2 15:04:29 2017 From: marc.savy at redhat.com (Marc Savy) Date: Mon, 2 Jan 2017 20:04:29 +0000 Subject: [Apiman-user] How to configure CORS in APIMan? Problems with Headers in ajax In-Reply-To: References: Message-ID: I addressed this for Celso over JIRA. Summary: - In general, if you're using CORS you should probably use the query parameter to transmit your access token (if you have one). This is because of a limitation to CORS preflight request phase which never transmits custom headers. - A separate issue was a bug (now fixed on master) where a data structure would cause certain header-value fields to be mixed up in specific circumstances. On 28 December 2016 at 14:10, Celso Agra wrote: > Hi all, > > It's me again! > So, I was looking for some solutions about my issue, and I found this: > https://issues.jboss.org/browse/APIMAN-516 > > It seems this issue still occurs with me. I tries to send some headers via > ajax, and get this response: > >> XMLHttpRequest cannot load https://apiman.url. Response to preflight >> request doesn't pass access control check: No 'Access-Control-Allow-Origin' >> header is present on the requested resource. Origin ' >> http://192.168.56.22:8080' is therefore not allowed access. The response >> had HTTP status code 500. > > > Here is the Response Headers: > >> Connection:close >> Content-Type:application/json >> Date:Wed, 28 Dec 2016 13:54:08 GMT >> Server:Apache/2.4.18 (Ubuntu) >> Transfer-Encoding:chunked >> X-Gateway-Error:API not public. >> X-Powered-By:Undertow/1 > > > and > > Here is the Request Headers: > >> Accept:*/* >> Accept-Encoding:gzip, deflate, sdch, br >> Accept-Language:pt-BR,pt;q=0.8,en-US;q=0.6,en;q=0.4 >> Access-Control-Request-Headers:authorization, x-api-key >> Access-Control-Request-Method:GET >> Connection:keep-alive >> Host: apiman.url >> Origin:http://192.168.56.22:8080 >> Referer:http://192.168.56.22:8080/app >> User-Agent:Mozilla/5.0 ... >> Query String Parameters >> view source >> view URL encoded > > > Does anyone has the same problem? > > 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/20170102/f3c9a702/attachment.html From marc.savy at redhat.com Tue Jan 3 14:03:31 2017 From: marc.savy at redhat.com (Marc Savy) Date: Tue, 3 Jan 2017 19:03:31 +0000 Subject: [Apiman-user] How to configure CORS in APIMan? Problems with Headers in ajax In-Reply-To: References: Message-ID: Replying to list. This going to help me a lot! I'm still planning to update my apiman > instance. Could I just remove my old version (1.2.3) and then deploy the > new one with my configurations files? Yes, that should work fine. You might want to build from master, considering the bug you encountered. I'll see if it's possible to at least do a snapshot release soon. People are on holiday at the moment. How to avoid chunked encoding when the rest api is passing through APIMan? > At present we use chunked encoding[1] because it's much simpler when handling mutable streaming payloads - especially if we're doing a transformation where it is not be clear what the final payload size will be until the process is completed (which would cause substantial buffering). That being said, in the case of a pipeline where no body mutation policies exist, we could consider setting content-length. I'll have to think about it to consider whether there are any important implications. This would be a feature request. How to consume a service with chunked-encoding transfer in java using > Jersey Framework > Chunked encoding has been supported since HTTP/1.1, unless you are using an extremely old/buggy version of Jersey it should work fine. It should be pretty much transparent in practice. Your bug might be something else. I suggest trying the latest release and then filing a JIRA with full information (e.g. expected vs actual; console output; configuration). Maybe this is happen for that reason -> APIMAN 984 > > I don't think you are using the policy mentioned in that ticket, are you? For now, I do not found any ways to workaround that issue, so I think I'm > gonna create a policy / plugin to solve that, just to adding a response > header setting the Content-Length on header. I don't know if it is a good > idea, but maybe could solve this for while. > You may be able to do that, but it would require buffering which will reduce performance. It may also be tricky to determine from within the policy which is the final chunk of a stream (with small payloads it's likely just 1 chunk, though). On 2 January 2017 at 22:12, Celso Agra wrote: > Thanks Marc! > > This going to help me a lot! I'm still planning to update my apiman > instance. Could I just remove my old version (1.2.3) and then deploy the > new one with my configurations files? > > Just to let you know... I believe I got another issue with apiman: > > - How to avoid chunked encoding when the rest api is passing through > APIMan? > > - How to consume a service with chunked-encoding transfer in java > using Jersey Framework > > > Maybe this is happen for that reason -> APIMAN 984 > > For now, I do not found any ways to workaround that issue, so I think I'm > gonna create a policy / plugin to solve that, just to adding a response > header setting the Content-Length on header. I don't know if it is a good > idea, but maybe could solve this for while. > > Thanks for your help Marc! > > > 2017-01-02 17:04 GMT-03:00 Marc Savy : > >> I addressed this for Celso over JIRA. >> >> Summary: >> >> - In general, if you're using CORS you should probably use the query >> parameter to transmit your access token (if you have one). This is because >> of a limitation to CORS preflight request phase which never transmits >> custom headers. >> >> - A separate issue was a bug (now fixed on master) where a data structure >> would cause certain header-value fields to be mixed up in specific >> circumstances. >> >> On 28 December 2016 at 14:10, Celso Agra wrote: >> >>> Hi all, >>> >>> It's me again! >>> So, I was looking for some solutions about my issue, and I found this: >>> https://issues.jboss.org/browse/APIMAN-516 >>> >>> It seems this issue still occurs with me. I tries to send some headers >>> via ajax, and get this response: >>> >>>> XMLHttpRequest cannot load https://apiman.url. Response to preflight >>>> request doesn't pass access control check: No 'Access-Control-Allow-Origin' >>>> header is present on the requested resource. Origin ' >>>> http://192.168.56.22:8080' is therefore not allowed access. The >>>> response had HTTP status code 500. >>> >>> >>> Here is the Response Headers: >>> >>>> Connection:close >>>> Content-Type:application/json >>>> Date:Wed, 28 Dec 2016 13:54:08 GMT >>>> Server:Apache/2.4.18 (Ubuntu) >>>> Transfer-Encoding:chunked >>>> X-Gateway-Error:API not public. >>>> X-Powered-By:Undertow/1 >>> >>> >>> and >>> >>> Here is the Request Headers: >>> >>>> Accept:*/* >>>> Accept-Encoding:gzip, deflate, sdch, br >>>> Accept-Language:pt-BR,pt;q=0.8,en-US;q=0.6,en;q=0.4 >>>> Access-Control-Request-Headers:authorization, x-api-key >>>> Access-Control-Request-Method:GET >>>> Connection:keep-alive >>>> Host: apiman.url >>>> Origin:http://192.168.56.22:8080 >>>> Referer:http://192.168.56.22:8080/app >>>> User-Agent:Mozilla/5.0 ... >>>> Query String Parameters >>>> view source >>>> view URL encoded >>> >>> >>> Does anyone has the same problem? >>> >>> 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/20170103/d7ed65be/attachment-0001.html From celso.agra at gmail.com Tue Jan 3 14:41:24 2017 From: celso.agra at gmail.com (Celso Agra) Date: Tue, 3 Jan 2017 16:41:24 -0300 Subject: [Apiman-user] How to configure CORS in APIMan? Problems with Headers in ajax In-Reply-To: References: Message-ID: Thanks for the reply! I was thinking there is some config to set up in APIMan, but the problem was not there. My backend server is not adding the Content-Length, so the server add Transfer-Encoding as Chunked in the Response-Header (now I understand what's going on!). So, what I do was add the HTTP Header Policy Plugin, and then added "Transfer-Encoding" in the Strip Headers fields, as the image below: ? I believe this is not the best thing to do but works for me for while. I'll add the Content-Length in service to solve it! 2017-01-03 16:03 GMT-03:00 Marc Savy : > Replying to list. > > > This going to help me a lot! I'm still planning to update my apiman >> instance. Could I just remove my old version (1.2.3) and then deploy the >> new one with my configurations files? > > > Yes, that should work fine. You might want to build from master, > considering the bug you encountered. I'll see if it's possible to at least > do a snapshot release soon. People are on holiday at the moment. > > How to avoid chunked encoding when the rest api is passing through APIMan? >> > > > At present we use chunked encoding[1] because it's much simpler when > handling mutable streaming payloads - especially if we're doing a > transformation where it is not be clear what the final payload size will be > until the process is completed (which would cause substantial buffering). > > That being said, in the case of a pipeline where no body mutation policies > exist, we could consider setting content-length. I'll have to think about > it to consider whether there are any important implications. This would be > a feature request. > > How to consume a service with chunked-encoding transfer in java using >> Jersey Framework >> > > > Chunked encoding has been supported since HTTP/1.1, unless you are using > an extremely old/buggy version of Jersey it should work fine. It should be > pretty much transparent in practice. > > Your bug might be something else. I suggest trying the latest release and > then filing a JIRA with full information (e.g. expected vs actual; console > output; configuration). > > Maybe this is happen for that reason -> APIMAN 984 >> >> > > I don't think you are using the policy mentioned in that ticket, are you? > > For now, I do not found any ways to workaround that issue, so I think I'm >> gonna create a policy / plugin to solve that, just to adding a response >> header setting the Content-Length on header. I don't know if it is a good >> idea, but maybe could solve this for while. >> > > You may be able to do that, but it would require buffering which will > reduce performance. It may also be tricky to determine from within the > policy which is the final chunk of a stream (with small payloads it's > likely just 1 chunk, though). > > On 2 January 2017 at 22:12, Celso Agra wrote: > >> Thanks Marc! >> >> This going to help me a lot! I'm still planning to update my apiman >> instance. Could I just remove my old version (1.2.3) and then deploy the >> new one with my configurations files? >> > >> Just to let you know... I believe I got another issue with apiman: >> >> - How to avoid chunked encoding when the rest api is passing through >> APIMan? >> >> - How to consume a service with chunked-encoding transfer in java >> using Jersey Framework >> >> >> Maybe this is happen for that reason -> APIMAN 984 >> >> > For now, I do not found any ways to workaround that issue, so I think I'm >> gonna create a policy / plugin to solve that, just to adding a response >> header setting the Content-Length on header. I don't know if it is a good >> idea, but maybe could solve this for while. >> > >> Thanks for your help Marc! >> >> >> 2017-01-02 17:04 GMT-03:00 Marc Savy : >> >>> I addressed this for Celso over JIRA. >>> >>> Summary: >>> >>> - In general, if you're using CORS you should probably use the query >>> parameter to transmit your access token (if you have one). This is because >>> of a limitation to CORS preflight request phase which never transmits >>> custom headers. >>> >>> - A separate issue was a bug (now fixed on master) where a data >>> structure would cause certain header-value fields to be mixed up in >>> specific circumstances. >>> >>> On 28 December 2016 at 14:10, Celso Agra wrote: >>> >>>> Hi all, >>>> >>>> It's me again! >>>> So, I was looking for some solutions about my issue, and I found this: >>>> https://issues.jboss.org/browse/APIMAN-516 >>>> >>>> It seems this issue still occurs with me. I tries to send some headers >>>> via ajax, and get this response: >>>> >>>>> XMLHttpRequest cannot load https://apiman.url. Response to preflight >>>>> request doesn't pass access control check: No 'Access-Control-Allow-Origin' >>>>> header is present on the requested resource. Origin ' >>>>> http://192.168.56.22:8080' is therefore not allowed access. The >>>>> response had HTTP status code 500. >>>> >>>> >>>> Here is the Response Headers: >>>> >>>>> Connection:close >>>>> Content-Type:application/json >>>>> Date:Wed, 28 Dec 2016 13:54:08 GMT >>>>> Server:Apache/2.4.18 (Ubuntu) >>>>> Transfer-Encoding:chunked >>>>> X-Gateway-Error:API not public. >>>>> X-Powered-By:Undertow/1 >>>> >>>> >>>> and >>>> >>>> Here is the Request Headers: >>>> >>>>> Accept:*/* >>>>> Accept-Encoding:gzip, deflate, sdch, br >>>>> Accept-Language:pt-BR,pt;q=0.8,en-US;q=0.6,en;q=0.4 >>>>> Access-Control-Request-Headers:authorization, x-api-key >>>>> Access-Control-Request-Method:GET >>>>> Connection:keep-alive >>>>> Host: apiman.url >>>>> Origin:http://192.168.56.22:8080 >>>>> Referer:http://192.168.56.22:8080/app >>>>> User-Agent:Mozilla/5.0 ... >>>>> Query String Parameters >>>>> view source >>>>> view URL encoded >>>> >>>> >>>> Does anyone has the same problem? >>>> >>>> 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/20170103/d083132d/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: apiman images.png Type: image/png Size: 17124 bytes Desc: not available Url : http://lists.jboss.org/pipermail/apiman-user/attachments/20170103/d083132d/attachment-0001.png From David.Rush at ihsmarkit.com Thu Jan 5 14:54:00 2017 From: David.Rush at ihsmarkit.com (David Rush) Date: Thu, 5 Jan 2017 19:54:00 +0000 Subject: [Apiman-user] Stream closed / Broken Pipe issues with custom plugin Message-ID: Good afternoon, I'm having issues with on a production API which has started to receive high volumes of traffic. At peak volume times I see many exceptions being thrown in the logs. The stack is indicating that an error occurred in the policy chain, but when it tries to write the error to the response the connection has been closed. There seems to be a couple of flavors of IOException (broken pipe or stream closed from undertow). My plugin is calling chain.doApply(request) when it succeeds but the stack trace is indicating there is then an exception being caught in doApply(Chain.java:153). I am on version 1.2.2-Final. 2017-01-05 18:28:49,095 ERROR [stderr] (default task-17) java.io.IOException: UT010029: Stream is closed 2017-01-05 18:28:49,095 ERROR [stderr] (default task-17) at io.undertow.servlet.spec.ServletOutputStreamImpl.write(ServletOutputStreamImpl.java:136) 2017-01-05 18:28:49,095 ERROR [stderr] (default task-17) at io.undertow.servlet.spec.ServletOutputStreamImpl.write(ServletOutputStreamImpl.java:128) 2017-01-05 18:28:49,095 ERROR [stderr] (default task-17) at io.apiman.gateway.platforms.servlet.GatewayServlet$4.write(GatewayServlet.java:406) 2017-01-05 18:28:49,095 ERROR [stderr] (default task-17) at io.apiman.gateway.platforms.servlet.GatewayServlet$4.write(GatewayServlet.java:395) 2017-01-05 18:28:49,095 ERROR [stderr] (default task-17) at io.apiman.gateway.engine.impl.DefaultPolicyErrorWriter.write(DefaultPolicyErrorWriter.java:87) 2017-01-05 18:28:49,095 ERROR [stderr] (default task-17) at io.apiman.gateway.platforms.servlet.GatewayServlet.writeError(GatewayServlet.java:392) 2017-01-05 18:28:49,095 ERROR [stderr] (default task-17) at io.apiman.gateway.platforms.servlet.GatewayServlet$1.handle(GatewayServlet.java:210) 2017-01-05 18:28:49,095 ERROR [stderr] (default task-17) at io.apiman.gateway.platforms.servlet.GatewayServlet$1.handle(GatewayServlet.java:157) 2017-01-05 18:28:49,095 ERROR [stderr] (default task-17) at io.apiman.gateway.engine.impl.ApiRequestExecutorImpl.lambda$wrapResultHandler$0(ApiRequestExecutorImpl.java:159) 2017-01-05 18:28:49,095 ERROR [stderr] (default task-17) at io.apiman.gateway.engine.impl.ApiRequestExecutorImpl.lambda$createPolicyErrorHandler$17(ApiRequestExecutorImpl.java:614) 2017-01-05 18:28:49,095 ERROR [stderr] (default task-17) at io.apiman.gateway.engine.policy.Chain.throwError(Chain.java:249) 2017-01-05 18:28:49,095 ERROR [stderr] (default task-17) at io.apiman.gateway.engine.policy.Chain.doApply(Chain.java:153) 2017-01-05 18:28:49,096 ERROR [stderr] (default task-17) at com.markit.ondemand.auth.apiman.plugins.pingfed_oauth_policy.PingFedOauthPolicy.doSuccess(PingFedOauthPolicy.java:114) 2017-01-05 18:28:49,096 ERROR [stderr] (default task-17) at com.markit.ondemand.auth.apiman.plugins.pingfed_oauth_policy.PingFedOauthPolicy.access$100(PingFedOauthPolicy.java:38) 2017-01-05 18:28:49,096 ERROR [stderr] (default task-17) at com.markit.ondemand.auth.apiman.plugins.pingfed_oauth_policy.PingFedOauthPolicy$2.handle(PingFedOauthPolicy.java:193) 2017-01-05 18:28:49,096 ERROR [stderr] (default task-17) at com.markit.ondemand.auth.apiman.plugins.pingfed_oauth_policy.PingFedOauthPolicy$2.handle(PingFedOauthPolicy.java:174) 2017-01-05 18:28:49,096 ERROR [stderr] (default task-17) at io.apiman.gateway.platforms.servlet.components.HttpClientRequestImpl.end(HttpClientRequestImpl.java:140) 2017-01-05 18:28:49,096 ERROR [stderr] (default task-17) at com.markit.ondemand.auth.apiman.plugins.pingfed_oauth_policy.PingFedOauthPolicy.retrieveAccessTokenFromPing(PingFedOauthPolicy.java:232) 2017-01-05 18:28:49,096 ERROR [stderr] (default task-17) at com.markit.ondemand.auth.apiman.plugins.pingfed_oauth_policy.PingFedOauthPolicy.retrieveAccessTokenFromPing(PingFedOauthPolicy.java:174) 2017-01-05 18:28:49,096 ERROR [stderr] (default task-17) at com.markit.ondemand.auth.apiman.plugins.pingfed_oauth_policy.PingFedOauthPolicy.doApply(PingFedOauthPolicy.java:83) 2017-01-05 18:28:49,096 ERROR [stderr] (default task-17) at com.markit.ondemand.auth.apiman.plugins.pingfed_oauth_policy.PingFedOauthPolicy.doApply(PingFedOauthPolicy.java:38) My plugin is making either an external request to ElasticSearch or an HTTP request using IHttpClientComponent and then calling chain.doApply or chain.doFailure from within the IAsyncResultHandler handle method. Is there a problem with that pattern? Any help you can provide would be great. Thanks, [IHS Markit] David Rush Director, API Development | Markit Digital 5775 Flatiron Parkway | Boulder, CO 80301 P: +1 303 583 4244 Main: +1 303 417 9999 david.rush at ihsmarkit.com ________________________________ This e-mail, including accompanying communications and attachments, is strictly confidential and only for the intended recipient. Any retention, use or disclosure not expressly authorised by Markit is prohibited. This email is subject to all waivers and other terms at the following link: http://www.markit.com/en/about/legal/email-disclaimer.page Please visit http://www.markit.com/en/about/contact/contact-us.page for contact information on our offices worldwide. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20170105/b9422151/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 6881 bytes Desc: image001.png Url : http://lists.jboss.org/pipermail/apiman-user/attachments/20170105/b9422151/attachment-0001.png From David.Rush at ihsmarkit.com Thu Jan 5 14:44:57 2017 From: David.Rush at ihsmarkit.com (David Rush) Date: Thu, 5 Jan 2017 19:44:57 +0000 Subject: [Apiman-user] Stream closed / Broken Pipe issues with custom plugin Message-ID: Good afternoon, I'm having issues with on a production API which has started to receive high volumes of traffic. At peak volume times I see many exceptions being thrown in the logs. The stack is indicating that an error occurred in the policy chain, but when it tries to write the error to the response the connection has been closed. There seems to be a couple of flavors of IOException (broken pipe or stream closed from undertow). My plugin is calling chain.doApply(request) when it succeeds but the stack trace is indicating there is then an exception being caught in doApply(Chain.java:153). I am on version 1.2.2-Final. 2017-01-05 18:28:49,095 ERROR [stderr] (default task-17) java.io.IOException: UT010029: Stream is closed 2017-01-05 18:28:49,095 ERROR [stderr] (default task-17) at io.undertow.servlet.spec.ServletOutputStreamImpl.write(ServletOutputStreamImpl.java:136) 2017-01-05 18:28:49,095 ERROR [stderr] (default task-17) at io.undertow.servlet.spec.ServletOutputStreamImpl.write(ServletOutputStreamImpl.java:128) 2017-01-05 18:28:49,095 ERROR [stderr] (default task-17) at io.apiman.gateway.platforms.servlet.GatewayServlet$4.write(GatewayServlet.java:406) 2017-01-05 18:28:49,095 ERROR [stderr] (default task-17) at io.apiman.gateway.platforms.servlet.GatewayServlet$4.write(GatewayServlet.java:395) 2017-01-05 18:28:49,095 ERROR [stderr] (default task-17) at io.apiman.gateway.engine.impl.DefaultPolicyErrorWriter.write(DefaultPolicyErrorWriter.java:87) 2017-01-05 18:28:49,095 ERROR [stderr] (default task-17) at io.apiman.gateway.platforms.servlet.GatewayServlet.writeError(GatewayServlet.java:392) 2017-01-05 18:28:49,095 ERROR [stderr] (default task-17) at io.apiman.gateway.platforms.servlet.GatewayServlet$1.handle(GatewayServlet.java:210) 2017-01-05 18:28:49,095 ERROR [stderr] (default task-17) at io.apiman.gateway.platforms.servlet.GatewayServlet$1.handle(GatewayServlet.java:157) 2017-01-05 18:28:49,095 ERROR [stderr] (default task-17) at io.apiman.gateway.engine.impl.ApiRequestExecutorImpl.lambda$wrapResultHandler$0(ApiRequestExecutorImpl.java:159) 2017-01-05 18:28:49,095 ERROR [stderr] (default task-17) at io.apiman.gateway.engine.impl.ApiRequestExecutorImpl.lambda$createPolicyErrorHandler$17(ApiRequestExecutorImpl.java:614) 2017-01-05 18:28:49,095 ERROR [stderr] (default task-17) at io.apiman.gateway.engine.policy.Chain.throwError(Chain.java:249) 2017-01-05 18:28:49,095 ERROR [stderr] (default task-17) at io.apiman.gateway.engine.policy.Chain.doApply(Chain.java:153) 2017-01-05 18:28:49,096 ERROR [stderr] (default task-17) at com.markit.ondemand.auth.apiman.plugins.pingfed_oauth_policy.PingFedOauthPolicy.doSuccess(PingFedOauthPolicy.java:114) 2017-01-05 18:28:49,096 ERROR [stderr] (default task-17) at com.markit.ondemand.auth.apiman.plugins.pingfed_oauth_policy.PingFedOauthPolicy.access$100(PingFedOauthPolicy.java:38) 2017-01-05 18:28:49,096 ERROR [stderr] (default task-17) at com.markit.ondemand.auth.apiman.plugins.pingfed_oauth_policy.PingFedOauthPolicy$2.handle(PingFedOauthPolicy.java:193) 2017-01-05 18:28:49,096 ERROR [stderr] (default task-17) at com.markit.ondemand.auth.apiman.plugins.pingfed_oauth_policy.PingFedOauthPolicy$2.handle(PingFedOauthPolicy.java:174) 2017-01-05 18:28:49,096 ERROR [stderr] (default task-17) at io.apiman.gateway.platforms.servlet.components.HttpClientRequestImpl.end(HttpClientRequestImpl.java:140) 2017-01-05 18:28:49,096 ERROR [stderr] (default task-17) at com.markit.ondemand.auth.apiman.plugins.pingfed_oauth_policy.PingFedOauthPolicy.retrieveAccessTokenFromPing(PingFedOauthPolicy.java:232) 2017-01-05 18:28:49,096 ERROR [stderr] (default task-17) at com.markit.ondemand.auth.apiman.plugins.pingfed_oauth_policy.PingFedOauthPolicy.retrieveAccessTokenFromPing(PingFedOauthPolicy.java:174) 2017-01-05 18:28:49,096 ERROR [stderr] (default task-17) at com.markit.ondemand.auth.apiman.plugins.pingfed_oauth_policy.PingFedOauthPolicy.doApply(PingFedOauthPolicy.java:83) 2017-01-05 18:28:49,096 ERROR [stderr] (default task-17) at com.markit.ondemand.auth.apiman.plugins.pingfed_oauth_policy.PingFedOauthPolicy.doApply(PingFedOauthPolicy.java:38) My plugin is making either an external request to ElasticSearch or an HTTP request using IHttpClientComponent and then calling chain.doApply or chain.doFailure from within the IAsyncResultHandler handle method. Is there a problem with that pattern? Any help you can provide would be great. Thanks, [IHS Markit] David Rush Director, API Development | Markit Digital 5775 Flatiron Parkway | Boulder, CO 80301 P: +1 303 583 4244 Main: +1 303 417 9999 david.rush at ihsmarkit.com ________________________________ This e-mail, including accompanying communications and attachments, is strictly confidential and only for the intended recipient. Any retention, use or disclosure not expressly authorised by Markit is prohibited. This email is subject to all waivers and other terms at the following link: http://www.markit.com/en/about/legal/email-disclaimer.page Please visit http://www.markit.com/en/about/contact/contact-us.page for contact information on our offices worldwide. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20170105/d6e0ef9b/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.png Type: image/png Size: 6881 bytes Desc: image003.png Url : http://lists.jboss.org/pipermail/apiman-user/attachments/20170105/d6e0ef9b/attachment-0001.png From harrytpc at gmail.com Thu Jan 5 22:51:08 2017 From: harrytpc at gmail.com (Harry Trinta) Date: Fri, 6 Jan 2017 01:51:08 -0200 Subject: [Apiman-user] Stream closed / Broken Pipe issues with custom plugin In-Reply-To: References: Message-ID: Hi, David! I had exactly this problem. It is not relationed with the Apiman. The problem is with Wildfly. If your Wildfly is with default configuration, you have a limit of concurrent requests (Default "*Task max threads" = *16 * vCPUs). So, when the Wildfly is working in the limit, it create a queue of requests. Suggested settings for your wildfly (adjust according to your server): Configuration -> Subsystem -> IO WORKER Io threads: 128 Task max threads: 2048 Stack size: 0 Task keepalive: 120 BUFFER POLL Buffer size: 16384 Buffers per slice: 128 Direct buffers: true 2017-01-05 17:54 GMT-02:00 David Rush : > Good afternoon, > > > > I?m having issues with on a production API which has started to receive > high volumes of traffic. At peak volume times I see many exceptions being > thrown in the logs. The stack is indicating that an error occurred in the > policy chain, but when it tries to write the error to the response the > connection has been closed. There seems to be a couple of flavors of > IOException (broken pipe or stream closed from undertow). My plugin is > calling chain.doApply(request) when it succeeds but the stack trace is > indicating there is then an exception being caught in > doApply(Chain.java:153). I am on version 1.2.2-Final. > > > > 2017-01-05 18:28:49,095 ERROR [stderr] (default task-17) > java.io.IOException: UT010029: Stream is closed > > 2017-01-05 18:28:49,095 ERROR [stderr] (default task-17) at > io.undertow.servlet.spec.ServletOutputStreamImpl.write( > ServletOutputStreamImpl.java:136) > > 2017-01-05 18:28:49,095 ERROR [stderr] (default task-17) at > io.undertow.servlet.spec.ServletOutputStreamImpl.write( > ServletOutputStreamImpl.java:128) > > 2017-01-05 18:28:49,095 ERROR [stderr] (default task-17) at > io.apiman.gateway.platforms.servlet.GatewayServlet$4. > write(GatewayServlet.java:406) > > 2017-01-05 18:28:49,095 ERROR [stderr] (default task-17) at > io.apiman.gateway.platforms.servlet.GatewayServlet$4. > write(GatewayServlet.java:395) > > 2017-01-05 18:28:49,095 ERROR [stderr] (default task-17) at > io.apiman.gateway.engine.impl.DefaultPolicyErrorWriter.write( > DefaultPolicyErrorWriter.java:87) > > 2017-01-05 18:28:49,095 ERROR [stderr] (default task-17) at > io.apiman.gateway.platforms.servlet.GatewayServlet. > writeError(GatewayServlet.java:392) > > 2017-01-05 18:28:49,095 ERROR [stderr] (default task-17) at > io.apiman.gateway.platforms.servlet.GatewayServlet$1. > handle(GatewayServlet.java:210) > > 2017-01-05 18:28:49,095 ERROR [stderr] (default task-17) at > io.apiman.gateway.platforms.servlet.GatewayServlet$1. > handle(GatewayServlet.java:157) > > 2017-01-05 18:28:49,095 ERROR [stderr] (default task-17) at > io.apiman.gateway.engine.impl.ApiRequestExecutorImpl.lambda$ > wrapResultHandler$0(ApiRequestExecutorImpl.java:159) > > 2017-01-05 18:28:49,095 ERROR [stderr] (default task-17) at > io.apiman.gateway.engine.impl.ApiRequestExecutorImpl.lambda$ > createPolicyErrorHandler$17(ApiRequestExecutorImpl.java:614) > > 2017-01-05 18:28:49,095 ERROR [stderr] (default task-17) at > io.apiman.gateway.engine.policy.Chain.throwError(Chain.java:249) > > 2017-01-05 18:28:49,095 ERROR [stderr] (default task-17) at > io.apiman.gateway.engine.policy.Chain.doApply(Chain.java:153) > > 2017-01-05 18:28:49,096 ERROR [stderr] (default task-17) at > com.markit.ondemand.auth.apiman.plugins.pingfed_oauth_ > policy.PingFedOauthPolicy.doSuccess(PingFedOauthPolicy.java:114) > > 2017-01-05 18:28:49,096 ERROR [stderr] (default task-17) at > com.markit.ondemand.auth.apiman.plugins.pingfed_oauth_ > policy.PingFedOauthPolicy.access$100(PingFedOauthPolicy.java:38) > > 2017-01-05 18:28:49,096 ERROR [stderr] (default task-17) at > com.markit.ondemand.auth.apiman.plugins.pingfed_oauth_ > policy.PingFedOauthPolicy$2.handle(PingFedOauthPolicy.java:193) > > 2017-01-05 18:28:49,096 ERROR [stderr] (default task-17) at > com.markit.ondemand.auth.apiman.plugins.pingfed_oauth_ > policy.PingFedOauthPolicy$2.handle(PingFedOauthPolicy.java:174) > > 2017-01-05 18:28:49,096 ERROR [stderr] (default task-17) at > io.apiman.gateway.platforms.servlet.components.HttpClientRequestImpl.end( > HttpClientRequestImpl.java:140) > > 2017-01-05 18:28:49,096 ERROR [stderr] (default task-17) at > com.markit.ondemand.auth.apiman.plugins.pingfed_oauth_ > policy.PingFedOauthPolicy.retrieveAccessTokenFromPing( > PingFedOauthPolicy.java:232) > > 2017-01-05 18:28:49,096 ERROR [stderr] (default task-17) at > com.markit.ondemand.auth.apiman.plugins.pingfed_oauth_ > policy.PingFedOauthPolicy.retrieveAccessTokenFromPing( > PingFedOauthPolicy.java:174) > > 2017-01-05 18:28:49,096 ERROR [stderr] (default task-17) at > com.markit.ondemand.auth.apiman.plugins.pingfed_oauth_ > policy.PingFedOauthPolicy.doApply(PingFedOauthPolicy.java:83) > > 2017-01-05 18:28:49,096 ERROR [stderr] (default task-17) at > com.markit.ondemand.auth.apiman.plugins.pingfed_oauth_ > policy.PingFedOauthPolicy.doApply(PingFedOauthPolicy.java:38) > > > > My plugin is making either an external request to ElasticSearch or an HTTP > request using IHttpClientComponent and then calling chain.doApply or > chain.doFailure from within the IAsyncResultHandler handle method. Is > there a problem with that pattern? > > > > Any help you can provide would be great. > > Thanks, > > > > [image: IHS Markit] > > * David Rush* > Director, API Development | Markit Digital > 5775 Flatiron Parkway | Boulder, CO 80301 > *P:* +1 303 583 4244 *Main:* +1 303 417 9999 > david.rush at ihsmarkit.com > > > > > > > > ------------------------------ > > This e-mail, including accompanying communications and attachments, is > strictly confidential and only for the intended recipient. Any retention, > use or disclosure not expressly authorised by Markit is prohibited. This > email is subject to all waivers and other terms at the following link: > http://www.markit.com/en/about/legal/email-disclaimer.page > > Please visit http://www.markit.com/en/about/contact/contact-us.page for > contact information on our offices worldwide. > > _______________________________________________ > 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/20170106/70f9930a/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 6881 bytes Desc: not available Url : http://lists.jboss.org/pipermail/apiman-user/attachments/20170106/70f9930a/attachment-0001.png From marc.savy at redhat.com Fri Jan 6 09:16:48 2017 From: marc.savy at redhat.com (Marc Savy) Date: Fri, 6 Jan 2017 14:16:48 +0000 Subject: [Apiman-user] Stream closed / Broken Pipe issues with custom plugin In-Reply-To: References: Message-ID: Hi Harry & David, Very interesting and glad to see a workaround/solution. I wonder if it's a manifestation of this bug: https://issues.jboss.org/browse/UNDERTOW-849 In the servlet implementation we use Undertow. I'll do some more research to see whether we can handle this more gracefully and in a more informative manner. May I ask what sort of load levels you were seeing that made the errors evident? Regards, Marc On 6 January 2017 at 03:51, Harry Trinta wrote: > Hi, David! > > I had exactly this problem. It is not relationed with the Apiman. The > problem is with Wildfly. If your Wildfly is with default configuration, you > have a limit of concurrent requests (Default "*Task max threads" = *16 * > vCPUs). So, when the Wildfly is working in the limit, it create a queue of > requests. > > > Suggested settings for your wildfly (adjust according to your server): > > > Configuration -> Subsystem -> IO > > WORKER > Io threads: 128 > Task max threads: 2048 > Stack size: 0 > Task keepalive: 120 > > BUFFER POLL > Buffer size: 16384 > Buffers per slice: 128 > Direct buffers: true > > 2017-01-05 17:54 GMT-02:00 David Rush : > >> Good afternoon, >> >> >> >> I?m having issues with on a production API which has started to receive >> high volumes of traffic. At peak volume times I see many exceptions being >> thrown in the logs. The stack is indicating that an error occurred in the >> policy chain, but when it tries to write the error to the response the >> connection has been closed. There seems to be a couple of flavors of >> IOException (broken pipe or stream closed from undertow). My plugin is >> calling chain.doApply(request) when it succeeds but the stack trace is >> indicating there is then an exception being caught in >> doApply(Chain.java:153). I am on version 1.2.2-Final. >> >> >> >> 2017-01-05 18:28:49,095 ERROR [stderr] (default task-17) >> java.io.IOException: UT010029: Stream is closed >> >> 2017-01-05 18:28:49,095 ERROR [stderr] (default task-17) at >> io.undertow.servlet.spec.ServletOutputStreamImpl.write(Servl >> etOutputStreamImpl.java:136) >> >> 2017-01-05 18:28:49,095 ERROR [stderr] (default task-17) at >> io.undertow.servlet.spec.ServletOutputStreamImpl.write(Servl >> etOutputStreamImpl.java:128) >> >> 2017-01-05 18:28:49,095 ERROR [stderr] (default task-17) at >> io.apiman.gateway.platforms.servlet.GatewayServlet$4.write( >> GatewayServlet.java:406) >> >> 2017-01-05 18:28:49,095 ERROR [stderr] (default task-17) at >> io.apiman.gateway.platforms.servlet.GatewayServlet$4.write( >> GatewayServlet.java:395) >> >> 2017-01-05 18:28:49,095 ERROR [stderr] (default task-17) at >> io.apiman.gateway.engine.impl.DefaultPolicyErrorWriter.write >> (DefaultPolicyErrorWriter.java:87) >> >> 2017-01-05 18:28:49,095 ERROR [stderr] (default task-17) at >> io.apiman.gateway.platforms.servlet.GatewayServlet.writeErro >> r(GatewayServlet.java:392) >> >> 2017-01-05 18:28:49,095 ERROR [stderr] (default task-17) at >> io.apiman.gateway.platforms.servlet.GatewayServlet$1.handle( >> GatewayServlet.java:210) >> >> 2017-01-05 18:28:49,095 ERROR [stderr] (default task-17) at >> io.apiman.gateway.platforms.servlet.GatewayServlet$1.handle( >> GatewayServlet.java:157) >> >> 2017-01-05 18:28:49,095 ERROR [stderr] (default task-17) at >> io.apiman.gateway.engine.impl.ApiRequestExecutorImpl.lambda$ >> wrapResultHandler$0(ApiRequestExecutorImpl.java:159) >> >> 2017-01-05 18:28:49,095 ERROR [stderr] (default task-17) at >> io.apiman.gateway.engine.impl.ApiRequestExecutorImpl.lambda$ >> createPolicyErrorHandler$17(ApiRequestExecutorImpl.java:614) >> >> 2017-01-05 18:28:49,095 ERROR [stderr] (default task-17) at >> io.apiman.gateway.engine.policy.Chain.throwError(Chain.java:249) >> >> 2017-01-05 18:28:49,095 ERROR [stderr] (default task-17) at >> io.apiman.gateway.engine.policy.Chain.doApply(Chain.java:153) >> >> 2017-01-05 18:28:49,096 ERROR [stderr] (default task-17) at >> com.markit.ondemand.auth.apiman.plugins.pingfed_oauth_policy >> .PingFedOauthPolicy.doSuccess(PingFedOauthPolicy.java:114) >> >> 2017-01-05 18:28:49,096 ERROR [stderr] (default task-17) at >> com.markit.ondemand.auth.apiman.plugins.pingfed_oauth_policy >> .PingFedOauthPolicy.access$100(PingFedOauthPolicy.java:38) >> >> 2017-01-05 18:28:49,096 ERROR [stderr] (default task-17) at >> com.markit.ondemand.auth.apiman.plugins.pingfed_oauth_policy >> .PingFedOauthPolicy$2.handle(PingFedOauthPolicy.java:193) >> >> 2017-01-05 18:28:49,096 ERROR [stderr] (default task-17) at >> com.markit.ondemand.auth.apiman.plugins.pingfed_oauth_policy >> .PingFedOauthPolicy$2.handle(PingFedOauthPolicy.java:174) >> >> 2017-01-05 18:28:49,096 ERROR [stderr] (default task-17) at >> io.apiman.gateway.platforms.servlet.components.HttpClientReq >> uestImpl.end(HttpClientRequestImpl.java:140) >> >> 2017-01-05 18:28:49,096 ERROR [stderr] (default task-17) at >> com.markit.ondemand.auth.apiman.plugins.pingfed_oauth_policy >> .PingFedOauthPolicy.retrieveAccessTokenFromPing(PingFedOauth >> Policy.java:232) >> >> 2017-01-05 18:28:49,096 ERROR [stderr] (default task-17) at >> com.markit.ondemand.auth.apiman.plugins.pingfed_oauth_policy >> .PingFedOauthPolicy.retrieveAccessTokenFromPing(PingFedOauth >> Policy.java:174) >> >> 2017-01-05 18:28:49,096 ERROR [stderr] (default task-17) at >> com.markit.ondemand.auth.apiman.plugins.pingfed_oauth_policy >> .PingFedOauthPolicy.doApply(PingFedOauthPolicy.java:83) >> >> 2017-01-05 18:28:49,096 ERROR [stderr] (default task-17) at >> com.markit.ondemand.auth.apiman.plugins.pingfed_oauth_policy >> .PingFedOauthPolicy.doApply(PingFedOauthPolicy.java:38) >> >> >> >> My plugin is making either an external request to ElasticSearch or an >> HTTP request using IHttpClientComponent and then calling chain.doApply or >> chain.doFailure from within the IAsyncResultHandler handle method. Is >> there a problem with that pattern? >> >> >> >> Any help you can provide would be great. >> >> Thanks, >> >> >> >> [image: IHS Markit] >> >> * David Rush* >> Director, API Development | Markit Digital >> 5775 Flatiron Parkway | Boulder, CO 80301 >> *P:* +1 303 583 4244 <(303)%20583-4244> *Main:* +1 303 417 9999 >> <(303)%20417-9999> >> david.rush at ihsmarkit.com >> >> >> >> >> >> >> >> ------------------------------ >> >> This e-mail, including accompanying communications and attachments, is >> strictly confidential and only for the intended recipient. Any retention, >> use or disclosure not expressly authorised by Markit is prohibited. This >> email is subject to all waivers and other terms at the following link: >> http://www.markit.com/en/about/legal/email-disclaimer.page >> >> Please visit http://www.markit.com/en/about/contact/contact-us.page for >> contact information on our offices worldwide. >> >> _______________________________________________ >> Apiman-user mailing list >> Apiman-user at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/apiman-user >> >> > > _______________________________________________ > 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/20170106/bb6b8658/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 6881 bytes Desc: not available Url : http://lists.jboss.org/pipermail/apiman-user/attachments/20170106/bb6b8658/attachment-0001.png From David.Rush at ihsmarkit.com Fri Jan 6 19:38:06 2017 From: David.Rush at ihsmarkit.com (David Rush) Date: Sat, 7 Jan 2017 00:38:06 +0000 Subject: [Apiman-user] Stream closed / Broken Pipe issues with custom plugin In-Reply-To: References: Message-ID: <258fa8afb7f04784a019e1050fef52c5@RIC1PDMSGDAG02.markit.partners> The particular API having the problem is doing about a million hits an hour at peak, spread across a pool of 6 hosts. I think the majority of our problem stemmed from the backend app we were calling from our custom plugin, which was itself queuing up requests. Increasing thread pool sizes in that app (and in addition Wildfly ? thanks Harry!) seems to have resolved the issue for now. I think the slow requests are causing connections to be timed out by either our front end load balancers or the client apps, thereby causing the stream errors. I am still curious as to how the exception manifests in the Chain.doApply method though. It might help to have that logged to file in addition to being sent to the response, which is failing because the connection is dead. Thanks, David From: Marc Savy [mailto:marc.savy at redhat.com] Sent: Friday, January 06, 2017 7:17 AM To: Harry Trinta Cc: David Rush; apiman-user at lists.jboss.org Subject: Re: [Apiman-user] Stream closed / Broken Pipe issues with custom plugin Hi Harry & David, Very interesting and glad to see a workaround/solution. I wonder if it's a manifestation of this bug: https://issues.jboss.org/browse/UNDERTOW-849 In the servlet implementation we use Undertow. I'll do some more research to see whether we can handle this more gracefully and in a more informative manner. May I ask what sort of load levels you were seeing that made the errors evident? Regards, Marc On 6 January 2017 at 03:51, Harry Trinta > wrote: Hi, David! I had exactly this problem. It is not relationed with the Apiman. The problem is with Wildfly. If your Wildfly is with default configuration, you have a limit of concurrent requests (Default "Task max threads" = 16 * vCPUs). So, when the Wildfly is working in the limit, it create a queue of requests. Suggested settings for your wildfly (adjust according to your server): Configuration -> Subsystem -> IO WORKER Io threads: 128 Task max threads: 2048 Stack size: 0 Task keepalive: 120 BUFFER POLL Buffer size: 16384 Buffers per slice: 128 Direct buffers: true 2017-01-05 17:54 GMT-02:00 David Rush >: Good afternoon, I?m having issues with on a production API which has started to receive high volumes of traffic. At peak volume times I see many exceptions being thrown in the logs. The stack is indicating that an error occurred in the policy chain, but when it tries to write the error to the response the connection has been closed. There seems to be a couple of flavors of IOException (broken pipe or stream closed from undertow). My plugin is calling chain.doApply(request) when it succeeds but the stack trace is indicating there is then an exception being caught in doApply(Chain.java:153). I am on version 1.2.2-Final. 2017-01-05 18:28:49,095 ERROR [stderr] (default task-17) java.io.IOException: UT010029: Stream is closed 2017-01-05 18:28:49,095 ERROR [stderr] (default task-17) at io.undertow.servlet.spec.ServletOutputStreamImpl.write(ServletOutputStreamImpl.java:136) 2017-01-05 18:28:49,095 ERROR [stderr] (default task-17) at io.undertow.servlet.spec.ServletOutputStreamImpl.write(ServletOutputStreamImpl.java:128) 2017-01-05 18:28:49,095 ERROR [stderr] (default task-17) at io.apiman.gateway.platforms.servlet.GatewayServlet$4.write(GatewayServlet.java:406) 2017-01-05 18:28:49,095 ERROR [stderr] (default task-17) at io.apiman.gateway.platforms.servlet.GatewayServlet$4.write(GatewayServlet.java:395) 2017-01-05 18:28:49,095 ERROR [stderr] (default task-17) at io.apiman.gateway.engine.impl.DefaultPolicyErrorWriter.write(DefaultPolicyErrorWriter.java:87) 2017-01-05 18:28:49,095 ERROR [stderr] (default task-17) at io.apiman.gateway.platforms.servlet.GatewayServlet.writeError(GatewayServlet.java:392) 2017-01-05 18:28:49,095 ERROR [stderr] (default task-17) at io.apiman.gateway.platforms.servlet.GatewayServlet$1.handle(GatewayServlet.java:210) 2017-01-05 18:28:49,095 ERROR [stderr] (default task-17) at io.apiman.gateway.platforms.servlet.GatewayServlet$1.handle(GatewayServlet.java:157) 2017-01-05 18:28:49,095 ERROR [stderr] (default task-17) at io.apiman.gateway.engine.impl.ApiRequestExecutorImpl.lambda$wrapResultHandler$0(ApiRequestExecutorImpl.java:159) 2017-01-05 18:28:49,095 ERROR [stderr] (default task-17) at io.apiman.gateway.engine.impl.ApiRequestExecutorImpl.lambda$createPolicyErrorHandler$17(ApiRequestExecutorImpl.java:614) 2017-01-05 18:28:49,095 ERROR [stderr] (default task-17) at io.apiman.gateway.engine.policy.Chain.throwError(Chain.java:249) 2017-01-05 18:28:49,095 ERROR [stderr] (default task-17) at io.apiman.gateway.engine.policy.Chain.doApply(Chain.java:153) 2017-01-05 18:28:49,096 ERROR [stderr] (default task-17) at com.markit.ondemand.auth.apiman.plugins.pingfed_oauth_policy.PingFedOauthPolicy.doSuccess(PingFedOauthPolicy.java:114) 2017-01-05 18:28:49,096 ERROR [stderr] (default task-17) at com.markit.ondemand.auth.apiman.plugins.pingfed_oauth_policy.PingFedOauthPolicy.access$100(PingFedOauthPolicy.java:38) 2017-01-05 18:28:49,096 ERROR [stderr] (default task-17) at com.markit.ondemand.auth.apiman.plugins.pingfed_oauth_policy.PingFedOauthPolicy$2.handle(PingFedOauthPolicy.java:193) 2017-01-05 18:28:49,096 ERROR [stderr] (default task-17) at com.markit.ondemand.auth.apiman.plugins.pingfed_oauth_policy.PingFedOauthPolicy$2.handle(PingFedOauthPolicy.java:174) 2017-01-05 18:28:49,096 ERROR [stderr] (default task-17) at io.apiman.gateway.platforms.servlet.components.HttpClientRequestImpl.end(HttpClientRequestImpl.java:140) 2017-01-05 18:28:49,096 ERROR [stderr] (default task-17) at com.markit.ondemand.auth.apiman.plugins.pingfed_oauth_policy.PingFedOauthPolicy.retrieveAccessTokenFromPing(PingFedOauthPolicy.java:232) 2017-01-05 18:28:49,096 ERROR [stderr] (default task-17) at com.markit.ondemand.auth.apiman.plugins.pingfed_oauth_policy.PingFedOauthPolicy.retrieveAccessTokenFromPing(PingFedOauthPolicy.java:174) 2017-01-05 18:28:49,096 ERROR [stderr] (default task-17) at com.markit.ondemand.auth.apiman.plugins.pingfed_oauth_policy.PingFedOauthPolicy.doApply(PingFedOauthPolicy.java:83) 2017-01-05 18:28:49,096 ERROR [stderr] (default task-17) at com.markit.ondemand.auth.apiman.plugins.pingfed_oauth_policy.PingFedOauthPolicy.doApply(PingFedOauthPolicy.java:38) My plugin is making either an external request to ElasticSearch or an HTTP request using IHttpClientComponent and then calling chain.doApply or chain.doFailure from within the IAsyncResultHandler handle method. Is there a problem with that pattern? Any help you can provide would be great. Thanks, [IHS Markit] David Rush Director, API Development | Markit Digital 5775 Flatiron Parkway | Boulder, CO 80301 P: +1 303 583 4244 Main: +1 303 417 9999 david.rush at ihsmarkit.com ________________________________ This e-mail, including accompanying communications and attachments, is strictly confidential and only for the intended recipient. Any retention, use or disclosure not expressly authorised by Markit is prohibited. This email is subject to all waivers and other terms at the following link: http://www.markit.com/en/about/legal/email-disclaimer.page Please visit http://www.markit.com/en/about/contact/contact-us.page for contact information on our offices worldwide. _______________________________________________ Apiman-user mailing list Apiman-user at lists.jboss.org https://lists.jboss.org/mailman/listinfo/apiman-user _______________________________________________ Apiman-user mailing list Apiman-user at lists.jboss.org https://lists.jboss.org/mailman/listinfo/apiman-user ________________________________ This e-mail, including accompanying communications and attachments, is strictly confidential and only for the intended recipient. Any retention, use or disclosure not expressly authorised by Markit is prohibited. This email is subject to all waivers and other terms at the following link: http://www.markit.com/en/about/legal/email-disclaimer.page Please visit http://www.markit.com/en/about/contact/contact-us.page for contact information on our offices worldwide. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20170107/59215191/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 6881 bytes Desc: image001.png Url : http://lists.jboss.org/pipermail/apiman-user/attachments/20170107/59215191/attachment-0001.png From marc.savy at redhat.com Tue Jan 10 08:09:18 2017 From: marc.savy at redhat.com (Marc Savy) Date: Tue, 10 Jan 2017 13:09:18 +0000 Subject: [Apiman-user] Generic JWT plugin policy In-Reply-To: References: Message-ID: This is now released as: G: io.apiman.plugins A: apiman-plugins-jwt-policy V: 1.2.9.Final Feedback welcome! On 1 December 2016 at 16:33, Marc Savy wrote: > I should clarify that the purpose of this plugin is to work with any JWT > provider (rather than being Keycloak-focussed). > > Let me know how it works for you! > > On 1 December 2016 at 16:06, Marc Savy wrote: > >> Hi, >> >> I just pushed a (very simple) generic JWT plugin policy to master. >> >> To try it out right now you will need to build it. Just check out the >> apiman/apiman-plugins repo and execute `mvn clean install`. The plugin >> coordinates will be G: io.apiman.plugins A: apiman-plugins-jwt-policy V: >> 1.2.9-SNAPSHOT. >> >> It isn't yet as feature-rich as the Keycloak plugin, but you can: >> >> - Require JWT. >> - Require claims (e.g. sub = foo). >> - Require transport security (TLS, SSL). >> - Require JWT be cryptographically signed (aka. JWS). >> - Validate JWT against a provided public key. >> - Remove auth tokens (prevent them reaching the backend). >> - Set maximum clock skew. >> >> I'll expand on this shortly to add something that will hopefully add some >> commonly-used features from the Keycloak plugin: >> >> - Allow extraction of roles for authorization >> - Forward token fields as headers (e.g. X-Sub = sub) >> >> Regards, >> Marc >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20170110/a97bc597/attachment.html From Ram.Tanna at ril.com Thu Jan 12 04:25:26 2017 From: Ram.Tanna at ril.com (Ram.Tanna at ril.com) Date: Thu, 12 Jan 2017 09:25:26 +0000 Subject: [Apiman-user] Unable to get Simple Header Policy response when Rate Limiting Policy fails Message-ID: <96cb448f7679476cb5e831eea8006a3a@SIDC1EXMBX28.in.ril.com> Hi Guys, I have added Simple Header Policy and Rate Limiting Policy on my API. I want my custom response header(defined in simple header policy) in all the responses. I am getting custom header when the response is 200. But as my Rate limit exceeds I receive 429 status code and custom response doesn?t appear. I want Custom Response Header in all the scenarios (whether its 200 or 429). Can you please help me in achieving it ? 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/20170112/3f0a9ec5/attachment.html From marc.savy at redhat.com Thu Jan 12 09:05:48 2017 From: marc.savy at redhat.com (Marc Savy) Date: Thu, 12 Jan 2017 14:05:48 +0000 Subject: [Apiman-user] Unable to get Simple Header Policy response when Rate Limiting Policy fails In-Reply-To: <96cb448f7679476cb5e831eea8006a3a@SIDC1EXMBX28.in.ril.com> References: <96cb448f7679476cb5e831eea8006a3a@SIDC1EXMBX28.in.ril.com> Message-ID: This is an interesting use-case. In short, it is not possible with the standard apiman workflow, but is still achievable (although the granularity may not be satisfactory). This is because failures and errors return immediately - which has always been the desired behaviour up until now. I don't know what the specifics of your usage are, but, broadly: Options: 1. Modify your Undertow subsystem config to add the header to all responses (in standalone.xml). See: https://access.redhat.com/documentation/en/red-hat-jboss-enterprise-application-platform/7.0/paged/configuration-guide/chapter-17-configuring-the-web-server-undertow Example: 2. Provide your own implementations of IPolicyFailureWriter and/or IPolicyErrorWriter. In your apiman config: apiman-gateway.writers.policy-failure= apiman-gateway.writers.error= It may be that you only want to do one, or both. On 12 January 2017 at 09:25, wrote: > Hi Guys, > > > > I have added *Simple Header Policy* and *Rate Limiting Policy* on my API. > > > > I want my custom response header(defined in simple header policy) in all > the responses. > > > > I am getting custom header when the response is 200. But as my Rate limit > exceeds I receive 429 status code and custom response doesn?t appear. > > > > I want Custom Response Header in all the scenarios (whether its 200 or > 429). > > > > Can you please help me in achieving it ? > > > > 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/20170112/21e4b0d9/attachment.html From eric.wittmann at redhat.com Thu Jan 12 09:16:45 2017 From: eric.wittmann at redhat.com (Eric Wittmann) Date: Thu, 12 Jan 2017 09:16:45 -0500 Subject: [Apiman-user] Unable to get Simple Header Policy response when Rate Limiting Policy fails In-Reply-To: References: <96cb448f7679476cb5e831eea8006a3a@SIDC1EXMBX28.in.ril.com> Message-ID: Note that #2 is documented here: http://www.apiman.io/latest/developer-guide.html#_providing_a_custom_policy_failure_error_writer -Eric On Thu, Jan 12, 2017 at 9:05 AM, Marc Savy wrote: > This is an interesting use-case. In short, it is not possible with the > standard apiman workflow, but is still achievable (although the granularity > may not be satisfactory). This is because failures and errors return > immediately - which has always been the desired behaviour up until now. > > I don't know what the specifics of your usage are, but, broadly: > > Options: > > 1. Modify your Undertow subsystem config to add the header to all > responses (in standalone.xml). > > See: https://access.redhat.com/documentation/en/red-hat- > jboss-enterprise-application-platform/7.0/paged/ > configuration-guide/chapter-17-configuring-the-web-server-undertow > > Example: > > > header-value="WildFly/10/apiman"/> > > > 2. Provide your own implementations of IPolicyFailureWriter and/or > IPolicyErrorWriter. > > In your apiman config: > > apiman-gateway.writers.policy-failure= > apiman-gateway.writers.error= > > It may be that you only want to do one, or both. > > On 12 January 2017 at 09:25, wrote: > >> Hi Guys, >> >> >> >> I have added *Simple Header Policy* and *Rate Limiting Policy* on my >> API. >> >> >> >> I want my custom response header(defined in simple header policy) in all >> the responses. >> >> >> >> I am getting custom header when the response is 200. But as my Rate limit >> exceeds I receive 429 status code and custom response doesn?t appear. >> >> >> >> I want Custom Response Header in all the scenarios (whether its 200 or >> 429). >> >> >> >> Can you please help me in achieving it ? >> >> >> >> 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 >> >> > > _______________________________________________ > 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/20170112/9eb9047c/attachment-0001.html From Ram.Tanna at ril.com Fri Jan 13 07:54:38 2017 From: Ram.Tanna at ril.com (Ram.Tanna at ril.com) Date: Fri, 13 Jan 2017 12:54:38 +0000 Subject: [Apiman-user] Impact of adding extra fields in Rate Limiting Policy Message-ID: <07f77c3421db4cd69bd5ec3afa536363@SIDC1EXMBX28.in.ril.com> Dear Team, I have added 2 extra fields in Rate limiting Policy, as shown in the below image. These extra fields are added because I need it in response header in success(200) as well as failure(429) responses. To do so I have modified below mentioned files, 1. rate-limiting.include
I want to set retry time to
2. RateLimitingConfig private long retryTime; private RateLimitingPeriod retryTimeUnit; -- getter , setters 3. RateLimitingPolicy responseHeaders.put("X-Retry-Time", timeLimit); Kindly Confirm, - Where are we storing these information ? In Elastic Search, in SQL or somewhere else ? - Will these changes make any impact on other components ? - Would you recommend this code change ? Kindly suggest if you have any other solution for similar requirement. [cid:image001.png at 01D26DC5.2691F410] Regards, Ram Tanna 9819002243 "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/20170113/2bf32bea/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 62442 bytes Desc: image001.png Url : http://lists.jboss.org/pipermail/apiman-user/attachments/20170113/2bf32bea/attachment-0001.png From marc.savy at redhat.com Fri Jan 13 08:33:58 2017 From: marc.savy at redhat.com (Marc Savy) Date: Fri, 13 Jan 2017 13:33:58 +0000 Subject: [Apiman-user] Impact of adding extra fields in Rate Limiting Policy In-Reply-To: <07f77c3421db4cd69bd5ec3afa536363@SIDC1EXMBX28.in.ril.com> References: <07f77c3421db4cd69bd5ec3afa536363@SIDC1EXMBX28.in.ril.com> Message-ID: Hi, Just to understand: All you display in this header is a fixed value of, for instance, X-Retry-Time: 50000 - it's not a calculated value? If so, then assuming things are wired up correctly this should work fine. Apiman is split into two parts, the manager and the gateway, which have *separate* data-stores for typical decoupling reasons (performance, reliability, etc). - Before publishing config will be in the manager only. - After publishing config will be in the manager and gateway. So, if your manager uses ElasticSearch the config will be in the ElasticSearch. If your gateway the config will also be in ElasticSearch but a different "region". However one could be Infinispan and another ElasticSearch. Regards, Marc On 13 January 2017 at 12:54, wrote: > > > Dear Team, > > > > I have added 2 extra fields in Rate limiting Policy, as shown in the below > image. > > > > These extra fields are added because I need it in response header in > success(200) as well as failure(429) responses. > > > > To do so I have modified below mentioned files, > > *1. **rate-limiting.include* > > > >
> > I want to set retry time to > > apiman-i18n-key="rate-limiting.enter-num-requests" placeholder="Time > limit" ng-disabled="isEntityDisabled()"> > > > > > >
> > > > *2. **RateLimitingConfig* > > private long retryTime; > > private RateLimitingPeriod retryTimeUnit; > > -- getter , setters > > > > *3. **RateLimitingPolicy* > > responseHeaders.put("X-Retry-Time", timeLimit); > > > > > > Kindly Confirm, > > - Where are we storing these information ? In Elastic Search, in > SQL or somewhere else ? > > - Will these changes make any impact on other components ? > > - Would you recommend this code change ? > > > > Kindly suggest if you have any other solution for similar requirement. > > > > > > > > > > Regards, > > Ram Tanna > > 9819002243 > > > "*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/20170113/6872502d/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 62442 bytes Desc: not available Url : http://lists.jboss.org/pipermail/apiman-user/attachments/20170113/6872502d/attachment-0001.png From marc.savy at redhat.com Fri Jan 13 08:38:41 2017 From: marc.savy at redhat.com (Marc Savy) Date: Fri, 13 Jan 2017 13:38:41 +0000 Subject: [Apiman-user] Impact of adding extra fields in Rate Limiting Policy In-Reply-To: References: <07f77c3421db4cd69bd5ec3afa536363@SIDC1EXMBX28.in.ril.com> Message-ID: Missed out part of my reply: - If your manager is configured to use ElasticSearch the config will be in the ElasticSearch. - If your gateway registry is ElasticSearch the gateway config will also be in ElasticSearch but a different "region". However one could be Infinispan and another ElasticSearch, or SQL, etc. > - Where are we storing these information ? In Elastic Search, in SQL or somewhere else ? To reiterate, it should be whatever you configured. > - Will these changes make any impact on other components ? Should not have an impact. > - Would you recommend this code change ? Seems benign, if my assumptions are correct (other feedback welcome). On 13 January 2017 at 13:33, Marc Savy wrote: > Hi, > > Just to understand: > > All you display in this header is a fixed value of, for instance, > X-Retry-Time: 50000 - it's not a calculated value? > > If so, then assuming things are wired up correctly this should work fine. > > Apiman is split into two parts, the manager and the gateway, which have > *separate* data-stores for typical decoupling reasons (performance, > reliability, etc). > > - Before publishing config will be in the manager only. > - After publishing config will be in the manager and gateway. > > So, if your manager uses ElasticSearch the config will be in the > ElasticSearch. If your gateway the config will also be in ElasticSearch > but a different "region". However one could be Infinispan and another > ElasticSearch. > > Regards, > Marc > > On 13 January 2017 at 12:54, wrote: > >> >> >> Dear Team, >> >> >> >> I have added 2 extra fields in Rate limiting Policy, as shown in the >> below image. >> >> >> >> These extra fields are added because I need it in response header in >> success(200) as well as failure(429) responses. >> >> >> >> To do so I have modified below mentioned files, >> >> *1. **rate-limiting.include* >> >> >> >>
>> >> I want to set retry time to >> >> > class="form-control inline-apiman-form-control form-control" style="width: >> 100px" type="text" apiman-i18n-key="rate-limiting.enter-num-requests" >> placeholder="Time limit" ng-disabled="isEntityDisabled()"> >> >> >> >> >> >>
>> >> >> >> *2. **RateLimitingConfig* >> >> private long retryTime; >> >> private RateLimitingPeriod retryTimeUnit; >> >> -- getter , setters >> >> >> >> *3. **RateLimitingPolicy* >> >> responseHeaders.put("X-Retry-Time", timeLimit); >> >> >> >> >> >> Kindly Confirm, >> >> - Where are we storing these information ? In Elastic Search, >> in SQL or somewhere else ? >> >> - Will these changes make any impact on other components ? >> >> - Would you recommend this code change ? >> >> >> >> Kindly suggest if you have any other solution for similar requirement. >> >> >> >> >> >> >> >> >> >> Regards, >> >> Ram Tanna >> >> 9819002243 >> >> >> "*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/20170113/4f3115a3/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 62442 bytes Desc: not available Url : http://lists.jboss.org/pipermail/apiman-user/attachments/20170113/4f3115a3/attachment-0001.png From eric.wittmann at redhat.com Fri Jan 13 08:41:01 2017 From: eric.wittmann at redhat.com (Eric Wittmann) Date: Fri, 13 Jan 2017 08:41:01 -0500 Subject: [Apiman-user] Impact of adding extra fields in Rate Limiting Policy In-Reply-To: References: <07f77c3421db4cd69bd5ec3afa536363@SIDC1EXMBX28.in.ril.com> Message-ID: +1 to what Marc has already said. Note that unless you have changed the apiman config, the manager stores data in an H2 sql database and the gateway stores config in elasticsearch. These settings can be changed, but when you download the quickstart distribution those are the default settings. Also note that in both cases the configuration information is stored as a JSON blob - so you do NOT need to make any backend storage changes in order to accommodate this new configuration setting. Could you perhaps briefly explain the use-case for the Retry-Time response header? If it makes enough sense it would be great to pull these changes into the main repository. -Eric On Fri, Jan 13, 2017 at 8:33 AM, Marc Savy wrote: > Hi, > > Just to understand: > > All you display in this header is a fixed value of, for instance, > X-Retry-Time: 50000 - it's not a calculated value? > > If so, then assuming things are wired up correctly this should work fine. > > Apiman is split into two parts, the manager and the gateway, which have > *separate* data-stores for typical decoupling reasons (performance, > reliability, etc). > > - Before publishing config will be in the manager only. > - After publishing config will be in the manager and gateway. > > So, if your manager uses ElasticSearch the config will be in the > ElasticSearch. If your gateway the config will also be in ElasticSearch > but a different "region". However one could be Infinispan and another > ElasticSearch. > > Regards, > Marc > > On 13 January 2017 at 12:54, wrote: > >> >> >> Dear Team, >> >> >> >> I have added 2 extra fields in Rate limiting Policy, as shown in the >> below image. >> >> >> >> These extra fields are added because I need it in response header in >> success(200) as well as failure(429) responses. >> >> >> >> To do so I have modified below mentioned files, >> >> *1. **rate-limiting.include* >> >> >> >>
>> >> I want to set retry time to >> >> > class="form-control inline-apiman-form-control form-control" style="width: >> 100px" type="text" apiman-i18n-key="rate-limiting.enter-num-requests" >> placeholder="Time limit" ng-disabled="isEntityDisabled()"> >> >> >> >> >> >>
>> >> >> >> *2. **RateLimitingConfig* >> >> private long retryTime; >> >> private RateLimitingPeriod retryTimeUnit; >> >> -- getter , setters >> >> >> >> *3. **RateLimitingPolicy* >> >> responseHeaders.put("X-Retry-Time", timeLimit); >> >> >> >> >> >> Kindly Confirm, >> >> - Where are we storing these information ? In Elastic Search, >> in SQL or somewhere else ? >> >> - Will these changes make any impact on other components ? >> >> - Would you recommend this code change ? >> >> >> >> Kindly suggest if you have any other solution for similar requirement. >> >> >> >> >> >> >> >> >> >> Regards, >> >> Ram Tanna >> >> 9819002243 >> >> >> "*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 >> >> > > _______________________________________________ > 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/20170113/4e986226/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 62442 bytes Desc: not available Url : http://lists.jboss.org/pipermail/apiman-user/attachments/20170113/4e986226/attachment-0001.png From marc.savy at redhat.com Fri Jan 13 12:33:25 2017 From: marc.savy at redhat.com (Marc Savy) Date: Fri, 13 Jan 2017 17:33:25 +0000 Subject: [Apiman-user] Upcoming enhancement: Content-Length when no body mutating (data) policies in pipeline Message-ID: Based upon a community request, I'm making a small patch that ensures the Content-Length header is left intact when no data policies are in the pipeline (instead of using chunked encoding). This is handy if you want the client to know how far downloaded their file is, for instance. *Let me know if this might have any adverse impact upon you.* Example: CORS <-> Rate Limiting - Content-Length set. CORS <-> [ URL Rewriting ] - Transfer-Encoding: chunked; *no* Content-Length set. We don't set Content-Length in cases when body mutation may occur because it would require buffering to determine the final size before transmission - which is something we avoid for performance reasons. Regards, Marc -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20170113/42717020/attachment.html From Ram.Tanna at ril.com Mon Jan 16 01:51:48 2017 From: Ram.Tanna at ril.com (Ram.Tanna at ril.com) Date: Mon, 16 Jan 2017 06:51:48 +0000 Subject: [Apiman-user] Impact of adding extra fields in Rate Limiting Policy In-Reply-To: References: <07f77c3421db4cd69bd5ec3afa536363@SIDC1EXMBX28.in.ril.com> Message-ID: <06108ef741e24c8da45a9f67ae9d685a@SIDC1EXMBX28.in.ril.com> Thank you team for the inputs. Hi Eric, Retry-Time response header Use case : The application which we are developing has millions of users. We needed an option to down the API for certain amount of time at runtime. Let?s say If my API is not working as required due to high load (or any other reason), admin should have option to provide a downtime on that particular API. The downtime period should be dynamic. It could be anything 15 min / 30 min/ 1 hour?.. If admin is setting it as 15 min then clients will be able to see appropriate message as ?The operation which you are trying to perform is under maintenance, please try after 15/30 mins (or please try at 1:15 AM/PM). ? Hi Marc, X-Retry-Time: 1800 :- The value is set by the admin while configuring the policy. If admin is setting it as 30 mins then response would be X-Retry-Time: 1800. It is converted into seconds and stored. Dear Team, I have a file upload feature in my application. Just want to understand If client uploads a file, then does apiman store it or its bytes in temp folder or anywhere else ? Or Apiman doesn?t care about the uploaded file and just forwards the request to end API. I have a file upload feature in my application. Just want to understand, If client uploads a file then, does apiman store the file(or bytes) in temp folder or somewhere else ? Or Apiman don?t care about the uploaded file and just forwards the request to end API. Regards, Ram Tanna 9819002243 From: Eric Wittmann [mailto:eric.wittmann at redhat.com] Sent: 13 January 2017 19:11 To: Marc Savy Cc: Ram Tanna ; ram_tanna3 at yahoo.co.in; apiman-user at lists.jboss.org Subject: Re: [Apiman-user] Impact of adding extra fields in Rate Limiting Policy +1 to what Marc has already said. Note that unless you have changed the apiman config, the manager stores data in an H2 sql database and the gateway stores config in elasticsearch. These settings can be changed, but when you download the quickstart distribution those are the default settings. Also note that in both cases the configuration information is stored as a JSON blob - so you do NOT need to make any backend storage changes in order to accommodate this new configuration setting. Could you perhaps briefly explain the use-case for the Retry-Time response header? If it makes enough sense it would be great to pull these changes into the main repository. -Eric On Fri, Jan 13, 2017 at 8:33 AM, Marc Savy > wrote: Hi, Just to understand: All you display in this header is a fixed value of, for instance, X-Retry-Time: 50000 - it's not a calculated value? If so, then assuming things are wired up correctly this should work fine. Apiman is split into two parts, the manager and the gateway, which have *separate* data-stores for typical decoupling reasons (performance, reliability, etc). - Before publishing config will be in the manager only. - After publishing config will be in the manager and gateway. So, if your manager uses ElasticSearch the config will be in the ElasticSearch. If your gateway the config will also be in ElasticSearch but a different "region". However one could be Infinispan and another ElasticSearch. Regards, Marc On 13 January 2017 at 12:54, > wrote: Dear Team, I have added 2 extra fields in Rate limiting Policy, as shown in the below image. These extra fields are added because I need it in response header in success(200) as well as failure(429) responses. To do so I have modified below mentioned files, 1. rate-limiting.include
I want to set retry time to
2. RateLimitingConfig private long retryTime; private RateLimitingPeriod retryTimeUnit; -- getter , setters 3. RateLimitingPolicy responseHeaders.put("X-Retry-Time", timeLimit); Kindly Confirm, - Where are we storing these information ? In Elastic Search, in SQL or somewhere else ? - Will these changes make any impact on other components ? - Would you recommend this code change ? Kindly suggest if you have any other solution for similar requirement. [cid:image001.png at 01D26FEB.D65BBDE0] Regards, Ram Tanna 9819002243 "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 _______________________________________________ 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/20170116/74bebb78/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 62442 bytes Desc: image001.png Url : http://lists.jboss.org/pipermail/apiman-user/attachments/20170116/74bebb78/attachment-0001.png From palrawat at gmail.com Mon Jan 16 02:01:04 2017 From: palrawat at gmail.com (pal rawat) Date: Mon, 16 Jan 2017 12:31:04 +0530 Subject: [Apiman-user] Query Message-ID: Hi Apiman Team, I am Devops with a startup Project. Need ur help. We have apiman that is storing data in Elastic Search. We have Grafana, that is using ElasticSearch as data source.One of the variable in apiman is resource [ "resource" : { "type" : "string"] The resource values are like "/token/refresh", so when I trying to parse/execute calucaiton this resource type, its displaying it as two different values like token one and refresh another, that is wrong. I need it to as single "/token/refresh". I know about data collector like logstash, where one can declare them as data type URIPARAM, that can fix the problem. But not sure here. May I request you to please help me. Best Regards Deepak -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20170116/1f1aa895/attachment.html From marc.savy at redhat.com Tue Jan 17 07:02:31 2017 From: marc.savy at redhat.com (Marc Savy) Date: Tue, 17 Jan 2017 12:02:31 +0000 Subject: [Apiman-user] Impact of adding extra fields in Rate Limiting Policy In-Reply-To: <06108ef741e24c8da45a9f67ae9d685a@SIDC1EXMBX28.in.ril.com> References: <07f77c3421db4cd69bd5ec3afa536363@SIDC1EXMBX28.in.ril.com> <06108ef741e24c8da45a9f67ae9d685a@SIDC1EXMBX28.in.ril.com> Message-ID: Hi, So, do I understand correctly that you want to have a value that you can alter in the UI that dynamically changes the corresponding value in the gateway? If so, that's not possible with the mechanism you're using, as it is essentially immutable once published. Could you clarify that's your attempted workflow? Regards, Marc On 16 January 2017 at 06:51, wrote: > Thank you team for the inputs. > > > > Hi Eric, > > > > Retry-Time response header Use case : > > > > The application which we are developing has millions of users. > > > > We needed an option to down the API for certain amount of time at runtime. > Let?s say If my API is not working as required due to high load (or any > other reason), admin should have option to provide a downtime on that > particular API. > > > > The downtime period should be dynamic. It could be anything 15 min / 30 > min/ 1 hour?.. > > > > If admin is setting it as 15 min then clients will be able to see > appropriate message as ?The operation which you are trying to perform is > under maintenance, please try after 15/30 mins (or please try at 1:15 > AM/PM). ? > > > > Hi Marc, > > > > X-Retry-Time: 1800 :- The value is set by the admin while configuring the > policy. If admin is setting it as 30 mins then response would be *X-Retry-Time: > 1800*. It is converted into seconds and stored. > > > > > > Dear Team, > > > > I have a file upload feature in my application. Just want to understand If > client uploads a file, then does apiman store it or its bytes in temp > folder or anywhere else ? Or Apiman doesn?t care about the uploaded file > and just forwards the request to end API. > > > > > > I have a file upload feature in my application. > > Just want to understand, > > If client uploads a file then, does apiman store the file(or bytes) in > temp folder or somewhere else ? Or Apiman don?t care about the uploaded > file and just forwards the request to end API. > > > > > > Regards, > > Ram Tanna > > 9819002243 > > > > *From:* Eric Wittmann [mailto:eric.wittmann at redhat.com] > *Sent:* 13 January 2017 19:11 > *To:* Marc Savy > *Cc:* Ram Tanna ; ram_tanna3 at yahoo.co.in; > apiman-user at lists.jboss.org > *Subject:* Re: [Apiman-user] Impact of adding extra fields in Rate > Limiting Policy > > > > +1 to what Marc has already said. Note that unless you have changed the > apiman config, the manager stores data in an H2 sql database and the > gateway stores config in elasticsearch. These settings can be changed, but > when you download the quickstart distribution those are the default > settings. > > > > Also note that in both cases the configuration information is stored as a > JSON blob - so you do NOT need to make any backend storage changes in order > to accommodate this new configuration setting. > > > > Could you perhaps briefly explain the use-case for the Retry-Time response > header? If it makes enough sense it would be great to pull these changes > into the main repository. > > > > -Eric > > > > On Fri, Jan 13, 2017 at 8:33 AM, Marc Savy wrote: > > Hi, > > > > Just to understand: > > > > All you display in this header is a fixed value of, for instance, > X-Retry-Time: 50000 - it's not a calculated value? > > > > If so, then assuming things are wired up correctly this should work fine. > > > > Apiman is split into two parts, the manager and the gateway, which have > *separate* data-stores for typical decoupling reasons (performance, > reliability, etc). > > > > - Before publishing config will be in the manager only. > > - After publishing config will be in the manager and gateway. > > > > So, if your manager uses ElasticSearch the config will be in the > ElasticSearch. If your gateway the config will also be in ElasticSearch > but a different "region". However one could be Infinispan and another > ElasticSearch. > > > > Regards, > > Marc > > > > On 13 January 2017 at 12:54, wrote: > > > > Dear Team, > > > > I have added 2 extra fields in Rate limiting Policy, as shown in the below > image. > > > > These extra fields are added because I need it in response header in > success(200) as well as failure(429) responses. > > > > To do so I have modified below mentioned files, > > *1.** rate-limiting.include* > > > >
> > I want to set retry time to > > apiman-i18n-key="rate-limiting.enter-num-requests" placeholder="Time > limit" ng-disabled="isEntityDisabled()"> > > > > > >
> > > > *2.** RateLimitingConfig* > > private long retryTime; > > private RateLimitingPeriod retryTimeUnit; > > -- getter , setters > > > > *3.** RateLimitingPolicy* > > responseHeaders.put("X-Retry-Time", timeLimit); > > > > > > Kindly Confirm, > > - Where are we storing these information ? In Elastic Search, in > SQL or somewhere else ? > > - Will these changes make any impact on other components ? > > - Would you recommend this code change ? > > > > Kindly suggest if you have any other solution for similar requirement. > > > > > > > > > > [image: cid:image001.png at 01D26FEB.D65BBDE0] > > Regards, > > Ram Tanna > > 9819002243 > > > "*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 > > > > > _______________________________________________ > 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/20170117/e10b6b0e/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 62442 bytes Desc: not available Url : http://lists.jboss.org/pipermail/apiman-user/attachments/20170117/e10b6b0e/attachment-0001.png From marc.savy at redhat.com Tue Jan 17 07:03:32 2017 From: marc.savy at redhat.com (Marc Savy) Date: Tue, 17 Jan 2017 12:03:32 +0000 Subject: [Apiman-user] Query In-Reply-To: References: Message-ID: Hi, Which versions of apiman, ES and Grafana are you using? Was trying to reproduce your issue but the latest Grafana OOTB only supports ES 2.x, seemingly. Regards, Marc On 16 January 2017 at 07:01, pal rawat wrote: > Hi Apiman Team, > > I am Devops with a startup Project. Need ur help. > > We have apiman that is storing data in Elastic Search. We have Grafana, > that is using ElasticSearch as data source.One of the variable in apiman is > resource [ "resource" : { > "type" : "string"] The resource values are like > "/token/refresh", so when I trying to parse/execute calucaiton this > resource type, its displaying it as two different values like token one and > refresh another, that is wrong. I need it to as single "/token/refresh". > > I know about data collector like logstash, where one can declare them as > data type URIPARAM, that can fix the problem. But not sure here. > > May I request you to please help me. > > Best Regards > Deepak > > _______________________________________________ > 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/20170117/eb7e684d/attachment.html From palrawat at gmail.com Tue Jan 17 07:34:58 2017 From: palrawat at gmail.com (pal rawat) Date: Tue, 17 Jan 2017 18:04:58 +0530 Subject: [Apiman-user] Query In-Reply-To: References: Message-ID: Hi Marc, Nice to hear from you. Here are the details : Apiman : 1.2.6 ES : 2.3.2 Grafana : 4.0.2 Best Regards Deepak On Tue, Jan 17, 2017 at 5:33 PM, Marc Savy wrote: > Hi, > > Which versions of apiman, ES and Grafana are you using? Was trying to > reproduce your issue but the latest Grafana OOTB only supports ES 2.x, > seemingly. > > Regards, > Marc > > On 16 January 2017 at 07:01, pal rawat wrote: > >> Hi Apiman Team, >> >> I am Devops with a startup Project. Need ur help. >> >> We have apiman that is storing data in Elastic Search. We have Grafana, >> that is using ElasticSearch as data source.One of the variable in apiman is >> resource [ "resource" : { >> "type" : "string"] The resource values are like >> "/token/refresh", so when I trying to parse/execute calucaiton this >> resource type, its displaying it as two different values like token one and >> refresh another, that is wrong. I need it to as single "/token/refresh". >> >> I know about data collector like logstash, where one can declare them as >> data type URIPARAM, that can fix the problem. But not sure here. >> >> May I request you to please help me. >> >> Best Regards >> Deepak >> >> _______________________________________________ >> 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/20170117/846302bb/attachment.html From marc.savy at redhat.com Thu Jan 19 12:42:14 2017 From: marc.savy at redhat.com (Marc Savy) Date: Thu, 19 Jan 2017 17:42:14 +0000 Subject: [Apiman-user] Upcoming enhancement: Content-Length when no body mutating (data) policies in pipeline In-Reply-To: References: Message-ID: This has landed on master, please give it a go if you want to try it out. Regards, Marc On 13 January 2017 at 17:33, Marc Savy wrote: > Based upon a community request, I'm making a small patch that ensures the > Content-Length header is left intact when no data policies are in the > pipeline (instead of using chunked encoding). This is handy if you want the > client to know how far downloaded their file is, for instance. > > *Let me know if this might have any adverse impact upon you.* > > Example: > > CORS <-> Rate Limiting - Content-Length set. > CORS <-> [ URL Rewriting ] - Transfer-Encoding: chunked; *no* > Content-Length set. > > We don't set Content-Length in cases when body mutation may occur because > it would require buffering to determine the final size before transmission > - which is something we avoid for performance reasons. > > Regards, > Marc > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20170119/eb577b63/attachment.html From marc.savy at redhat.com Thu Jan 19 12:43:23 2017 From: marc.savy at redhat.com (Marc Savy) Date: Thu, 19 Jan 2017 17:43:23 +0000 Subject: [Apiman-user] How to configure CORS in APIMan? Problems with Headers in ajax In-Reply-To: References: Message-ID: If you build from master you should be able to see Content-Length now if you're not using any body mutating policies. On 3 January 2017 at 19:41, Celso Agra wrote: > Thanks for the reply! > > I was thinking there is some config to set up in APIMan, but the problem > was not there. My backend server is not adding the Content-Length, so the > server add Transfer-Encoding as Chunked in the Response-Header (now I > understand what's going on!). > > So, what I do was add the HTTP Header Policy Plugin, and then added > "Transfer-Encoding" in the Strip Headers fields, as the image below: > > ? > > I believe this is not the best thing to do but works for me for while. > I'll add the Content-Length in service to solve it! > > 2017-01-03 16:03 GMT-03:00 Marc Savy : > >> Replying to list. >> >> >> This going to help me a lot! I'm still planning to update my apiman >>> instance. Could I just remove my old version (1.2.3) and then deploy the >>> new one with my configurations files? >> >> >> Yes, that should work fine. You might want to build from master, >> considering the bug you encountered. I'll see if it's possible to at least >> do a snapshot release soon. People are on holiday at the moment. >> >> How to avoid chunked encoding when the rest api is passing through APIMan? >>> >> >> >> At present we use chunked encoding[1] because it's much simpler when >> handling mutable streaming payloads - especially if we're doing a >> transformation where it is not be clear what the final payload size will be >> until the process is completed (which would cause substantial buffering). >> >> That being said, in the case of a pipeline where no body mutation >> policies exist, we could consider setting content-length. I'll have to >> think about it to consider whether there are any important implications. >> This would be a feature request. >> >> How to consume a service with chunked-encoding transfer in java using >>> Jersey Framework >>> >> >> >> Chunked encoding has been supported since HTTP/1.1, unless you are using >> an extremely old/buggy version of Jersey it should work fine. It should be >> pretty much transparent in practice. >> >> Your bug might be something else. I suggest trying the latest release and >> then filing a JIRA with full information (e.g. expected vs actual; console >> output; configuration). >> >> Maybe this is happen for that reason -> APIMAN 984 >>> >>> >> >> I don't think you are using the policy mentioned in that ticket, are you? >> >> For now, I do not found any ways to workaround that issue, so I think I'm >>> gonna create a policy / plugin to solve that, just to adding a response >>> header setting the Content-Length on header. I don't know if it is a good >>> idea, but maybe could solve this for while. >>> >> >> You may be able to do that, but it would require buffering which will >> reduce performance. It may also be tricky to determine from within the >> policy which is the final chunk of a stream (with small payloads it's >> likely just 1 chunk, though). >> >> On 2 January 2017 at 22:12, Celso Agra wrote: >> >>> Thanks Marc! >>> >>> This going to help me a lot! I'm still planning to update my apiman >>> instance. Could I just remove my old version (1.2.3) and then deploy the >>> new one with my configurations files? >>> >> >>> Just to let you know... I believe I got another issue with apiman: >>> >>> - How to avoid chunked encoding when the rest api is passing through >>> APIMan? >>> >>> - How to consume a service with chunked-encoding transfer in java >>> using Jersey Framework >>> >>> >>> Maybe this is happen for that reason -> APIMAN 984 >>> >>> >> For now, I do not found any ways to workaround that issue, so I think I'm >>> gonna create a policy / plugin to solve that, just to adding a response >>> header setting the Content-Length on header. I don't know if it is a good >>> idea, but maybe could solve this for while. >>> >> >>> Thanks for your help Marc! >>> >>> >>> 2017-01-02 17:04 GMT-03:00 Marc Savy : >>> >>>> I addressed this for Celso over JIRA. >>>> >>>> Summary: >>>> >>>> - In general, if you're using CORS you should probably use the query >>>> parameter to transmit your access token (if you have one). This is because >>>> of a limitation to CORS preflight request phase which never transmits >>>> custom headers. >>>> >>>> - A separate issue was a bug (now fixed on master) where a data >>>> structure would cause certain header-value fields to be mixed up in >>>> specific circumstances. >>>> >>>> On 28 December 2016 at 14:10, Celso Agra wrote: >>>> >>>>> Hi all, >>>>> >>>>> It's me again! >>>>> So, I was looking for some solutions about my issue, and I found this: >>>>> https://issues.jboss.org/browse/APIMAN-516 >>>>> >>>>> It seems this issue still occurs with me. I tries to send some headers >>>>> via ajax, and get this response: >>>>> >>>>>> XMLHttpRequest cannot load https://apiman.url. Response to preflight >>>>>> request doesn't pass access control check: No 'Access-Control-Allow-Origin' >>>>>> header is present on the requested resource. Origin ' >>>>>> http://192.168.56.22:8080' is therefore not allowed access. The >>>>>> response had HTTP status code 500. >>>>> >>>>> >>>>> Here is the Response Headers: >>>>> >>>>>> Connection:close >>>>>> Content-Type:application/json >>>>>> Date:Wed, 28 Dec 2016 13:54:08 GMT >>>>>> Server:Apache/2.4.18 (Ubuntu) >>>>>> Transfer-Encoding:chunked >>>>>> X-Gateway-Error:API not public. >>>>>> X-Powered-By:Undertow/1 >>>>> >>>>> >>>>> and >>>>> >>>>> Here is the Request Headers: >>>>> >>>>>> Accept:*/* >>>>>> Accept-Encoding:gzip, deflate, sdch, br >>>>>> Accept-Language:pt-BR,pt;q=0.8,en-US;q=0.6,en;q=0.4 >>>>>> Access-Control-Request-Headers:authorization, x-api-key >>>>>> Access-Control-Request-Method:GET >>>>>> Connection:keep-alive >>>>>> Host: apiman.url >>>>>> Origin:http://192.168.56.22:8080 >>>>>> Referer:http://192.168.56.22:8080/app >>>>>> User-Agent:Mozilla/5.0 ... >>>>>> Query String Parameters >>>>>> view source >>>>>> view URL encoded >>>>> >>>>> >>>>> Does anyone has the same problem? >>>>> >>>>> 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/20170119/c64b690b/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: apiman images.png Type: image/png Size: 17124 bytes Desc: not available Url : http://lists.jboss.org/pipermail/apiman-user/attachments/20170119/c64b690b/attachment-0001.png From celso.agra at gmail.com Fri Jan 20 20:42:01 2017 From: celso.agra at gmail.com (Celso Agra) Date: Fri, 20 Jan 2017 22:42:01 -0300 Subject: [Apiman-user] How to configure CORS in APIMan? Problems with Headers in ajax In-Reply-To: References: Message-ID: Great! Thanks, Marc. 2017-01-19 14:43 GMT-03:00 Marc Savy : > If you build from master you should be able to see Content-Length now if > you're not using any body mutating policies. > > On 3 January 2017 at 19:41, Celso Agra wrote: > >> Thanks for the reply! >> >> I was thinking there is some config to set up in APIMan, but the problem >> was not there. My backend server is not adding the Content-Length, so the >> server add Transfer-Encoding as Chunked in the Response-Header (now I >> understand what's going on!). >> >> So, what I do was add the HTTP Header Policy Plugin, and then added >> "Transfer-Encoding" in the Strip Headers fields, as the image below: >> >> ? >> >> I believe this is not the best thing to do but works for me for while. >> I'll add the Content-Length in service to solve it! >> >> 2017-01-03 16:03 GMT-03:00 Marc Savy : >> >>> Replying to list. >>> >>> >>> This going to help me a lot! I'm still planning to update my apiman >>>> instance. Could I just remove my old version (1.2.3) and then deploy the >>>> new one with my configurations files? >>> >>> >>> Yes, that should work fine. You might want to build from master, >>> considering the bug you encountered. I'll see if it's possible to at least >>> do a snapshot release soon. People are on holiday at the moment. >>> >>> How to avoid chunked encoding when the rest api is passing through >>>> APIMan? >>>> >>> >>> >>> At present we use chunked encoding[1] because it's much simpler when >>> handling mutable streaming payloads - especially if we're doing a >>> transformation where it is not be clear what the final payload size will be >>> until the process is completed (which would cause substantial buffering). >>> >>> That being said, in the case of a pipeline where no body mutation >>> policies exist, we could consider setting content-length. I'll have to >>> think about it to consider whether there are any important implications. >>> This would be a feature request. >>> >>> How to consume a service with chunked-encoding transfer in java using >>>> Jersey Framework >>>> >>> >>> >>> Chunked encoding has been supported since HTTP/1.1, unless you are using >>> an extremely old/buggy version of Jersey it should work fine. It should be >>> pretty much transparent in practice. >>> >>> Your bug might be something else. I suggest trying the latest release >>> and then filing a JIRA with full information (e.g. expected vs actual; >>> console output; configuration). >>> >>> Maybe this is happen for that reason -> APIMAN 984 >>>> >>>> >>> >>> I don't think you are using the policy mentioned in that ticket, are you? >>> >>> For now, I do not found any ways to workaround that issue, so I think >>>> I'm gonna create a policy / plugin to solve that, just to adding a response >>>> header setting the Content-Length on header. I don't know if it is a good >>>> idea, but maybe could solve this for while. >>>> >>> >>> You may be able to do that, but it would require buffering which will >>> reduce performance. It may also be tricky to determine from within the >>> policy which is the final chunk of a stream (with small payloads it's >>> likely just 1 chunk, though). >>> >>> On 2 January 2017 at 22:12, Celso Agra wrote: >>> >>>> Thanks Marc! >>>> >>>> This going to help me a lot! I'm still planning to update my apiman >>>> instance. Could I just remove my old version (1.2.3) and then deploy the >>>> new one with my configurations files? >>>> >>> >>>> Just to let you know... I believe I got another issue with apiman: >>>> >>>> - How to avoid chunked encoding when the rest api is passing >>>> through APIMan? >>>> >>>> - How to consume a service with chunked-encoding transfer in java >>>> using Jersey Framework >>>> >>>> >>>> Maybe this is happen for that reason -> APIMAN 984 >>>> >>>> >>> For now, I do not found any ways to workaround that issue, so I think >>>> I'm gonna create a policy / plugin to solve that, just to adding a response >>>> header setting the Content-Length on header. I don't know if it is a good >>>> idea, but maybe could solve this for while. >>>> >>> >>>> Thanks for your help Marc! >>>> >>>> >>>> 2017-01-02 17:04 GMT-03:00 Marc Savy : >>>> >>>>> I addressed this for Celso over JIRA. >>>>> >>>>> Summary: >>>>> >>>>> - In general, if you're using CORS you should probably use the query >>>>> parameter to transmit your access token (if you have one). This is because >>>>> of a limitation to CORS preflight request phase which never transmits >>>>> custom headers. >>>>> >>>>> - A separate issue was a bug (now fixed on master) where a data >>>>> structure would cause certain header-value fields to be mixed up in >>>>> specific circumstances. >>>>> >>>>> On 28 December 2016 at 14:10, Celso Agra wrote: >>>>> >>>>>> Hi all, >>>>>> >>>>>> It's me again! >>>>>> So, I was looking for some solutions about my issue, and I found >>>>>> this: https://issues.jboss.org/browse/APIMAN-516 >>>>>> >>>>>> It seems this issue still occurs with me. I tries to send some >>>>>> headers via ajax, and get this response: >>>>>> >>>>>>> XMLHttpRequest cannot load https://apiman.url. Response to >>>>>>> preflight request doesn't pass access control check: No >>>>>>> 'Access-Control-Allow-Origin' header is present on the requested resource. >>>>>>> Origin 'http://192.168.56.22:8080' is therefore not allowed access. >>>>>>> The response had HTTP status code 500. >>>>>> >>>>>> >>>>>> Here is the Response Headers: >>>>>> >>>>>>> Connection:close >>>>>>> Content-Type:application/json >>>>>>> Date:Wed, 28 Dec 2016 13:54:08 GMT >>>>>>> Server:Apache/2.4.18 (Ubuntu) >>>>>>> Transfer-Encoding:chunked >>>>>>> X-Gateway-Error:API not public. >>>>>>> X-Powered-By:Undertow/1 >>>>>> >>>>>> >>>>>> and >>>>>> >>>>>> Here is the Request Headers: >>>>>> >>>>>>> Accept:*/* >>>>>>> Accept-Encoding:gzip, deflate, sdch, br >>>>>>> Accept-Language:pt-BR,pt;q=0.8,en-US;q=0.6,en;q=0.4 >>>>>>> Access-Control-Request-Headers:authorization, x-api-key >>>>>>> Access-Control-Request-Method:GET >>>>>>> Connection:keep-alive >>>>>>> Host: apiman.url >>>>>>> Origin:http://192.168.56.22:8080 >>>>>>> Referer:http://192.168.56.22:8080/app >>>>>>> User-Agent:Mozilla/5.0 ... >>>>>>> Query String Parameters >>>>>>> view source >>>>>>> view URL encoded >>>>>> >>>>>> >>>>>> Does anyone has the same problem? >>>>>> >>>>>> 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* >> > > -- --- *Celso Agra* -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20170120/ef34b7e2/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: apiman images.png Type: image/png Size: 17124 bytes Desc: not available Url : http://lists.jboss.org/pipermail/apiman-user/attachments/20170120/ef34b7e2/attachment-0001.png From sbalu27 at gmail.com Mon Jan 23 05:23:49 2017 From: sbalu27 at gmail.com (Balu Sadhasivam) Date: Mon, 23 Jan 2017 11:23:49 +0100 Subject: [Apiman-user] ApiMan error writer implementation. Message-ID: Hello, I can see in the developer guide that to custom generate IPolicyErrorWriter, one can extend using below option 4.5.3.2.6. io.apiman.gateway.engine.IPolicyErrorWriter Example Configuration apiman-gateway.writers.policy-error=plugin:com.example.groupId:artifactId:1.0.Final/com.example.apiman.FooPolicyErrorWriterImpl But the code base defines the error writer to be loaded from below property. GatewayConfigPropertiesERROR_WRITER_CLASS = "apiman-gateway.writers.error"; Is this case of mistake in documentation ? Does there exists more than one error writer API for policy and separately for other components ? regards Balu -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20170123/c291a7bf/attachment.html From eric.wittmann at redhat.com Mon Jan 23 08:52:59 2017 From: eric.wittmann at redhat.com (Eric Wittmann) Date: Mon, 23 Jan 2017 08:52:59 -0500 Subject: [Apiman-user] ApiMan error writer implementation. In-Reply-To: References: Message-ID: It's definitely just a documentation mistake. I'll get it corrected. Thanks! -Eric On Mon, Jan 23, 2017 at 5:23 AM, Balu Sadhasivam wrote: > Hello, > I can see in the developer guide > that to custom > generate IPolicyErrorWriter, one can extend using below option > > 4.5.3.2.6. io.apiman.gateway.engine.IPolicyErrorWriter Example > Configuration > > apiman-gateway.writers.policy-error=plugin:com.example.groupId:artifactId:1.0.Final/com.example.apiman.FooPolicyErrorWriterImpl > > > But the code base defines the error writer to be loaded from below > property. > > GatewayConfigPropertiesERROR_WRITER_CLASS = "apiman-gateway.writers.error" > ; > > Is this case of mistake in documentation ? Does there exists more than one > error writer API for policy and separately for other components ? > > > 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/20170123/8bdb3b40/attachment.html From sbalu27 at gmail.com Mon Jan 23 09:04:16 2017 From: sbalu27 at gmail.com (Balu S) Date: Mon, 23 Jan 2017 15:04:16 +0100 Subject: [Apiman-user] ApiMan error writer implementation. In-Reply-To: References: Message-ID: Hello Eric, Thanks. Is it possible to declare both Error and Failure writer implementations in single plugin ? It looks each need its own plugin.json. But I find it unnecessary as they both similar purpose and creating multiple plugins only makes additional deployment step. Regards Balu On Mon, Jan 23, 2017 at 2:52 PM, Eric Wittmann wrote: > It's definitely just a documentation mistake. I'll get it corrected. > > Thanks! > > -Eric > > > On Mon, Jan 23, 2017 at 5:23 AM, Balu Sadhasivam > wrote: > >> Hello, >> I can see in the developer guide >> that to custom >> generate IPolicyErrorWriter, one can extend using below option >> >> 4.5.3.2.6. io.apiman.gateway.engine.IPolicyErrorWriter Example >> Configuration >> >> apiman-gateway.writers.policy-error=plugin:com.example.groupId:artifactId:1.0.Final/com.example.apiman.FooPolicyErrorWriterImpl >> >> >> But the code base defines the error writer to be loaded from below >> property. >> >> GatewayConfigPropertiesERROR_WRITER_CLASS = >> "apiman-gateway.writers.error"; >> >> Is this case of mistake in documentation ? Does there exists more than >> one error writer API for policy and separately for other components ? >> >> >> 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/20170123/379ace82/attachment.html From eric.wittmann at redhat.com Mon Jan 23 10:14:47 2017 From: eric.wittmann at redhat.com (Eric Wittmann) Date: Mon, 23 Jan 2017 10:14:47 -0500 Subject: [Apiman-user] ApiMan error writer implementation. In-Reply-To: References: Message-ID: It is absolutely possible to declare both implementations in a single plugin. They would simply be two classes stored in the same plugin WAR. -Eric On Mon, Jan 23, 2017 at 9:04 AM, Balu S wrote: > Hello Eric, > Thanks. Is it possible to declare both Error and Failure writer > implementations in single plugin ? It looks each need its own plugin.json. > But I find it unnecessary as they both similar purpose and creating > multiple plugins only makes additional deployment step. > > Regards > Balu > > On Mon, Jan 23, 2017 at 2:52 PM, Eric Wittmann > wrote: > >> It's definitely just a documentation mistake. I'll get it corrected. >> >> Thanks! >> >> -Eric >> >> >> On Mon, Jan 23, 2017 at 5:23 AM, Balu Sadhasivam >> wrote: >> >>> Hello, >>> I can see in the developer guide >>> that to custom >>> generate IPolicyErrorWriter, one can extend using below option >>> >>> 4.5.3.2.6. io.apiman.gateway.engine.IPolicyErrorWriter Example >>> Configuration >>> >>> apiman-gateway.writers.policy-error=plugin:com.example.groupId:artifactId:1.0.Final/com.example.apiman.FooPolicyErrorWriterImpl >>> >>> >>> But the code base defines the error writer to be loaded from below >>> property. >>> >>> GatewayConfigPropertiesERROR_WRITER_CLASS = >>> "apiman-gateway.writers.error"; >>> >>> Is this case of mistake in documentation ? Does there exists more than >>> one error writer API for policy and separately for other components ? >>> >>> >>> 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/20170123/2cf83cbf/attachment.html From sbalu27 at gmail.com Mon Jan 23 11:48:39 2017 From: sbalu27 at gmail.com (Balu S) Date: Mon, 23 Jan 2017 17:48:39 +0100 Subject: [Apiman-user] ApiMan error writer implementation. In-Reply-To: References: Message-ID: looks like there is a problem if we declare both error and failure writers together inside the same war. If I remove the reference to one of the plugin from apiman.properties, it works.Should I raise a JIRA ? apiman-gateway.writers.error= apiman-gateway.writers.policy-failure= 17:40:40,689 ERROR [stderr] (default task-13) java.lang.IllegalStateException: zip file closed 17:40:40,690 ERROR [stderr] (default task-13) at java.util.zip.ZipFile.ensureOpen(ZipFile.java:669 ) 17:40:40,691 ERROR [stderr] (default task-13) at java.util.zip.ZipFile.getEntry(ZipFile.java:309) 17:40:40,691 ERROR [stderr] (default task-13) at io.apiman.common.plugin.PluginClassLoader.findCla ssContent(PluginClassLoader.java:202) 17:40:40,691 ERROR [stderr] (default task-13) at io.apiman.common.plugin.PluginClassLoader.findCla ss(PluginClassLoader.java:178) 17:40:40,692 ERROR [stderr] (default task-13) at java.lang.ClassLoader.loadClass(ClassLoader.java: 424) 17:40:40,693 ERROR [stderr] (default task-13) at java.lang.ClassLoader.loadClass(ClassLoader.java: 357) 17:40:40,693 ERROR [stderr] (default task-13) at com.fasterxml.jackson.module.jaxb.JaxbAnnotationI ntrospector.findAutoDetectVisibility(JaxbAnnotationIntrospector.java:533) 17:40:40,694 ERROR [stderr] (default task-13) at com.fasterxml.jackson.databind.introspect.Annotat ionIntrospectorPair.findAutoDetectVisibility(AnnotationIntrospectorPair.java:198) 17:40:40,694 ERROR [stderr] (default task-13) at com.fasterxml.jackson.databind.introspect.POJOPro pertiesCollector.(POJOPropertiesCollector.java:126) On Mon, Jan 23, 2017 at 4:14 PM, Eric Wittmann wrote: > It is absolutely possible to declare both implementations in a single > plugin. They would simply be two classes stored in the same plugin WAR. > > -Eric > > On Mon, Jan 23, 2017 at 9:04 AM, Balu S wrote: > >> Hello Eric, >> Thanks. Is it possible to declare both Error and Failure writer >> implementations in single plugin ? It looks each need its own plugin.json. >> But I find it unnecessary as they both similar purpose and creating >> multiple plugins only makes additional deployment step. >> >> Regards >> Balu >> >> On Mon, Jan 23, 2017 at 2:52 PM, Eric Wittmann >> wrote: >> >>> It's definitely just a documentation mistake. I'll get it corrected. >>> >>> Thanks! >>> >>> -Eric >>> >>> >>> On Mon, Jan 23, 2017 at 5:23 AM, Balu Sadhasivam >>> wrote: >>> >>>> Hello, >>>> I can see in the developer guide >>>> that to custom >>>> generate IPolicyErrorWriter, one can extend using below option >>>> >>>> 4.5.3.2.6. io.apiman.gateway.engine.IPolicyErrorWriter Example >>>> Configuration >>>> >>>> apiman-gateway.writers.policy-error=plugin:com.example.groupId:artifactId:1.0.Final/com.example.apiman.FooPolicyErrorWriterImpl >>>> >>>> >>>> But the code base defines the error writer to be loaded from below >>>> property. >>>> >>>> GatewayConfigPropertiesERROR_WRITER_CLASS = >>>> "apiman-gateway.writers.error"; >>>> >>>> Is this case of mistake in documentation ? Does there exists more than >>>> one error writer API for policy and separately for other components ? >>>> >>>> >>>> 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/20170123/21bcd748/attachment-0001.html From eric.wittmann at redhat.com Mon Jan 23 14:52:58 2017 From: eric.wittmann at redhat.com (Eric Wittmann) Date: Mon, 23 Jan 2017 14:52:58 -0500 Subject: [Apiman-user] ApiMan error writer implementation. In-Reply-To: References: Message-ID: Yes please - that is definitely a bug. On Mon, Jan 23, 2017 at 11:48 AM, Balu S wrote: > looks like there is a problem if we declare both error and failure writers > together inside the same war. If I remove the reference to one of the > plugin from apiman.properties, it works.Should I raise a JIRA ? > > apiman-gateway.writers.error= > apiman-gateway.writers.policy-failure= > > 17:40:40,689 ERROR [stderr] (default task-13) java.lang.IllegalStateException: > zip file closed > 17:40:40,690 ERROR [stderr] (default task-13) at java.util.zip.ZipFile. > ensureOpen(ZipFile.java:669 > ) > 17:40:40,691 ERROR [stderr] (default task-13) at java.util.zip.ZipFile. > getEntry(ZipFile.java:309) > 17:40:40,691 ERROR [stderr] (default task-13) at io.apiman.common.plugin. > PluginClassLoader.findCla > ssContent(PluginClassLoader.java:202) > 17:40:40,691 ERROR [stderr] (default task-13) at io.apiman.common.plugin. > PluginClassLoader.findCla > ss(PluginClassLoader.java:178) > 17:40:40,692 ERROR [stderr] (default task-13) at java.lang.ClassLoader. > loadClass(ClassLoader.java: > 424) > 17:40:40,693 ERROR [stderr] (default task-13) at java.lang.ClassLoader. > loadClass(ClassLoader.java: > 357) > 17:40:40,693 ERROR [stderr] (default task-13) at > com.fasterxml.jackson.module.jaxb.JaxbAnnotationI > ntrospector.findAutoDetectVisibility(JaxbAnnotationIntrospector.java:533) > 17:40:40,694 ERROR [stderr] (default task-13) at com.fasterxml.jackson. > databind.introspect.Annotat > ionIntrospectorPair.findAutoDetectVisibility(AnnotationIntrospectorPair. > java:198) > 17:40:40,694 ERROR [stderr] (default task-13) at com.fasterxml.jackson. > databind.introspect.POJOPro > pertiesCollector.(POJOPropertiesCollector.java:126) > > On Mon, Jan 23, 2017 at 4:14 PM, Eric Wittmann > wrote: > >> It is absolutely possible to declare both implementations in a single >> plugin. They would simply be two classes stored in the same plugin WAR. >> >> -Eric >> >> On Mon, Jan 23, 2017 at 9:04 AM, Balu S wrote: >> >>> Hello Eric, >>> Thanks. Is it possible to declare both Error and Failure writer >>> implementations in single plugin ? It looks each need its own plugin.json. >>> But I find it unnecessary as they both similar purpose and creating >>> multiple plugins only makes additional deployment step. >>> >>> Regards >>> Balu >>> >>> On Mon, Jan 23, 2017 at 2:52 PM, Eric Wittmann >> > wrote: >>> >>>> It's definitely just a documentation mistake. I'll get it corrected. >>>> >>>> Thanks! >>>> >>>> -Eric >>>> >>>> >>>> On Mon, Jan 23, 2017 at 5:23 AM, Balu Sadhasivam >>>> wrote: >>>> >>>>> Hello, >>>>> I can see in the developer guide >>>>> that to custom >>>>> generate IPolicyErrorWriter, one can extend using below option >>>>> >>>>> 4.5.3.2.6. io.apiman.gateway.engine.IPolicyErrorWriter Example >>>>> Configuration >>>>> >>>>> apiman-gateway.writers.policy-error=plugin:com.example.groupId:artifactId:1.0.Final/com.example.apiman.FooPolicyErrorWriterImpl >>>>> >>>>> >>>>> But the code base defines the error writer to be loaded from below >>>>> property. >>>>> >>>>> GatewayConfigPropertiesERROR_WRITER_CLASS = >>>>> "apiman-gateway.writers.error"; >>>>> >>>>> Is this case of mistake in documentation ? Does there exists more than >>>>> one error writer API for policy and separately for other components ? >>>>> >>>>> >>>>> 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/20170123/a9c0b180/attachment.html From celso.agra at gmail.com Thu Jan 26 16:16:47 2017 From: celso.agra at gmail.com (Celso Agra) Date: Thu, 26 Jan 2017 18:16:47 -0300 Subject: [Apiman-user] How to limit access for IP Address Message-ID: 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* -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20170126/7f18cbeb/attachment.html From sbalu27 at gmail.com Mon Jan 30 10:57:08 2017 From: sbalu27 at gmail.com (Balu S) Date: Mon, 30 Jan 2017 16:57:08 +0100 Subject: [Apiman-user] Logger exception Message-ID: 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.default-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.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$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.DeploymentManagerImpl.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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20170130/f6d42675/attachment.html From marc.savy at redhat.com Mon Jan 30 11:07:28 2017 From: marc.savy at redhat.com (Marc Savy) Date: Mon, 30 Jan 2017 16:07:28 +0000 Subject: [Apiman-user] Logger exception In-Reply-To: References: Message-ID: 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 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.default-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.ThreadPoolExecutor.runWorker( > ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$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.DeploymentManagerImpl.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/20170130/6e622a79/attachment-0001.html From sbalu27 at gmail.com Tue Jan 31 03:54:56 2017 From: sbalu27 at gmail.com (Balu S) Date: Tue, 31 Jan 2017 09:54:56 +0100 Subject: [Apiman-user] maven local m2 override missing. Message-ID: Hello, I have checked the source and one of the place that downloads plugin does not have this m2override defined. String m2Override = System.getProperty("apiman.gateway.m2-repository-path"); I think Apiman gateway looks at io.apiman.gateway.engine.impl.DefaultPluginRegistry.loadPlugin(PluginCoordinates, IAsyncResultHandler) where as Apiman manager UI reads from io.apiman.manager.api.core.plugin.AbstractPluginRegistry.downloadPlugin(File, PluginCoordinates) This makes the application inconsistent. Please let me know if I can raise JIRA or pull request ? Thanks. Best regards Balu -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20170131/e59bb2d2/attachment.html From eric.wittmann at redhat.com Tue Jan 31 09:08:03 2017 From: eric.wittmann at redhat.com (Eric Wittmann) Date: Tue, 31 Jan 2017 09:08:03 -0500 Subject: [Apiman-user] How to limit access for IP Address In-Reply-To: References: Message-ID: 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 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20170131/fa2444d8/attachment.html From eric.wittmann at redhat.com Tue Jan 31 09:09:22 2017 From: eric.wittmann at redhat.com (Eric Wittmann) Date: Tue, 31 Jan 2017 09:09:22 -0500 Subject: [Apiman-user] maven local m2 override missing. In-Reply-To: References: Message-ID: Yes, please raise a JIRA ticket for this. And then a pull request would be even better! :) On Tue, Jan 31, 2017 at 3:54 AM, Balu S wrote: > Hello, > I have checked the source and one of the place that downloads plugin does > not have this m2override defined. > > String m2Override = System.getProperty("apiman. > gateway.m2-repository-path"); > > I think Apiman gateway looks at io.apiman.gateway.engine.impl. > DefaultPluginRegistry.loadPlugin(PluginCoordinates, > IAsyncResultHandler) > > where as Apiman manager UI reads from > io.apiman.manager.api.core.plugin.AbstractPluginRegistry.downloadPlugin(File, > PluginCoordinates) > > This makes the application inconsistent. Please let me know if I can raise > JIRA or pull request ? Thanks. > > 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/20170131/c5c44232/attachment.html From marc.savy at redhat.com Tue Jan 31 09:14:55 2017 From: marc.savy at redhat.com (Marc Savy) Date: Tue, 31 Jan 2017 14:14:55 +0000 Subject: [Apiman-user] Logger exception In-Reply-To: References: Message-ID: I'll try to look into it shortly and post back onto the ML. On 30 January 2017 at 16:16, Balu S 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.UndertowDeploymentService$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( > ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$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.RuntimeException: > java.lang.NullPointerException > at io.undertow.servlet.core.DeploymentManagerImpl.deploy( > DeploymentManagerImpl.java:236) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentService. > startContext(UndertowDeploymentService.java:100) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1. > run(UndertowDeploymentService.java:82) > ... 6 more > Caused by: java.lang.RuntimeException: java.lang.NullPointerException > at io.apiman.gateway.engine.impl.ConfigDrivenEngineFactory.instantiate( > ConfigDrivenEngineFactory.java:179) > at io.apiman.gateway.engine.impl.ConfigDrivenEngineFactory.create( > ConfigDrivenEngineFactory.java:163) > at io.apiman.gateway.engine.impl.ConfigDrivenEngineFactory. > createLoggerFactory(ConfigDrivenEngineFactory.java:152) > at io.apiman.gateway.engine.impl.AbstractEngineFactory.createEngine( > AbstractEngineFactory.java:60) > at io.apiman.gateway.platforms.war.WarGateway.init(WarGateway.java:55) > at io.apiman.gateway.platforms.war.listeners.WarGatewayBootstrapper. > contextInitialized(WarGatewayBootstrapper.java: > > On Mon, Jan 30, 2017 at 5:07 PM, Marc Savy 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 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/20170131/c9117a99/attachment-0001.html From celso.agra at gmail.com Tue Jan 31 20:02:44 2017 From: celso.agra at gmail.com (Celso Agra) Date: Tue, 31 Jan 2017 22:02:44 -0300 Subject: [Apiman-user] How to limit access for IP Address In-Reply-To: References: Message-ID: 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 : > 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 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/20170131/98ef11de/attachment.html