[ 
https://issues.apache.org/jira/browse/FLUME-706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13083016#comment-13083016
 ] 

Jonathan Hsieh edited comment on FLUME-706 at 8/11/11 11:04 AM:
----------------------------------------------------------------

Note: this seemed flaky because it will only ever occur on a mapped logical 
node.  This doesn't affect the default node because this is always present and 
has a correct FlumeConfigData config and version.  This will probably not 
happen either if a node is mapped first and then config'ed after the node has 
been spawned.

      was (Author: jmhsieh):
    Note: this seemed flaky because it will only ever on a mapped logical node. 
 This doesn't affect the default node because this is always present and has a 
correct FlumeConfigData config and version.  This will probably not happen 
either if a node is mapped first and then config'ed after the node has been 
spawned.
  
> Flume nodes launch duplicate logical nodes
> ------------------------------------------
>
>                 Key: FLUME-706
>                 URL: https://issues.apache.org/jira/browse/FLUME-706
>             Project: Flume
>          Issue Type: Bug
>          Components: Master, Node
>    Affects Versions: v0.9.5
>            Reporter: E. Sammer
>            Assignee: E. Sammer
>            Priority: Critical
>             Fix For: v0.9.5
>
>         Attachments: 
> 0001-FLUME-706-Flume-nodes-launch-duplicate-logical-nodes.patch, FLUME-706.log
>
>
> When submitting a config command to the flume master, it seems as if the 
> downstream node attempts to load the config twice.
> In a test case, starting a single master and a single node, I submitted a 
> "config node rpcSource(12345) console". The node sees the config change on 
> the next heartbeat and updates its config and starts the thrift source on 
> port 12345. Immediately after, it logs "Taking another heartbeat" (DEBUG) and 
> attempts to create another logical node with the same config. This leads to 
> thrift errors in bind() and "Could not create ServerSocket on address ...". 
> Looking at the root cause in a debugger (thrift swallows the original 
> exception) I can see it's an "Address already in use" IOException.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Reply via email to