| Commit message (Collapse) | Author | Age |
... | |
|
|
|
|
|
|
| |
In theory, now we can cancel Ping() and Cancel() RPCs, too, but since we don't tell their UUID anyone, we are fine.
--
MOS_MIGRATED_REVID=127703598
|
|
|
|
|
|
|
| |
unlike System#currentTimeMillis().
--
MOS_MIGRATED_REVID=127697254
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
Underlying issue fixed in commit 5b12f6e759c1f3137a7149d3026ff96686d07696
*** Original change description ***
Automated [] rollback of commit a3381b6ac136a0cab3ba86020c739fe16b42cee9.
*** Reason for rollback ***
Broke bazel_rules_test
See https://github.com/bazelbuild/bazel/issues/1501.
*** Original change description ***
Fix default for temporary directories to honor TMPDIR
...and only use the hard-coded "/tmp" as default for the default.
Note that is unchanged that blaze.rpcserver.tmpdir still overrides.
--
MOS_MIGRATED_REVID=127201018
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
Broke bazel_rules_test
See https://github.com/bazelbuild/bazel/issues/1501.
*** Original change description ***
Fix default for temporary directories to honor TMPDIR
...and only use the hard-coded "/tmp" as default for the default.
Note that is unchanged that blaze.rpcserver.tmpdir still overrides.
--
MOS_MIGRATED_REVID=127179462
|
|
|
|
|
|
|
|
|
|
| |
...and only use the hard-coded "/tmp" as default for the default.
Note that is unchanged that blaze.rpcserver.tmpdir still overrides.
--
Change-Id: I2ad6b9904b7cde3917968090e85cf2d6c8ad88ab
Reviewed-on: https://bazel-review.googlesource.com/#/c/3962
MOS_MIGRATED_REVID=127076270
|
|
|
|
|
|
|
|
|
|
|
| |
passes between the Ping() and Run() calls and make Ping() and Cancel() calls restart the server timeout interval.
This "fixes" a race condition where the client would call Ping(), the server would time out and then the Run() call would fail. Of course, this is not an principled fix because in theory, the timeout can still happen between the two calls, but now there are only simple file system operations and a tiny bit of CPU use between the two so it should be vanishingly unlikely. We use ->Ping() to verify server liveness after we start it up, so in theory, the timeout could strike between those two calls, too...
TESTED=By running "bazel --max_timeout_secs=2 info install_base" 100 times in a test and running the test 200 times. This procedure triggered the bug pretty reliably.
--
MOS_MIGRATED_REVID=126902519
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=126685659
|
|
|
|
|
|
|
| |
way that actually works.
--
MOS_MIGRATED_REVID=120997894
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
2009!).
If a "blaze clean --expunge" was run concurrently with another command (that was waiting for the lock), it's possible that the clean command deletes the lock file, the new server starts up, then the JVM shutdown hooks delete the PID files from the *new* server.
There is still a slight possibility of a race condition if the lock is deleted then IOException occurs which prevents the BlazeShutdownException from being raised, but I'd rather not introduce another channel from command implementations to RPCServer to close that loophole.
This issue was triggered by commit 5a78166ee4edbd295f5d5fdb94785025285e764b, after which the PID files for the new server are written a bit more early, thus increasing the time window in which the race condition can happen.
--
MOS_MIGRATED_REVID=120805163
|
|
|
|
|
|
|
|
|
| |
new ones.
Add server.pid.txt that contains the same information in text form. ExecuteDaemon() on Windows will simply not write server.pid .
--
MOS_MIGRATED_REVID=120802055
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=120699557
|
|
|
|
|
|
|
| |
This is because OsUtils.getpid() cannot work under msys2 since java.exe is not an msys2 binary. We might make it work by including JNI code, but the current plan is to go without JNI on Windows.
--
MOS_MIGRATED_REVID=120694746
|
|
|
|
|
|
|
| |
This is necessary because on Windows/msys2, the Java gRPC server listens only on IPv6 but the C++ client only tries to connect over IPv4, resulting in breakage.
--
MOS_MIGRATED_REVID=120689437
|
|
|
|
|
|
|
| |
I wonder why it was implemented like this in the first place. Unsurprisingly, it doesn't work on Windows.
--
MOS_MIGRATED_REVID=120682316
|
|
|
|
|
|
|
|
|
|
|
| |
In particular:
- Make a SIGINT to the server interrupt every command
- Parse negative numbers on the command line correctly (std::stoi throws an exception, and I'd rather not start using C++ exceptions)
- Use "bytes" for command line arguments instead of "string" in the client/server proto . This is more principled, although we pretend all arguments are strings all over the place and it works for "blaze run" mostly by accident.
--
MOS_MIGRATED_REVID=120434432
|
|
|
|
|
|
|
|
|
| |
- Actually make it work again (commit 00cfb7df61b1f3d9fac8ee29d92b315cbfe6d28f broke it, maybe I shouldn't send out changes in a hurry next time)
- Rename --grpc_port to --command_port (it's a bit better name)
- Do not send a kill signal to the server that can't be connected if we only connect to it to verify its presence
--
MOS_MIGRATED_REVID=120418784
|
|
|
|
|
|
|
| |
when in gRPC mode.
--
MOS_MIGRATED_REVID=120233121
|
|
|
|
|
|
|
| |
Work towards #930.
--
MOS_MIGRATED_REVID=120205147
|
|
|
|
|
|
|
|
|
|
|
| |
Drive-by fix: eliminate the GRPC messages from the console by passing a null logging function.
This also prepares us for the time when multiple commands will be running, because then we'll need to tell which command exactly we want to interrupt.
Work towards #930.
--
MOS_MIGRATED_REVID=120203008
|
|
|
|
|
|
|
| |
Work towards #930. With this, it's conceivable that server mode works on Windows to some degree (I haven't tried, though, because there are many issues that need to be fixed)
--
MOS_MIGRATED_REVID=120202037
|
|
|
|
|
|
|
|
|
| |
C symbols.
Fixed #1155.
--
MOS_MIGRATED_REVID=120107746
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This still has a number of issues, including, but not limited to:
- When switching between gRPC and AF_UNIX mode, you need to do a manual shutdown
- The console is spammed with "connection refused" messages on server startup
- When in gRPC mode, server also starts up an AF_UNIX server even though it's not necessary and concurrent requests probably make Bazel crash and burn
- I have no idea how concurrent gRPC requests are handled and now many threads gRPC creates
- Not tested except under Linux
- The request/response cookies are written in an odd format (negative bytes are not handled correctly). This is only a cosmetic issue, since the data content of the string is the same either way.
Can be tested with the --grpc_port=0 (or a valid port number) startup option.
--
MOS_MIGRATED_REVID=119948959
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Note that the presence of server/grpc_port does not guarantee that the server actually listens to it and we can't guarantee it, either, because it can always be kill -9'd.
I haven't decided yet how the transition between AF_UNIX and gRPC will work. For now, I'm happy that we can start up a Java server.
The way to get the kernel-chosen port is truly awful, but it is apparently impossible to do so in a different way:
https://github.com/grpc/grpc-java/issues/72
--
MOS_MIGRATED_REVID=119828354
|
|
|
|
|
|
|
| |
The code doesn't do anything yet and it's unused code for now. This change only serves to add all the necessary dependencies to BUILD files that gRPC needs.
--
MOS_MIGRATED_REVID=119628697
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=118940625
|
|
|
|
|
|
|
| |
This check is awful and should be done somewhat differently, but since we are migrating to gRPC, there isn't much point in investing much in this.
--
MOS_MIGRATED_REVID=118656266
|
|
|
|
|
|
|
|
|
| |
Windows.
Progress towards #930.
--
MOS_MIGRATED_REVID=117799006
|
|
|
|
|
|
|
| |
OutOfMemoryError and have the JVM send Bazel a SIGUSR2 when it detects an OOM. This should help in certain pathological cases when Bazel GC thrashes for some time after an OOM has been detected.
--
MOS_MIGRATED_REVID=116819359
|
|
|
|
|
|
|
| |
Fixed bazel github issue #978
--
MOS_MIGRATED_REVID=116164610
|
|
|
|
|
|
|
| |
invocation could be lost. Note that the client sends an empty request to the Blaze server to check its existence. Previously, we were treating this as a full command invocation in the server and resetting the interrupt bit. Now we detect this and do not alter the interrupt bit.
--
MOS_MIGRATED_REVID=115337972
|
|
|
|
|
|
|
| |
This helps avoid confusion with File*S*ystemUtils, which differs in only the case of a character but is a completely different class.
--
MOS_MIGRATED_REVID=113054116
|
|
|
|
|
|
|
| |
Reduces garbage.
--
MOS_MIGRATED_REVID=109914243
|
|
|
|
|
|
|
|
|
|
|
| |
The headers were modified with
`find . -type f -exec 'sed' '-Ei' 's|Copyright 201([45]) Google|Copyright 201\1 The Bazel Authors|' '{}' ';'`
And manual edit for not Google owned copyright. Because of the nature of ijar, I did not modified the header of file owned by Alan Donovan.
The list of authors were extracted from the git log. It is missing older Google contributors that can be added on-demand.
--
MOS_MIGRATED_REVID=103938715
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=102584924
|
|
|
|
|
|
|
| |
--
Change-Id: I36b096cfdf7b150121809ff5b07c74eac1cbf7ad
Reviewed-on: https://bazel-review.git.corp.google.com/#/c/1771
MOS_MIGRATED_REVID=100573875
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=87821306
|
|
--
MOE_MIGRATED_REVID=85702957
|