| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
|
| |
disambiguate the case where the blaze grpc client tells the blaze grpc server to cancel a running command (e.g. the blaze user ctrl+c's the blaze client) between the case a streaming rpc call gets cancelled (e.g. when the grpc client hangs up).
--
PiperOrigin-RevId: 149960615
MOS_MIGRATED_REVID=149960615
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
Bisected by dmarting as a root cause of TF breakage: http://ci.bazel.io/job/TensorFlow/672/BAZEL_VERSION=HEAD,PLATFORM_NAME=linux-x86_64/console
*** Original change description ***
Reinstate idleness checks where the server self-terminates when it's idle and there is either too much memory pressure or the workspace directory is gone.
Arguably, it should kill itself when the workspace directory is gone regardless of whether it's idle or not, but let's first get us back to a known good state, then we can think about improvements.
--
PiperOrigin-RevId: 147726386
MOS_MIGRATED_REVID=147726386
|
|
|
|
|
|
|
|
| |
Our Jenkins slaves are apparently slower than our workstations, thus, they are timeout-flaky.
--
PiperOrigin-RevId: 147590913
MOS_MIGRATED_REVID=147590913
|
|
|
|
|
|
|
|
|
|
| |
and there is either too much memory pressure or the workspace directory is gone.
Arguably, it should kill itself when the workspace directory is gone regardless of whether it's idle or not, but let's first get us back to a known good state, then we can think about improvements.
--
PiperOrigin-RevId: 147454329
MOS_MIGRATED_REVID=147454329
|
|
|
|
|
|
| |
--
PiperOrigin-RevId: 144054816
MOS_MIGRATED_REVID=144054816
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=135768834
|
|
|
|
|
|
|
|
|
| |
the Bazel server.
RELNOTES[INC]: --command_port=-1 to use AF_UNIX for client/server communications is not supported anymore.
--
MOS_MIGRATED_REVID=135355673
|
|
|
|
|
|
|
| |
Prevents overly large responses from overwhelming grpc.
--
MOS_MIGRATED_REVID=134083479
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=132039389
|
|
|
|
|
|
|
|
|
| |
the logical rollback of commit 67ad82a319ff8959e69e774e7c15d3af904ec23d.
RELNOTES[INC]: Bazel supports Unix domain sockets for communication between its client and server again, temporarily, while we diagnose a memory leak.
--
MOS_MIGRATED_REVID=130027009
|
|
|
|
|
|
|
|
|
| |
It has been superseded by gRPC.
RELNOTES[INC]: Blaze doesn't support Unix domain sockets for communication between its client and server anymore. Therefore, the --command_port command line argument doesn't accept -1 as a valid value anymore.
--
MOS_MIGRATED_REVID=129424092
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
when in gRPC mode.
--
MOS_MIGRATED_REVID=120233121
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
| |
Windows.
Progress towards #930.
--
MOS_MIGRATED_REVID=117799006
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=108797636
|
|
--
MOS_MIGRATED_REVID=108127872
|