On Tue, Dec 17, 2013 at 10:39 AM, Imesh Gunaratne <[email protected]> wrote:
> I just noticed a potential issue in fault message generation process: > > It looks like the Cartridge Agent is sending ports_not_open messages to > CEP if the application ports are not open. I think this should happen other > way around. Otherwise if cartridge agent goes down the system will think > that the member is still active and another instance may not be spawned. > WDYT? > > If the agent goes down, CEP will detect it and it will send member fault event after waiting few cycles. I think this is already there... Thanks > > > On Tue, Dec 17, 2013 at 10:21 AM, Imesh Gunaratne <[email protected]>wrote: > >> Hi, >> >> I just wanted to document the inputs and outputs of the Complex Event >> Processor. Once this is finalized we could add this information to the Wiki. >> >> >> *Input Stream Payload Definitions* >> Following payload definitions describe the messages sent to CEP by load >> balancers and cartridge agents: >> >> *1. In-Flight Request Count:* >> >> <payloadData> >> <property name="cluster_id" type="String"/> >> <property name="network_partition_id" type="String"/> >> <property name="in_flight_request_count" type="int"/> >> </payloadData> >> >> These messages are sent by load balancers to the CEP. >> >> *2. Cartridge Agent Health Stats:* >> >> <payloadData> >> <property name="cluster_id" type="String" /> >> <property name="network_partition_id" type="String"/> >> <property name="member_id" type="String" /> >> <property name="health_description" type="String"/> >> <property name="value" type="double"/> >> </payloadData> >> >> These messages are sent by cartridge agents to CEP. >> >> health_description: 'port_not_open', 'load_average', 'memory_consumption' >> Here I would like to suggest to rename "health_description" to something >> like "parameter". >> >> >> *Output Message Formats* >> Following are the formats of the messages sent by the CEP to the message >> broker: >> >> *1. Average In-Flight Requests:* >> >> {"average_in_flight_requests":{"cluster_id":"{{cluster_id}}","network_partition_id":"{{network_partition_id}}","value":"{{count}}"}} >> >> *2. Average Load Average:* >> >> {"average_load_average":{"cluster_id":"{{cluster_id}}","network_partition_id":"{{network_partition_id}}","value":"{{average_load_average}}"}} >> >> *3. Average Memory Consumption:* >> >> {"average_memory_consumption":{"cluster_id":"{{cluster_id}}","network_partition_id":"{{network_partition_id}}","value":"{{average_memory_consumption}}"}} >> >> *4. Fault Member:* >> >> {"member_fault":{"cluster_id":"{{cluster_id}}","network_partition_id":"{{network_partition_id}}","member_id":"{{member_id}}"}} >> >> *5. Gradient In-Flight Requests:* >> >> {"gradient_in_flight_requests":{"cluster_id":"{{cluster_id}}","network_partition_id":"{{network_partition_id}}","value":"{{count}}"}} >> >> *6. Gradient Load Average:* >> >> {"gradient_load_average":{"cluster_id":"{{cluster_id}}","network_partition_id":"{{network_partition_id}}","value":"{{gradient_load_average}}"}} >> >> *7. Gradient Memory Consumption:* >> >> {"gradient_memory_consumption":{"cluster_id":"{{cluster_id}}","network_partition_id":"{{network_partition_id}}","value":"{{gradient_memory_consumption}}"}} >> >> *8. Second Derivative In-Flight Requests:* >> >> {"second_derivative_in_flight_requests":{"cluster_id":"{{cluster_id}}","network_partition_id":"{{network_partition_id}}","value":"{{count}}"}} >> >> *9. Second Derivative Load Average:* >> >> {"second_derivative_load_average":{"cluster_id":"{{cluster_id}}","network_partition_id":"{{network_partition_id}}","value":"{{second_derivative_load_average}}"}} >> >> *10. Second Derivative Memory Consumption:* >> >> {"second_derivative_memory_consumption":{"cluster_id":"{{cluster_id}}","network_partition_id":"{{network_partition_id}}","value":"{{second_derivative_memory_consumption}}"}} >> >> I think we need to implement message processors and event listeners for >> these messages in messaging component and Autoscaler could use those to >> listen to required events. >> >> >> Many Thanks >> Imesh >> > > -- -- Lahiru Sandaruwan Software Engineer, Platform Technologies, WSO2 Inc., http://wso2.com lean.enterprise.middleware email: [email protected] cell: (+94) 773 325 954 blog: http://lahiruwrites.blogspot.com/ twitter: http://twitter.com/lahirus linked-in: http://lk.linkedin.com/pub/lahiru-sandaruwan/16/153/146
