Re: [Dev] [EI] Getting empty cached response

[Riyafa Abdul Hameed]

Hi,

There has been a regression and the following PR fixes it.
https://github.com/wso2/carbon-mediation/pull/965

Thanks,
Riyafa

On Thu, Feb 1, 2018 at 11:18 AM, Keerthika Mahendralingam <
keerth...@wso2.com> wrote:

> Hi All,
>
> I have cloned the latest fix for cache mediator and tried with WSO2 EI
> 6.1.1-update19-SNAPSHOT. But I'm getting the correct response to the first
> call and an empty response to the subsequent request. What could be the
> reason?
>
> I'm using the following proxy:
>
> 
> http://ws.apache.org/ns/synapse;
>name="connectMockito"
>startOnLoad="true"
>statistics="disable"
>trace="disable"
>transports="http,https">
>
>   
>  
> 
>
> 
> 
>GET
>
>(1|2)[0-9][0-9]
>org.wso2.carbon.mediator.cache.digest.
> HttpRequestHashGenerator
> 
> 
>  
>  
> 
>http://demo2236300.mockable.io/testService"/>
> 
>  
>   
>   
>  
>  
>  
>   
>
>
> 
>
>
>
> *Log:*
>
> [2018-02-01 11:14:45,069] [EI-Core] DEBUG - wire HTTP-Sender I/O
> dispatcher-1 << "GET /testService HTTP/1.1[\r][\n]"
>
> [2018-02-01 11:14:45,069] [EI-Core] DEBUG - wire HTTP-Sender I/O
> dispatcher-1 << "Accept: */*[\r][\n]"
>
> [2018-02-01 11:14:45,069] [EI-Core] DEBUG - wire HTTP-Sender I/O
> dispatcher-1 << "Content-Type: application/json[\r][\n]"
>
> [2018-02-01 11:14:45,069] [EI-Core] DEBUG - wire HTTP-Sender I/O
> dispatcher-1 << "Host: demo2236300.mockable.io[\r][\n]"
>
> [2018-02-01 11:14:45,069] [EI-Core] DEBUG - wire HTTP-Sender I/O
> dispatcher-1 << "Connection: Keep-Alive[\r][\n]"
>
> [2018-02-01 11:14:45,069] [EI-Core] DEBUG - wire HTTP-Sender I/O
> dispatcher-1 << "User-Agent: Synapse-PT-HttpComponents-NIO[\r][\n]"
>
> [2018-02-01 11:14:45,069] [EI-Core] DEBUG - wire HTTP-Sender I/O
> dispatcher-1 << "[\r][\n]"
>
> [2018-02-01 11:14:45,789] [EI-Core] DEBUG - wire HTTP-Sender I/O
> dispatcher-1 >> "HTTP/1.1 200 OK[\r][\n]"
>
> [2018-02-01 11:14:45,789] [EI-Core] DEBUG - wire HTTP-Sender I/O
> dispatcher-1 >> "cache-control: no-cache[\r][\n]"
>
> [2018-02-01 11:14:45,789] [EI-Core] DEBUG - wire HTTP-Sender I/O
> dispatcher-1 >> "access-control-allow-origin: *[\r][\n]"
>
> [2018-02-01 11:14:45,789] [EI-Core] DEBUG - wire HTTP-Sender I/O
> dispatcher-1 >> "Content-Type: application/json; charset=UTF-8[\r][\n]"
>
> [2018-02-01 11:14:45,789] [EI-Core] DEBUG - wire HTTP-Sender I/O
> dispatcher-1 >> "X-Cloud-Trace-Context: 8321c3bfbcd3e65e547803b2ed3252
> 00[\r][\n]"
>
> [2018-02-01 11:14:45,790] [EI-Core] DEBUG - wire HTTP-Sender I/O
> dispatcher-1 >> "Date: Thu, 01 Feb 2018 05:44:45 GMT[\r][\n]"
>
> [2018-02-01 11:14:45,790] [EI-Core] DEBUG - wire HTTP-Sender I/O
> dispatcher-1 >> "Server: Google Frontend[\r][\n]"
>
> [2018-02-01 11:14:45,790] [EI-Core] DEBUG - wire HTTP-Sender I/O
> dispatcher-1 >> "Content-Length: 27[\r][\n]"
>
> [2018-02-01 11:14:45,790] [EI-Core] DEBUG - wire HTTP-Sender I/O
> dispatcher-1 >> "[\r][\n]"
>
> [2018-02-01 11:14:45,790] [EI-Core] DEBUG - wire HTTP-Sender I/O
> dispatcher-1 >> "{[\n]"
>
> [2018-02-01 11:14:45,790] [EI-Core] DEBUG - wire HTTP-Sender I/O
> dispatcher-1 >> " "msg": "Hello Worldaa"[\n]"
>
> [2018-02-01 11:14:45,790] [EI-Core] DEBUG - wire HTTP-Sender I/O
> dispatcher-1 >> "}"
>
> [2018-02-01 11:14:45,821] [EI-Core]  INFO - LogMediator To:
> http://www.w3.org/2005/08/addressing/anonymous, WSAction: , SOAPAction: ,
> MessageID: urn:uuid:933544bb-4a63-4d0b-9022-2fe03d54b6db, Direction:
> response, Envelope:  xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/;><
> soapenv:Body>Hello Worldaa soapenv:Body>
>
> [2018-02-01 11:14:45,845] [EI-Core] DEBUG - wire HTTP-Listener I/O
> dispatcher-1 << "HTTP/1.1 200 OK[\r][\n]"
>
> [2018-02-01 11:14:45,845] [EI-Core] DEBUG - wire HTTP-Listener I/O
> dispatcher-1 << "access-control-allow-origin: *[\r][\n]"
>
> [2018-02-01 11:14:45,845] [EI-Core] DEBUG - wire HTTP-Listener I/O
> dispatcher-1 << "X-Cloud-Trace-Context: 8321c3bfbcd3e65e547803b2ed3252
> 00[\r][\n]"
>
> [2018-02-01 11:14:45,846] [EI-Core] DEBUG - wire HTTP-Listener I/O
> dispatcher-1 << "cacheKey: -27-21-649412412586-85-97-
> 8340-52-11-819416[\r][\n]"
>
> [2018-02-01 11:14:45,846] [EI-Core] DEBUG - wire HTTP-Listener I/O
> dispatcher-1 << "cache-control: no-cache[\r][\n]"
>
> [2018-02-01 11:14:45,846] [EI-Core] DEBUG - wire HTTP-Listener I/O
> dispatcher-1 << "Content-Type: application/json; charset=UTF-8[\r][\n]"
>
> [2018-02-01 11:14:45,846] [EI-Core] DEBUG - wire HTTP-Listener I/O
> dispatcher-1 << "Date: Thu, 01 Feb 2018 05:44:45 GMT[\r][\n]"
>
> [2018-02-01 11:14:45,846] [EI-Core] DEBUG - wire HTTP-Listener I/O
> dispatcher-1 << "Transfer-Encoding: chunked[\r][\n]"
>
> [2018-02-01 11:14:45,846] [EI-Core] DEBUG - wire HTTP-Listener I/O
> dispatcher-1 << "[\r][\n]"
>
> 

[Dev] [EI] Getting empty cached response

[Keerthika Mahendralingam]

Hi All,

I have cloned the latest fix for cache mediator and tried with WSO2 EI
6.1.1-update19-SNAPSHOT. But I'm getting the correct response to the first
call and an empty response to the subsequent request. What could be the
reason?

I'm using the following proxy:


http://ws.apache.org/ns/synapse;
   name="connectMockito"
   startOnLoad="true"
   statistics="disable"
   trace="disable"
   transports="http,https">
   
  
 

   


   GET
   
   (1|2)[0-9][0-9]

 
org.wso2.carbon.mediator.cache.digest.HttpRequestHashGenerator


 
 

   http://demo2236300.mockable.io/testService"/>

 
  
  
 
 
 
  
   
   




*Log:*

[2018-02-01 11:14:45,069] [EI-Core] DEBUG - wire HTTP-Sender I/O
dispatcher-1 << "GET /testService HTTP/1.1[\r][\n]"

[2018-02-01 11:14:45,069] [EI-Core] DEBUG - wire HTTP-Sender I/O
dispatcher-1 << "Accept: */*[\r][\n]"

[2018-02-01 11:14:45,069] [EI-Core] DEBUG - wire HTTP-Sender I/O
dispatcher-1 << "Content-Type: application/json[\r][\n]"

[2018-02-01 11:14:45,069] [EI-Core] DEBUG - wire HTTP-Sender I/O
dispatcher-1 << "Host: demo2236300.mockable.io[\r][\n]"

[2018-02-01 11:14:45,069] [EI-Core] DEBUG - wire HTTP-Sender I/O
dispatcher-1 << "Connection: Keep-Alive[\r][\n]"

[2018-02-01 11:14:45,069] [EI-Core] DEBUG - wire HTTP-Sender I/O
dispatcher-1 << "User-Agent: Synapse-PT-HttpComponents-NIO[\r][\n]"

[2018-02-01 11:14:45,069] [EI-Core] DEBUG - wire HTTP-Sender I/O
dispatcher-1 << "[\r][\n]"

[2018-02-01 11:14:45,789] [EI-Core] DEBUG - wire HTTP-Sender I/O
dispatcher-1 >> "HTTP/1.1 200 OK[\r][\n]"

[2018-02-01 11:14:45,789] [EI-Core] DEBUG - wire HTTP-Sender I/O
dispatcher-1 >> "cache-control: no-cache[\r][\n]"

[2018-02-01 11:14:45,789] [EI-Core] DEBUG - wire HTTP-Sender I/O
dispatcher-1 >> "access-control-allow-origin: *[\r][\n]"

[2018-02-01 11:14:45,789] [EI-Core] DEBUG - wire HTTP-Sender I/O
dispatcher-1 >> "Content-Type: application/json; charset=UTF-8[\r][\n]"

[2018-02-01 11:14:45,789] [EI-Core] DEBUG - wire HTTP-Sender I/O
dispatcher-1 >> "X-Cloud-Trace-Context:
8321c3bfbcd3e65e547803b2ed325200[\r][\n]"

[2018-02-01 11:14:45,790] [EI-Core] DEBUG - wire HTTP-Sender I/O
dispatcher-1 >> "Date: Thu, 01 Feb 2018 05:44:45 GMT[\r][\n]"

[2018-02-01 11:14:45,790] [EI-Core] DEBUG - wire HTTP-Sender I/O
dispatcher-1 >> "Server: Google Frontend[\r][\n]"

[2018-02-01 11:14:45,790] [EI-Core] DEBUG - wire HTTP-Sender I/O
dispatcher-1 >> "Content-Length: 27[\r][\n]"

[2018-02-01 11:14:45,790] [EI-Core] DEBUG - wire HTTP-Sender I/O
dispatcher-1 >> "[\r][\n]"

[2018-02-01 11:14:45,790] [EI-Core] DEBUG - wire HTTP-Sender I/O
dispatcher-1 >> "{[\n]"

[2018-02-01 11:14:45,790] [EI-Core] DEBUG - wire HTTP-Sender I/O
dispatcher-1 >> " "msg": "Hello Worldaa"[\n]"

[2018-02-01 11:14:45,790] [EI-Core] DEBUG - wire HTTP-Sender I/O
dispatcher-1 >> "}"

[2018-02-01 11:14:45,821] [EI-Core]  INFO - LogMediator To:
http://www.w3.org/2005/08/addressing/anonymous, WSAction: , SOAPAction: ,
MessageID: urn:uuid:933544bb-4a63-4d0b-9022-2fe03d54b6db, Direction:
response, Envelope: http://schemas.xmlsoap.org/soap/envelope/;>Hello
Worldaa

[2018-02-01 11:14:45,845] [EI-Core] DEBUG - wire HTTP-Listener I/O
dispatcher-1 << "HTTP/1.1 200 OK[\r][\n]"

[2018-02-01 11:14:45,845] [EI-Core] DEBUG - wire HTTP-Listener I/O
dispatcher-1 << "access-control-allow-origin: *[\r][\n]"

[2018-02-01 11:14:45,845] [EI-Core] DEBUG - wire HTTP-Listener I/O
dispatcher-1 << "X-Cloud-Trace-Context:
8321c3bfbcd3e65e547803b2ed325200[\r][\n]"

[2018-02-01 11:14:45,846] [EI-Core] DEBUG - wire HTTP-Listener I/O
dispatcher-1 << "cacheKey:
-27-21-649412412586-85-97-8340-52-11-819416[\r][\n]"

[2018-02-01 11:14:45,846] [EI-Core] DEBUG - wire HTTP-Listener I/O
dispatcher-1 << "cache-control: no-cache[\r][\n]"

[2018-02-01 11:14:45,846] [EI-Core] DEBUG - wire HTTP-Listener I/O
dispatcher-1 << "Content-Type: application/json; charset=UTF-8[\r][\n]"

[2018-02-01 11:14:45,846] [EI-Core] DEBUG - wire HTTP-Listener I/O
dispatcher-1 << "Date: Thu, 01 Feb 2018 05:44:45 GMT[\r][\n]"

[2018-02-01 11:14:45,846] [EI-Core] DEBUG - wire HTTP-Listener I/O
dispatcher-1 << "Transfer-Encoding: chunked[\r][\n]"

[2018-02-01 11:14:45,846] [EI-Core] DEBUG - wire HTTP-Listener I/O
dispatcher-1 << "[\r][\n]"

[2018-02-01 11:14:45,846] [EI-Core] DEBUG - wire HTTP-Listener I/O
dispatcher-1 << "17[\r][\n]"

[2018-02-01 11:14:45,846] [EI-Core] DEBUG - wire HTTP-Listener I/O
dispatcher-1 << "{"msg":"Hello Worldaa"}[\r][\n]"

[2018-02-01 11:14:45,846] [EI-Core] DEBUG - wire HTTP-Listener I/O
dispatcher-1 << "0[\r][\n]"

[2018-02-01 11:14:45,846] [EI-Core] DEBUG - wire HTTP-Listener I/O
dispatcher-1 << "[\r][\n]"

[2018-02-01 11:14:51,035] [EI-Core] DEBUG - wire HTTP-Listener I/O
dispatcher-2 >> "GET /services/connectMockito HTTP/1.1[\r][\n]"

Re: [Dev] When to mark a proxy service as a faulty service

[Malaka Gangananda]

Hi Shafreen,

Thanks for the reply.
Yes if it is get deployed as a CAR file, the proxy won't get deployed and
the CAR file is getting marked as faulty.

Thanks,

On Thu, Feb 1, 2018 at 8:45 AM, Shafreen Anfar  wrote:

> Hi Malaka,
>
> On Thu, Feb 1, 2018 at 8:31 AM, Malaka Gangananda 
> wrote:
>
>> Hi All,
>>
>> When we deploy a JMSListener proxy without activating the broker, proxy
>> service will be get marked as a faulty service.
>> This happens while trying to start listening for the service in axis2
>> transport. When this occurs the proxy service and the axis2 service also
>> have been built.
>>
>> But if an exception occurs while creating the proxy (In
>> ProxyServiceDeployer class) , for an example a required jar is missing to
>> create a script mediator, the proxy service will not be get deployed and
>> since that it will not be get marked as a faulty service as well.
>> But the exception will logged in the server.
>> So is this the expected behavior ?
>>
>
> Yeah. AFAIU, this is the expected behaviour. Anyways, if you do the same
> using a CAR file, you should see the CAR file marked as faulty.
>
>
>> Also it should be noted that in this situation the axis2 service or the
>> proxy service hasn't been built as well, since the exception occurs in the
>> process of creating the proxy.
>>
>> Thanks,
>> --
>> Malaka.
>> --
>> Malaka Gangananda - Software Engineer | WSO2
>> Email : mala...@wso2.com
>> Mobile : +94713564340 <+94%2071%20356%204340>
>> Web : http://wso2.com
>>   
>>
>
>
>
> --
> Regards,
> *Shafreen*
> Associate Technical Lead
> WSO2 Inc
> Mobile : 077-556-395-1
>



-- 
Malaka.
-- 
Malaka Gangananda - Software Engineer | WSO2
Email : mala...@wso2.com
Mobile : +94713564340
Web : http://wso2.com
  
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] When to mark a proxy service as a faulty service

[Shafreen Anfar]

Hi Malaka,

On Thu, Feb 1, 2018 at 8:31 AM, Malaka Gangananda  wrote:

> Hi All,
>
> When we deploy a JMSListener proxy without activating the broker, proxy
> service will be get marked as a faulty service.
> This happens while trying to start listening for the service in axis2
> transport. When this occurs the proxy service and the axis2 service also
> have been built.
>
> But if an exception occurs while creating the proxy (In
> ProxyServiceDeployer class) , for an example a required jar is missing to
> create a script mediator, the proxy service will not be get deployed and
> since that it will not be get marked as a faulty service as well.
> But the exception will logged in the server.
> So is this the expected behavior ?
>

Yeah. AFAIU, this is the expected behaviour. Anyways, if you do the same
using a CAR file, you should see the CAR file marked as faulty.


> Also it should be noted that in this situation the axis2 service or the
> proxy service hasn't been built as well, since the exception occurs in the
> process of creating the proxy.
>
> Thanks,
> --
> Malaka.
> --
> Malaka Gangananda - Software Engineer | WSO2
> Email : mala...@wso2.com
> Mobile : +94713564340 <+94%2071%20356%204340>
> Web : http://wso2.com
>   
>



-- 
Regards,
*Shafreen*
Associate Technical Lead
WSO2 Inc
Mobile : 077-556-395-1
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [APIM][1.10] Setting HTTP_SC in Auth failure handler does not work

[Malintha Amarasinghe]

On Wed, Jan 31, 2018 at 8:39 PM, Harsha Kumara  wrote:

>
>
> On Wed, Jan 31, 2018 at 8:37 PM, Isuru Haththotuwa 
> wrote:
>
>>
>>
>> On Wed, Jan 31, 2018 at 8:19 PM, Malintha Amarasinghe > > wrote:
>>
>>> Hi All,
>>>
>>> Shall we move our sequence execution logic [1] such a way that it is
>>> followed by response setting logic in the code [2]? Currently, it is
>>> preceded by [2] so whatever we set in the sequence is getting overridden by
>>> the code [2]. That needs to happen in the other way round ideally. If we do
>>> it, we can simply override the HTTP_SC only without affecting other things.
>>> WDYT?
>>>
>> +1
>>
> Yes that's better. Let's create a issue to track this.
>

Created https://github.com/wso2/product-apim/issues/2642 to track this.

Thanks!

>
>>> [1] https://github.com/wso2/carbon-apimgt/blob/e5bda7afcf0fb
>>> 9679cfcba96f56682692c0eb87a/components/apimgt/org.wso2.carbo
>>> n.apimgt.gateway/src/main/java/org/wso2/carbon/apimgt/
>>> gateway/handlers/security/APIAuthenticationHandler.java#L200-L204
>>> [2] https://github.com/wso2/carbon-apimgt/blob/e5bda7afcf0fb
>>> 9679cfcba96f56682692c0eb87a/components/apimgt/org.wso2.carbo
>>> n.apimgt.gateway/src/main/java/org/wso2/carbon/apimgt/
>>> gateway/handlers/security/APIAuthenticationHandler.java#L219-L235
>>>
>>> On Wed, Jan 31, 2018 at 9:25 AM, Lahiru Sandaruwan 
>>> wrote:
>>>
 I see. Will follow that and set the code, respond from the sequence
 then.

 Thanks.

 On Tue, Jan 30, 2018 at 9:28 PM, Sanjeewa Malalgoda 
 wrote:

> Yes send from custom sequence and then drop flow will work. Its better
> to maintain separate convert sequence.
>
> Thanks,
> sanjeewa.
>
> On Wed, Jan 31, 2018 at 8:21 AM, Harsha Kumara 
> wrote:
>
>> Hi Lahiru,
>>
>> I think it's not possible to override it but you can follow [1] to do
>> it in a separate way.
>>
>> [1] http://sanjeewamalalgoda.blogspot.com/2015/04/how-to-gen
>> erate-custom-error-message.html
>>
>> Thanks,
>> Harsha
>>
>> On Wed, Jan 31, 2018 at 2:08 AM, Lahiru Sandaruwan 
>> wrote:
>>
>>> Hi,
>>>
>>> I changed _auth_failure_handler_ to set HTTP code to 498. But it
>>> still responds with 401. My handler after change is as follows,
>>>
>>> http://ws.apache.org/ns/synapse;>
>>> 
>>> 
>>> >> />
>>> 
>>>
>>> Anything wrong with my config?
>>>
>>> Thanks.
>>>
>>> --
>>> --
>>>
>>> Lahiru Sandaruwan
>>> Associate Technical Lead,
>>> WSO2 Inc., http://wso2.com
>>>
>>> lean.enterprise.middleware
>>>
>>> m: +1 901 530 2379 <(901)%20530-2379>
>>> e: lahi...@wso2.com b: https://medium.com/@lahirugmg
>>> in: http://lk.linkedin.com/pub/lahiru-sandaruwan/16/153/146
>>>
>>>
>>
>>
>> --
>> Harsha Kumara
>> Software Engineer, WSO2 Inc.
>> Mobile: +94775505618 <077%20550%205618>
>> Blog:harshcreationz.blogspot.com
>>
>
>
>
> --
>
> *Sanjeewa Malalgoda*
> WSO2 Inc.
> Mobile : +94713068779 <071%20306%208779>
>
> blog
> :http://sanjeewamalalgoda.blogspot.com/
> 
>
>
>


 --
 --

 Lahiru Sandaruwan
 Associate Technical Lead,
 WSO2 Inc., http://wso2.com

 lean.enterprise.middleware

 m: +1 901 530 2379 <(901)%20530-2379>
 e: lahi...@wso2.com b: https://medium.com/@lahirugmg
 in: http://lk.linkedin.com/pub/lahiru-sandaruwan/16/153/146


 ___
 Dev mailing list
 Dev@wso2.org
 http://wso2.org/cgi-bin/mailman/listinfo/dev


>>>
>>>
>>> --
>>> Malintha Amarasinghe
>>> *WSO2, Inc. - lean | enterprise | middleware*
>>> http://wso2.com/
>>>
>>> Mobile : +94 712383306 <+94%2071%20238%203306>
>>>
>>> ___
>>> Dev mailing list
>>> Dev@wso2.org
>>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>>
>>>
>>
>>
>> --
>> Thanks and Regards,
>>
>> Isuru H.
>> +94 716 358 048 <+94%2071%20635%208048>* *
>>
>>
>>
>
>
> --
> Harsha Kumara
> Software Engineer, WSO2 Inc.
> Mobile: +94775505618 <+94%2077%20550%205618>
> Blog:harshcreationz.blogspot.com
>



-- 
Malintha Amarasinghe
*WSO2, Inc. - lean | enterprise | middleware*
http://wso2.com/

Mobile : +94 712383306
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [APIM][1.10] Setting HTTP_SC in Auth failure handler does not work

[Harsha Kumara]

On Wed, Jan 31, 2018 at 8:37 PM, Isuru Haththotuwa  wrote:

>
>
> On Wed, Jan 31, 2018 at 8:19 PM, Malintha Amarasinghe 
> wrote:
>
>> Hi All,
>>
>> Shall we move our sequence execution logic [1] such a way that it is
>> followed by response setting logic in the code [2]? Currently, it is
>> preceded by [2] so whatever we set in the sequence is getting overridden by
>> the code [2]. That needs to happen in the other way round ideally. If we do
>> it, we can simply override the HTTP_SC only without affecting other things.
>> WDYT?
>>
> +1
>
Yes that's better. Let's create a issue to track this.

>
>> [1] https://github.com/wso2/carbon-apimgt/blob/e5bda7afcf0fb
>> 9679cfcba96f56682692c0eb87a/components/apimgt/org.wso2.
>> carbon.apimgt.gateway/src/main/java/org/wso2/carbon/
>> apimgt/gateway/handlers/security/APIAuthenticationHandler.java#L200-L204
>> [2] https://github.com/wso2/carbon-apimgt/blob/e5bda7afcf0fb
>> 9679cfcba96f56682692c0eb87a/components/apimgt/org.wso2.
>> carbon.apimgt.gateway/src/main/java/org/wso2/carbon/
>> apimgt/gateway/handlers/security/APIAuthenticationHandler.java#L219-L235
>>
>> On Wed, Jan 31, 2018 at 9:25 AM, Lahiru Sandaruwan 
>> wrote:
>>
>>> I see. Will follow that and set the code, respond from the sequence then.
>>>
>>> Thanks.
>>>
>>> On Tue, Jan 30, 2018 at 9:28 PM, Sanjeewa Malalgoda 
>>> wrote:
>>>
 Yes send from custom sequence and then drop flow will work. Its better
 to maintain separate convert sequence.

 Thanks,
 sanjeewa.

 On Wed, Jan 31, 2018 at 8:21 AM, Harsha Kumara 
 wrote:

> Hi Lahiru,
>
> I think it's not possible to override it but you can follow [1] to do
> it in a separate way.
>
> [1] http://sanjeewamalalgoda.blogspot.com/2015/04/how-to-gen
> erate-custom-error-message.html
>
> Thanks,
> Harsha
>
> On Wed, Jan 31, 2018 at 2:08 AM, Lahiru Sandaruwan 
> wrote:
>
>> Hi,
>>
>> I changed _auth_failure_handler_ to set HTTP code to 498. But it
>> still responds with 401. My handler after change is as follows,
>>
>> http://ws.apache.org/ns/synapse;>
>> 
>> 
>> > />
>> 
>>
>> Anything wrong with my config?
>>
>> Thanks.
>>
>> --
>> --
>>
>> Lahiru Sandaruwan
>> Associate Technical Lead,
>> WSO2 Inc., http://wso2.com
>>
>> lean.enterprise.middleware
>>
>> m: +1 901 530 2379 <(901)%20530-2379>
>> e: lahi...@wso2.com b: https://medium.com/@lahirugmg
>> in: http://lk.linkedin.com/pub/lahiru-sandaruwan/16/153/146
>>
>>
>
>
> --
> Harsha Kumara
> Software Engineer, WSO2 Inc.
> Mobile: +94775505618 <077%20550%205618>
> Blog:harshcreationz.blogspot.com
>



 --

 *Sanjeewa Malalgoda*
 WSO2 Inc.
 Mobile : +94713068779 <071%20306%208779>

 blog
 :http://sanjeewamalalgoda.blogspot.com/
 



>>>
>>>
>>> --
>>> --
>>>
>>> Lahiru Sandaruwan
>>> Associate Technical Lead,
>>> WSO2 Inc., http://wso2.com
>>>
>>> lean.enterprise.middleware
>>>
>>> m: +1 901 530 2379 <(901)%20530-2379>
>>> e: lahi...@wso2.com b: https://medium.com/@lahirugmg
>>> in: http://lk.linkedin.com/pub/lahiru-sandaruwan/16/153/146
>>>
>>>
>>> ___
>>> Dev mailing list
>>> Dev@wso2.org
>>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>>
>>>
>>
>>
>> --
>> Malintha Amarasinghe
>> *WSO2, Inc. - lean | enterprise | middleware*
>> http://wso2.com/
>>
>> Mobile : +94 712383306 <+94%2071%20238%203306>
>>
>> ___
>> Dev mailing list
>> Dev@wso2.org
>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>
>>
>
>
> --
> Thanks and Regards,
>
> Isuru H.
> +94 716 358 048 <+94%2071%20635%208048>* *
>
>
>


-- 
Harsha Kumara
Software Engineer, WSO2 Inc.
Mobile: +94775505618
Blog:harshcreationz.blogspot.com
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [APIM][1.10] Setting HTTP_SC in Auth failure handler does not work

[Isuru Haththotuwa]

On Wed, Jan 31, 2018 at 8:19 PM, Malintha Amarasinghe 
wrote:

> Hi All,
>
> Shall we move our sequence execution logic [1] such a way that it is
> followed by response setting logic in the code [2]? Currently, it is
> preceded by [2] so whatever we set in the sequence is getting overridden by
> the code [2]. That needs to happen in the other way round ideally. If we do
> it, we can simply override the HTTP_SC only without affecting other things.
> WDYT?
>
+1

>
> [1] https://github.com/wso2/carbon-apimgt/blob/
> e5bda7afcf0fb9679cfcba96f56682692c0eb87a/components/apimgt/
> org.wso2.carbon.apimgt.gateway/src/main/java/org/
> wso2/carbon/apimgt/gateway/handlers/security/
> APIAuthenticationHandler.java#L200-L204
> [2] https://github.com/wso2/carbon-apimgt/blob/
> e5bda7afcf0fb9679cfcba96f56682692c0eb87a/components/apimgt/
> org.wso2.carbon.apimgt.gateway/src/main/java/org/
> wso2/carbon/apimgt/gateway/handlers/security/
> APIAuthenticationHandler.java#L219-L235
>
> On Wed, Jan 31, 2018 at 9:25 AM, Lahiru Sandaruwan 
> wrote:
>
>> I see. Will follow that and set the code, respond from the sequence then.
>>
>> Thanks.
>>
>> On Tue, Jan 30, 2018 at 9:28 PM, Sanjeewa Malalgoda 
>> wrote:
>>
>>> Yes send from custom sequence and then drop flow will work. Its better
>>> to maintain separate convert sequence.
>>>
>>> Thanks,
>>> sanjeewa.
>>>
>>> On Wed, Jan 31, 2018 at 8:21 AM, Harsha Kumara  wrote:
>>>
 Hi Lahiru,

 I think it's not possible to override it but you can follow [1] to do
 it in a separate way.

 [1] http://sanjeewamalalgoda.blogspot.com/2015/04/how-to-gen
 erate-custom-error-message.html

 Thanks,
 Harsha

 On Wed, Jan 31, 2018 at 2:08 AM, Lahiru Sandaruwan 
 wrote:

> Hi,
>
> I changed _auth_failure_handler_ to set HTTP code to 498. But it still
> responds with 401. My handler after change is as follows,
>
> http://ws.apache.org/ns
> /synapse">
> 
> 
> 
> 
>
> Anything wrong with my config?
>
> Thanks.
>
> --
> --
>
> Lahiru Sandaruwan
> Associate Technical Lead,
> WSO2 Inc., http://wso2.com
>
> lean.enterprise.middleware
>
> m: +1 901 530 2379 <(901)%20530-2379>
> e: lahi...@wso2.com b: https://medium.com/@lahirugmg
> in: http://lk.linkedin.com/pub/lahiru-sandaruwan/16/153/146
>
>


 --
 Harsha Kumara
 Software Engineer, WSO2 Inc.
 Mobile: +94775505618 <077%20550%205618>
 Blog:harshcreationz.blogspot.com

>>>
>>>
>>>
>>> --
>>>
>>> *Sanjeewa Malalgoda*
>>> WSO2 Inc.
>>> Mobile : +94713068779 <071%20306%208779>
>>>
>>> blog
>>> :http://sanjeewamalalgoda.blogspot.com/
>>> 
>>>
>>>
>>>
>>
>>
>> --
>> --
>>
>> Lahiru Sandaruwan
>> Associate Technical Lead,
>> WSO2 Inc., http://wso2.com
>>
>> lean.enterprise.middleware
>>
>> m: +1 901 530 2379 <(901)%20530-2379>
>> e: lahi...@wso2.com b: https://medium.com/@lahirugmg
>> in: http://lk.linkedin.com/pub/lahiru-sandaruwan/16/153/146
>>
>>
>> ___
>> Dev mailing list
>> Dev@wso2.org
>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>
>>
>
>
> --
> Malintha Amarasinghe
> *WSO2, Inc. - lean | enterprise | middleware*
> http://wso2.com/
>
> Mobile : +94 712383306 <+94%2071%20238%203306>
>
> ___
> Dev mailing list
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>


-- 
Thanks and Regards,

Isuru H.
+94 716 358 048* *
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [APIM][1.10] Setting HTTP_SC in Auth failure handler does not work

[Malintha Amarasinghe]

Hi All,

Shall we move our sequence execution logic [1] such a way that it is
followed by response setting logic in the code [2]? Currently, it is
preceded by [2] so whatever we set in the sequence is getting overridden by
the code [2]. That needs to happen in the other way round ideally. If we do
it, we can simply override the HTTP_SC only without affecting other things.
WDYT?

[1]
https://github.com/wso2/carbon-apimgt/blob/e5bda7afcf0fb9679cfcba96f56682692c0eb87a/components/apimgt/org.wso2.carbon.apimgt.gateway/src/main/java/org/wso2/carbon/apimgt/gateway/handlers/security/APIAuthenticationHandler.java#L200-L204
[2]
https://github.com/wso2/carbon-apimgt/blob/e5bda7afcf0fb9679cfcba96f56682692c0eb87a/components/apimgt/org.wso2.carbon.apimgt.gateway/src/main/java/org/wso2/carbon/apimgt/gateway/handlers/security/APIAuthenticationHandler.java#L219-L235

On Wed, Jan 31, 2018 at 9:25 AM, Lahiru Sandaruwan  wrote:

> I see. Will follow that and set the code, respond from the sequence then.
>
> Thanks.
>
> On Tue, Jan 30, 2018 at 9:28 PM, Sanjeewa Malalgoda 
> wrote:
>
>> Yes send from custom sequence and then drop flow will work. Its better to
>> maintain separate convert sequence.
>>
>> Thanks,
>> sanjeewa.
>>
>> On Wed, Jan 31, 2018 at 8:21 AM, Harsha Kumara  wrote:
>>
>>> Hi Lahiru,
>>>
>>> I think it's not possible to override it but you can follow [1] to do it
>>> in a separate way.
>>>
>>> [1] http://sanjeewamalalgoda.blogspot.com/2015/04/how-to-gen
>>> erate-custom-error-message.html
>>>
>>> Thanks,
>>> Harsha
>>>
>>> On Wed, Jan 31, 2018 at 2:08 AM, Lahiru Sandaruwan 
>>> wrote:
>>>
 Hi,

 I changed _auth_failure_handler_ to set HTTP code to 498. But it still
 responds with 401. My handler after change is as follows,

 http://ws.apache.org/ns
 /synapse">
 
 
 
 

 Anything wrong with my config?

 Thanks.

 --
 --

 Lahiru Sandaruwan
 Associate Technical Lead,
 WSO2 Inc., http://wso2.com

 lean.enterprise.middleware

 m: +1 901 530 2379 <(901)%20530-2379>
 e: lahi...@wso2.com b: https://medium.com/@lahirugmg
 in: http://lk.linkedin.com/pub/lahiru-sandaruwan/16/153/146


>>>
>>>
>>> --
>>> Harsha Kumara
>>> Software Engineer, WSO2 Inc.
>>> Mobile: +94775505618 <077%20550%205618>
>>> Blog:harshcreationz.blogspot.com
>>>
>>
>>
>>
>> --
>>
>> *Sanjeewa Malalgoda*
>> WSO2 Inc.
>> Mobile : +94713068779 <071%20306%208779>
>>
>> blog
>> :http://sanjeewamalalgoda.blogspot.com/
>> 
>>
>>
>>
>
>
> --
> --
>
> Lahiru Sandaruwan
> Associate Technical Lead,
> WSO2 Inc., http://wso2.com
>
> lean.enterprise.middleware
>
> m: +1 901 530 2379 <(901)%20530-2379>
> e: lahi...@wso2.com b: https://medium.com/@lahirugmg
> in: http://lk.linkedin.com/pub/lahiru-sandaruwan/16/153/146
>
>
> ___
> Dev mailing list
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>


-- 
Malintha Amarasinghe
*WSO2, Inc. - lean | enterprise | middleware*
http://wso2.com/

Mobile : +94 712383306 <+94%2071%20238%203306>
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [DAS][HA] Reason for using a receiver queue in HA mode

[Sriskandarajah Suhothayan]

On Wed, Jan 31, 2018 at 4:56 PM Nirmal Fernando  wrote:

> Suho,
>
> Thanks for the reply. What I am thinking is why we need a receiver queue,
> if we made DAS1->DAS2 async?
>
How will this fix the issue?

>
>
> On Wednesday, January 31, 2018, Sriskandarajah Suhothayan 
> wrote:
>
>> AFAIR the event queue is used for buffering the events when states are
>> being synced, else there will be back pressure on the clients.
>> I think the rationale for using the same thread with synchronous call and
>> performing operations in both DAS1 and DAS2 ( in the order DAS1 -> DAS2 ->
>> DAS2-Siddhi -> DAS1-Siddhi) is to make sure both nodes have processed the
>> same events at the same time.
>>
>> I think event processing can be made asynchronous, such that the DAS1's
>> threads send the event to DAS2 and then returns (DAS1 -> DAS2 -> DAS1), and
>> a separate thread pool can handle sending events into DAS2-Siddhi.
>> One possible option is depicted in the image attached.
>>
>> WDYT?
>>
>> On Wed, Jan 31, 2018 at 1:15 PM, Nirmal Fernando  wrote:
>>
>>> Thanks, Grainier. Please see my comments inline.
>>>
>>> On Wed, Jan 31, 2018 at 1:07 PM, Grainier Perera 
>>> wrote:
>>>
 InputEventDispatcher will send the event to the callback immediately
 while QueueInputEventDispatcher will queue events first and there will be
 an internal worker (QueueInputEventDispatcherWorker) which send the events
 to the callback.

>>> The reason to accumulate events in a queue in HA is to be used for event
 syncing. If the event duplicated in the cluster is set to false, then this
 queue will be used for the event sync among other nodes in the HA
 deployment.

>>>
>>> Actually it's the same QueueInputEventDispatcherWorker which will do
>>> the event sync too, AFAIU. But why a queue? Is it because event sync is a
>>> synchronous operation (DAS1 -> DAS2 -> DAS2-Siddhi -> DAS1)? If so, then my
>>> next question is, why does the event sync has to be synchronous?
>>>
>>>
 Regards,
 Grainier

 On Wed, Jan 31, 2018 at 6:31 AM, Nirmal Fernando 
 wrote:

> Hi All,
>
> Can any of you remember the reason for using a receiver queue in HA
> mode?
>
> if (mode == Mode.HA) {
> HAConfiguration haConfiguration = 
> EventReceiverServiceValueHolder.getEventManagementService()
> .getManagementModeInfo().getHaConfiguration();
> Lock readLock = 
> EventReceiverServiceValueHolder.getCarbonEventReceiverManagementService().getReadLock();
> inputEventDispatcher = new QueueInputEventDispatcher(tenantId,
> EventManagementUtil.constructEventSyncId(tenantId,
> eventReceiverConfiguration.getEventReceiverName(), 
> Manager.ManagerType.Receiver),
> readLock, exportedStreamDefinition, 
> haConfiguration.getEventSyncReceiverMaxQueueSizeInMb(),
> haConfiguration.getEventSyncReceiverQueueSize());
> inputEventDispatcher.setSendToOther(!isEventDuplicatedInCluster);
> EventReceiverServiceValueHolder.getEventManagementService()
> .registerEventSync((EventSync) inputEventDispatcher, 
> Manager.ManagerType.Receiver);
> } else {
> inputEventDispatcher = new InputEventDispatcher();
> }
>
>
> --
>
> Thanks & regards,
> Nirmal
>
> Technical Lead, WSO2 Inc.
> Mobile: +94715779733 <+94%2071%20577%209733>
> Blog: http://nirmalfdo.blogspot.com/
>
>
>


 --
 Grainier Perera
 Senior Software Engineer
 Mobile : +94716122384 <+94%2071%20612%202384>
 WSO2 Inc. | http://wso2.com
 lean.enterprise.middleware

>>>
>>>
>>>
>>> --
>>>
>>> Thanks & regards,
>>> Nirmal
>>>
>>> Technical Lead, WSO2 Inc.
>>> Mobile: +94715779733 <071%20577%209733>
>>> Blog: http://nirmalfdo.blogspot.com/
>>>
>>>
>>>
>>
>>
>> --
>>
>> *S. Suhothayan*
>> Director
>> *WSO2 Inc. *
>> http://wso2.com  
>>
>>
>> *cell: (+94) 779 756 757 | blog: http://suhothayan.blogspot.com/
>> twitter: http://twitter.com/suhothayan
>>  | linked-in:
>> http://lk.linkedin.com/in/suhothayan *
>>
>
>
> --
>
> Thanks & regards,
> Nirmal
>
> Technical Lead, WSO2 Inc.
> Mobile: +94715779733
> Blog: http://nirmalfdo.blogspot.com/
>
>
>
> --

*S. Suhothayan*
Director
*WSO2 Inc. *
http://wso2.com  


*cell: (+94) 779 756 757 | blog: http://suhothayan.blogspot.com/
twitter: http://twitter.com/suhothayan
 | linked-in:
http://lk.linkedin.com/in/suhothayan *
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [DAS][HA] Reason for using a receiver queue in HA mode

[Nirmal Fernando]

Suho,

Thanks for the reply. What I am thinking is why we need a receiver queue,
if we made DAS1->DAS2 async?

On Wednesday, January 31, 2018, Sriskandarajah Suhothayan 
wrote:

> AFAIR the event queue is used for buffering the events when states are
> being synced, else there will be back pressure on the clients.
> I think the rationale for using the same thread with synchronous call and
> performing operations in both DAS1 and DAS2 ( in the order DAS1 -> DAS2 ->
> DAS2-Siddhi -> DAS1-Siddhi) is to make sure both nodes have processed the
> same events at the same time.
>
> I think event processing can be made asynchronous, such that the DAS1's
> threads send the event to DAS2 and then returns (DAS1 -> DAS2 -> DAS1), and
> a separate thread pool can handle sending events into DAS2-Siddhi.
> One possible option is depicted in the image attached.
>
> WDYT?
>
> On Wed, Jan 31, 2018 at 1:15 PM, Nirmal Fernando  wrote:
>
>> Thanks, Grainier. Please see my comments inline.
>>
>> On Wed, Jan 31, 2018 at 1:07 PM, Grainier Perera 
>> wrote:
>>
>>> InputEventDispatcher will send the event to the callback immediately
>>> while QueueInputEventDispatcher will queue events first and there will be
>>> an internal worker (QueueInputEventDispatcherWorker) which send the
>>> events to the callback.
>>>
>> The reason to accumulate events in a queue in HA is to be used for event
>>> syncing. If the event duplicated in the cluster is set to false, then this
>>> queue will be used for the event sync among other nodes in the HA
>>> deployment.
>>>
>>
>> Actually it's the same QueueInputEventDispatcherWorker which will do the
>> event sync too, AFAIU. But why a queue? Is it because event sync is a
>> synchronous operation (DAS1 -> DAS2 -> DAS2-Siddhi -> DAS1)? If so, then my
>> next question is, why does the event sync has to be synchronous?
>>
>>
>>> Regards,
>>> Grainier
>>>
>>> On Wed, Jan 31, 2018 at 6:31 AM, Nirmal Fernando 
>>> wrote:
>>>
 Hi All,

 Can any of you remember the reason for using a receiver queue in HA
 mode?

 if (mode == Mode.HA) {
 HAConfiguration haConfiguration = 
 EventReceiverServiceValueHolder.getEventManagementService()
 .getManagementModeInfo().getHaConfiguration();
 Lock readLock = 
 EventReceiverServiceValueHolder.getCarbonEventReceiverManagementService().getReadLock();
 inputEventDispatcher = new QueueInputEventDispatcher(tenantId,
 EventManagementUtil.constructEventSyncId(tenantId,
 eventReceiverConfiguration.getEventReceiverName(), 
 Manager.ManagerType.Receiver),
 readLock, exportedStreamDefinition, 
 haConfiguration.getEventSyncReceiverMaxQueueSizeInMb(),
 haConfiguration.getEventSyncReceiverQueueSize());
 inputEventDispatcher.setSendToOther(!isEventDuplicatedInCluster);
 EventReceiverServiceValueHolder.getEventManagementService()
 .registerEventSync((EventSync) inputEventDispatcher, 
 Manager.ManagerType.Receiver);
 } else {
 inputEventDispatcher = new InputEventDispatcher();
 }


 --

 Thanks & regards,
 Nirmal

 Technical Lead, WSO2 Inc.
 Mobile: +94715779733 <+94%2071%20577%209733>
 Blog: http://nirmalfdo.blogspot.com/



>>>
>>>
>>> --
>>> Grainier Perera
>>> Senior Software Engineer
>>> Mobile : +94716122384 <+94%2071%20612%202384>
>>> WSO2 Inc. | http://wso2.com
>>> lean.enterprise.middleware
>>>
>>
>>
>>
>> --
>>
>> Thanks & regards,
>> Nirmal
>>
>> Technical Lead, WSO2 Inc.
>> Mobile: +94715779733 <071%20577%209733>
>> Blog: http://nirmalfdo.blogspot.com/
>>
>>
>>
>
>
> --
>
> *S. Suhothayan*
> Director
> *WSO2 Inc. *
> http://wso2.com  
>
>
> *cell: (+94) 779 756 757 | blog: http://suhothayan.blogspot.com/
> twitter: http://twitter.com/suhothayan
>  | linked-in:
> http://lk.linkedin.com/in/suhothayan *
>


-- 

Thanks & regards,
Nirmal

Technical Lead, WSO2 Inc.
Mobile: +94715779733
Blog: http://nirmalfdo.blogspot.com/
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [DAS][HA] Reason for using a receiver queue in HA mode

[Sriskandarajah Suhothayan]

AFAIR the event queue is used for buffering the events when states are
being synced, else there will be back pressure on the clients.
I think the rationale for using the same thread with synchronous call and
performing operations in both DAS1 and DAS2 ( in the order DAS1 -> DAS2 ->
DAS2-Siddhi -> DAS1-Siddhi) is to make sure both nodes have processed the
same events at the same time.

I think event processing can be made asynchronous, such that the DAS1's
threads send the event to DAS2 and then returns (DAS1 -> DAS2 -> DAS1), and
a separate thread pool can handle sending events into DAS2-Siddhi.
One possible option is depicted in the image attached.

WDYT?

On Wed, Jan 31, 2018 at 1:15 PM, Nirmal Fernando  wrote:

> Thanks, Grainier. Please see my comments inline.
>
> On Wed, Jan 31, 2018 at 1:07 PM, Grainier Perera 
> wrote:
>
>> InputEventDispatcher will send the event to the callback immediately
>> while QueueInputEventDispatcher will queue events first and there will be
>> an internal worker (QueueInputEventDispatcherWorker) which send the
>> events to the callback.
>>
> The reason to accumulate events in a queue in HA is to be used for event
>> syncing. If the event duplicated in the cluster is set to false, then this
>> queue will be used for the event sync among other nodes in the HA
>> deployment.
>>
>
> Actually it's the same QueueInputEventDispatcherWorker which will do the
> event sync too, AFAIU. But why a queue? Is it because event sync is a
> synchronous operation (DAS1 -> DAS2 -> DAS2-Siddhi -> DAS1)? If so, then my
> next question is, why does the event sync has to be synchronous?
>
>
>> Regards,
>> Grainier
>>
>> On Wed, Jan 31, 2018 at 6:31 AM, Nirmal Fernando  wrote:
>>
>>> Hi All,
>>>
>>> Can any of you remember the reason for using a receiver queue in HA mode?
>>>
>>> if (mode == Mode.HA) {
>>> HAConfiguration haConfiguration = 
>>> EventReceiverServiceValueHolder.getEventManagementService()
>>> .getManagementModeInfo().getHaConfiguration();
>>> Lock readLock = 
>>> EventReceiverServiceValueHolder.getCarbonEventReceiverManagementService().getReadLock();
>>> inputEventDispatcher = new QueueInputEventDispatcher(tenantId,
>>> EventManagementUtil.constructEventSyncId(tenantId,
>>> eventReceiverConfiguration.getEventReceiverName(), 
>>> Manager.ManagerType.Receiver),
>>> readLock, exportedStreamDefinition, 
>>> haConfiguration.getEventSyncReceiverMaxQueueSizeInMb(),
>>> haConfiguration.getEventSyncReceiverQueueSize());
>>> inputEventDispatcher.setSendToOther(!isEventDuplicatedInCluster);
>>> EventReceiverServiceValueHolder.getEventManagementService()
>>> .registerEventSync((EventSync) inputEventDispatcher, 
>>> Manager.ManagerType.Receiver);
>>> } else {
>>> inputEventDispatcher = new InputEventDispatcher();
>>> }
>>>
>>>
>>> --
>>>
>>> Thanks & regards,
>>> Nirmal
>>>
>>> Technical Lead, WSO2 Inc.
>>> Mobile: +94715779733 <+94%2071%20577%209733>
>>> Blog: http://nirmalfdo.blogspot.com/
>>>
>>>
>>>
>>
>>
>> --
>> Grainier Perera
>> Senior Software Engineer
>> Mobile : +94716122384 <+94%2071%20612%202384>
>> WSO2 Inc. | http://wso2.com
>> lean.enterprise.middleware
>>
>
>
>
> --
>
> Thanks & regards,
> Nirmal
>
> Technical Lead, WSO2 Inc.
> Mobile: +94715779733 <071%20577%209733>
> Blog: http://nirmalfdo.blogspot.com/
>
>
>


-- 

*S. Suhothayan*
Director
*WSO2 Inc. *
http://wso2.com  


*cell: (+94) 779 756 757 | blog: http://suhothayan.blogspot.com/
twitter: http://twitter.com/suhothayan
 | linked-in:
http://lk.linkedin.com/in/suhothayan *
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [DAS][HA] Reason for using a receiver queue in HA mode

[Grainier Perera]

InputEventDispatcher will send the event to the callback immediately while
QueueInputEventDispatcher will queue events first and there will be an
internal worker (QueueInputEventDispatcherWorker) which send the events to
the callback. The reason to accumulate events in a queue in HA is to be
used for event syncing. If the event duplicated in the cluster is set to
false, then this queue will be used for the event sync among other nodes in
the HA deployment.

Regards,
Grainier

On Wed, Jan 31, 2018 at 6:31 AM, Nirmal Fernando  wrote:

> Hi All,
>
> Can any of you remember the reason for using a receiver queue in HA mode?
>
> if (mode == Mode.HA) {
> HAConfiguration haConfiguration = 
> EventReceiverServiceValueHolder.getEventManagementService()
> .getManagementModeInfo().getHaConfiguration();
> Lock readLock = 
> EventReceiverServiceValueHolder.getCarbonEventReceiverManagementService().getReadLock();
> inputEventDispatcher = new QueueInputEventDispatcher(tenantId,
> EventManagementUtil.constructEventSyncId(tenantId,
> eventReceiverConfiguration.getEventReceiverName(), 
> Manager.ManagerType.Receiver),
> readLock, exportedStreamDefinition, 
> haConfiguration.getEventSyncReceiverMaxQueueSizeInMb(),
> haConfiguration.getEventSyncReceiverQueueSize());
> inputEventDispatcher.setSendToOther(!isEventDuplicatedInCluster);
> EventReceiverServiceValueHolder.getEventManagementService()
> .registerEventSync((EventSync) inputEventDispatcher, 
> Manager.ManagerType.Receiver);
> } else {
> inputEventDispatcher = new InputEventDispatcher();
> }
>
>
> --
>
> Thanks & regards,
> Nirmal
>
> Technical Lead, WSO2 Inc.
> Mobile: +94715779733 <+94%2071%20577%209733>
> Blog: http://nirmalfdo.blogspot.com/
>
>
>


-- 
Grainier Perera
Senior Software Engineer
Mobile : +94716122384
WSO2 Inc. | http://wso2.com
lean.enterprise.middleware
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev