-
Notifications
You must be signed in to change notification settings - Fork 113
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
EOS GRPC interface #1471
EOS GRPC interface #1471
Conversation
Why these things in the build fail, as they are not testing eosgrpc ? Maybe I have to wait some time and rebase ? |
Hi Ishank, thank for the review. I'll go through all these points in the next days |
This pull request introduces 2 alerts when merging 2f5a2e1 into 2011cb5 - view on LGTM.com new alerts:
|
This pull request introduces 2 alerts when merging 7724aea into 491455c - view on LGTM.com new alerts:
|
This pull request introduces 2 alerts when merging b6646ac into 1808b1c - view on LGTM.com new alerts:
|
This pull request introduces 2 alerts when merging df43e99 into 1808b1c - view on LGTM.com new alerts:
|
This pull request introduces 2 alerts when merging c0231a7 into 3b7e1f0 - view on LGTM.com new alerts:
|
This pull request introduces 2 alerts when merging 9423a36 into 03346dd - view on LGTM.com new alerts:
|
This pull request introduces 2 alerts when merging 91cb5c4 into 03346dd - view on LGTM.com new alerts:
|
This pull request introduces 2 alerts when merging f2e244e into 03346dd - view on LGTM.com new alerts:
|
This pull request introduces 1 alert when merging e838b6e into e8a00d9 - view on LGTM.com new alerts:
|
@ffurano can you rebase instead of merging? It's impossible to review |
Uhm... I only did rebase so far |
Actually I have the impression that you have put into master some previous stage of my work. I am reviewing all the new conflicts, yet now it's really a mess |
Rebase done |
This pull request introduces 1 alert when merging 328a1da into 1c0c24a - view on LGTM.com new alerts:
|
@ffurano I see a dependency to a private repo of yours:
Could you replace it with an upstream version? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Remove private repos
There's no such a thing by now... |
Uhm, nothing enforces that in the Client, and it seems pretty awkward to assume that there is just one instance. The creator can create as many clients it needs, as it goes through the config file: |
If you have a better way to implement a singleton in golang please let me know... so far I have done more or less like this: https://medium.com/@ishagirdhar/singleton-pattern-in-golang-9f60d7fdab23 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure this should be a singleton in the first place. We'll have one instance of the eos driver to connect to each of the EOS instances and I don't see any advantage of sharing the transport among them. I'd prefer it to be a part of the Client struct. We also need to increase the defaults and make transport configurable.
// From the basepath and the file path... build an url | ||
func (c *Client) buildFullURL(urlpath, uid, gid string) (string, error) { | ||
s := c.opt.BaseURL | ||
if len(urlpath) > 0 && urlpath[0] != '/' { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you do something like https://github.com/cs3org/reva/blob/master/pkg/ocm/share/manager/json/json.go#L321-L326?
// I feel safer putting here a check, to prohibit malicious users to | ||
// inject a false uid/gid into the url | ||
// Who knows, maybe it's redundant? Better more than nothing. | ||
p1 := strings.Index(urlpath, "eos.ruid") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Certificates: []tls.Certificate{cert}, | ||
}, | ||
MaxIdleConns: 10, | ||
MaxConnsPerHost: 8, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you make these configurable?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, of course
resp, err := c.cl.Do(req) | ||
|
||
// Let's support redirections... and if we retry we have to retry at the same FST, avoid going back to the MGM | ||
if resp != nil && (resp.StatusCode == 307 || resp.StatusCode == 302) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(resp.StatusCode == http.StatusFound || resp.StatusCode == http.StatusTemporaryRedirect)
Oh, I think you make a good point here about sharing the transport, I'll have a look if it an eos instance can keep the same transport to cache the conns |
…ll of its parameters configurable
@ffurano reva/pkg/eosclient/eosgrpc/eosgrpc.go Lines 197 to 201 in 338598b
and |
This is how it's meant to work, the creation of a new http client is based on the common instance of the transport class, which caches the real connections behind (plus keepalive, max numbers etc). Instances of the client class are meant to be just local and short lived |
Ah, and now the transport class is not a singleton anymore, there is one instance per EOS endpoint configured |
…ent. Use the golang url class to parse urls
No description provided.