Hi Saneth, Sorry I missed this email hence the late reply. See my comments inline.
On Thu, Jul 9, 2015 at 7:48 AM, Saneth Dharmakeerthi <[email protected]> wrote: > Hi Evanthika, > > Why is service is deactivation is not a failover scenario?, > So the reason why this is not considered by ESB/API-M as a failover scenario is because we get a response for the invocation that we do. For example, when you invoke the endpoint, you get a HTTP 200OK response. And so, it does not consider it as a failure. See [1] for a clear explanation on this. > The main problem here is the server return HTTP 200 for a URL which is not > there. Here there might not be problem in Failover function, but as i see > there is issue with web application deployment function. After web > application un-deploy if we access the web application why it navigate to > carbon login page ? > Yep. This is an issue with the backend side (in this case, App server). So maybe AS guys can answer this and explain why it is redirected to the carbon login page. > we can't expect all the time client side to use a web browser to assess > a web application. In our case the web app is a REST web service where it > is accessed by a Java client or CURL. > So in summary, for this particular API-M test case where you are testing failover, at the moment, you clearly cannot use the method of stopping the service. If this is the only option you have to write the test case, we might have to get this fixed at AS/Carbon level. [1] - https://docs.wso2.com/display/ESB481/Failover+Group Regards, Evanthika > > > Thanks and Best Regards, > > Saneth Dharmakeerthi > Senior Software Engineer > WSO2, Inc. > Mobile: +94772325511 > > On Wed, Jul 8, 2015 at 6:54 PM, Lasitha Deergawansa <[email protected]> > wrote: > >> I have tried this with different servers as backends and failover >> endpoint function is working fine. >> >> On Wed, Jul 8, 2015 at 5:55 PM, Evanthika Amarasiri <[email protected]> >> wrote: >> >>> I got Lasitha's web apps and tried to recreate the issue. >>> >>> In his scenario, he's deactivating the service from the UI. Once the >>> service is deactivated, when you send a request to that endpoint, it >>> redirects you to the Carbon login page with a HTTP 200 OK. >>> >>> Response headers: >>> HTTP/1.1 200 OK >>> Set-Cookie: JSESSIONID=BF80113B54C712FAA4810A027BA1CB03; Path=/; Secure; >>> HttpOnly >>> X-FRAME-OPTIONS: DENY >>> Content-Type: text/html;charset=UTF-8 >>> Content-Language: en-US >>> Transfer-Encoding: chunked >>> Vary: Accept-Encoding >>> Date: Wed, 08 Jul 2015 12:18:01 GMT >>> Server: WSO2 Carbon Server >>> >>> So it actually does not consider it as a failed scenario. That is why >>> it's not failing over. >>> >>> @Lasith, could you kindly try with an actual scenario where the endpoint >>> fails? >>> >>> Regards, >>> Evanthika >>> >>> On Wed, Jul 8, 2015 at 2:03 PM, Lasitha Deergawansa <[email protected]> >>> wrote: >>> >>>> Hi All, >>>> >>>> I'm in process of automating Failover end point function test case - >>>> APIM-45 [1] and figured out the Failover Endpoint function is not working >>>> in APIM 1.9.0. This is a blocker for the completion of the test case. >>>> Tracking purpose I have created a JIRA APIMANAGER-3967 [2] >>>> >>>> Steps to recreate: >>>> 1. Create, Publish and Subscribe a API with "Endpoint Type=Failover >>>> Endpoint" with a production endpoint and multiple production failover >>>> endpoints. >>>> 2. Send a request to the API and it will correctly invoked the >>>> production end point. >>>> 3. Make the production end point unavailable and send the request again >>>> 4. No response from the API. >>>> >>>> >>>> >>>> >>>> [1] >>>> https://testlink.wso2.com/linkto.php?tprojectPrefix=APIM&item=testcase&id=APIM-45 >>>> [2] https://wso2.org/jira/browse/APIMANAGER-3967 >>>> >>>> >>>> >>>> Thanks & Best Regards, >>>> Lasitha. >>>> >>> >>> >> >
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
