Skip to content
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

Resource locking serializes concurrent buf executions? #2863

Open
bjhartin opened this issue Apr 3, 2024 · 4 comments
Open

Resource locking serializes concurrent buf executions? #2863

bjhartin opened this issue Apr 3, 2024 · 4 comments

Comments

@bjhartin
Copy link

bjhartin commented Apr 3, 2024

Hello all,

It seems to me like buf convert (and maybe other commands) locks on some resource. If so, could this be either changed, documented or worked around on my side?

For example, in a hacky script to process a bunch of files I tried:

for ((i=1; i<=20; i++)); do
  echo "Starting $i" && \
  cat ... | buf convert ... > "file_$i.binpb" && \
  echo "Done with $i" & # <-- Spawning processes to hopefully do some work in parallel
done

As you can see on the fourth line, I spawn processes in the background to try and speed things up. However, the result was the same as when I did not spawn them in the background. So, it seemed to me that the buf convert processes are queueing up and waiting for some resource.

@bufdev
Copy link
Member

bufdev commented Apr 3, 2024

It's possible - for example, depending on what is in ..., it may be making a network call. You'd have to give us a specific, reproducible example for us to investigate. If you can provide that, we're happy to look into it.

@bjhartin
Copy link
Author

bjhartin commented Apr 3, 2024

@bufdev It's all local:

cat fooRequest.json | buf convert ./my_proto_project --type="com.mycompany.FooRequest" --from -#format=json --to -#format=binpb

@bufdev
Copy link
Member

bufdev commented Apr 3, 2024

We need something that we can run locally. If you can set up, for example, a temporary github repostory with the code you are executing, so that we can run this code and reproduce the issue, we're happy to look into it!

@bjhartin
Copy link
Author

bjhartin commented Apr 4, 2024

No problem. I'll get to that soon!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants