[ https://forge.continuent.org/jira/browse/SEQUOIA-129?page=all ]
     
Olivier Fambon closed SEQUOIA-129:
----------------------------------


Both directly related issues closed (This is fixed by SEQUOIA-101. Related to 
SEQUOIA-102.)
Closing.

> "transfer" Command Does Not Complete in Mutli-homed Environment
> ---------------------------------------------------------------
>
>          Key: SEQUOIA-129
>          URL: https://forge.continuent.org/jira/browse/SEQUOIA-129
>      Project: Sequoia
>         Type: Bug
>   Components: Backup System
>     Versions: Version 2.2
>  Environment: 2 Redhat EL machines, each with 2 network interfaces on 2 
> separate networks.  PostgreSQL 7.4.8.  Sequoia from CVS on Friday, Sept 30 at 
> approx 13:30 PDT
>     Reporter: Dylan Hansen
>     Assignee: Olivier Fambon
>      Fix For: Version 2.2

>
>
> This is fixed by SEQUOIA-101.
> Related to SEQUOIA-102.
> ---- original description ----
> I'm trying to transfer a dump from a live controller to a recently revived 
> controller.  Sequoia is running on 2 separate Linux boxes, each with two 
> network interfaces.  Each corresponding interface on each node is on the same 
> network (ie eth0 on Node1 is on the same network as eth0 on node 2, etc.).
> When attempting to transfer the dump from Controller A to Controller B, the 
> command actually completes.  However, the dump is not transferred.  Here are 
> the log outputs:
> Controller A (source of dump)
> 2005-10-03 10:32:58,765 DEBUG controller.jmx.AuthenticatingMBeanServer no 
> authentication required
> 2005-10-03 10:32:58,766 DEBUG controller.jmx.AuthenticatingMBeanServer 
> Authentication with principal was successfull
> 2005-10-03 10:32:58,767 DEBUG sequoia.controller.recoverylog Retrieving dump 
> h2st-backup01 information
> 2005-10-03 10:32:58,769 INFO  controller.backup.BackupManager Using 
> InetAddress.getLocalHost() as dump-server address: 
> H2STDatabasenode01/127.0.0.1
> 2005-10-03 10:32:58,770 INFO  controller.backup.BackupManager Dump server 
> started @ 0.0.0.0/0.0.0.0:33046
> Controller B (destination of dump)
> 2005-10-03 10:32:58,927 DEBUG controller.virtualdatabase.h2st 
> handleMessageSingleThreaded (class 
> org.continuent.sequoia.controller.virtualdatabase.protocol.InitiateDumpCopy): 
> [EMAIL PROTECTED]
> 2005-10-03 10:32:58,928 DEBUG controller.virtualdatabase.h2st 
> handleMessageMultiThreaded (class 
> org.continuent.sequoia.controller.virtualdatabase.protocol.InitiateDumpCopy): 
> [EMAIL PROTECTED]
> 2005-10-03 10:32:58,928 INFO  controller.backup.BackupManager Dump fetch 
> starting from H2STDatabasenode01/127.0.0.1:33048
> What seems to be strange is that Controller B is trying to fetch it's dump 
> from H2STDatabasenode01/127.0.0.1:33048.  H2STDatabasenode01 is correct, but 
> 127.0.0.1 is wrong.  It should be pointing to the remote Controller A IP 
> address.
> We have our controllers specified to listen on eth0 on both nodes (our 
> internal production network.  Here is a snippet of the controller.xml config 
> file:
> <SEQUOIA-CONTROLLER>
>   <Controller port="25322" ipAddress="192.168._.10">
>     <Report hideSensitiveData="true" generateOnShutdown="true" 
> generateOnFatal="true" enableFileLogging="true" />
>     <JmxSettings>
>       <RmiJmxAdaptor/>
>     </JmxSettings>
> This issue does not come up when testing on my local machine in Eclipse, 
> which makes me think that it is a networking issue and the fact that the 2 
> nodes are multihomed.  I have not been able to debug this as I am not testing 
> it locally.  I would like to hook up my debugger remotely to test the code 
> running on the other machines.
> I did some peeking around the code and I noticed the following comment in 
> BackupManager.java:
>     // FIXME: sending the address we are listening to is dirty because:
>     // - it prevents us from listening to any interface/address
>     // - we may listen on some wrong interface/address!
>     // The Right Way to do this would be to bootstrap this socket from the
>     // existing inter-controller communication/addresses, this way we would be
>     // 100% sure to succeed.
> Does this prevent us from being able to transfer a dump on a multi-homed 
> machine?
>  

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   https://forge.continuent.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


_______________________________________________
Sequoia mailing list
[email protected]
https://forge.continuent.org/mailman/listinfo/sequoia

Reply via email to