From scottpelliott at gmail.com Thu May 4 13:48:03 2017 From: scottpelliott at gmail.com (Scott Elliott) Date: Thu, 04 May 2017 17:48:03 +0000 Subject: [Apiman-user] Response when gateway cannot connect to the API implementation Message-ID: Right now, when the APIMAN gateway cannot connect to the API implementation's endpoint, the response code is 500, the message is null, and there is a stack trace. It's not a very useful response for the caller, and it's not really an internal problem with the gateway. It would be better if another response code were used (502? 503?) and a useful message were returned instead of a stack trace. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20170504/86e2e5f3/attachment.html From marc.savy at redhat.com Thu May 4 15:35:36 2017 From: marc.savy at redhat.com (Marc Savy) Date: Thu, 4 May 2017 20:35:36 +0100 Subject: [Apiman-user] Response when gateway cannot connect to the API implementation In-Reply-To: References: Message-ID: Hi Scott, Which implementation are you using? We actually just quietly released 1.3.0.Final (will be officially released once I finish the rafts of new documentation, website, blog, etc). Perhaps you can quickly replicate the scenario to see if the error still occurs in the same manner, else I'll try to improve it for the next release. WF10 http://downloads.jboss.org/apiman/1.3.0.Final/apiman-distro-wildfly10-1.3.0.Final-overlay.zip Vert.x Gateway http://downloads.jboss.org/apiman/1.3.0.Final/apiman-distro-vertx-1.3.0.Final.zip Regards, Marc On 4 May 2017 at 18:48, Scott Elliott wrote: > Right now, when the APIMAN gateway cannot connect to the API > implementation's endpoint, the response code is 500, the message is null, > and there is a stack trace. It's not a very useful response for the > caller, and it's not really an internal problem with the gateway. It would > be better if another response code were used (502? 503?) and a useful > message were returned instead of a stack trace. > > _______________________________________________ > Apiman-user mailing list > Apiman-user 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/20170504/a3d2d517/attachment.html From eric.wittmann at redhat.com Thu May 4 15:41:22 2017 From: eric.wittmann at redhat.com (Eric Wittmann) Date: Thu, 4 May 2017 15:41:22 -0400 Subject: [Apiman-user] Response when gateway cannot connect to the API implementation In-Reply-To: References: Message-ID: +1 good point. Can you perhaps open a JIRA ticket? That would be super helpful and would allow you to automatically track progress on the issue. -Eric On Thu, May 4, 2017 at 1:48 PM, Scott Elliott wrote: > Right now, when the APIMAN gateway cannot connect to the API > implementation's endpoint, the response code is 500, the message is null, > and there is a stack trace. It's not a very useful response for the > caller, and it's not really an internal problem with the gateway. It would > be better if another response code were used (502? 503?) and a useful > message were returned instead of a stack trace. > > _______________________________________________ > Apiman-user mailing list > Apiman-user 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/20170504/c27d43b5/attachment.html From scottpelliott at gmail.com Thu May 4 17:28:42 2017 From: scottpelliott at gmail.com (Scott Elliott) Date: Thu, 04 May 2017 21:28:42 +0000 Subject: [Apiman-user] Response when gateway cannot connect to the API implementation In-Reply-To: References: Message-ID: I tested the 1.3.0 EAP7 overlay. At least there's a message now: { "responseCode": 500, "message", "io.apiman.gateway.engine.beans.exceptions.ConnectionException: Not connected.", ... Then a stack trace. On Thu, May 4, 2017 at 3:41 PM Eric Wittmann wrote: > +1 good point. Can you perhaps open a JIRA ticket? That would be super > helpful and would allow you to automatically track progress on the issue. > > -Eric > > On Thu, May 4, 2017 at 1:48 PM, Scott Elliott > wrote: > >> Right now, when the APIMAN gateway cannot connect to the API >> implementation's endpoint, the response code is 500, the message is null, >> and there is a stack trace. It's not a very useful response for the >> caller, and it's not really an internal problem with the gateway. It would >> be better if another response code were used (502? 503?) and a useful >> message were returned instead of a stack trace. >> >> _______________________________________________ >> Apiman-user mailing list >> Apiman-user 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/20170504/65d9a5cc/attachment.html From marc.savy at redhat.com Fri May 5 06:48:34 2017 From: marc.savy at redhat.com (Marc Savy) Date: Fri, 5 May 2017 11:48:34 +0100 Subject: [Apiman-user] Response when gateway cannot connect to the API implementation In-Reply-To: References: Message-ID: Thanks for the feedback. I'll create an issue for this and look to improve the behaviour further for the next release. On 4 May 2017 at 22:28, Scott Elliott wrote: > I tested the 1.3.0 EAP7 overlay. At least there's a message now: > > { "responseCode": 500, "message", "io.apiman.gateway.engine. > beans.exceptions.ConnectionException: Not connected.", ... > > Then a stack trace. > > > On Thu, May 4, 2017 at 3:41 PM Eric Wittmann > wrote: > >> +1 good point. Can you perhaps open a JIRA ticket? That would be super >> helpful and would allow you to automatically track progress on the issue. >> >> -Eric >> >> On Thu, May 4, 2017 at 1:48 PM, Scott Elliott >> wrote: >> >>> Right now, when the APIMAN gateway cannot connect to the API >>> implementation's endpoint, the response code is 500, the message is null, >>> and there is a stack trace. It's not a very useful response for the >>> caller, and it's not really an internal problem with the gateway. It would >>> be better if another response code were used (502? 503?) and a useful >>> message were returned instead of a stack trace. >>> >>> _______________________________________________ >>> Apiman-user mailing list >>> Apiman-user 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/20170505/2d79985a/attachment-0001.html From scottpelliott at gmail.com Fri May 5 08:01:26 2017 From: scottpelliott at gmail.com (Scott Elliott) Date: Fri, 05 May 2017 12:01:26 +0000 Subject: [Apiman-user] Response when gateway cannot connect to the API implementation In-Reply-To: References: Message-ID: Thanks. Also along this line, we intermittently get a connection error like: {"statusCode":500,"data":"{\"responseCode\":500,\"message\":null,\"trace\":\"io.apiman.gateway.engine.beans.exceptions.RequestAbortedException\\n\\tat io.apiman.gateway.engine.impl.ApiRequestExecutorImpl$3.abort(ApiRequestExecutorImpl.java:721)\\n\\tat io.apiman.gateway.platforms.servlet.GatewayServlet$2.handle(GatewayServlet.java:173)\\n\\tat io.apiman.gateway.platforms.servlet.GatewayServlet$2.handle(GatewayServlet.java:160)\\n\\tat io.apiman.gateway.engine.impl.ApiRequestExecutorImpl.handleStream(ApiRequestExecutorImpl.java:693)\\n\\tat io.apiman.gateway.engine.impl.ApiRequestExecutorImpl.lambda$null$3(ApiRequestExecutorImpl.java:268)\\n\\tat io.apiman.gateway.engine.policy.Chain.handleHead(Chain.java:211)\\n\\tat io.apiman.gateway.engine.policy.Chain.doApply(Chain.java:150)\\n\\tat even though the service is available. I saw another message about setting some Wildfly subsystems configuration parameters for IO, but we still encounter this, and have to restart the gateway. Any idea what's happening, or suggestions on how to diagnose it? Thanks, Scott On Fri, May 5, 2017 at 6:48 AM Marc Savy wrote: > Thanks for the feedback. I'll create an issue for this and look to improve > the behaviour further for the next release. > > On 4 May 2017 at 22:28, Scott Elliott wrote: > >> I tested the 1.3.0 EAP7 overlay. At least there's a message now: >> >> { "responseCode": 500, "message", >> "io.apiman.gateway.engine.beans.exceptions.ConnectionException: Not >> connected.", ... >> >> Then a stack trace. >> >> >> On Thu, May 4, 2017 at 3:41 PM Eric Wittmann >> wrote: >> >>> +1 good point. Can you perhaps open a JIRA ticket? That would be super >>> helpful and would allow you to automatically track progress on the issue. >>> >>> -Eric >>> >>> On Thu, May 4, 2017 at 1:48 PM, Scott Elliott >>> wrote: >>> >>>> Right now, when the APIMAN gateway cannot connect to the API >>>> implementation's endpoint, the response code is 500, the message is null, >>>> and there is a stack trace. It's not a very useful response for the >>>> caller, and it's not really an internal problem with the gateway. It would >>>> be better if another response code were used (502? 503?) and a useful >>>> message were returned instead of a stack trace. >>>> >>>> _______________________________________________ >>>> Apiman-user mailing list >>>> Apiman-user 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/20170505/3eb99e36/attachment.html From donovan.muller at gmail.com Tue May 9 15:27:25 2017 From: donovan.muller at gmail.com (Donovan Muller) Date: Tue, 09 May 2017 19:27:25 +0000 Subject: [Apiman-user] Future of APIMan (in the context of recent announcements)? Message-ID: Hi all, Having seen the response (from Marc Savy) on the thread with the subject "Response when gateway cannot connect to the API implementation" about a 1.3.0 release of APIMan (with the vert.x gateway) and then having seen related commits on the GitHub repo ( https://github.com/apiman/apiman/commit/d3cedc5e05f143d45df8aa065e61de40b441c7fc). I'd just like to ask about the future of APIMan in relation to the 3Scale integration, especially, considering this announcement in relation to OpenShift: https://www.redhat.com/en/about/press-releases/red-hat-introduces-fully-containerized-api-management-platform . Some questions I have: * Will APIMan form some part of the new 3Scale integration (more specifically, the on premise solution/OpenShift)? * If not, why the 1.3.0 release (since this adds new features)? * If so, what would APIMan be used for? I'm asking this in the context of a financial services organisation needing an on premise OpenShift integrated API Gateway solution. We are currently using APIMan (based on what was done here: https://github.com/openshift/origin-apiman) as a temporary solution until whatever 3Scale on premise solution will be released... Thanks in advance -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20170509/ac9f22a2/attachment.html From marc.savy at redhat.com Wed May 10 11:11:09 2017 From: marc.savy at redhat.com (Marc Savy) Date: Wed, 10 May 2017 16:11:09 +0100 Subject: [Apiman-user] apiman 1.3.0.Final released! Message-ID: Greetings Apilytes, I'm pleased to officially announce the release of apiman 1.3.0.Final. For more information, check out the blog post: http://www.apiman.io/blog/apiman/release/2017/05/25/release-1.3.html Some prominent changes: - Vert.x gateway officially released! Please try it out and let us know your experiences. - Headless registry (load gateway config from local or remote JSON file). - Documentation reworked and published in GitBook format (use the tabs in the top right of certain pages to change between Servlet properties and Vert.x JSON examples!). - Lots of bug-fixes, features and enhancements. - Performance tuning Subsequent releases will occur more regularly from now, and you can expect for more information to be released regarding 3scale integration in the community as we're able to. Regards, Marc -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20170510/202c778f/attachment.html From marc.savy at redhat.com Wed May 10 11:25:16 2017 From: marc.savy at redhat.com (Marc Savy) Date: Wed, 10 May 2017 16:25:16 +0100 Subject: [Apiman-user] Future of APIMan (in the context of recent announcements)? In-Reply-To: References: Message-ID: Hi Donovan, * Will APIMan form some part of the new 3Scale integration As per our blog posts in the past, the aim is to integrate the apiman gateway with the 3scale manager in the community. In the next release I'll hopefully be providing some initial integration for folk to play with, but I'm not in a position to comment yet on fuller integration with the UI, etc -- rest assured as soon as I can, I'll let you all know. Of course, I will forward your interest to the relevant parties (and that of others who contact me -- or have already done so). (more specifically, the on premise solution/OpenShift)? > I can't really speak about products, but I will put you in touch with people who can! If not, why the 1.3.0 release (since this adds new features)? Some of this work is setting the ground for future work (including the above), ensuring that we keep the apiman community well-served in terms of gateway bug-fixes, features, performance, etc. The reason for the version number bump is (in part) that some small incompatible changes were introduced -- so, according to semver that requires a minor increment rather than patch. Plus some substantial new features released (apiman Vert.x gateway, headless registry, etc). Regards, Marc On 9 May 2017 at 20:27, Donovan Muller wrote: > Hi all, > > Having seen the response (from Marc Savy) on the thread with the subject > "Response when gateway cannot connect to the API implementation" about a > 1.3.0 release of APIMan (with the vert.x gateway) and then having seen > related commits on the GitHub repo (https://github.com/apiman/api > man/commit/d3cedc5e05f143d45df8aa065e61de40b441c7fc). I'd just like to > ask about the future of APIMan in relation to the 3Scale integration, > especially, considering this announcement in relation to OpenShift: > https://www.redhat.com/en/about/press-releases/re > d-hat-introduces-fully-containerized-api-management-platform. > > Some questions I have: > > * Will APIMan form some part of the new 3Scale integration (more > specifically, the on premise solution/OpenShift)? > * If not, why the 1.3.0 release (since this adds new features)? > * If so, what would APIMan be used for? > > I'm asking this in the context of a financial services organisation > needing an on premise OpenShift integrated API Gateway solution. We are > currently using APIMan (based on what was done here: > https://github.com/openshift/origin-apiman) as a temporary solution until > whatever 3Scale on premise solution will be released... > > Thanks in advance > > _______________________________________________ > 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/20170510/58b62162/attachment-0001.html From marc.savy at redhat.com Tue May 16 05:08:10 2017 From: marc.savy at redhat.com (Marc Savy) Date: Tue, 16 May 2017 10:08:10 +0100 Subject: [Apiman-user] Any objections to retiring the WildFly 8 & 9 distros of apiman? Message-ID: Hi, Both of these versions are quite old and the quality has been suffering accordingly. If nobody has objections I'm going to retire the WF 8 and 9 distros. WF10 (and soon 11) and EAP should continue to be supported. Regards, Marc -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20170516/16422bc9/attachment.html From eric.wittmann at redhat.com Tue May 16 09:37:35 2017 From: eric.wittmann at redhat.com (Eric Wittmann) Date: Tue, 16 May 2017 09:37:35 -0400 Subject: [Apiman-user] [Apiman-dev] Any objections to retiring the WildFly 8 & 9 distros of apiman? In-Reply-To: References: Message-ID: +1 to retiring WF8 and WF9 On Tue, May 16, 2017 at 5:08 AM, Marc Savy wrote: > Hi, > > Both of these versions are quite old and the quality has been suffering > accordingly. > > If nobody has objections I'm going to retire the WF 8 and 9 distros. > > WF10 (and soon 11) and EAP should continue to be supported. > > Regards, > Marc > > _______________________________________________ > Apiman-dev mailing list > Apiman-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/apiman-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20170516/89b1a3c6/attachment.html From kstam at redhat.com Tue May 16 09:54:27 2017 From: kstam at redhat.com (Kurt Stam) Date: Tue, 16 May 2017 09:54:27 -0400 Subject: [Apiman-user] [Apiman-dev] Any objections to retiring the WildFly 8 & 9 distros of apiman? In-Reply-To: References: Message-ID: No problem for me. Cheers, ?Kurt > On May 16, 2017, at 5:08 AM, Marc Savy wrote: > > Hi, > > Both of these versions are quite old and the quality has been suffering accordingly. > > If nobody has objections I'm going to retire the WF 8 and 9 distros. > > WF10 (and soon 11) and EAP should continue to be supported. > > Regards, > Marc > _______________________________________________ > Apiman-dev mailing list > Apiman-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/apiman-dev From David.Rush at ihsmarkit.com Thu May 18 15:56:59 2017 From: David.Rush at ihsmarkit.com (David Rush) Date: Thu, 18 May 2017 19:56:59 +0000 Subject: [Apiman-user] Future of APIMan (in the context of recent announcements)? In-Reply-To: References: Message-ID: <17b8e81ec2974e5e9eabe9e0bd5766e5@RIC1PDMSGDAG02.markit.partners> Hi Marc, Have you benchmarked apiman gateway performance against the 3scale gateway? Thanks, David From: apiman-user-bounces at lists.jboss.org [mailto:apiman-user-bounces at lists.jboss.org] On Behalf Of Marc Savy Sent: Wednesday, May 10, 2017 9:25 AM To: Donovan Muller Cc: apiman-user at lists.jboss.org Subject: Re: [Apiman-user] Future of APIMan (in the context of recent announcements)? Hi Donovan, * Will APIMan form some part of the new 3Scale integration As per our blog posts in the past, the aim is to integrate the apiman gateway with the 3scale manager in the community. In the next release I'll hopefully be providing some initial integration for folk to play with, but I'm not in a position to comment yet on fuller integration with the UI, etc -- rest assured as soon as I can, I'll let you all know. Of course, I will forward your interest to the relevant parties (and that of others who contact me -- or have already done so). (more specifically, the on premise solution/OpenShift)? I can't really speak about products, but I will put you in touch with people who can! If not, why the 1.3.0 release (since this adds new features)? Some of this work is setting the ground for future work (including the above), ensuring that we keep the apiman community well-served in terms of gateway bug-fixes, features, performance, etc. The reason for the version number bump is (in part) that some small incompatible changes were introduced -- so, according to semver that requires a minor increment rather than patch. Plus some substantial new features released (apiman Vert.x gateway, headless registry, etc). Regards, Marc On 9 May 2017 at 20:27, Donovan Muller > wrote: Hi all, Having seen the response (from Marc Savy) on the thread with the subject "Response when gateway cannot connect to the API implementation" about a 1.3.0 release of APIMan (with the vert.x gateway) and then having seen related commits on the GitHub repo (https://github.com/apiman/apiman/commit/d3cedc5e05f143d45df8aa065e61de40b441c7fc). I'd just like to ask about the future of APIMan in relation to the 3Scale integration, especially, considering this announcement in relation to OpenShift: https://www.redhat.com/en/about/press-releases/red-hat-introduces-fully-containerized-api-management-platform. Some questions I have: * Will APIMan form some part of the new 3Scale integration (more specifically, the on premise solution/OpenShift)? * If not, why the 1.3.0 release (since this adds new features)? * If so, what would APIMan be used for? I'm asking this in the context of a financial services organisation needing an on premise OpenShift integrated API Gateway solution. We are currently using APIMan (based on what was done here: https://github.com/openshift/origin-apiman) as a temporary solution until whatever 3Scale on premise solution will be released... Thanks in advance _______________________________________________ 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/20170518/0661aa1a/attachment-0001.html From David.Rush at ihsmarkit.com Thu May 18 20:51:46 2017 From: David.Rush at ihsmarkit.com (David Rush) Date: Fri, 19 May 2017 00:51:46 +0000 Subject: [Apiman-user] Response when gateway cannot connect to the API implementation In-Reply-To: References: Message-ID: <126338382004444ab6c2102592b07f4f@RIC1PDMSGDAG02.markit.partners> We also see this. Consumers often confuse it as a problem with the api gateway rather than the upstream app. I think this also leaks too much internal detail out to the public side, which is the kind of thing that gets flagged up on security audits. The option to return a simple 503 return status to the browser with the more detailed error sent to the log would be great. David From: apiman-user-bounces at lists.jboss.org [mailto:apiman-user-bounces at lists.jboss.org] On Behalf Of Scott Elliott Sent: Friday, May 05, 2017 6:01 AM To: Marc Savy Cc: apiman-user at lists.jboss.org Subject: Re: [Apiman-user] Response when gateway cannot connect to the API implementation Thanks. Also along this line, we intermittently get a connection error like: {"statusCode":500,"data":"{\"responseCode\":500,\"message\":null,\"trace\":\"io.apiman.gateway.engine.beans.exceptions.RequestAbortedException\\n\\tat io.apiman.gateway.engine.impl.ApiRequestExecutorImpl$3.abort(ApiRequestExecutorImpl.java:721)\\n\\tat io.apiman.gateway.platforms.servlet.GatewayServlet$2.handle(GatewayServlet.java:173)\\n\\tat io.apiman.gateway.platforms.servlet.GatewayServlet$2.handle(GatewayServlet.java:160)\\n\\tat io.apiman.gateway.engine.impl.ApiRequestExecutorImpl.handleStream(ApiRequestExecutorImpl.java:693)\\n\\tat io.apiman.gateway.engine.impl.ApiRequestExecutorImpl.lambda$null$3(ApiRequestExecutorImpl.java:268)\\n\\tat io.apiman.gateway.engine.policy.Chain.handleHead(Chain.java:211)\\n\\tat io.apiman.gateway.engine.policy.Chain.doApply(Chain.java:150)\\n\\tat even though the service is available. I saw another message about setting some Wildfly subsystems configuration parameters for IO, but we still encounter this, and have to restart the gateway. Any idea what's happening, or suggestions on how to diagnose it? Thanks, Scott On Fri, May 5, 2017 at 6:48 AM Marc Savy > wrote: Thanks for the feedback. I'll create an issue for this and look to improve the behaviour further for the next release. On 4 May 2017 at 22:28, Scott Elliott > wrote: I tested the 1.3.0 EAP7 overlay. At least there's a message now: { "responseCode": 500, "message", "io.apiman.gateway.engine.beans.exceptions.ConnectionException: Not connected.", ... Then a stack trace. On Thu, May 4, 2017 at 3:41 PM Eric Wittmann > wrote: +1 good point. Can you perhaps open a JIRA ticket? That would be super helpful and would allow you to automatically track progress on the issue. -Eric On Thu, May 4, 2017 at 1:48 PM, Scott Elliott > wrote: Right now, when the APIMAN gateway cannot connect to the API implementation's endpoint, the response code is 500, the message is null, and there is a stack trace. It's not a very useful response for the caller, and it's not really an internal problem with the gateway. It would be better if another response code were used (502? 503?) and a useful message were returned instead of a stack trace. _______________________________________________ Apiman-user mailing list Apiman-user 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/20170519/1e0c477d/attachment.html From marc.savy at redhat.com Fri May 19 10:15:16 2017 From: marc.savy at redhat.com (Marc Savy) Date: Fri, 19 May 2017 15:15:16 +0100 Subject: [Apiman-user] Future of APIMan (in the context of recent announcements)? In-Reply-To: <17b8e81ec2974e5e9eabe9e0bd5766e5@RIC1PDMSGDAG02.markit.partners> References: <17b8e81ec2974e5e9eabe9e0bd5766e5@RIC1PDMSGDAG02.markit.partners> Message-ID: Hi David, I don't have a comparison like that yet, no. It's going to be challenging to do an apples-to-apples comparison as functionality differs between the platforms. For example, the 3scale gateway doesn't have the concept of custom policy plugins and it doesn't support pluggable/raw metrics. That said: I'm going to try to produce a set of benchmarking scenarios (using Gatling) to sensibly approximate real-world setups. I'll publish those scenarios and numbers once I get access to some benchmarking hardware. As part of the process I want to reach out to the community to help define what we should be putting into those scenarios -- I hope I can include your use-cases into that. For example thought will need to be given to: - What kind of hardware and setups are people using. - What the policy setup is (e.g. JWT auth? rate limiting?) - Which components to use (e.g. Elasticsearch metrics, no metrics, ...) - Logging config - How many users will interact with the system in parallel - What do the payloads look like Naturally, we can have multiple scenarios to cover various setups. Armed with this, I'm hopeful that will provide sufficient information for folk to determine whether it's fast enough, sufficiently low latency, etc, for their use-cases. In general, my experience is that the Vert.x-based gateway has been good -- but that's from running tests on my dev machine, and I realise that's not rigorous, so I want to provide what you're asking for. There's another important aspect unrelated to Vert.x: over time I'll be doing more work to optimise component implementations (e.g. more optimal rate limiting algorithms, etc). This should improve performance on all platforms. Regards, Marc On 18 May 2017 at 20:56, David Rush wrote: > Hi Marc, > > > > Have you benchmarked apiman gateway performance against the 3scale gateway? > > > > Thanks, > David > > > > *From:* apiman-user-bounces at lists.jboss.org [mailto:apiman-user-bounces@ > lists.jboss.org] *On Behalf Of *Marc Savy > *Sent:* Wednesday, May 10, 2017 9:25 AM > *To:* Donovan Muller > *Cc:* apiman-user at lists.jboss.org > *Subject:* Re: [Apiman-user] Future of APIMan (in the context of recent > announcements)? > > > > Hi Donovan, > > > > * Will APIMan form some part of the new 3Scale integration > > > > As per our blog posts in the past, the aim is to integrate the apiman > gateway with the 3scale manager in the community. > > > > In the next release I'll hopefully be providing some initial integration > for folk to play with, but I'm not in a position to comment yet on fuller > integration with the UI, etc -- rest assured as soon as I can, I'll let you > all know. > > > > Of course, I will forward your interest to the relevant parties (and that > of others who contact me -- or have already done so). > > > > (more specifically, the on premise solution/OpenShift)? > > > > I can't really speak about products, but I will put you in touch with > people who can! > > > > If not, why the 1.3.0 release (since this adds new features)? > > > > Some of this work is setting the ground for future work (including the > above), ensuring that we keep the apiman community well-served in terms of > gateway bug-fixes, features, performance, etc. > > > > The reason for the version number bump is (in part) that some small > incompatible changes were introduced -- so, according to semver that > requires a minor increment rather than patch. Plus some substantial new > features released (apiman Vert.x gateway, headless registry, etc). > > > > Regards, > > Marc > > > > On 9 May 2017 at 20:27, Donovan Muller wrote: > > Hi all, > > > > Having seen the response (from Marc Savy) on the thread with the subject > "Response when gateway cannot connect to the API implementation" about a > 1.3.0 release of APIMan (with the vert.x gateway) and then having seen > related commits on the GitHub repo (https://github.com/apiman/ > apiman/commit/d3cedc5e05f143d45df8aa065e61de40b441c7fc). I'd just like to > ask about the future of APIMan in relation to the 3Scale integration, > especially, considering this announcement in relation to OpenShift: > https://www.redhat.com/en/about/press-releases/red-hat-introduces-fully- > containerized-api-management-platform. > > > > Some questions I have: > > > > * Will APIMan form some part of the new 3Scale integration (more > specifically, the on premise solution/OpenShift)? > > * If not, why the 1.3.0 release (since this adds new features)? > > * If so, what would APIMan be used for? > > > > I'm asking this in the context of a financial services organisation > needing an on premise OpenShift integrated API Gateway solution. We are > currently using APIMan (based on what was done here: > https://github.com/openshift/origin-apiman) as a temporary solution until > whatever 3Scale on premise solution will be released... > > > > Thanks in advance > > > _______________________________________________ > 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/20170519/bf3035ef/attachment-0001.html From David.Rush at ihsmarkit.com Fri May 19 11:59:46 2017 From: David.Rush at ihsmarkit.com (David Rush) Date: Fri, 19 May 2017 15:59:46 +0000 Subject: [Apiman-user] Future of APIMan (in the context of recent announcements)? In-Reply-To: References: <17b8e81ec2974e5e9eabe9e0bd5766e5@RIC1PDMSGDAG02.markit.partners> Message-ID: <6abb7c84540a4634af182212f52bde5d@RIC1PDMSGDAG02.markit.partners> Thanks for the response Marc. I will send over some of our use cases separately. Similar to Donovan I am trying to figure out why the compatibility is being built between the two platforms. What reasons (features or perf) are there to use the apiman gateway instead of just moving to the 3scale solution? Or is this just to provide an easy migration path for current apiman users to 3scale? Like others I was under the impression that apiman was basically moribund, so we began to evaluate options going forward and will need to make a decision soon. I?m pleasantly surprised you guys are still actively working on apiman, but a bit more clarity around Red Hat?s strategy would be great. Thanks again, David From: Marc Savy [mailto:marc.savy at redhat.com] Sent: Friday, May 19, 2017 8:15 AM To: David Rush Cc: apiman-user at lists.jboss.org Subject: Re: [Apiman-user] Future of APIMan (in the context of recent announcements)? Hi David, I don't have a comparison like that yet, no. It's going to be challenging to do an apples-to-apples comparison as functionality differs between the platforms. For example, the 3scale gateway doesn't have the concept of custom policy plugins and it doesn't support pluggable/raw metrics. That said: I'm going to try to produce a set of benchmarking scenarios (using Gatling) to sensibly approximate real-world setups. I'll publish those scenarios and numbers once I get access to some benchmarking hardware. As part of the process I want to reach out to the community to help define what we should be putting into those scenarios -- I hope I can include your use-cases into that. For example thought will need to be given to: - What kind of hardware and setups are people using. - What the policy setup is (e.g. JWT auth? rate limiting?) - Which components to use (e.g. Elasticsearch metrics, no metrics, ...) - Logging config - How many users will interact with the system in parallel - What do the payloads look like Naturally, we can have multiple scenarios to cover various setups. Armed with this, I'm hopeful that will provide sufficient information for folk to determine whether it's fast enough, sufficiently low latency, etc, for their use-cases. In general, my experience is that the Vert.x-based gateway has been good -- but that's from running tests on my dev machine, and I realise that's not rigorous, so I want to provide what you're asking for. There's another important aspect unrelated to Vert.x: over time I'll be doing more work to optimise component implementations (e.g. more optimal rate limiting algorithms, etc). This should improve performance on all platforms. Regards, Marc On 18 May 2017 at 20:56, David Rush > wrote: Hi Marc, Have you benchmarked apiman gateway performance against the 3scale gateway? Thanks, David From: apiman-user-bounces at lists.jboss.org [mailto:apiman-user-bounces at lists.jboss.org] On Behalf Of Marc Savy Sent: Wednesday, May 10, 2017 9:25 AM To: Donovan Muller Cc: apiman-user at lists.jboss.org Subject: Re: [Apiman-user] Future of APIMan (in the context of recent announcements)? Hi Donovan, * Will APIMan form some part of the new 3Scale integration As per our blog posts in the past, the aim is to integrate the apiman gateway with the 3scale manager in the community. In the next release I'll hopefully be providing some initial integration for folk to play with, but I'm not in a position to comment yet on fuller integration with the UI, etc -- rest assured as soon as I can, I'll let you all know. Of course, I will forward your interest to the relevant parties (and that of others who contact me -- or have already done so). (more specifically, the on premise solution/OpenShift)? I can't really speak about products, but I will put you in touch with people who can! If not, why the 1.3.0 release (since this adds new features)? Some of this work is setting the ground for future work (including the above), ensuring that we keep the apiman community well-served in terms of gateway bug-fixes, features, performance, etc. The reason for the version number bump is (in part) that some small incompatible changes were introduced -- so, according to semver that requires a minor increment rather than patch. Plus some substantial new features released (apiman Vert.x gateway, headless registry, etc). Regards, Marc On 9 May 2017 at 20:27, Donovan Muller > wrote: Hi all, Having seen the response (from Marc Savy) on the thread with the subject "Response when gateway cannot connect to the API implementation" about a 1.3.0 release of APIMan (with the vert.x gateway) and then having seen related commits on the GitHub repo (https://github.com/apiman/apiman/commit/d3cedc5e05f143d45df8aa065e61de40b441c7fc). I'd just like to ask about the future of APIMan in relation to the 3Scale integration, especially, considering this announcement in relation to OpenShift: https://www.redhat.com/en/about/press-releases/red-hat-introduces-fully-containerized-api-management-platform. Some questions I have: * Will APIMan form some part of the new 3Scale integration (more specifically, the on premise solution/OpenShift)? * If not, why the 1.3.0 release (since this adds new features)? * If so, what would APIMan be used for? I'm asking this in the context of a financial services organisation needing an on premise OpenShift integrated API Gateway solution. We are currently using APIMan (based on what was done here: https://github.com/openshift/origin-apiman) as a temporary solution until whatever 3Scale on premise solution will be released... Thanks in advance _______________________________________________ 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. ________________________________ 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/20170519/79849f6d/attachment-0001.html From marc.savy at redhat.com Sat May 20 15:34:22 2017 From: marc.savy at redhat.com (Marc Savy) Date: Sat, 20 May 2017 20:34:22 +0100 Subject: [Apiman-user] Future of APIMan (in the context of recent announcements)? In-Reply-To: <6abb7c84540a4634af182212f52bde5d@RIC1PDMSGDAG02.markit.partners> References: <17b8e81ec2974e5e9eabe9e0bd5766e5@RIC1PDMSGDAG02.markit.partners> <6abb7c84540a4634af182212f52bde5d@RIC1PDMSGDAG02.markit.partners> Message-ID: I can gladly put you in touch with people who know and can talk to you about support/product. I can only talk about project in this context. What reasons (features or perf) are there to use the apiman gateway instead > of just moving to the 3scale solution? The short answer: My view is that that they're *different* and strongly complementary, rather than competitive. Apiman is a great offering if you want: Java/JVM; custom policy plugins and plugin lifecycle management; a heck of a lot of flexibility in terms of components and platforms, then I think apiman gateway is a great offering. The long answer: I encourage you to go and do an analysis to see whether 3scale fulfils your needs, as I'm not an expert on 3scale by any means. That said, I think the apiman gateway has some very clear features and differentiators which may be valuable **depending on your requirements**. Just off the top of my head, to speak about some of apiman's attributes: - The apiman gateway is JVM/Java based, and can be run on a bunch of different platforms and in a few different ways (Vert.x, Tomcat, WildFly, EAP, Jetty, embedded, ...). 3scale's standard gateway is NGINX/LUA. - Apiman has custom policy policy plugins, with a clearly-defined development and lifecycle management. 3scale doesn't have a concept of policies, plugins or a policy chain; however, customisation can be done via LUA scripting which may be sufficient. Clearly, if you're a Java/JVM shop; want to do extensive customisation; want a familiar toolchain; want a familiar build and deployment system - then apiman gateway is a strong offering. Java/JVM offers an impressive ecosystem in terms of tools, libraries, performance, etc. Ultimately, we can offer practically arbitrary functionality in a flexible way, which is very powerful [if you need it!]. - Apiman is supremely flexible; you can swap out almost all components and provide alternative or custom implementations. For example, different rate limiting implementations, different shared state implementations, etc. - Apiman has pluggable metrics [amongst other things], giving you access to raw data that you can do almost anything with (e.g. shove into Elasticsearch, InfluxDB, etc). AIUI, 3scale requires up-front definition of metrics to be collected, so once your decision is made, that's it. - Apiman policies allow mutation of header and body, whereas AIUI, 3scale gateway doesn't presently do body mutation. There may be some features 3scale gateway that apiman gateway doesn't have -- but I'm just not expert in that software! Naturally, I encourage you to research your options. In terms of perf, as I mentioned I don't have numbers yet, but in my experience we've been more than fast enough (especially given that adding extra nodes isn't problematic for most people). More on that to come, of course... Or is this just to provide an easy migration path for current apiman users > to 3scale? > In the community we're looking to provide the ability for the apiman gateway to draw its configuration from 3scale manager/backend, so you can get all of the awesome-sauce of the apiman gateway in combination with the 3scale manager. Importantly, compatibility with the existing apiman UI/Manager is being maintained in these releases. [Of course, for some users a completely headless operation is what they want, and you can do that easily now]. In the longer term, I hope we will be able to offer deeper integration into the 3scale manager UI side of things. I've already received quite a lot of enthusiasm for that, and the more feedback/demand the better. As I'm the lead for only the apiman gateway, I can't make any commitments on behalf of other projects, but I sense there's a strong case. I?m pleasantly surprised you guys are still actively working on apiman, but > a bit more clarity around Red Hat?s strategy would be great. I'll contact you off-list to get answers to your other questions. Ultimately, demand from folk like you is an important factor in driving these decisions :-). So, the feedback I'm getting is really encouraging and **extremely important* *to show to the relevant people. I hope to land the initial 3scale integration I referred to earlier in the next couple of weeks. Regards, Marc On 19 May 2017 at 16:59, David Rush wrote: > Thanks for the response Marc. I will send over some of our use cases > separately. > > > > Similar to Donovan I am trying to figure out why the compatibility is > being built between the two platforms. What reasons (features or perf) are > there to use the apiman gateway instead of just moving to the 3scale > solution? Or is this just to provide an easy migration path for current > apiman users to 3scale? > > > > Like others I was under the impression that apiman was basically moribund, > so we began to evaluate options going forward and will need to make a > decision soon. I?m pleasantly surprised you guys are still actively > working on apiman, but a bit more clarity around Red Hat?s strategy would > be great. > > > > Thanks again, > David > > > > *From:* Marc Savy [mailto:marc.savy at redhat.com] > *Sent:* Friday, May 19, 2017 8:15 AM > *To:* David Rush > > *Cc:* apiman-user at lists.jboss.org > *Subject:* Re: [Apiman-user] Future of APIMan (in the context of recent > announcements)? > > > > Hi David, > > > > I don't have a comparison like that yet, no. It's going to be challenging > to do an apples-to-apples comparison as functionality differs between the > platforms. > > > > For example, the 3scale gateway doesn't have the concept of custom policy > plugins and it doesn't support pluggable/raw metrics. > > > > That said: > > > > I'm going to try to produce a set of benchmarking scenarios (using > Gatling) to sensibly approximate real-world setups. I'll publish those > scenarios and numbers once I get access to some benchmarking hardware. > > > > As part of the process I want to reach out to the community to help define > what we should be putting into those scenarios -- I hope I can include your > use-cases into that. > > > > For example thought will need to be given to: > > - What kind of hardware and setups are people using. > > - What the policy setup is (e.g. JWT auth? rate limiting?) > > - Which components to use (e.g. Elasticsearch metrics, no metrics, ...) > > - Logging config > > - How many users will interact with the system in parallel > > - What do the payloads look like > > > > Naturally, we can have multiple scenarios to cover various setups. > > > > Armed with this, I'm hopeful that will provide sufficient information for > folk to determine whether it's fast enough, sufficiently low latency, etc, > for their use-cases. > > > > In general, my experience is that the Vert.x-based gateway has been good > -- but that's from running tests on my dev machine, and I realise that's > not rigorous, so I want to provide what you're asking for. > > > > There's another important aspect unrelated to Vert.x: over time I'll be > doing more work to optimise component implementations (e.g. more optimal > rate limiting algorithms, etc). This should improve performance on all > platforms. > > > > Regards, > > Marc > > > > On 18 May 2017 at 20:56, David Rush wrote: > > Hi Marc, > > > > Have you benchmarked apiman gateway performance against the 3scale gateway? > > > > Thanks, > David > > > > *From:* apiman-user-bounces at lists.jboss.org [mailto:apiman-user-bounces at li > sts.jboss.org] *On Behalf Of *Marc Savy > *Sent:* Wednesday, May 10, 2017 9:25 AM > *To:* Donovan Muller > *Cc:* apiman-user at lists.jboss.org > *Subject:* Re: [Apiman-user] Future of APIMan (in the context of recent > announcements)? > > > > Hi Donovan, > > > > * Will APIMan form some part of the new 3Scale integration > > > > As per our blog posts in the past, the aim is to integrate the apiman > gateway with the 3scale manager in the community. > > > > In the next release I'll hopefully be providing some initial integration > for folk to play with, but I'm not in a position to comment yet on fuller > integration with the UI, etc -- rest assured as soon as I can, I'll let you > all know. > > > > Of course, I will forward your interest to the relevant parties (and that > of others who contact me -- or have already done so). > > > > (more specifically, the on premise solution/OpenShift)? > > > > I can't really speak about products, but I will put you in touch with > people who can! > > > > If not, why the 1.3.0 release (since this adds new features)? > > > > Some of this work is setting the ground for future work (including the > above), ensuring that we keep the apiman community well-served in terms of > gateway bug-fixes, features, performance, etc. > > > > The reason for the version number bump is (in part) that some small > incompatible changes were introduced -- so, according to semver that > requires a minor increment rather than patch. Plus some substantial new > features released (apiman Vert.x gateway, headless registry, etc). > > > > Regards, > > Marc > > > > On 9 May 2017 at 20:27, Donovan Muller wrote: > > Hi all, > > > > Having seen the response (from Marc Savy) on the thread with the subject > "Response when gateway cannot connect to the API implementation" about a > 1.3.0 release of APIMan (with the vert.x gateway) and then having seen > related commits on the GitHub repo (https://github.com/apiman/api > man/commit/d3cedc5e05f143d45df8aa065e61de40b441c7fc). I'd just like to > ask about the future of APIMan in relation to the 3Scale integration, > especially, considering this announcement in relation to OpenShift: > https://www.redhat.com/en/about/press-releases/re > d-hat-introduces-fully-containerized-api-management-platform. > > > > Some questions I have: > > > > * Will APIMan form some part of the new 3Scale integration (more > specifically, the on premise solution/OpenShift)? > > * If not, why the 1.3.0 release (since this adds new features)? > > * If so, what would APIMan be used for? > > > > I'm asking this in the context of a financial services organisation > needing an on premise OpenShift integrated API Gateway solution. We are > currently using APIMan (based on what was done here: > https://github.com/openshift/origin-apiman) as a temporary solution until > whatever 3Scale on premise solution will be released... > > > > Thanks in advance > > > _______________________________________________ > 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. > > > > ------------------------------ > > 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/20170520/a03a512e/attachment-0001.html From celso.agra at gmail.com Wed May 31 16:45:40 2017 From: celso.agra at gmail.com (Celso Agra) Date: Wed, 31 May 2017 17:45:40 -0300 Subject: [Apiman-user] Would be possible to upgrade APIMan from 1.2.8 to 1.3.0? Message-ID: Hi all, Sorry about that, but I'm concern to upgrade my apiman to a newest. I read about upgrating the application: http://www.apiman.io/latest/installation-guide.html#_upgrading_to_a_new_apiman_version But I'd like to know if I upgrade from 1.2.8 to 1.3.0 is must needed to export and reimport all data from different versions. Could I just change server and application without change anything in my database? just put the new wildfly running the apiman instance. Would be possible to do that? PS.: My APIMan is running with a remote database and remote Keycloak. Best Regards, -- --- *Celso Agra* -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20170531/1b696474/attachment.html