Please check out my comment in the below mail.
Willem Jiang Twitter: willemjiang Weibo: 姜宁willem On Sat, Aug 4, 2018 at 12:46 AM, 黎 先生 <[email protected]> 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. > > ------------------------------ > *发件人:* 黎 先生 <[email protected]> > *发送时间:* 2018年8月3日 9:43 > *收件人:* [email protected] > *主题:* 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. >
