[
https://issues.apache.org/jira/browse/FLUME-962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13237712#comment-13237712
]
[email protected] commented on FLUME-962:
-----------------------------------------------------
bq. On 2012-03-24 00:47:27, Mike Percy wrote:
bq. > Hi, thanks for doing this work.
bq. >
bq. > I have the following suggestions on the config format:
bq. >
bq. > The properties format is not extensible. Right now it looks like this:
bq. > hosts = host1 host2
bq. > host1 = hostname1:port1
bq. > host2 = hostname2:port2
bq. >
bq. > How about something like:
bq. > hosts = host1 host2
bq. > host.host1.endpoint = hostname1:port1
bq. > host.host2.endpoint = hostname2:port2
bq. >
bq. > In this way, we namespace the host specifications, and also have the
option of adding stuff like groups or priorities to them later if we want.
bq. >
bq. > Also, I have reservations about using the enum and reflection. My
thoughts regarding that are below.
I don't think we should make the properties more and more complex. I already
have reservations about taking in a properties file.
Namespacing should not be required if this is going to be kept simple. I know
the client might have other properties data(if it is being loaded from a file,
in that case namespacing it as just as "hosts" also can cause issues - we will
need to make it something like flume.hosts or even org.apache.flume.hosts at
which point we are overthinking it). Either way I would assume that the client
code would be using some data of his own and creating this properties object
and passing it to our code, rather than passing the config file entirely to our
code anyway - open source aside, passing your config, (not pertinent to that
component) is a bad idea.
I think this would also be extensible:
host1 = hostname1:port1
host2 = hostname2:port2
If we add groups we can do something like:
host1.group = <blah>
or
group1.hosts = host1, host2
same applies for priorities.
I think it is good to make the properties extensible, but making it more and
more complex, expecting to add more features in the future is not something I
want to do right now. I'd rather keep it simple, than make it complex when most
of the features like groups and priorities(which also can be added as shown
above) are not likely to be used very frequently.
For now, I think this should be kept simple.
- Hari
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/4380/#review6312
-----------------------------------------------------------
On 2012-03-22 03:43:56, Hari Shreedharan wrote:
bq.
bq. -----------------------------------------------------------
bq. This is an automatically generated e-mail. To reply, visit:
bq. https://reviews.apache.org/r/4380/
bq. -----------------------------------------------------------
bq.
bq. (Updated 2012-03-22 03:43:56)
bq.
bq.
bq. Review request for Flume.
bq.
bq.
bq. Summary
bq. -------
bq.
bq. Submitting an initial cut of FailoverRpcClient that uses the
NettyRpcClient under the hood. In this version, host selection is not exactly
the best, please make suggestions on how to improve it. As of now, the first
version will not have a backoff mechanism to not retry a host for a fixed time
etc(as discussed in the jira). I will add unit tests soon.
bq.
bq. Note that the actual "connect" call to a host is hidden from the
FailoverClient (by the Netty client or any other implementation, which we may
choose to use later). Since this connect call is hidden, failure to create a
client(the build function throwing an exception) is not being considered a
failure. Only a failure to append is considered a failure, and counted towards
the maximum number of tries. In other words, as far as the FailoverClient(for
that matter, any implementation of RpcClient interface) would consider an
append failure as failure, not a failure to a build() call - if we want to make
sure that a connect failure also is counted, we should move the connect call to
the append function and keep track of the connection state internally, and not
expect any code depending on an implementation of RpcClient(including other
clients which depend on pre-existing clients) to know that a build call also
creates a connection - this is exactly like a socket implementation, creating a
new socket does not initialize a connection, it is done explicitly.
bq.
bq.
bq. This addresses bug FLUME-962.
bq. https://issues.apache.org/jira/browse/FLUME-962
bq.
bq.
bq. Diffs
bq. -----
bq.
bq. flume-ng-sdk/src/main/java/org/apache/flume/api/ClientType.java
PRE-CREATION
bq. flume-ng-sdk/src/main/java/org/apache/flume/api/FailoverRpcClient.java
PRE-CREATION
bq. flume-ng-sdk/src/main/java/org/apache/flume/api/NettyAvroRpcClient.java
965b2ff
bq. flume-ng-sdk/src/main/java/org/apache/flume/api/RpcClientFactory.java
351b5b1
bq. flume-ng-sdk/src/test/java/org/apache/flume/api/RpcTestUtils.java
93bfee9
bq.
flume-ng-sdk/src/test/java/org/apache/flume/api/TestFailoverRpcClient.java
PRE-CREATION
bq.
flume-ng-sdk/src/test/java/org/apache/flume/api/TestNettyAvroRpcClient.java
a33e9c8
bq.
flume-ng-sdk/src/test/java/org/apache/flume/api/TestRpcClientFactory.java
0c94231
bq.
bq. Diff: https://reviews.apache.org/r/4380/diff
bq.
bq.
bq. Testing
bq. -------
bq.
bq. Unit tests added for the new functionality
bq.
bq.
bq. Thanks,
bq.
bq. Hari
bq.
bq.
> Failover capability for Client SDK
> ----------------------------------
>
> Key: FLUME-962
> URL: https://issues.apache.org/jira/browse/FLUME-962
> Project: Flume
> Issue Type: Sub-task
> Affects Versions: v1.0.0
> Reporter: Kathleen Ting
> Assignee: Hari Shreedharan
> Fix For: v1.2.0
>
> Attachments: FLUME-962-2.patch, FLUME-962-2.patch, FLUME-962-3.patch,
> FLUME-962-3.patch, FLUME-962-4.patch, FLUME-962-5.patch, FLUME-962-6.patch,
> FLUME-962-rebased-1.patch
>
>
> Need a client SDK for Flume that will allow clients to be able to failover
> from one source to another in case the first agent is not available. This
> will help in keeping client implementations developed outside of the project
> decoupled from internal details of HA implementation within Flume.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
