答复: LoadBalancedMessageSender && RetryableMessageSender

[黎 先生 <im...@outlook.com>]

I have questions about these two classes.

1、Can LoadBalancedMessageSender be refactored using Object Pool design pattern?

2、Consider such test case :

@Test
public void avoidFailingForeverUsingFastestStrategy() {
  MessageSender underlying1 = mock(MessageSender.class);
  when(underlying1.send(Mockito.any(TxEvent.class)))
      .thenReturn(new AlphaResponse(false))
      .thenThrow(RuntimeException.class);

  MessageSender underlying2 = mock(MessageSender.class);
  when(underlying2.send(Mockito.any(TxEvent.class)))
      .thenThrow(RuntimeException.class)
      .thenReturn(new AlphaResponse(false));


  LoadBalancedClusterMessageSender composite
      = new LoadBalancedClusterMessageSender(underlying1, underlying2);

  for(int i = 0; i < 10; i++) {
    composite.send(event, new FastestSender());
    System.out.println(i);
  }
}[cid:6620dd09-647d-45da-8b7c-9ac5fbc4fd03]

The program stay blocked here, since there were no more availableMessageSenders to take:
org.apache.servicecomb.saga.omega.connector.grpc.RetryableMessageSender#send

@Override
public AlphaResponse send(TxEvent event) {
  if (event.type() == SagaStartedEvent) {
    throw new OmegaException("Failed to process subsequent requests because no alpha server is available");
  }
  try {
    return availableMessageSenders.take().send(event); // stay blocked here
  } catch (InterruptedException e) {
    throw new OmegaException("Failed to send event " + event + " due to interruption", e);
  }

[cid:ab5a747a-98ac-4964-83cb-b6e75d65c6a7]

3、I don't quite understand what makes RetryableMessageSender "retryable" yet.

Can anybody tell me the motivation of designing these two classes? As well as the thinking of designing them.

________________________________
发件人: 黎 先生 <im...@outlook.com>
发送时间: 2018年8月3日 9:43
收件人: dev@servicecomb.apache.org
主题: LoadBalancedMessageSender && RetryableMessageSender

I have questions about these two classes.

1、Can LoadBalancedMessageSender be refactored using Object Pool design pattern?

2、Consider such test case :
[cid:8dc25bb0-c9e4-4780-ab9a-05ac45a2df96]

The program stay blocked here, since there were no more availableMessageSenders to take:
[cid:89060a94-5f39-4838-8ac0-71527df7726f]

3、I don't quite understand what makes RetryableMessageSender "retryable" yet.

Can anybody tell me the motivation of designing these two classes? As well as the thinking of designing them.

Re: 答复: LoadBalancedMessageSender && RetryableMessageSender

[Willem Jiang <wi...@gmail.com>]

Please check out my comment in the below mail.


Willem Jiang

Twitter: willemjiang
Weibo: 姜宁willem

On Sat, Aug 4, 2018 at 12:46 AM, 黎 先生 <im...@outlook.com> wrote:

> I have questions about these two classes.
>
> 1、Can LoadBalancedMessageSender be refactored using Object Pool design
> pattern?
>
Yeah, I think it's a good way to go.
Do you mind create a JIRA for it?


>
> 2、Consider such test case :
>
> @Test
> public void avoidFailingForeverUsingFastestStrategy() {
>   MessageSender underlying1 = mock(MessageSender.class);
>   when(underlying1.send(Mockito.any(TxEvent.class)))
>       .thenReturn(new AlphaResponse(false))
>       .thenThrow(RuntimeException.class);
>
>   MessageSender underlying2 = mock(MessageSender.class);
>   when(underlying2.send(Mockito.any(TxEvent.class)))
>       .thenThrow(RuntimeException.class)
>       .thenReturn(new AlphaResponse(false));
>
> If the AlphaResponse false, Omega could throw exception out.
But if the MessageSend throw the exception, I don't the return false
response could take effects.

>
>
>   LoadBalancedClusterMessageSender composite
>       = new LoadBalancedClusterMessageSender(underlying1, underlying2);
>
>   for(int i = 0; i < 10; i++) {
>     composite.send(event, new FastestSender());
>     System.out.println(i);
>   }
> }
>
>
> The program stay blocked here, since there were no more
> availableMessageSenders to take:
>
> *org.apache.servicecomb.saga.omega.connector.grpc.RetryableMessageSender#send*
>
> @Override
> public AlphaResponse send(TxEvent event) {
>   if (event.type() == SagaStartedEvent) {
>     throw new OmegaException("Failed to process subsequent requests because no alpha server is available");
>   }
>   try {
>     return availableMessageSenders.take().send(event);* // stay blocked here*
>   } catch (InterruptedException e) {
>     throw new OmegaException("Failed to send event " + event + " due to interruption", e);
>   }
>
> I think it just reproduce the issue,  now we should  break the blockqueue.
Just like put the message sender  which is throw the exception back to the
availableMessageSender blocking queue to let it retry.

>
> 3、I don't quite understand what makes RetryableMessageSender "retryable"
> yet.
>
May we can change it to leverage the object pool concept, if the message
sender have some connection related issue, we could deactivate it
(disconnect the alpha server)
then reactivate it (connect the alpha server).
It's just my two cents, any thoughts?


> Can anybody tell me the motivation of designing these two classes? As well
> as the thinking of designing them.
>
> ------------------------------
> *发件人:* 黎 先生 <im...@outlook.com>
> *发送时间:* 2018年8月3日 9:43
> *收件人:* dev@servicecomb.apache.org
> *主题:* LoadBalancedMessageSender && RetryableMessageSender
>
> I have questions about these two classes.
>
> 1、Can LoadBalancedMessageSender be refactored using Object Pool design
> pattern?
>
> 2、Consider such test case :
>
>
> The program stay blocked here, since there were no more
> availableMessageSenders to take:
>
>
> 3、I don't quite understand what makes RetryableMessageSender "retryable"
> yet.
>
> Can anybody tell me the motivation of designing these two classes? As well
> as the thinking of designing them.
>