gearpump-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vincent Wang <fvunic...@gmail.com>
Subject Re: [jira] [Commented] (GEARPUMP-363) Why not synchronize app jar files between active master and standby masters
Date Tue, 28 Nov 2017 07:18:24 GMT
Hi Xuetong,

I was on vacation last week and I'm very sorry for the late response.
I think it would be great if we can make jar files highly available in
default mode. But manually distributing jars across masters may not be a
good idea.
If we want to do so, each master should have the knowledge of whether there
are other standby masters, where they are and whether they are active. I
think this is kind of anti-design and not intuitive.

Thanks,
Huafeng

Xuetong Zhu (JIRA) <jira@apache.org>于2017年11月16日周四 下午4:36写道:

>
>     [
> https://issues.apache.org/jira/browse/GEARPUMP-363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16254950#comment-16254950
> ]
>
> Xuetong Zhu commented on GEARPUMP-363:
> --------------------------------------
>
> Yes, I mean we should make jar files highly available in the cluster mode.
> we could deploy gearpump in same directory of every machine,  then we
> could  upload application jars to same folders of every master machine,
> eventually make jar files highly available.
>
> > Why not synchronize app jar files between active master and standby
> masters
> >
> ---------------------------------------------------------------------------
> >
> >                 Key: GEARPUMP-363
> >                 URL: https://issues.apache.org/jira/browse/GEARPUMP-363
> >             Project: Apache Gearpump
> >          Issue Type: Wish
> >            Reporter: Xuetong Zhu
> >            Priority: Minor
> >
> > In addition to HDFS and NFS,  Could we add synchronization jar file
> method, which I think more convenience than the former.
>
>
>
> --
> This message was sent by Atlassian JIRA
> (v6.4.14#64029)
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message