You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@flink.apache.org by tillrohrmann <gi...@git.apache.org> on 2016/08/11 16:36:55 UTC

[GitHub] flink pull request #2358: [FLINK-4382] Buffer rpc calls until the RpcEndpoin...

GitHub user tillrohrmann opened a pull request:

    https://github.com/apache/flink/pull/2358

    [FLINK-4382] Buffer rpc calls until the RpcEndpoint has been started

    This PR allows the AkkaRpcActor to stash messages until the corresponding RcpEndpoint
    has been started. When receiving a Processing.START message, the AkkaRpcActor
    unstashes all messages and starts processing rpcs. When receiving a Processing.STOP
    message, it will stop processing messages and stash incoming messages again.
    
    This PR is based on #2357.
    
    R @StephanEwen 


You can merge this pull request into a Git repository by running:

    $ git pull https://github.com/tillrohrmann/flink messageStashing

Alternatively you can review and apply these changes as the patch at:

    https://github.com/apache/flink/pull/2358.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

    This closes #2358
    
----
commit 13f6f392943e32b14bf0d08c7ded2d88496911ab
Author: Till Rohrmann <tr...@apache.org>
Date:   2016-08-10T16:42:26Z

    [FLINK-4362] [rpc] Auto generate rpc gateways via Java proxies
    
    This PR introduces a generic AkkaRpcActor which receives rpc calls as a
    RpcInvocation message. The RpcInvocation message is generated by the
    AkkaInvocationHandler which gets them from automatically generated Java Proxies.
    
    Add documentation for proxy based akka rpc service

commit 32dbb077e49c8d6180afaaf844238fd6a3178395
Author: Till Rohrmann <tr...@apache.org>
Date:   2016-08-11T15:27:18Z

    Log unknown message type in AkkaRpcActor but do not fail actor

commit 2c8062fb5ad567932bb63a9c005587773e0f0ab9
Author: Till Rohrmann <tr...@apache.org>
Date:   2016-08-11T16:13:25Z

    [FLINK-4382] [rpc] Buffer rpc calls until the RpcEndpoint has been started
    
    This PR allows the AkkaRpcActor to stash messages until the corresponding RcpEndpoint
    has been started. When receiving a Processing.START message, the AkkaRpcActor
    unstashes all messages and starts processing rpcs. When receiving a Processing.STOP
    message, it will stop processing messages and stash incoming messages again.

commit 3477f1d819d4a30d1fe73d0689117acfc63c8534
Author: Till Rohrmann <tr...@apache.org>
Date:   2016-08-11T16:35:03Z

    Add test case for message stashing

----


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] flink issue #2358: [FLINK-4382] Buffer rpc calls until the RpcEndpoint has b...

Posted by tillrohrmann <gi...@git.apache.org>.
Github user tillrohrmann commented on the issue:

    https://github.com/apache/flink/pull/2358
  
    Dropping is also a solution. I think this will also happen implicitly if the mailbox grows too big.
    
    Stashing has the advantage that we try (on a best effort basis) to answer early requests. That way the rpc calls won't have to time out on the sending side before being retried or alternative measures are taken. Of course this can happen if the start up takes too long on the server side. Thus, I would imagine that this approach is a little bit more responsive wrt early rpcs.
    
    So I don't think that stashing actually hurts.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] flink issue #2358: [FLINK-4382] Buffer rpc calls until the RpcEndpoint has b...

Posted by StephanEwen <gi...@git.apache.org>.
Github user StephanEwen commented on the issue:

    https://github.com/apache/flink/pull/2358
  
    Not completely sure about the message stashing. Why not drop the messages? That would be safer (less to clean up, no overflow).
    
    Is this mainly to not loose the messages from the "self gateway"?  Because for all remote messages, it should be not necessary, it should simply appear as if the actor/endpoint started a few milliseconds later.
    
    It may in the common case not be much of an issue, as the period during which messages are stashed is small, but I think it is simply not necessary.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] flink pull request #2358: [FLINK-4382] Buffer rpc calls until the RpcEndpoin...

Posted by tillrohrmann <gi...@git.apache.org>.
Github user tillrohrmann closed the pull request at:

    https://github.com/apache/flink/pull/2358


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] flink issue #2358: [FLINK-4382] Buffer rpc calls until the RpcEndpoint has b...

Posted by tillrohrmann <gi...@git.apache.org>.
Github user tillrohrmann commented on the issue:

    https://github.com/apache/flink/pull/2358
  
    The stashing is a feature which comes for free with Akka. Of course the sending side should not rely on this behaviour when implementing its failure treatment. But in cases where we have a race condition between the start-up of the `RpcEndpoint` and a `RpcGateway` it should result into a slightly more forgiving receiver behaviour.
    
    I will rebase the PR and if Travis gives green light I would like to merge this PR to the flip-6 feature branch if nobody objects.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---