Hi Andy, One problem with prefixing the master name to the rangeserver ids is dealing with change of master. Another issue is with the case where people want to run multiple Hypertable clusters on the same set of machines, so there could be 3 masters running on different ports on the same machine.
-Sanjit On Mon, Dec 20, 2010 at 12:58 PM, Andy <[email protected]> wrote: > Hi Doug > > Well I just like to ensure that such a use case is covered. A client > (single process) should be able to deal with more than one hypertable > instance (completely independent instances); ideally without any > special configuration requirements on the server side, just knowing > the hosts/ports. For example a client collects and stores raw > measurements very frequent from many sensors into one instance, where > a second client queries the row measurements, does some analysis/post- > processing and pushes the result to second hypertable instance. I have > added a new Hypertable::Client constructor Client(const String > &install_dir, ConnectionManagerPtr conn_mgr, Hyperspace::SessionPtr& > session, PropertiesPtr &props, uint32_t default_timeout_ms=0); Each > hypertable instance will get it's own hs session, connection manager > and property set, that's the way I configure the clients. In addition > I have changed the cleanup procedure in order to gracefully close > connections and to be able to re-connect later. > > -Andy > > On Dec 20, 6:41 pm, Doug Judd <[email protected]> wrote: > > Hi Andy, > > > > That would be better. Some of the configuration would have to be > different > > for each hypertable instance, such as Hypertable.Master.Host > > and Hyperspace.Replica.Host. Can you give us some background of the > > multi-instance situation that you're trying to accomodate? In > particular, > > how do you specify different masters and how common do you expect this > > situation to be? > > > > - Doug > > > > On Mon, Dec 20, 2010 at 7:08 AM, Andy <[email protected]> wrote: > > > Hi Doug > > > > > A config property wouldn't solve the problem, because using more than > > > one hypertable instance with default configuration the proxy names > > > still conflict. Nevertheless a config property would simplify the > > > configuration in such situations. It would be sufficient if the master > > > hostname is just part of the prefix something like this "rs-" + > > > <master hostname> + "-" + <#>; do you think this is still confusing? > > > It indicates a range server ("rs") and the master where it belongs to. > > > > > -Andy > > > > > On Dec 17, 5:43 pm, Doug Judd <[email protected]> wrote: > > > > Hi Andy, > > > > > > What if we made it a config property (e.g. > > > > Hypertable.Master.ProxyName.Prefix) that defaults to "rs" ? I'm a > little > > > > concerned about using the Master hostname because the proxy name is > > > exposed > > > > in a number of places and it seems like it might be confusing for > someone > > > > trying to familiarize themselves with the system. Would the config > > > property > > > > approach work for you? > > > > > > - Doug > > > > > > On Fri, Dec 17, 2010 at 3:51 AM, Andy <[email protected]> > wrote: > > > > > There is an issue with Master::register_server; this > > > > > methods assigns a location if not already assigned, the assigned > > > > > location always starts with "rs" (rs1, rs2, ...). This assignment > > > > > makes troubles > > > > > if a client (one process) connects (not via thrift) to more than > one > > > > > hypertable > > > > > instance for which the proxy names for the range servers have not > been > > > > > explicitly > > > > > defined (via hypertable.cfg). As a result the client proxy map gets > > > > > mixed up. > > > > > > > As a workaround I have changed the location assignment for the > Windows > > > > > version to: > > > > > location = (!System::net_info().host_name.empty() ? > > > > > System::net_info().host_name : String("rs")) + m_next_server_id++; > > > > > it uses the master host name as prefix. > > > > > > > Does this have any negative side effects? > > > > > Is this a change which could find the way into the main branch? > > > > > > > -Andy > > > > > > > -- > > > > > You received this message because you are subscribed to the Google > > > Groups > > > > > "Hypertable Development" group. > > > > > To post to this group, send email to > [email protected]. > > > > > To unsubscribe from this group, send email to > > > > > [email protected]<hypertable-dev%[email protected]> > <hypertable-dev%[email protected]<hypertable-dev%[email protected]> > > > > > <hypertable-dev%[email protected]<hypertable-dev%[email protected]> > <hypertable-dev%[email protected]<hypertable-dev%[email protected]> > > > > > > > > > . > > > > > For more options, visit this group at > > > > >http://groups.google.com/group/hypertable-dev?hl=en. > > > > > -- > > > You received this message because you are subscribed to the Google > Groups > > > "Hypertable Development" group. > > > To post to this group, send email to [email protected]. > > > To unsubscribe from this group, send email to > > > [email protected]<hypertable-dev%[email protected]> > <hypertable-dev%[email protected]<hypertable-dev%[email protected]> > > > > > . > > > For more options, visit this group at > > >http://groups.google.com/group/hypertable-dev?hl=en. > > -- > You received this message because you are subscribed to the Google Groups > "Hypertable Development" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]<hypertable-dev%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/hypertable-dev?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Hypertable Development" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/hypertable-dev?hl=en.
