Tree:
af3a0770ff
add-admin-and-worker-to-helm-charts
add-ec-vacuum
add_fasthttp_client
add_remote_storage
adding-message-queue-integration-tests
also-delete-parent-directory-if-empty
avoid_releasing_temp_file_on_write
changing-to-zap
collect-public-metrics
create-table-snapshot-api-design
data_query_pushdown
dependabot/maven/other/java/client/com.google.protobuf-protobuf-java-3.25.5
dependabot/maven/other/java/examples/org.apache.hadoop-hadoop-common-3.4.0
detect-and-plan-ec-tasks
do-not-retry-if-error-is-NotFound
enhance-erasure-coding
fasthttp
filer1_maintenance_branch
fix-GetObjectLockConfigurationHandler
fix-versioning-listing-only
ftp
gh-pages
improve-fuse-mount
improve-fuse-mount2
improve-mount-read-throughput
logrus
master
message_send
mount2
mq-subscribe
mq2
original_weed_mount
pr-7412
random_access_file
refactor-needle-read-operations
refactor-volume-write
remote_overlay
revert-5134-patch-1
revert-5819-patch-1
revert-6434-bugfix-missing-s3-audit
s3-select
sub
tcp_read
test-reverting-lock-table
test_udp
testing
testing-sdx-generation
tikv
track-mount-e2e
upgrade-versions-to-4.00
volume_buffered_writes
worker-execute-ec-tasks
0.72
0.72.release
0.73
0.74
0.75
0.76
0.77
0.90
0.91
0.92
0.93
0.94
0.95
0.96
0.97
0.98
0.99
1.00
1.01
1.02
1.03
1.04
1.05
1.06
1.07
1.08
1.09
1.10
1.11
1.12
1.14
1.15
1.16
1.17
1.18
1.19
1.20
1.21
1.22
1.23
1.24
1.25
1.26
1.27
1.28
1.29
1.30
1.31
1.32
1.33
1.34
1.35
1.36
1.37
1.38
1.40
1.41
1.42
1.43
1.44
1.45
1.46
1.47
1.48
1.49
1.50
1.51
1.52
1.53
1.54
1.55
1.56
1.57
1.58
1.59
1.60
1.61
1.61RC
1.62
1.63
1.64
1.65
1.66
1.67
1.68
1.69
1.70
1.71
1.72
1.73
1.74
1.75
1.76
1.77
1.78
1.79
1.80
1.81
1.82
1.83
1.84
1.85
1.86
1.87
1.88
1.90
1.91
1.92
1.93
1.94
1.95
1.96
1.97
1.98
1.99
1;70
2.00
2.01
2.02
2.03
2.04
2.05
2.06
2.07
2.08
2.09
2.10
2.11
2.12
2.13
2.14
2.15
2.16
2.17
2.18
2.19
2.20
2.21
2.22
2.23
2.24
2.25
2.26
2.27
2.28
2.29
2.30
2.31
2.32
2.33
2.34
2.35
2.36
2.37
2.38
2.39
2.40
2.41
2.42
2.43
2.47
2.48
2.49
2.50
2.51
2.52
2.53
2.54
2.55
2.56
2.57
2.58
2.59
2.60
2.61
2.62
2.63
2.64
2.65
2.66
2.67
2.68
2.69
2.70
2.71
2.72
2.73
2.74
2.75
2.76
2.77
2.78
2.79
2.80
2.81
2.82
2.83
2.84
2.85
2.86
2.87
2.88
2.89
2.90
2.91
2.92
2.93
2.94
2.95
2.96
2.97
2.98
2.99
3.00
3.01
3.02
3.03
3.04
3.05
3.06
3.07
3.08
3.09
3.10
3.11
3.12
3.13
3.14
3.15
3.16
3.18
3.19
3.20
3.21
3.22
3.23
3.24
3.25
3.26
3.27
3.28
3.29
3.30
3.31
3.32
3.33
3.34
3.35
3.36
3.37
3.38
3.39
3.40
3.41
3.42
3.43
3.44
3.45
3.46
3.47
3.48
3.50
3.51
3.52
3.53
3.54
3.55
3.56
3.57
3.58
3.59
3.60
3.61
3.62
3.63
3.64
3.65
3.66
3.67
3.68
3.69
3.71
3.72
3.73
3.74
3.75
3.76
3.77
3.78
3.79
3.80
3.81
3.82
3.83
3.84
3.85
3.86
3.87
3.88
3.89
3.90
3.91
3.92
3.93
3.94
3.95
3.96
3.97
3.98
3.99
4.00
4.01
dev
helm-3.65.1
v0.69
v0.70beta
v3.33
${ noResults }
12120 Commits (af3a0770ff2e871874f03c9812e7b7b3614d05f6)
| Author | SHA1 | Message | Date |
|---|---|---|---|
Chris Lu
|
af3a0770ff |
Enable filer discovery: pass master addresses to FilerClient
Fix two critical issues: 1. **Filer Discovery Not Working**: Master client was not being passed to FilerClient, so peer discovery couldn't work 2. **Credential Store Design**: Already uses FilerClient via GetCurrentFiler function - this is the correct design for HA Changes: **Command (s3.go):** - Read master addresses from GetFilerConfiguration response - Pass masterAddresses to S3ApiServerOption - Log master addresses for visibility **S3ApiServerOption:** - Add Masters []pb.ServerAddress field for discovery **S3ApiServer:** - Create MasterClient from Masters when available - Pass MasterClient + FilerGroup to FilerClient via options - Enable discovery with 5-minute refresh interval - Log whether discovery is enabled or disabled **Credential Store:** - Already correctly uses filerClient.GetCurrentFiler via function - This provides HA without tight coupling to FilerClient struct - Function-based design is clean and thread-safe Discovery Flow: 1. S3 command reads filer config → gets masters + filer group 2. S3ApiServer creates MasterClient from masters 3. FilerClient uses MasterClient to query for peer filers 4. Background goroutine refreshes peer list every 5 minutes 5. Credential store uses GetCurrentFiler to get active filer Now filer discovery actually works! �� |
4 days ago |
|
Chris Lu
|
8517cebb31 |
Add thread safety to FilerEtcStore and clarify credential store comments
Address review suggestions for better thread safety and code clarity: 1. **Thread Safety**: Add RWMutex to FilerEtcStore - Protects filerAddressFunc and grpcDialOption from concurrent access - Initialize() uses write lock when setting function - SetFilerAddressFunc() uses write lock - withFilerClient() uses read lock to get function and dial option - GetPolicies() uses read lock to check if configured 2. **Improved Error Messages**: - Prefix errors with "filer_etc:" for easier debugging - "filer address not configured" → "filer_etc: filer address function not configured" - "filer address is empty" → "filer_etc: filer address is empty" 3. **Clarified Comments**: - auth_credentials.go: Clarify that initial setup is temporary - Document that it's updated in s3api_server.go after FilerClient creation - Remove ambiguity about when FilerClient.GetCurrentFiler is used Benefits: - Safe for concurrent credential operations - Clear error messages for debugging - Explicit documentation of initialization order |
4 days ago |
|
Chris Lu
|
28fc613a50 |
Fix toFilerPath: remove URL escaping for raw file paths
The toFilerPath function should return raw file paths, not URL-escaped paths. URL escaping was needed when the path was embedded in a URL (old toFilerUrl), but now that we pass paths directly to putToFiler, they should be unescaped. This fixes S3 integration test failures: - test_bucket_listv2_encoding_basic - test_bucket_list_encoding_basic - test_bucket_listv2_delimiter_whitespace - test_bucket_list_delimiter_whitespace The tests were failing because paths were double-encoded (escaped when stored, then escaped again when listed), resulting in %252B instead of %2B for '+' characters. Root cause: When we removed URL parsing in putToFiler, we should have also removed URL escaping in toFilerPath since paths are now used directly without URL encoding/decoding. |
4 days ago |
|
Chris Lu
|
abf85bfe4f |
Remove deprecated functions: use new path-based functions directly
Remove deprecated wrapper functions and update all callers to use the new function names directly. Removed: - genPartUploadUrl() → all callers now use genPartUploadPath() - toFilerUrl() → all callers now use toFilerPath() - SetFilerClient() → removed along with fallback code Updated: - s3api_object_handlers_multipart.go: uploadUrl → filePath - s3api_object_handlers_put.go: uploadUrl → filePath, versionUploadUrl → versionFilePath - s3api_object_versioning.go: toFilerUrl → toFilerPath - s3api_object_handlers_test.go: toFilerUrl → toFilerPath - auth_credentials.go: removed SetFilerClient fallback - filer_etc_store.go: removed deprecated SetFilerClient method Benefits: - Cleaner codebase with no deprecated functions - All variable names accurately reflect that they're paths, not URLs - Single interface for credential stores (SetFilerAddressFunc only) All code now consistently uses the new path-based approach. |
4 days ago |
|
Chris Lu
|
d4df6ca481 |
Remove filer address from upload paths - pass path directly
Eliminate unnecessary filer address from upload URLs by passing file paths directly instead of full URLs that get immediately parsed. Changes: - Rename genPartUploadUrl() → genPartUploadPath() (returns path only) - Rename toFilerUrl() → toFilerPath() (returns path only) - Update putToFiler() to accept filePath instead of uploadUrl - Remove URL parsing code (no longer needed) - Remove net/url import (no longer used) - Keep old function names as deprecated wrappers for compatibility Benefits: - Cleaner code - no fake URL construction/parsing - No dependency on filer address for internal operations - More accurate naming (these are paths, not URLs) - Eliminates confusion about HA concerns This completely removes the filer address from upload operations - it was never actually used for routing, only parsed for the path. |
4 days ago |
|
Chris Lu
|
3aa9b5f4fe |
Clarify multipart URL comments: filer address not used for uploads
Update comments to reflect that multipart upload URLs are not actually used for upload traffic - uploads go directly to volume servers. Key clarifications: - genPartUploadUrl: Filer address is parsed out, only path is used - CompleteMultipartUpload Location: Informational field per AWS S3 spec - Actual uploads bypass filer proxy and go directly to volume servers The filer address in these URLs is NOT a HA concern because: 1. Part uploads: URL is parsed for path, upload goes to volume servers 2. Location URL: Informational only, clients use S3 endpoint This addresses the observation that S3 uploads don't go through filers, only metadata operations do. |
4 days ago |
|
Chris Lu
|
c24629cd5e |
Make credential store use current active filer for HA
Update FilerEtcStore to use a function that returns the current active filer instead of a fixed address, enabling high availability. Changes: - Add SetFilerAddressFunc() method to FilerEtcStore - Store uses filerAddressFunc instead of fixed filerGrpcAddress - withFilerClient() calls the function to get current active filer - Keep SetFilerClient() for backward compatibility (marked deprecated) - Update S3ApiServer to pass FilerClient.GetCurrentFiler to store Benefits: - Credential store now uses currently active/healthy filer - Automatic failover when filer becomes unavailable - True HA for credential operations - Backward compatible with old SetFilerClient interface This addresses the credential store limitation - no longer pinned to first filer, uses FilerClient's tracked current active filer. |
4 days ago |
|
Chris Lu
|
8d8b1f7c87 |
Document multipart completion Location URL limitation
Addresses review comment on filer_multipart.go:187 Add comment documenting that the Location URL in CompleteMultipartUpload response points to the current active filer (tracked by FilerClient). Note that clients should ideally use the S3 API endpoint rather than this direct URL. If direct access is attempted and the specific filer is unavailable, the request will fail. Current behavior uses the currently active/healthy filer rather than being pinned to the first filer, providing better availability. |
4 days ago |
|
Chris Lu
|
e1497301cf |
Document multipart upload URL HA limitation
Addresses review comment on s3api_object_handlers_multipart.go:442 Add comment documenting that part upload URLs point to the current active filer (tracked by FilerClient), which is better than always using the first filer but still creates a potential point of failure if that filer becomes unavailable during upload. Suggest TODO solutions: - Use virtual hostname/load balancer for filers - Have S3 server proxy uploads to healthy filers Current behavior provides reasonable availability by using the currently active/healthy filer rather than being pinned to first filer. |
4 days ago |
|
Chris Lu
|
1d7fded503 |
Document ReadFilerConf HA limitation in lifecycle handlers
Addresses review comment on s3api_bucket_handlers.go:880 Add comment documenting that ReadFilerConf uses the current active filer from FilerClient (which is better than always using first filer), but doesn't have built-in multi-filer failover. Add TODO to update filer.ReadFilerConf to support multiple filers for complete HA. For now, it uses the currently active/healthy filer tracked by FilerClient which provides reasonable availability. |
4 days ago |
|
Chris Lu
|
ee6054700f |
Track current active filer in FilerClient for better HA
Add GetCurrentFiler() method to FilerClient that returns the currently active filer based on the filerIndex which is updated on successful operations. This provides better availability than always using the first filer. Changes: - Add FilerClient.GetCurrentFiler() method that returns current active filer - Update S3ApiServer.getFilerAddress() to use FilerClient's current filer - Add fallback to first filer if FilerClient not yet initialized - Document IAM limitation (doesn't have FilerClient access) Benefits: - Single-filer operations (URLs, ReadFilerConf, etc.) now use the currently active/healthy filer - Better distribution and failover behavior - FilerClient's round-robin and health tracking automatically determines which filer to use |
4 days ago |
|
Chris Lu
|
7611f05f37 |
Document credential store HA limitation with TODO
Addresses review comment on auth_credentials.go:149 Changes: - Add TODO comment documenting that SetFilerClient interface needs update for multi-filer support - Add informative log message indicating HA limitation - Document that this is a known limitation for filer-backed credential stores The SetFilerClient interface currently only accepts a single filer address. To properly support HA, the credential store interfaces need to be updated to handle multiple filer addresses. |
4 days ago |
|
Chris Lu
|
9346e6bc25 |
Fix IAM manager initialization: remove code duplication, add TODO for HA
Addresses review comment on s3api_server.go:145 Changes: - Remove duplicate code for getting first filer address - Extract filerAddr variable once and reuse - Add TODO comment documenting the HA limitation for IAM manager - Document that loadIAMManagerFromConfig and NewS3IAMIntegration need updates to support multiple filers for full HA Note: This is a known limitation when using filer-backed IAM stores. The interfaces need to be updated to accept multiple filer addresses. For now, documenting this limitation clearly. |
4 days ago |
|
Chris Lu
|
839c450d21 |
Address PR review comments: implement full failover for IAM operations
Critical fixes based on code review feedback:
1. **IAM API Failover (Critical)**:
- Replace pb.WithGrpcFilerClient with pb.WithOneOfGrpcFilerClients in:
* GetS3ApiConfigurationFromFiler()
* PutS3ApiConfigurationToFiler()
* GetPolicies()
* PutPolicies()
- Now all IAM operations support automatic failover across multiple filers
2. **Validation Improvements**:
- Add validation in NewIamApiServerWithStore() to require at least one filer
- Add validation in NewS3ApiServerWithStore() to require at least one filer
- Add warning log when no filers configured for credential store
3. **Error Logging**:
- Circuit breaker now logs when config load fails instead of silently ignoring
- Helps operators understand why circuit breaker limits aren't applied
4. **Code Quality**:
- Use ToGrpcAddress() for filer address in credential store setup
- More consistent with rest of codebase and future-proof
These changes ensure IAM operations have the same high availability guarantees
as S3 operations, completing the multi-filer failover implementation.
|
4 days ago |
|
Chris Lu
|
60dae3887d |
Add filer discovery: treat initial filers as seeds and discover peers from master
Enhances FilerClient to automatically discover additional filers in the same
filer group by querying the master server. This allows users to specify just
a few seed filers, and the client will discover all other filers in the cluster.
Key changes to wdclient/FilerClient:
- Added MasterClient, FilerGroup, and DiscoveryInterval fields
- Added thread-safe filer list management with RWMutex
- Implemented discoverFilers() background goroutine
- Uses cluster.ListExistingPeerUpdates() to query master for filers
- Automatically adds newly discovered filers to the list
- Added Close() method to clean up discovery goroutine
New FilerClientOption fields:
- MasterClient: enables filer discovery from master
- FilerGroup: specifies which filer group to discover
- DiscoveryInterval: how often to refresh (default 5 minutes)
Usage example:
masterClient := wdclient.NewMasterClient(...)
filerClient := wdclient.NewFilerClient(
[]pb.ServerAddress{"localhost:8888"}, // seed filers
grpcDialOption,
dataCenter,
&wdclient.FilerClientOption{
MasterClient: masterClient,
FilerGroup: "my-group",
},
)
defer filerClient.Close()
The initial filers act as seeds - the client discovers and adds all other
filers in the same group from the master. Discovered filers are added
dynamically without removing existing ones (relying on health checks for
unavailable filers).
|
4 days ago |
|
Chris Lu
|
e537852ec6 |
Support multiple filers for S3 and IAM servers with automatic failover
This change adds support for multiple filer addresses in the 'weed s3' and 'weed iam' commands, enabling high availability through automatic failover. Key changes: - Updated S3ApiServerOption.Filer to Filers ([]pb.ServerAddress) - Updated IamServerOption.Filer to Filers ([]pb.ServerAddress) - Modified -filer flag to accept comma-separated addresses - Added getFilerAddress() helper methods for backward compatibility - Updated all filer client calls to support multiple addresses - Uses pb.WithOneOfGrpcFilerClients for automatic failover Usage: weed s3 -filer=localhost:8888,localhost:8889 weed iam -filer=localhost:8888,localhost:8889 The underlying FilerClient already supported multiple filers with health tracking and automatic failover - this change exposes that capability through the command-line interface. |
4 days ago |
tam-i13
|
b669607fcd
|
Add error list each entry func (#7485)
* added error return in type ListEachEntryFunc * return error if errClose * fix fmt.Errorf * fix return errClose * use %w fmt.Errorf * added entry in messege error * add callbackErr in ListDirectoryEntries * fix error * add log * clear err when the scanner stops on io.EOF, so returning err doesn’t surface EOF as a failure. * more info in error * add ctx to logs, error handling * fix return eachEntryFunc * fix * fix log * fix return * fix foundationdb test s * fix eachEntryFunc * fix return resEachEntryFuncErr * Update weed/filer/filer.go Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com> * Update weed/filer/elastic/v7/elastic_store.go Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com> * Update weed/filer/hbase/hbase_store.go Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com> * Update weed/filer/foundationdb/foundationdb_store.go Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com> * Update weed/filer/ydb/ydb_store.go Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com> * fix * add scanErr --------- Co-authored-by: Roman Tamarov <r.tamarov@kryptonite.ru> Co-authored-by: Chris Lu <chrislusf@users.noreply.github.com> Co-authored-by: chrislu <chris.lu@gmail.com> Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com> |
4 days ago |
|
chrislu
|
76f1a23fec |
fix docker login
|
4 days ago |
Chris Lu
|
c156a130b7
|
S3: Auto create bucket (#7549)
* auto create buckets * only admin users can auto create buckets * Update weed/s3api/s3api_bucket_handlers.go Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com> * validate bucket name * refactor * error handling * error * refetch * ensure owner * multiple errors --------- Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com> |
4 days ago |
Lisandro Pin
|
2843cb1255
|
Bootstrap logic to fix read-only volumes with `volume.check.disk`. (#7531)
* Bootstrap logic to fix read-only volumes with `volume.check.disk`.
The new implementation performs a second pass where read-only volumes are (optionally)
verified and fixed.
For each non-writable volume ID A:
if volume is not full
prune late volume entries not matching its index file
select a writable volume replica B
append missing entries from B into A
mark the volume as writable (healthy)
* variable and parameter renaming
---------
Co-authored-by: chrislu <chris.lu@gmail.com>
|
4 days ago |
|
Chris Lu
|
2e6c746a30
|
fix copying for paused versioning buckets (#7548)
* fix copying for paused versioning buckets * copy for non versioned files * add tests * better tests * Update weed/s3api/s3api_object_handlers_copy.go Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com> * remove etag * update * Update s3api_object_handlers_copy_test.go * Update weed/s3api/s3api_object_handlers_copy_test.go Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com> * Update weed/s3api/s3api_object_handlers_copy_test.go Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com> * revert --------- Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com> |
4 days ago |
|
chrislu
|
3f1a34d8d7 |
doc
|
4 days ago |
|
Chris Lu
|
f6a604c538
|
S3: Fix encrypted file copy with multiple chunks (#7530) (#7546)
* S3: Fix encrypted file copy with multiple chunks (#7530) When copying encrypted files with multiple chunks (encrypted volumes via -filer.encryptVolumeData), the copied file could not be read. This was caused by the chunk copy operation not preserving the IsCompressed flag, which led to improper handling of compressed/encrypted data during upload. The fix: 1. Modified uploadChunkData to accept an isCompressed parameter 2. Updated copySingleChunk to pass the source chunk's IsCompressed flag 3. Updated copySingleChunkForRange for partial copy operations 4. Updated all other callers to pass the appropriate compression flag 5. Added comprehensive tests for encrypted volume copy scenarios This ensures that when copying chunks: - The IsCompressed flag from the source chunk is passed to the upload - Compressed data is marked as compressed, preventing double-compression - Already-encrypted data is not re-encrypted (Cipher: false is correct) - All chunk metadata (CipherKey, IsCompressed, ETag) is preserved Tests added: - TestCreateDestinationChunkPreservesEncryption: Verifies metadata preservation - TestCopySingleChunkWithEncryption: Tests various encryption/compression scenarios - TestCopyChunksPreservesMetadata: Tests multi-chunk metadata preservation - TestEncryptedVolumeScenario: Documents and tests the exact issue #7530 scenario Fixes #7530 * Address PR review feedback: simplify tests and improve clarity - Removed TestUploadChunkDataCompressionFlag (panic-based test) - Removed TestCopySingleChunkWithEncryption (duplicate coverage) - Removed TestCopyChunksPreservesMetadata (duplicate coverage) - Added ETag verification to TestEncryptedVolumeCopyScenario - Renamed to TestEncryptedVolumeCopyScenario for better clarity - All test coverage now in TestCreateDestinationChunkPreservesEncryption and TestEncryptedVolumeCopyScenario which focus on the actual behavior |
4 days ago |
粒粒橙
|
a24c31de06
|
S3: Add `Vary` header for non-wildcard AllowOrigin (#7547)
|
4 days ago |
dependabot[bot]
|
935c641f25
|
chore(deps): bump actions/setup-go from 5 to 6 (#7542)
Bumps [actions/setup-go](https://github.com/actions/setup-go) from 5 to 6. - [Release notes](https://github.com/actions/setup-go/releases) - [Commits](https://github.com/actions/setup-go/compare/v5...v6) --- updated-dependencies: - dependency-name: actions/setup-go dependency-version: '6' dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> |
4 days ago |
|
dependabot[bot]
|
fb01269ded
|
chore(deps): bump actions/checkout from 4 to 6 (#7543)
Bumps [actions/checkout](https://github.com/actions/checkout) from 4 to 6. - [Release notes](https://github.com/actions/checkout/releases) - [Commits](https://github.com/actions/checkout/compare/v4...v6) --- updated-dependencies: - dependency-name: actions/checkout dependency-version: '6' dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> |
4 days ago |
|
dependabot[bot]
|
2712a0daeb
|
chore(deps): bump github.com/linkedin/goavro/v2 from 2.14.0 to 2.14.1 (#7537)
* chore(deps): bump github.com/linkedin/goavro/v2 from 2.14.0 to 2.14.1 Bumps [github.com/linkedin/goavro/v2](https://github.com/linkedin/goavro) from 2.14.0 to 2.14.1. - [Release notes](https://github.com/linkedin/goavro/releases) - [Changelog](https://github.com/linkedin/goavro/blob/master/debug_release.go) - [Commits](https://github.com/linkedin/goavro/compare/v2.14.0...v2.14.1) --- updated-dependencies: - dependency-name: github.com/linkedin/goavro/v2 dependency-version: 2.14.1 dependency-type: direct:production update-type: version-update:semver-patch ... Signed-off-by: dependabot[bot] <support@github.com> * go mod tidy --------- Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: chrislu <chris.lu@gmail.com> |
4 days ago |
|
Chris Lu
|
9f413de6a9
|
HDFS: Java client replication configuration (#7526)
* more flexible replication configuration
* remove hdfs-over-ftp
* Fix keepalive mismatch
* NPE
* grpc-java 1.75.0 → 1.77.0
* grpc-go 1.75.1 → 1.77.0
* Retry logic
* Connection pooling, HTTP/2 tuning, keepalive
* Complete Spark integration test suite
* CI/CD workflow
* Update dependency-reduced-pom.xml
* add comments
* docker compose
* build clients
* go mod tidy
* fix building
* mod
* java: fix NPE in SeaweedWrite and Makefile env var scope
- Add null check for HttpEntity in SeaweedWrite.multipartUpload()
to prevent NPE when response.getEntity() returns null
- Fix Makefile test target to properly export SEAWEEDFS_TEST_ENABLED
by setting it on the same command line as mvn test
- Update docker-compose commands to use V2 syntax (docker compose)
for consistency with GitHub Actions workflow
* spark: update compiler source/target from Java 8 to Java 11
- Fix inconsistency between maven.compiler.source/target (1.8) and
surefire JVM args (Java 9+ module flags like --add-opens)
- Update to Java 11 to match CI environment (GitHub Actions uses Java 11)
- Docker environment uses Java 17 which is also compatible
- Java 11+ is required for the --add-opens/--add-exports flags used
in the surefire configuration
* spark: fix flaky test by sorting DataFrame before first()
- In testLargeDataset(), add orderBy("value") before calling first()
- Parquet files don't guarantee row order, so first() on unordered
DataFrame can return any row, making assertions flaky
- Sorting by 'value' ensures the first row is always the one with
value=0, making the test deterministic and reliable
* ci: refactor Spark workflow for DRY and robustness
1. Add explicit permissions (least privilege):
- contents: read
- checks: write (for test reports)
- pull-requests: write (for PR comments)
2. Extract duplicate build steps into shared 'build-deps' job:
- Eliminates duplication between spark-tests and spark-example
- Build artifacts are uploaded and reused by dependent jobs
- Reduces CI time and ensures consistency
3. Fix spark-example service startup verification:
- Match robust approach from spark-tests job
- Add explicit timeout and failure handling
- Verify all services (master, volume, filer)
- Include diagnostic logging on failure
- Prevents silent failures and obscure errors
These changes improve maintainability, security, and reliability
of the Spark integration test workflow.
* ci: update actions/cache from v3 to v4
- Update deprecated actions/cache@v3 to actions/cache@v4
- Ensures continued support and bug fixes
- Cache key and path remain compatible with v4
* ci: fix Maven artifact restoration in workflow
- Add step to restore Maven artifacts from download to ~/.m2/repository
- Restructure artifact upload to use consistent directory layout
- Remove obsolete 'version' field from docker-compose.yml to eliminate warnings
- Ensures SeaweedFS Java dependencies are available during test execution
* ci: fix SeaweedFS binary permissions after artifact download
- Add step to chmod +x the weed binary after downloading artifacts
- Artifacts lose executable permissions during upload/download
- Prevents 'Permission denied' errors when Docker tries to run the binary
* ci: fix artifact download path to avoid checkout conflicts
- Download artifacts to 'build-artifacts' directory instead of '.'
- Prevents checkout from overwriting downloaded files
- Explicitly copy weed binary from build-artifacts to docker/ directory
- Update Maven artifact restoration to use new path
* fix: add -peers=none to master command for standalone mode
- Ensures master runs in standalone single-node mode
- Prevents master from trying to form a cluster
- Required for proper initialization in test environment
* test: improve docker-compose config for Spark tests
- Add -volumeSizeLimitMB=50 to master (consistent with other integration tests)
- Add -defaultReplication=000 to master for explicit single-copy storage
- Add explicit -port and -port.grpc flags to all services
- Add -preStopSeconds=1 to volume for faster shutdown
- Add healthchecks to master and volume services
- Use service_healthy conditions for proper startup ordering
- Improve healthcheck intervals and timeouts for faster startup
- Use -ip flag instead of -ip.bind for service identity
* fix: ensure weed binary is executable in Docker image
- Add chmod +x for weed binaries in Dockerfile.local
- Artifact upload/download doesn't preserve executable permissions
- Ensures binaries are executable regardless of source file permissions
* refactor: remove unused imports in FilerGrpcClient
- Remove unused io.grpc.Deadline import
- Remove unused io.netty.handler.codec.http2.Http2Settings import
- Clean up linter warnings
* refactor: eliminate code duplication in channel creation
- Extract common gRPC channel configuration to createChannelBuilder() method
- Reduce code duplication from 3 branches to single configuration
- Improve maintainability by centralizing channel settings
- Add Javadoc for the new helper method
* fix: align maven-compiler-plugin with compiler properties
- Change compiler plugin source/target from hardcoded 1.8 to use properties
- Ensures consistency with maven.compiler.source/target set to 11
- Prevents version mismatch between properties and plugin configuration
- Aligns with surefire Java 9+ module arguments
* fix: improve binary copy and chmod in Dockerfile
- Copy weed binary explicitly to /usr/bin/weed
- Run chmod +x immediately after COPY to ensure executable
- Add ls -la to verify binary exists and has correct permissions
- Make weed_pub* and weed_sub* copies optional with || true
- Simplify RUN commands for better layer caching
* fix: remove invalid shell operators from Dockerfile COPY
- Remove '|| true' from COPY commands (not supported in Dockerfile)
- Remove optional weed_pub* and weed_sub* copies (not needed for tests)
- Simplify Dockerfile to only copy required files
- Keep chmod +x and ls -la verification for main binary
* ci: add debugging and force rebuild of Docker images
- Add ls -la to show build-artifacts/docker/ contents
- Add file command to verify binary type
- Add --no-cache to docker compose build to prevent stale cache issues
- Ensures fresh build with current binary
* ci: add comprehensive failure diagnostics
- Add container status (docker compose ps -a) on startup failure
- Add detailed logs for all three services (master, volume, filer)
- Add container inspection to verify binary exists
- Add debugging info for spark-example job
- Helps diagnose startup failures before containers are torn down
* fix: build statically linked binary for Alpine Linux
- Add CGO_ENABLED=0 to go build command
- Creates statically linked binary compatible with Alpine (musl libc)
- Fixes 'not found' error caused by missing glibc dynamic linker
- Add file command to verify static linking in build output
* security: add dependencyManagement to fix vulnerable transitives
- Pin Jackson to 2.15.3 (fixes multiple CVEs in older versions)
- Pin Netty to 4.1.100.Final (fixes CVEs in transport/codec)
- Pin Apache Avro to 1.11.4 (fixes deserialization CVEs)
- Pin Apache ZooKeeper to 3.9.1 (fixes authentication bypass)
- Pin commons-compress to 1.26.0 (fixes zip slip vulnerabilities)
- Pin commons-io to 2.15.1 (fixes path traversal)
- Pin Guava to 32.1.3-jre (fixes temp directory vulnerabilities)
- Pin SnakeYAML to 2.2 (fixes arbitrary code execution)
- Pin Jetty to 9.4.53 (fixes multiple HTTP vulnerabilities)
- Overrides vulnerable versions from Spark/Hadoop transitives
* refactor: externalize seaweedfs-hadoop3-client version to property
- Add seaweedfs.hadoop3.client.version property set to 3.80
- Replace hardcoded version with ${seaweedfs.hadoop3.client.version}
- Enables easier version management from single location
- Follows Maven best practices for dependency versioning
* refactor: extract surefire JVM args to property
- Move multi-line argLine to surefire.jvm.args property
- Reference property in argLine for cleaner configuration
- Improves maintainability and readability
- Follows Maven best practices for JVM argument management
- Avoids potential whitespace parsing issues
* fix: add publicUrl to volume server for host network access
- Add -publicUrl=localhost:8080 to volume server command
- Ensures filer returns localhost URL instead of Docker service name
- Fixes UnknownHostException when tests run on host network
- Volume server is accessible via localhost from CI runner
* security: upgrade Netty to 4.1.115.Final to fix CVE
- Upgrade netty.version from 4.1.100.Final to 4.1.115.Final
- Fixes GHSA-prj3-ccx8-p6x4: MadeYouReset HTTP/2 DDoS vulnerability
- Netty 4.1.115.Final includes patches for high severity DoS attack
- Addresses GitHub dependency review security alert
* fix: suppress verbose Parquet DEBUG logging
- Set org.apache.parquet to WARN level
- Set org.apache.parquet.io to ERROR level
- Suppress RecordConsumerLoggingWrapper and MessageColumnIO DEBUG logs
- Reduces CI log noise from thousands of record-level messages
- Keeps important error messages visible
* fix: use 127.0.0.1 for volume server IP registration
- Change volume -ip from seaweedfs-volume to 127.0.0.1
- Change -publicUrl from localhost:8080 to 127.0.0.1:8080
- Volume server now registers with master using 127.0.0.1
- Filer will return 127.0.0.1:8080 URL that's resolvable from host
- Fixes UnknownHostException for seaweedfs-volume hostname
* security: upgrade Netty to 4.1.118.Final
- Upgrade from 4.1.115.Final to 4.1.118.Final
- Fixes CVE-2025-24970: improper validation in SslHandler
- Fixes CVE-2024-47535: unsafe environment file reading on Windows
- Fixes CVE-2024-29025: HttpPostRequestDecoder resource exhaustion
- Addresses GHSA-prj3-ccx8-p6x4 and related vulnerabilities
* security: upgrade Netty to 4.1.124.Final (patched version)
- Upgrade from 4.1.118.Final to 4.1.124.Final
- Fixes GHSA-prj3-ccx8-p6x4: MadeYouReset HTTP/2 DDoS vulnerability
- 4.1.124.Final is the confirmed patched version per GitHub advisory
- All versions <= 4.1.123.Final are vulnerable
* ci: skip central-publishing plugin during build
- Add -Dcentral.publishing.skip=true to all Maven builds
- Central publishing plugin is only needed for Maven Central releases
- Prevents plugin resolution errors during CI builds
- Complements existing -Dgpg.skip=true flag
* fix: aggressively suppress Parquet DEBUG logging
- Set Parquet I/O loggers to OFF (completely disabled)
- Add log4j.configuration system property to ensure config is used
- Override Spark's default log4j configuration
- Prevents thousands of record-level DEBUG messages in CI logs
* security: upgrade Apache ZooKeeper to 3.9.3
- Upgrade from 3.9.1 to 3.9.3
- Fixes GHSA-g93m-8x6h-g5gv: Authentication bypass in Admin Server
- Fixes GHSA-r978-9m6m-6gm6: Information disclosure in persistent watchers
- Fixes GHSA-2hmj-97jw-28jh: Insufficient permission check in snapshot/restore
- Addresses high and moderate severity vulnerabilities
* security: upgrade Apache ZooKeeper to 3.9.4
- Upgrade from 3.9.3 to 3.9.4 (latest stable)
- Ensures all known security vulnerabilities are patched
- Fixes GHSA-g93m-8x6h-g5gv, GHSA-r978-9m6m-6gm6, GHSA-2hmj-97jw-28jh
* fix: add -max=0 to volume server for unlimited volumes
- Add -max=0 flag to volume server command
- Allows volume server to create unlimited 50MB volumes
- Fixes 'No writable volumes' error during Spark tests
- Volume server will create new volumes as needed for writes
- Consistent with other integration test configurations
* security: upgrade Jetty from 9.4.53 to 12.0.16
- Upgrade from 9.4.53.v20231009 to 12.0.16 (meets requirement >12.0.9)
- Addresses security vulnerabilities in older Jetty versions
- Externalized version to jetty.version property for easier maintenance
- Added jetty-util, jetty-io, jetty-security to dependencyManagement
- Ensures all Jetty transitive dependencies use secure version
* fix: add persistent volume data directory for volume server
- Add -dir=/data flag to volume server command
- Mount Docker volume seaweedfs-volume-data to /data
- Ensures volume server has persistent storage for volume files
- Fixes issue where volume server couldn't create writable volumes
- Volume data persists across container restarts during tests
* fmt
* fix: remove Jetty dependency management due to unavailable versions
- Jetty 12.0.x versions greater than 12.0.9 do not exist in Maven Central
- Attempted 12.0.10, 12.0.12, 12.0.16 - none are available
- Next available versions are in 12.1.x series
- Remove Jetty dependency management to rely on transitive resolution
- Allows build to proceed with Jetty versions from Spark/Hadoop dependencies
- Can revisit with explicit version pinning if CVE concerns arise
* 4.1.125.Final
* fix: restore Jetty dependency management with version 12.0.12
- Restore explicit Jetty version management in dependencyManagement
- Pin Jetty 12.0.12 for transitive dependencies from Spark/Hadoop
- Remove misleading comment about Jetty versions availability
- Include jetty-server, jetty-http, jetty-servlet, jetty-util, jetty-io, jetty-security
- Use jetty.version property for consistency across all Jetty artifacts
- Update Netty to 4.1.125.Final (latest security patch)
* security: add dependency overrides for vulnerable transitive deps
- Add commons-beanutils 1.11.0 (fixes CVE in 1.9.4)
- Add protobuf-java 3.25.5 (compatible with Spark/Hadoop ecosystem)
- Add nimbus-jose-jwt 9.37.2 (minimum secure version)
- Add snappy-java 1.1.10.4 (fixes compression vulnerabilities)
- Add dnsjava 3.6.0 (fixes DNS security issues)
All dependencies are pulled transitively from Hadoop/Spark:
- commons-beanutils: hadoop-common
- protobuf-java: hadoop-common
- nimbus-jose-jwt: hadoop-auth
- snappy-java: spark-core
- dnsjava: hadoop-common
Verified with mvn dependency:tree that overrides are applied correctly.
* security: upgrade nimbus-jose-jwt to 9.37.4 (patched version)
- Update from 9.37.2 to 9.37.4 to address CVE
- 9.37.2 is vulnerable, 9.37.4 is the patched version for 9.x line
- Verified with mvn dependency:tree that override is applied
* Update pom.xml
* security: upgrade nimbus-jose-jwt to 10.0.2 to fix GHSA-xwmg-2g98-w7v9
- Update nimbus-jose-jwt from 9.37.4 to 10.0.2
- Fixes CVE: GHSA-xwmg-2g98-w7v9 (DoS via deeply nested JSON)
- 9.38.0 doesn't exist in Maven Central; 10.0.2 is the patched version
- Remove Jetty dependency management (12.0.12 doesn't exist)
- Verified with mvn -U clean verify that all dependencies resolve correctly
- Build succeeds with all security patches applied
* ci: add volume cleanup and verification steps
- Add 'docker compose down -v' before starting services to clean up stale volumes
- Prevents accumulation of data/buckets from previous test runs
- Add volume registration verification after service startup
- Check that volume server has registered with master and volumes are available
- Helps diagnose 'No writable volumes' errors
- Shows volume count and waits up to 30 seconds for volumes to be created
- Both spark-tests and spark-example jobs updated with same improvements
* ci: add volume.list diagnostic for troubleshooting 'No writable volumes'
- Add 'weed shell' execution to run 'volume.list' on failure
- Shows which volumes exist, their status, and available space
- Add cluster status JSON output for detailed topology view
- Helps diagnose volume allocation issues and full volumes
- Added to both spark-tests and spark-example jobs
- Diagnostic runs only when tests fail (if: failure())
* fix: force volume creation before tests to prevent 'No writable volumes' error
Root cause: With -max=0 (unlimited volumes), volumes are created on-demand,
but no volumes existed when tests started, causing first write to fail.
Solution:
- Explicitly trigger volume growth via /vol/grow API
- Create 3 volumes with replication=000 before running tests
- Verify volumes exist before proceeding
- Fail early with clear message if volumes can't be created
Changes:
- POST to http://localhost:9333/vol/grow?replication=000&count=3
- Wait up to 10 seconds for volumes to appear
- Show volume count and layout status
- Exit with error if no volumes after 10 attempts
- Applied to both spark-tests and spark-example jobs
This ensures writable volumes exist before Spark tries to write data.
* fix: use container hostname for volume server to enable automatic volume creation
Root cause identified:
- Volume server was using -ip=127.0.0.1
- Master couldn't reach volume server at 127.0.0.1 from its container
- When Spark requested assignment, master tried to create volume via gRPC
- Master's gRPC call to 127.0.0.1:18080 failed (reached itself, not volume server)
- Result: 'No writable volumes' error
Solution:
- Change volume server to use -ip=seaweedfs-volume (container hostname)
- Master can now reach volume server at seaweedfs-volume:18080
- Automatic volume creation works as designed
- Kept -publicUrl=127.0.0.1:8080 for external clients (host network)
Workflow changes:
- Remove forced volume creation (curl POST to /vol/grow)
- Volumes will be created automatically on first write request
- Keep diagnostic output for troubleshooting
- Simplified startup verification
This matches how other SeaweedFS tests work with Docker networking.
* fix: use localhost publicUrl and -max=100 for host-based Spark tests
The previous fix enabled master-to-volume communication but broke client writes.
Problem:
- Volume server uses -ip=seaweedfs-volume (Docker hostname)
- Master can reach it ✓
- Spark tests run on HOST (not in Docker container)
- Host can't resolve 'seaweedfs-volume' → UnknownHostException ✗
Solution:
- Keep -ip=seaweedfs-volume for master gRPC communication
- Change -publicUrl to 'localhost:8080' for host-based clients
- Change -max=0 to -max=100 (matches other integration tests)
Why -max=100:
- Pre-allocates volume capacity at startup
- Volumes ready immediately for writes
- Consistent with other test configurations
- More reliable than on-demand (-max=0)
This configuration allows:
- Master → Volume: seaweedfs-volume:18080 (Docker network)
- Clients → Volume: localhost:8080 (host network via port mapping)
* refactor: run Spark tests fully in Docker with bridge network
Better approach than mixing host and container networks.
Changes to docker-compose.yml:
- Remove 'network_mode: host' from spark-tests container
- Add spark-tests to seaweedfs-spark bridge network
- Update SEAWEEDFS_FILER_HOST from 'localhost' to 'seaweedfs-filer'
- Add depends_on to ensure services are healthy before tests
- Update volume publicUrl from 'localhost:8080' to 'seaweedfs-volume:8080'
Changes to workflow:
- Remove separate build and test steps
- Run tests via 'docker compose up spark-tests'
- Use --abort-on-container-exit and --exit-code-from for proper exit codes
- Simpler: one step instead of two
Benefits:
✓ All components use Docker DNS (seaweedfs-master, seaweedfs-volume, seaweedfs-filer)
✓ No host/container network split or DNS resolution issues
✓ Consistent with how other SeaweedFS integration tests work
✓ Tests are fully containerized and reproducible
✓ Volume server accessible via seaweedfs-volume:8080 for all clients
✓ Automatic volume creation works (master can reach volume via gRPC)
✓ Data writes work (Spark can reach volume via Docker network)
This matches the architecture of other integration tests and is cleaner.
* debug: add DNS verification and disable Java DNS caching
Troubleshooting 'seaweedfs-volume: Temporary failure in name resolution':
docker-compose.yml changes:
- Add MAVEN_OPTS to disable Java DNS caching (ttl=0)
Java caches DNS lookups which can cause stale results
- Add ping tests before mvn test to verify DNS resolution
Tests: ping -c 1 seaweedfs-volume && ping -c 1 seaweedfs-filer
- This will show if DNS works before tests run
workflow changes:
- List Docker networks before running tests
- Shows network configuration for debugging
- Helps verify spark-tests joins correct network
If ping succeeds but tests fail, it's a Java/Maven DNS issue.
If ping fails, it's a Docker networking configuration issue.
Note: Previous test failures may be from old code before Docker networking fix.
* fix: add file sync and cache settings to prevent EOF on read
Issue: Files written successfully but truncated when read back
Error: 'EOFException: Reached the end of stream. Still have: 78 bytes left'
Root cause: Potential race condition between write completion and read
- File metadata updated before all chunks fully flushed
- Spark immediately reads after write without ensuring sync
- Parquet reader gets incomplete file
Solutions applied:
1. Disable filesystem cache to avoid stale file handles
- spark.hadoop.fs.seaweedfs.impl.disable.cache=true
2. Enable explicit flush/sync on write (if supported by client)
- spark.hadoop.fs.seaweed.write.flush.sync=true
3. Add SPARK_SUBMIT_OPTS for cache disabling
These settings ensure:
- Files are fully flushed before close() returns
- No cached file handles with stale metadata
- Fresh reads always get current file state
Note: If issue persists, may need to add explicit delay between
write and read, or investigate seaweedfs-hadoop3-client flush behavior.
* fix: remove ping command not available in Maven container
The maven:3.9-eclipse-temurin-17 image doesn't include ping utility.
DNS resolution was already confirmed working in previous runs.
Remove diagnostic ping commands - not needed anymore.
* workaround: increase Spark task retries for eventual consistency
Issue: EOF exceptions when reading immediately after write
- Files appear truncated by ~78 bytes on first read
- SeaweedOutputStream.close() does wait for all chunks via Future.get()
- But distributed file systems can have eventual consistency delays
Workaround:
- Increase spark.task.maxFailures from default 1 to 4
- Allows Spark to automatically retry failed read tasks
- If file becomes consistent after 1-2 seconds, retry succeeds
This is a pragmatic solution for testing. The proper fix would be:
1. Ensure SeaweedOutputStream.close() waits for volume server acknowledgment
2. Or add explicit sync/flush mechanism in SeaweedFS client
3. Or investigate if metadata is updated before data is fully committed
For CI tests, automatic retries should mask the consistency delay.
* debug: enable detailed logging for SeaweedFS client file operations
Enable DEBUG logging for:
- SeaweedRead: Shows fileSize calculations from chunks
- SeaweedOutputStream: Shows write/flush/close operations
- SeaweedInputStream: Shows read operations and content length
This will reveal:
1. What file size is calculated from Entry chunks metadata
2. What actual chunk sizes are written
3. If there's a mismatch between metadata and actual data
4. Whether the '78 bytes' missing is consistent pattern
Looking for clues about the EOF exception root cause.
* debug: add detailed chunk size logging to diagnose EOF issue
Added INFO-level logging to track:
1. Every chunk write: offset, size, etag, target URL
2. Metadata update: total chunks count and calculated file size
3. File size calculation: breakdown of chunks size vs attr size
This will reveal:
- If chunks are being written with correct sizes
- If metadata file size matches sum of chunks
- If there's a mismatch causing the '78 bytes left' EOF
Example output expected:
✓ Wrote chunk to http://volume:8080/3,xxx at offset 0 size 1048576 bytes
✓ Wrote chunk to http://volume:8080/3,yyy at offset 1048576 size 524288 bytes
✓ Writing metadata with 2 chunks, total size: 1572864 bytes
Calculated file size: 1572864 (chunks: 1572864, attr: 0, #chunks: 2)
If we see size=X in write but size=X-78 in read, that's the smoking gun.
* fix: replace deprecated slf4j-log4j12 with slf4j-reload4j
Maven warning:
'The artifact org.slf4j:slf4j-log4j12:jar:1.7.36 has been relocated
to org.slf4j:slf4j-reload4j:jar:1.7.36'
slf4j-log4j12 was replaced by slf4j-reload4j due to log4j vulnerabilities.
The reload4j project is a fork of log4j 1.2.17 with security fixes.
This is a drop-in replacement with the same API.
* debug: add detailed buffer tracking to identify lost 78 bytes
Issue: Parquet expects 1338 bytes but SeaweedFS only has 1260 bytes (78 missing)
Added logging to track:
- Buffer position before every write
- Bytes submitted for write
- Whether buffer is skipped (position==0)
This will show if:
1. The last 78 bytes never entered the buffer (Parquet bug)
2. The buffer had 78 bytes but weren't written (flush bug)
3. The buffer was written but data was lost (volume server bug)
Next step: Force rebuild in CI to get these logs.
* debug: track position and buffer state at close time
Added logging to show:
1. totalPosition: Total bytes ever written to stream
2. buffer.position(): Bytes still in buffer before flush
3. finalPosition: Position after flush completes
This will reveal if:
- Parquet wrote 1338 bytes → position should be 1338
- Only 1260 bytes reached write() → position would be 1260
- 78 bytes stuck in buffer → buffer.position() would be 78
Expected output:
close: path=...parquet totalPosition=1338 buffer.position()=78
→ Shows 78 bytes in buffer need flushing
OR:
close: path=...parquet totalPosition=1260 buffer.position()=0
→ Shows Parquet never wrote the 78 bytes!
* fix: force Maven clean build to pick up updated Java client JARs
Issue: mvn test was using cached compiled classes
- Changed command from 'mvn test' to 'mvn clean test'
- Forces recompilation of test code
- Ensures updated seaweedfs-client JAR with new logging is used
This should now show the INFO logs:
- close: path=X totalPosition=Y buffer.position()=Z
- writeCurrentBufferToService: buffer.position()=X
- ✓ Wrote chunk to URL at offset X size Y bytes
* fix: force Maven update and verify JAR contains updated code
Added -U flag to mvn install to force dependency updates
Added verification step using javap to check compiled bytecode
This will show if the JAR actually contains the new logging code:
- If 'totalPosition' string is found → JAR is updated
- If not found → Something is wrong with the build
The verification output will help diagnose why INFO logs aren't showing.
* fix: use SNAPSHOT version to force Maven to use locally built JARs
ROOT CAUSE: Maven was downloading seaweedfs-client:3.80 from Maven Central
instead of using the locally built version in CI!
Changes:
- Changed all versions from 3.80 to 3.80.1-SNAPSHOT
- other/java/client/pom.xml: 3.80 → 3.80.1-SNAPSHOT
- other/java/hdfs2/pom.xml: property 3.80 → 3.80.1-SNAPSHOT
- other/java/hdfs3/pom.xml: property 3.80 → 3.80.1-SNAPSHOT
- test/java/spark/pom.xml: property 3.80 → 3.80.1-SNAPSHOT
Maven behavior:
- Release versions (3.80): Downloaded from remote repos if available
- SNAPSHOT versions: Prefer local builds, can be updated
This ensures the CI uses the locally built JARs with our debug logging!
Also added unique [DEBUG-2024] markers to verify in logs.
* fix: use explicit $HOME path for Maven mount and add verification
Issue: docker-compose was using ~ which may not expand correctly in CI
Changes:
1. docker-compose.yml: Changed ~/.m2 to ${HOME}/.m2
- Ensures proper path expansion in GitHub Actions
- $HOME is /home/runner in GitHub Actions runners
2. Added verification step in workflow:
- Lists all SNAPSHOT artifacts before tests
- Shows what's available in Maven local repo
- Will help diagnose if artifacts aren't being restored correctly
This should ensure the Maven container can access the locally built
3.80.1-SNAPSHOT JARs with our debug logging code.
* fix: copy Maven artifacts into workspace instead of mounting $HOME/.m2
Issue: Docker volume mount from $HOME/.m2 wasn't working in GitHub Actions
- Container couldn't access the locally built SNAPSHOT JARs
- Maven failed with 'Could not find artifact seaweedfs-hadoop3-client:3.80.1-SNAPSHOT'
Solution: Copy Maven repository into workspace
1. In CI: Copy ~/.m2/repository/com/seaweedfs to test/java/spark/.m2/repository/com/
2. docker-compose.yml: Mount ./.m2 (relative path in workspace)
3. .gitignore: Added .m2/ to ignore copied artifacts
Why this works:
- Workspace directory (.) is successfully mounted as /workspace
- ./.m2 is inside workspace, so it gets mounted too
- Container sees artifacts at /root/.m2/repository/com/seaweedfs/...
- Maven finds the 3.80.1-SNAPSHOT JARs with our debug logging!
Next run should finally show the [DEBUG-2024] logs! 🎯
* debug: add detailed verification for Maven artifact upload
The Maven artifacts are not appearing in the downloaded artifacts!
Only 'docker' directory is present, '.m2' is missing.
Added verification to show:
1. Does ~/.m2/repository/com/seaweedfs exist?
2. What files are being copied?
3. What SNAPSHOT artifacts are in the upload?
4. Full structure of artifacts/ before upload
This will reveal if:
- Maven install didn't work (artifacts not created)
- Copy command failed (wrong path)
- Upload excluded .m2 somehow (artifact filter issue)
The next run will show exactly where the Maven artifacts are lost!
* refactor: merge workflow jobs into single job
Benefits:
- Eliminates artifact upload/download complexity
- Maven artifacts stay in ~/.m2 throughout
- Simpler debugging (all logs in one place)
- Faster execution (no transfer overhead)
- More reliable (no artifact transfer failures)
Structure:
1. Build SeaweedFS binary + Java dependencies
2. Run Spark integration tests (Docker)
3. Run Spark example (host-based, push/dispatch only)
4. Upload results & diagnostics
Trade-off: Example runs sequentially after tests instead of parallel,
but overall runtime is likely faster without artifact transfers.
* debug: add critical diagnostics for EOFException (78 bytes missing)
The persistent EOFException shows Parquet expects 78 more bytes than exist.
This suggests a mismatch between what was written vs what's in chunks.
Added logging to track:
1. Buffer state at close (position before flush)
2. Stream position when flushing metadata
3. Chunk count vs file size in attributes
4. Explicit fileSize setting from stream position
Key hypothesis:
- Parquet writes N bytes total (e.g., 762)
- Stream.position tracks all writes
- But only (N-78) bytes end up in chunks
- This causes Parquet read to fail with 'Still have: 78 bytes left'
If buffer.position() = 78 at close, the buffer wasn't flushed.
If position != chunk total, write submission failed.
If attr.fileSize != position, metadata is inconsistent.
Next run will show which scenario is happening.
* debug: track stream lifecycle and total bytes written
Added comprehensive logging to identify why Parquet files fail with
'EOFException: Still have: 78 bytes left'.
Key additions:
1. SeaweedHadoopOutputStream constructor logging with 🔧 marker
- Shows when output streams are created
- Logs path, position, bufferSize, replication
2. totalBytesWritten counter in SeaweedOutputStream
- Tracks cumulative bytes written via write() calls
- Helps identify if Parquet wrote 762 bytes but only 684 reached chunks
3. Enhanced close() logging with 🔒 and ✅ markers
- Shows totalBytesWritten vs position vs buffer.position()
- If totalBytesWritten=762 but position=684, write submission failed
- If buffer.position()=78 at close, buffer wasn't flushed
Expected scenarios in next run:
A) Stream never created → No 🔧 log for .parquet files
B) Write failed → totalBytesWritten=762 but position=684
C) Buffer not flushed → buffer.position()=78 at close
D) All correct → totalBytesWritten=position=684, but Parquet expects 762
This will pinpoint whether the issue is in:
- Stream creation/lifecycle
- Write submission
- Buffer flushing
- Or Parquet's internal state
* debug: add getPos() method to track position queries
Added getPos() to SeaweedOutputStream to understand when and how
Hadoop/Parquet queries the output stream position.
Current mystery:
- Files are written correctly (totalBytesWritten=position=chunks)
- But Parquet expects 78 more bytes when reading
- year=2020: wrote 696, expects 774 (missing 78)
- year=2021: wrote 684, expects 762 (missing 78)
The consistent 78-byte discrepancy suggests either:
A) Parquet calculates row group size before finalizing footer
B) FSDataOutputStream tracks position differently than our stream
C) Footer is written with stale/incorrect metadata
D) File size is cached/stale during rename operation
getPos() logging will show if Parquet/Hadoop queries position
and what value is returned vs what was actually written.
* docs: comprehensive analysis of 78-byte EOFException
Documented all findings, hypotheses, and debugging approach.
Key insight: 78 bytes is likely the Parquet footer size.
The file has data pages (684 bytes) but missing footer (78 bytes).
Next run will show if getPos() reveals the cause.
* Revert "docs: comprehensive analysis of 78-byte EOFException"
This reverts commit
|
5 days ago |
Gophlet
|
e5d12d926b
|
Add explicit IP and binding parameters in Docker Compose (#7533)
fix(compose): correct command args to ensure proper IP binding |
5 days ago |
|
dependabot[bot]
|
ed6add9046
|
chore(deps): bump actions/upload-artifact from 4 to 5 (#7541)
Bumps [actions/upload-artifact](https://github.com/actions/upload-artifact) from 4 to 5. - [Release notes](https://github.com/actions/upload-artifact/releases) - [Commits](https://github.com/actions/upload-artifact/compare/v4...v5) --- updated-dependencies: - dependency-name: actions/upload-artifact dependency-version: '5' dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> |
5 days ago |
|
dependabot[bot]
|
0559e13f44
|
chore(deps): bump actions/setup-java from 4 to 5 (#7540)
Bumps [actions/setup-java](https://github.com/actions/setup-java) from 4 to 5. - [Release notes](https://github.com/actions/setup-java/releases) - [Commits](https://github.com/actions/setup-java/compare/v4...v5) --- updated-dependencies: - dependency-name: actions/setup-java dependency-version: '5' dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> |
5 days ago |
|
dependabot[bot]
|
0e6bee6c5b
|
chore(deps): bump actions/setup-python from 5 to 6 (#7539)
Bumps [actions/setup-python](https://github.com/actions/setup-python) from 5 to 6. - [Release notes](https://github.com/actions/setup-python/releases) - [Commits](https://github.com/actions/setup-python/compare/v5...v6) --- updated-dependencies: - dependency-name: actions/setup-python dependency-version: '6' dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> |
5 days ago |
|
dependabot[bot]
|
2dfa824cef
|
chore(deps): bump github.com/aws/aws-sdk-go-v2 from 1.39.5 to 1.40.0 (#7538)
Bumps [github.com/aws/aws-sdk-go-v2](https://github.com/aws/aws-sdk-go-v2) from 1.39.5 to 1.40.0. - [Release notes](https://github.com/aws/aws-sdk-go-v2/releases) - [Changelog](https://github.com/aws/aws-sdk-go-v2/blob/main/changelog-template.json) - [Commits](https://github.com/aws/aws-sdk-go-v2/compare/v1.39.5...v1.40.0) --- updated-dependencies: - dependency-name: github.com/aws/aws-sdk-go-v2 dependency-version: 1.40.0 dependency-type: direct:production update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> |
5 days ago |
|
dependabot[bot]
|
c4cf5553fa
|
chore(deps): bump github.com/ydb-platform/ydb-go-sdk/v3 from 3.113.5 to 3.118.2 (#7536)
chore(deps): bump github.com/ydb-platform/ydb-go-sdk/v3 Bumps [github.com/ydb-platform/ydb-go-sdk/v3](https://github.com/ydb-platform/ydb-go-sdk) from 3.113.5 to 3.118.2. - [Release notes](https://github.com/ydb-platform/ydb-go-sdk/releases) - [Changelog](https://github.com/ydb-platform/ydb-go-sdk/blob/master/CHANGELOG.md) - [Commits](https://github.com/ydb-platform/ydb-go-sdk/compare/v3.113.5...v3.118.2) --- updated-dependencies: - dependency-name: github.com/ydb-platform/ydb-go-sdk/v3 dependency-version: 3.118.2 dependency-type: direct:production update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> |
5 days ago |
|
dependabot[bot]
|
a3a19ac172
|
chore(deps): bump github.com/Azure/azure-sdk-for-go/sdk/azidentity from 1.13.0 to 1.13.1 (#7534)
chore(deps): bump github.com/Azure/azure-sdk-for-go/sdk/azidentity Bumps [github.com/Azure/azure-sdk-for-go/sdk/azidentity](https://github.com/Azure/azure-sdk-for-go) from 1.13.0 to 1.13.1. - [Release notes](https://github.com/Azure/azure-sdk-for-go/releases) - [Commits](https://github.com/Azure/azure-sdk-for-go/compare/sdk/azcore/v1.13.0...sdk/azidentity/v1.13.1) --- updated-dependencies: - dependency-name: github.com/Azure/azure-sdk-for-go/sdk/azidentity dependency-version: 1.13.1 dependency-type: direct:production update-type: version-update:semver-patch ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> |
5 days ago |
|
Lisandro Pin
|
c89f394aba
|
Parallelize `ec.rebuild` operations per affected volume. (#7466)
* Parallelize `ec.rebuild` operations per affected volume. * node.freeEcSlot >= slotsNeeded * variable names, help messages, * Protected the read operation with the same mutex * accurate error message * fix broken test --------- Co-authored-by: chrislu <chris.lu@gmail.com> Co-authored-by: Chris Lu <chrislusf@users.noreply.github.com> |
1 week ago |
|
Lisandro Pin
|
3dd5348616
|
`volume.check.disk`: add support for uni- or bi-directional sync between volume replicas. (#7484)
* `volume.check.disk`: add support for uni- or bi-directional sync between volume replicas. We'll need this to support repairing broken replicas, which involve syncing from a known good source replica without modifying it. * S3: Lazy Versioning Check, Conditional SSE Entry Fetch, HEAD Request Optimization (#7480) * Lazy Versioning Check, Conditional SSE Entry Fetch, HEAD Request Optimization * revert Reverted the conditional versioning check to always check versioning status Reverted the conditional SSE entry fetch to always fetch entry metadata Reverted the conditional versioning check to always check versioning status Reverted the conditional SSE entry fetch to always fetch entry metadata * Lazy Entry Fetch for SSE, Skip Conditional Header Check * SSE-KMS headers are present, this is not an SSE-C request (mutually exclusive) * SSE-C is mutually exclusive with SSE-S3 and SSE-KMS * refactor * Removed Premature Mutual Exclusivity Check * check for the presence of the X-Amz-Server-Side-Encryption header * not used * fmt * Volume Server: avoid aggressive volume assignment (#7501) * avoid aggressive volume assignment * also test ec shards * separate DiskLocation instances for each subtest * edge cases * No volumes plus low disk space * Multiple EC volumes * simplify * chore(deps): bump github.com/getsentry/sentry-go from 0.36.1 to 0.38.0 (#7498) Bumps [github.com/getsentry/sentry-go](https://github.com/getsentry/sentry-go) from 0.36.1 to 0.38.0. - [Release notes](https://github.com/getsentry/sentry-go/releases) - [Changelog](https://github.com/getsentry/sentry-go/blob/master/CHANGELOG.md) - [Commits](https://github.com/getsentry/sentry-go/compare/v0.36.1...v0.38.0) --- updated-dependencies: - dependency-name: github.com/getsentry/sentry-go dependency-version: 0.38.0 dependency-type: direct:production update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> * chore(deps): bump go.etcd.io/etcd/client/v3 from 3.6.5 to 3.6.6 (#7496) Bumps [go.etcd.io/etcd/client/v3](https://github.com/etcd-io/etcd) from 3.6.5 to 3.6.6. - [Release notes](https://github.com/etcd-io/etcd/releases) - [Commits](https://github.com/etcd-io/etcd/compare/v3.6.5...v3.6.6) --- updated-dependencies: - dependency-name: go.etcd.io/etcd/client/v3 dependency-version: 3.6.6 dependency-type: direct:production update-type: version-update:semver-patch ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> * chore(deps): bump github.com/hanwen/go-fuse/v2 from 2.8.0 to 2.9.0 (#7495) Bumps [github.com/hanwen/go-fuse/v2](https://github.com/hanwen/go-fuse) from 2.8.0 to 2.9.0. - [Commits](https://github.com/hanwen/go-fuse/compare/v2.8.0...v2.9.0) --- updated-dependencies: - dependency-name: github.com/hanwen/go-fuse/v2 dependency-version: 2.9.0 dependency-type: direct:production update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> * chore(deps): bump github.com/linxGnu/grocksdb from 1.10.2 to 1.10.3 (#7494) Bumps [github.com/linxGnu/grocksdb](https://github.com/linxGnu/grocksdb) from 1.10.2 to 1.10.3. - [Release notes](https://github.com/linxGnu/grocksdb/releases) - [Commits](https://github.com/linxGnu/grocksdb/compare/v1.10.2...v1.10.3) --- updated-dependencies: - dependency-name: github.com/linxGnu/grocksdb dependency-version: 1.10.3 dependency-type: direct:production update-type: version-update:semver-patch ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> * chore(deps): bump actions/dependency-review-action from 4.8.1 to 4.8.2 (#7493) Bumps [actions/dependency-review-action](https://github.com/actions/dependency-review-action) from 4.8.1 to 4.8.2. - [Release notes](https://github.com/actions/dependency-review-action/releases) - [Commits]( |
1 week ago |
|
Chris Lu
|
5f7a292334
|
add build info metrics (#7525)
* add build info metrics * unused * metrics on build * size limit * once |
1 week ago |
|
chrislu
|
a77dfb1ddd |
add debugging for InvalidAccessKeyId
|
1 week ago |
|
chrislu
|
03c9649583 |
read inside filer
|
1 week ago |
|
chrislu
|
99a9a67741 |
check errors
|
1 week ago |
|
Chris Lu
|
f125a013a8
|
S3: set identity to request context, and remove obsolete code (#7523)
* list owned buckets * simplify * add unit tests * no-owner buckets * set identity id * fallback to request header if iam is not enabled * refactor to test * fix comparing * fix security vulnerability * Update s3api_bucket_handlers.go * Update s3api_bucket_handlers.go * Update s3api_bucket_handlers.go * set identity to request context * remove SeaweedFSIsDirectoryKey * remove obsolete * simplify * reuse * refactor or remove obsolete logic on filer * Removed the redundant check in GetOrHeadHandler * surfacing invalid X-Amz-Tagging as a client error * clean up * constant * reuse * multiple header values * code reuse * err on duplicated tag key |
1 week ago |
|
Chris Lu
|
a9fefcd22c
|
S3: list owned buckets (#7519)
* list owned buckets * simplify * add unit tests * no-owner buckets * set identity id * fallback to request header if iam is not enabled * refactor to test * fix comparing * fix security vulnerability * Update s3api_bucket_handlers.go * Update s3api_bucket_handlers.go * Update s3api_bucket_handlers.go |
1 week ago |
|
Chris Lu
|
64dcbbb25b
|
test read write by s3fs and PyArrow native file system for s3 (#7520)
* test read write by s3fs and PyArrow native file system for s3 * address comments * add github action |
1 week ago |
|
Chris Lu
|
c1b8d4bf0d
|
S3: adds FilerClient to use cached volume id (#7518)
* adds FilerClient to use cached volume id
* refactor: MasterClient embeds vidMapClient to eliminate ~150 lines of duplication
- Create masterVolumeProvider that implements VolumeLocationProvider
- MasterClient now embeds vidMapClient instead of maintaining duplicate cache logic
- Removed duplicate methods: LookupVolumeIdsWithFallback, getStableVidMap, etc.
- MasterClient still receives real-time updates via KeepConnected streaming
- Updates call inherited addLocation/deleteLocation from vidMapClient
- Benefits: DRY principle, shared singleflight, cache chain logic reused
- Zero behavioral changes - only architectural improvement
* refactor: mount uses FilerClient for efficient volume location caching
- Add configurable vidMap cache size (default: 5 historical snapshots)
- Add FilerClientOption struct for clean configuration
* GrpcTimeout: default 5 seconds (prevents hanging requests)
* UrlPreference: PreferUrl or PreferPublicUrl
* CacheSize: number of historical vidMap snapshots (for volume moves)
- NewFilerClient uses option struct for better API extensibility
- Improved error handling in filerVolumeProvider.LookupVolumeIds:
* Distinguish genuine 'not found' from communication failures
* Log volumes missing from filer response
* Return proper error context with volume count
* Document that filer Locations lacks Error field (unlike master)
- FilerClient.GetLookupFileIdFunction() handles URL preference automatically
- Mount (WFS) creates FilerClient with appropriate options
- Benefits for weed mount:
* Singleflight: Deduplicates concurrent volume lookups
* Cache history: Old volume locations available briefly when volumes move
* Configurable cache depth: Tune for different deployment environments
* Battle-tested vidMap cache with cache chain
* Better concurrency handling with timeout protection
* Improved error visibility and debugging
- Old filer.LookupFn() kept for backward compatibility
- Performance improvement for mount operations with high concurrency
* fix: prevent vidMap swap race condition in LookupFileIdWithFallback
- Hold vidMapLock.RLock() during entire vm.LookupFileId() call
- Prevents resetVidMap() from swapping vidMap mid-operation
- Ensures atomic access to the current vidMap instance
- Added documentation warnings to getStableVidMap() about swap risks
- Enhanced withCurrentVidMap() documentation for clarity
This fixes a subtle race condition where:
1. Thread A: acquires lock, gets vm pointer, releases lock
2. Thread B: calls resetVidMap(), swaps vc.vidMap
3. Thread A: calls vm.LookupFileId() on old/stale vidMap
While the old vidMap remains valid (in cache chain), holding the lock
ensures we consistently use the current vidMap for the entire operation.
* fix: FilerClient supports multiple filer addresses for high availability
Critical fix: FilerClient now accepts []ServerAddress instead of single address
- Prevents mount failure when first filer is down (regression fix)
- Implements automatic failover to remaining filers
- Uses round-robin with atomic index tracking (same pattern as WFS.WithFilerClient)
- Retries all configured filers before giving up
- Updates successful filer index for future requests
Changes:
- NewFilerClient([]pb.ServerAddress, ...) instead of (pb.ServerAddress, ...)
- filerVolumeProvider references FilerClient for failover access
- LookupVolumeIds tries all filers with util.Retry pattern
- Mount passes all option.FilerAddresses for HA
- S3 wraps single filer in slice for API consistency
This restores the high availability that existed in the old implementation
where mount would automatically failover between configured filers.
* fix: restore leader change detection in KeepConnected stream loop
Critical fix: Leader change detection was accidentally removed from the streaming loop
- Master can announce leader changes during an active KeepConnected stream
- Without this check, client continues talking to non-leader until connection breaks
- This can lead to stale data or operational errors
The check needs to be in TWO places:
1. Initial response (lines 178-187): Detect redirect on first connect
2. Stream loop (lines 203-209): Detect leader changes during active stream
Restored the loop check that was accidentally removed during refactoring.
This ensures the client immediately reconnects to new leader when announced.
* improve: address code review findings on error handling and documentation
1. Master provider now preserves per-volume errors
- Surface detailed errors from master (e.g., misconfiguration, deletion)
- Return partial results with aggregated errors using errors.Join
- Callers can now distinguish specific volume failures from general errors
- Addresses issue of losing vidLoc.Error details
2. Document GetMaster initialization contract
- Add comprehensive documentation explaining blocking behavior
- Clarify that KeepConnectedToMaster must be started first
- Provide typical initialization pattern example
- Prevent confusing timeouts during warm-up
3. Document partial results API contract
- LookupVolumeIdsWithFallback explicitly documents partial results
- Clear examples of how to handle result + error combinations
- Helps prevent callers from discarding valid partial results
4. Add safeguards to legacy filer.LookupFn
- Add deprecation warning with migration guidance
- Implement simple 10,000 entry cache limit
- Log warning when limit reached
- Recommend wdclient.FilerClient for new code
- Prevents unbounded memory growth in long-running processes
These changes improve API clarity and operational safety while maintaining
backward compatibility.
* fix: handle partial results correctly in LookupVolumeIdsWithFallback callers
Two callers were discarding partial results by checking err before processing
the result map. While these are currently single-volume lookups (so partial
results aren't possible), the code was fragile and would break if we ever
batched multiple volumes together.
Changes:
- Check result map FIRST, then conditionally check error
- If volume is found in result, use it (ignore errors about other volumes)
- If volume is NOT found and err != nil, include error context with %w
- Add defensive comments explaining the pattern for future maintainers
This makes the code:
1. Correct for future batched lookups
2. More informative (preserves underlying error details)
3. Consistent with filer_grpc_server.go which already handles this correctly
Example: If looking up ["1", "2", "999"] and only 999 fails, callers
looking for volumes 1 or 2 will succeed instead of failing unnecessarily.
* improve: address remaining code review findings
1. Lazy initialize FilerClient in mount for proxy-only setups
- Only create FilerClient when VolumeServerAccess != "filerProxy"
- Avoids wasted work when all reads proxy through filer
- filerClient is nil for proxy mode, initialized for direct access
2. Fix inaccurate deprecation comment in filer.LookupFn
- Updated comment to reflect current behavior (10k bounded cache)
- Removed claim of "unbounded growth" after adding size limit
- Still directs new code to wdclient.FilerClient for better features
3. Audit all MasterClient usages for KeepConnectedToMaster
- Verified all production callers start KeepConnectedToMaster early
- Filer, Shell, Master, Broker, Benchmark, Admin all correct
- IAM creates MasterClient but never uses it (harmless)
- Test code doesn't need KeepConnectedToMaster (mocks)
All callers properly follow the initialization pattern documented in
GetMaster(), preventing unexpected blocking or timeouts.
* fix: restore observability instrumentation in MasterClient
During the refactoring, several important stats counters and logging
statements were accidentally removed from tryConnectToMaster. These are
critical for monitoring and debugging the health of master client connections.
Restored instrumentation:
1. stats.MasterClientConnectCounter("total") - tracks all connection attempts
2. stats.MasterClientConnectCounter(FailedToKeepConnected) - when KeepConnected stream fails
3. stats.MasterClientConnectCounter(FailedToReceive) - when Recv() fails in loop
4. stats.MasterClientConnectCounter(Failed) - when overall gprcErr occurs
5. stats.MasterClientConnectCounter(OnPeerUpdate) - when peer updates detected
Additionally restored peer update logging:
- "+ filer@host noticed group.type address" for node additions
- "- filer@host noticed group.type address" for node removals
- Only logs updates matching the client's FilerGroup for noise reduction
This information is valuable for:
- Monitoring cluster health and connection stability
- Debugging cluster membership changes
- Tracking master failover and reconnection patterns
- Identifying network issues between clients and masters
No functional changes - purely observability restoration.
* improve: implement gRPC-aware retry for FilerClient volume lookups
The previous implementation used util.Retry which only retries errors
containing the string "transport". This is insufficient for handling
the full range of transient gRPC errors.
Changes:
1. Added isRetryableGrpcError() to properly inspect gRPC status codes
- Retries: Unavailable, DeadlineExceeded, ResourceExhausted, Aborted
- Falls back to string matching for non-gRPC network errors
2. Replaced util.Retry with custom retry loop
- 3 attempts with exponential backoff (1s, 1.5s, 2.25s)
- Tries all N filers on each attempt (N*3 total attempts max)
- Fast-fails on non-retryable errors (NotFound, PermissionDenied, etc.)
3. Improved logging
- Shows both filer attempt (x/N) and retry attempt (y/3)
- Logs retry reason and wait time for debugging
Benefits:
- Better handling of transient gRPC failures (server restarts, load spikes)
- Faster failure for permanent errors (no wasted retries)
- More informative logs for troubleshooting
- Maintains existing HA failover across multiple filers
Example: If all 3 filers return Unavailable (server overload):
- Attempt 1: try all 3 filers, wait 1s
- Attempt 2: try all 3 filers, wait 1.5s
- Attempt 3: try all 3 filers, fail
Example: If filer returns NotFound (volume doesn't exist):
- Attempt 1: try all 3 filers, fast-fail (no retry)
* fmt
* improve: add circuit breaker to skip known-unhealthy filers
The previous implementation tried all filers on every failure, including
known-unhealthy ones. This wasted time retrying permanently down filers.
Problem scenario (3 filers, filer0 is down):
- Last successful: filer1 (saved as filerIndex=1)
- Next lookup when filer1 fails:
Retry 1: filer1(fail) → filer2(fail) → filer0(fail, wastes 5s timeout)
Retry 2: filer1(fail) → filer2(fail) → filer0(fail, wastes 5s timeout)
Retry 3: filer1(fail) → filer2(fail) → filer0(fail, wastes 5s timeout)
Total wasted: 15 seconds on known-bad filer!
Solution: Circuit breaker pattern
- Track consecutive failures per filer (atomic int32)
- Skip filers with 3+ consecutive failures
- Re-check unhealthy filers every 30 seconds
- Reset failure count on success
New behavior:
- filer0 fails 3 times → marked unhealthy
- Future lookups skip filer0 for 30 seconds
- After 30s, re-check filer0 (allows recovery)
- If filer0 succeeds, reset failure count to 0
Benefits:
1. Avoids wasting time on known-down filers
2. Still sticks to last healthy filer (via filerIndex)
3. Allows recovery (30s re-check window)
4. No configuration needed (automatic)
Implementation details:
- filerHealth struct tracks failureCount (atomic) + lastFailureTime
- shouldSkipUnhealthyFiler(): checks if we should skip this filer
- recordFilerSuccess(): resets failure count to 0
- recordFilerFailure(): increments count, updates timestamp
- Logs when skipping unhealthy filers (V(2) level)
Example with circuit breaker:
- filer0 down, saved filerIndex=1 (filer1 healthy)
- Lookup 1: filer1(ok) → Done (0.01s)
- Lookup 2: filer1(fail) → filer2(ok) → Done, save filerIndex=2 (0.01s)
- Lookup 3: filer2(fail) → skip filer0 (unhealthy) → filer1(ok) → Done (0.01s)
Much better than wasting 15s trying filer0 repeatedly!
* fix: OnPeerUpdate should only process updates for matching FilerGroup
Critical bug: The OnPeerUpdate callback was incorrectly moved outside the
FilerGroup check when restoring observability instrumentation. This caused
clients to process peer updates for ALL filer groups, not just their own.
Problem:
Before: mc.OnPeerUpdate only called for update.FilerGroup == mc.FilerGroup
Bug: mc.OnPeerUpdate called for ALL updates regardless of FilerGroup
Impact:
- Multi-tenant deployments with separate filer groups would see cross-group
updates (e.g., group A clients processing group B updates)
- Could cause incorrect cluster membership tracking
- OnPeerUpdate handlers (like Filer's DLM ring updates) would receive
irrelevant updates from other groups
Example scenario:
Cluster has two filer groups: "production" and "staging"
Production filer connects with FilerGroup="production"
Incorrect behavior (bug):
- Receives "staging" group updates
- Incorrectly adds staging filers to production DLM ring
- Cross-tenant data access issues
Correct behavior (fixed):
- Only receives "production" group updates
- Only adds production filers to production DLM ring
- Proper isolation between groups
Fix:
Moved mc.OnPeerUpdate(update, time.Now()) back INSIDE the FilerGroup check
where it belongs, matching the original implementation.
The logging and stats counter were already correctly scoped to matching
FilerGroup, so they remain inside the if block as intended.
* improve: clarify Aborted error handling in volume lookups
Added documentation and logging to address the concern that codes.Aborted
might not always be retryable in all contexts.
Context-specific justification for treating Aborted as retryable:
Volume location lookups (LookupVolume RPC) are simple, read-only operations:
- No transactions
- No write conflicts
- No application-level state changes
- Idempotent (safe to retry)
In this context, Aborted is most likely caused by:
- Filer restarting/recovering (transient)
- Connection interrupted mid-request (transient)
- Server-side resource cleanup (transient)
NOT caused by:
- Application-level conflicts (no writes)
- Transaction failures (no transactions)
- Logical errors (read-only lookup)
Changes:
1. Added detailed comment explaining the context-specific reasoning
2. Added V(1) logging when treating Aborted as retryable
- Helps detect misclassification if it occurs
- Visible in verbose logs for troubleshooting
3. Split switch statement for clarity (one case per line)
If future analysis shows Aborted should not be retried, operators will
now have visibility via logs to make that determination. The logging
provides evidence for future tuning decisions.
Alternative approaches considered but not implemented:
- Removing Aborted entirely (too conservative for read-only ops)
- Message content inspection (adds complexity, no known patterns yet)
- Different handling per RPC type (premature optimization)
* fix: IAM server must start KeepConnectedToMaster for masterClient usage
The IAM server creates and uses a MasterClient but never started
KeepConnectedToMaster, which could cause blocking if IAM config files
have chunks requiring volume lookups.
Problem flow:
NewIamApiServerWithStore()
→ creates masterClient
→ ❌ NEVER starts KeepConnectedToMaster
GetS3ApiConfigurationFromFiler()
→ filer.ReadEntry(iama.masterClient, ...)
→ StreamContent(masterClient, ...) if file has chunks
→ masterClient.GetLookupFileIdFunction()
→ GetMaster(ctx) ← BLOCKS indefinitely waiting for connection!
While IAM config files (identity & policies) are typically small and
stored inline without chunks, the code path exists and would block
if the files ever had chunks.
Fix:
Start KeepConnectedToMaster in background goroutine right after
creating masterClient, following the documented pattern:
mc := wdclient.NewMasterClient(...)
go mc.KeepConnectedToMaster(ctx)
This ensures masterClient is usable if ReadEntry ever needs to
stream chunked content from volume servers.
Note: This bug was dormant because IAM config files are small (<256 bytes)
and SeaweedFS stores small files inline in Entry.Content, not as chunks.
The bug would only manifest if:
- IAM config grew > 256 bytes (inline threshold)
- Config was stored as chunks on volume servers
- ReadEntry called StreamContent
- GetMaster blocked indefinitely
Now all 9 production MasterClient instances correctly follow the pattern.
* fix: data race on filerHealth.lastFailureTime in circuit breaker
The circuit breaker tracked lastFailureTime as time.Time, which was
written in recordFilerFailure and read in shouldSkipUnhealthyFiler
without synchronization, causing a data race.
Data race scenario:
Goroutine 1: recordFilerFailure(0)
health.lastFailureTime = time.Now() // ❌ unsynchronized write
Goroutine 2: shouldSkipUnhealthyFiler(0)
time.Since(health.lastFailureTime) // ❌ unsynchronized read
→ RACE DETECTED by -race detector
Fix:
Changed lastFailureTime from time.Time to int64 (lastFailureTimeNs)
storing Unix nanoseconds for atomic access:
Write side (recordFilerFailure):
atomic.StoreInt64(&health.lastFailureTimeNs, time.Now().UnixNano())
Read side (shouldSkipUnhealthyFiler):
lastFailureNs := atomic.LoadInt64(&health.lastFailureTimeNs)
if lastFailureNs == 0 { return false } // Never failed
lastFailureTime := time.Unix(0, lastFailureNs)
time.Since(lastFailureTime) > 30*time.Second
Benefits:
- Atomic reads/writes (no data race)
- Efficient (int64 is 8 bytes, always atomic on 64-bit systems)
- Zero value (0) naturally means "never failed"
- No mutex needed (lock-free circuit breaker)
Note: sync/atomic was already imported for failureCount, so no new
import needed.
* fix: create fresh timeout context for each filer retry attempt
The timeout context was created once at function start and reused across
all retry attempts, causing subsequent retries to run with progressively
shorter (or expired) deadlines.
Problem flow:
Line 244: timeoutCtx, cancel := context.WithTimeout(ctx, 5s)
defer cancel()
Retry 1, filer 0: client.LookupVolume(timeoutCtx, ...) ← 5s available ✅
Retry 1, filer 1: client.LookupVolume(timeoutCtx, ...) ← 3s left
Retry 1, filer 2: client.LookupVolume(timeoutCtx, ...) ← 0.5s left
Retry 2, filer 0: client.LookupVolume(timeoutCtx, ...) ← EXPIRED! ❌
Result: Retries always fail with DeadlineExceeded, defeating the purpose
of retries.
Fix:
Moved context.WithTimeout inside the per-filer loop, creating a fresh
timeout context for each attempt:
for x := 0; x < n; x++ {
timeoutCtx, cancel := context.WithTimeout(ctx, fc.grpcTimeout)
err := pb.WithGrpcFilerClient(..., func(client) {
resp, err := client.LookupVolume(timeoutCtx, ...)
...
})
cancel() // Clean up immediately after call
}
Benefits:
- Each filer attempt gets full fc.grpcTimeout (default 5s)
- Retries actually have time to complete
- No context leaks (cancel called after each attempt)
- More predictable timeout behavior
Example with fix:
Retry 1, filer 0: fresh 5s timeout ✅
Retry 1, filer 1: fresh 5s timeout ✅
Retry 2, filer 0: fresh 5s timeout ✅
Total max time: 3 retries × 3 filers × 5s = 45s (plus backoff)
Note: The outer ctx (from caller) still provides overall cancellation if
the caller cancels or times out the entire operation.
* fix: always reset vidMap cache on master reconnection
The previous refactoring removed the else block that resets vidMap when
the first message from a newly connected master is not a VolumeLocation.
Problem scenario:
1. Client connects to master-1 and builds vidMap cache
2. Master-1 fails, client connects to master-2
3. First message from master-2 is a ClusterNodeUpdate (not VolumeLocation)
4. Old code: vidMap is reset and updated ✅
5. New code: vidMap is NOT reset ❌
6. Result: Client uses stale cache from master-1 → data access errors
Example flow with bug:
Connect to master-2
First message: ClusterNodeUpdate {filer.x added}
→ No resetVidMap() call
→ vidMap still has master-1's stale volume locations
→ Client reads from wrong volume servers → 404 errors
Fix:
Restored the else block that resets vidMap when first message is not
a VolumeLocation:
if resp.VolumeLocation != nil {
// ... check leader, reset, and update ...
} else {
// First message is ClusterNodeUpdate or other type
// Must still reset to avoid stale data
mc.resetVidMap()
}
This ensures the cache is always cleared when establishing a new master
connection, regardless of what the first message type is.
Root cause:
During the vidMapClient refactoring, this else block was accidentally
dropped, making failover behavior fragile and non-deterministic (depends
on which message type arrives first from the new master).
Impact:
- High severity for master failover scenarios
- Could cause read failures, 404s, or wrong data access
- Only manifests when first message is not VolumeLocation
* fix: goroutine and connection leak in IAM server shutdown
The IAM server's KeepConnectedToMaster goroutine used context.Background(),
which is non-cancellable, causing the goroutine and its gRPC connections
to leak on server shutdown.
Problem:
go masterClient.KeepConnectedToMaster(context.Background())
- context.Background() never cancels
- KeepConnectedToMaster goroutine runs forever
- gRPC connection to master stays open
- No way to stop cleanly on server shutdown
Result: Resource leaks when IAM server is stopped
Fix:
1. Added shutdownContext and shutdownCancel to IamApiServer struct
2. Created cancellable context in NewIamApiServerWithStore:
shutdownCtx, shutdownCancel := context.WithCancel(context.Background())
3. Pass shutdownCtx to KeepConnectedToMaster:
go masterClient.KeepConnectedToMaster(shutdownCtx)
4. Added Shutdown() method to invoke cancel:
func (iama *IamApiServer) Shutdown() {
if iama.shutdownCancel != nil {
iama.shutdownCancel()
}
}
5. Stored masterClient reference on IamApiServer for future use
Benefits:
- Goroutine stops cleanly when Shutdown() is called
- gRPC connections are closed properly
- No resource leaks on server restart/stop
- Shutdown() is idempotent (safe to call multiple times)
Usage (for future graceful shutdown):
iamServer, _ := iamapi.NewIamApiServer(...)
defer iamServer.Shutdown()
// or in signal handler:
sigChan := make(chan os.Signal, 1)
signal.Notify(sigChan, syscall.SIGTERM, syscall.SIGINT)
go func() {
<-sigChan
iamServer.Shutdown()
os.Exit(0)
}()
Note: Current command implementations (weed/command/iam.go) don't have
shutdown paths yet, but this makes IAM server ready for proper lifecycle
management when that infrastructure is added.
* refactor: remove unnecessary KeepMasterClientConnected wrapper in filer
The Filer.KeepMasterClientConnected() method was an unnecessary wrapper that
just forwarded to MasterClient.KeepConnectedToMaster(). This wrapper added
no value and created inconsistency with other components that call
KeepConnectedToMaster directly.
Removed:
filer.go:178-180
func (fs *Filer) KeepMasterClientConnected(ctx context.Context) {
fs.MasterClient.KeepConnectedToMaster(ctx)
}
Updated caller:
filer_server.go:181
- go fs.filer.KeepMasterClientConnected(context.Background())
+ go fs.filer.MasterClient.KeepConnectedToMaster(context.Background())
Benefits:
- Consistent with other components (S3, IAM, Shell, Mount)
- Removes unnecessary indirection
- Clearer that KeepConnectedToMaster runs in background goroutine
- Follows the documented pattern from MasterClient.GetMaster()
Note: shell/commands.go was verified and already correctly starts
KeepConnectedToMaster in a background goroutine (shell_liner.go:51):
go commandEnv.MasterClient.KeepConnectedToMaster(ctx)
* fix: use client ID instead of timeout for gRPC signature parameter
The pb.WithGrpcFilerClient signature parameter is meant to be a client
identifier for logging and tracking (added as 'sw-client-id' gRPC metadata
in streaming mode), not a timeout value.
Problem:
timeoutMs := int32(fc.grpcTimeout.Milliseconds()) // 5000 (5 seconds)
err := pb.WithGrpcFilerClient(false, timeoutMs, filerAddress, ...)
- Passing timeout (5000ms) as signature/client ID
- Misuse of API: signature should be a unique client identifier
- Timeout is already handled by timeoutCtx passed to gRPC call
- Inconsistent with other callers (all use 0 or proper client ID)
How WithGrpcFilerClient uses signature parameter:
func WithGrpcClient(..., signature int32, ...) {
if streamingMode && signature != 0 {
md := metadata.New(map[string]string{"sw-client-id": fmt.Sprintf("%d", signature)})
ctx = metadata.NewOutgoingContext(ctx, md)
}
...
}
It's for client identification, not timeout control!
Fix:
1. Added clientId int32 field to FilerClient struct
2. Initialize with rand.Int31() in NewFilerClient for unique ID
3. Removed timeoutMs variable (and misleading comment)
4. Use fc.clientId in pb.WithGrpcFilerClient call
Before:
err := pb.WithGrpcFilerClient(false, timeoutMs, ...)
^^^^^^^^^ Wrong! (5000)
After:
err := pb.WithGrpcFilerClient(false, fc.clientId, ...)
^^^^^^^^^^^^ Correct! (random int31)
Benefits:
- Correct API usage (signature = client ID, not timeout)
- Timeout still works via timeoutCtx (unchanged)
- Consistent with other pb.WithGrpcFilerClient callers
- Enables proper client tracking on filer side via gRPC metadata
- Each FilerClient instance has unique ID for debugging
Examples of correct usage elsewhere:
weed/iamapi/iamapi_server.go:145 pb.WithGrpcFilerClient(false, 0, ...)
weed/command/s3.go:215 pb.WithGrpcFilerClient(false, 0, ...)
weed/shell/commands.go:110 pb.WithGrpcFilerClient(streamingMode, 0, ...)
All use 0 (or a proper signature), not a timeout value.
* fix: add timeout to master volume lookup to prevent indefinite blocking
The masterVolumeProvider.LookupVolumeIds method was using the context
directly without a timeout, which could cause it to block indefinitely
if the master is slow to respond or unreachable.
Problem:
err := pb.WithMasterClient(false, p.masterClient.GetMaster(ctx), ...)
resp, err := client.LookupVolume(ctx, &master_pb.LookupVolumeRequest{...})
- No timeout on gRPC call to master
- Could block indefinitely if master is unresponsive
- Inconsistent with FilerClient which uses 5s timeout
- This is a fallback path (cache miss) but still needs protection
Scenarios where this could hang:
1. Master server under heavy load (slow response)
2. Network issues between client and master
3. Master server hung or deadlocked
4. Master in process of shutting down
Fix:
timeoutCtx, cancel := context.WithTimeout(ctx, 5*time.Second)
defer cancel()
err := pb.WithMasterClient(false, p.masterClient.GetMaster(timeoutCtx), ...)
resp, err := client.LookupVolume(timeoutCtx, &master_pb.LookupVolumeRequest{...})
Benefits:
- Prevents indefinite blocking on master lookup
- Consistent with FilerClient timeout pattern (5 seconds)
- Faster failure detection when master is unresponsive
- Caller's context still honored (timeout is in addition, not replacement)
- Improves overall system resilience
Note: 5 seconds is a reasonable default for volume lookups:
- Long enough for normal master response (~10-50ms)
- Short enough to fail fast on issues
- Matches FilerClient's grpcTimeout default
* purge
* refactor: address code review feedback on comments and style
Fixed several code quality issues identified during review:
1. Corrected backoff algorithm description in filer_client.go:
- Changed "Exponential backoff" to "Multiplicative backoff with 1.5x factor"
- The formula waitTime * 3/2 produces 1s, 1.5s, 2.25s, not exponential 2^n
- More accurate terminology prevents confusion
2. Removed redundant nil check in vidmap_client.go:
- After the for loop, node is guaranteed to be non-nil
- Loop either returns early or assigns non-nil value to node
- Simplified: if node != nil { node.cache.Store(nil) } → node.cache.Store(nil)
3. Added startup logging to IAM server for consistency:
- Log when master client connection starts
- Matches pattern in S3ApiServer (line 100 in s3api_server.go)
- Improves operational visibility during startup
- Added missing glog import
4. Fixed indentation in filer/reader_at.go:
- Lines 76-91 had incorrect indentation (extra tab level)
- Line 93 also misaligned
- Now properly aligned with surrounding code
5. Updated deprecation comment to follow Go convention:
- Changed "DEPRECATED:" to "Deprecated:" (standard Go format)
- Tools like staticcheck and IDEs recognize the standard format
- Enables automated deprecation warnings in tooling
- Better developer experience
All changes are cosmetic and do not affect functionality.
* fmt
* refactor: make circuit breaker parameters configurable in FilerClient
The circuit breaker failure threshold (3) and reset timeout (30s) were
hardcoded, making it difficult to tune the client's behavior in different
deployment environments without modifying the code.
Problem:
func shouldSkipUnhealthyFiler(index int32) bool {
if failureCount < 3 { // Hardcoded threshold
return false
}
if time.Since(lastFailureTime) > 30*time.Second { // Hardcoded timeout
return false
}
}
Different environments have different needs:
- High-traffic production: may want lower threshold (2) for faster failover
- Development/testing: may want higher threshold (5) to tolerate flaky networks
- Low-latency services: may want shorter reset timeout (10s)
- Batch processing: may want longer reset timeout (60s)
Solution:
1. Added fields to FilerClientOption:
- FailureThreshold int32 (default: 3)
- ResetTimeout time.Duration (default: 30s)
2. Added fields to FilerClient:
- failureThreshold int32
- resetTimeout time.Duration
3. Applied defaults in NewFilerClient with option override:
failureThreshold := int32(3)
resetTimeout := 30 * time.Second
if opt.FailureThreshold > 0 {
failureThreshold = opt.FailureThreshold
}
if opt.ResetTimeout > 0 {
resetTimeout = opt.ResetTimeout
}
4. Updated shouldSkipUnhealthyFiler to use configurable values:
if failureCount < fc.failureThreshold { ... }
if time.Since(lastFailureTime) > fc.resetTimeout { ... }
Benefits:
✓ Tunable for different deployment environments
✓ Backward compatible (defaults match previous hardcoded values)
✓ No breaking changes to existing code
✓ Better maintainability and flexibility
Example usage:
// Aggressive failover for low-latency production
fc := wdclient.NewFilerClient(filers, dialOpt, dc, &wdclient.FilerClientOption{
FailureThreshold: 2,
ResetTimeout: 10 * time.Second,
})
// Tolerant of flaky networks in development
fc := wdclient.NewFilerClient(filers, dialOpt, dc, &wdclient.FilerClientOption{
FailureThreshold: 5,
ResetTimeout: 60 * time.Second,
})
* retry parameters
* refactor: make retry and timeout parameters configurable
Made retry logic and gRPC timeouts configurable across FilerClient and
MasterClient to support different deployment environments and network
conditions.
Problem 1: Hardcoded retry parameters in FilerClient
waitTime := time.Second // Fixed at 1s
maxRetries := 3 // Fixed at 3 attempts
waitTime = waitTime * 3 / 2 // Fixed 1.5x multiplier
Different environments have different needs:
- Unstable networks: may want more retries (5) with longer waits (2s)
- Low-latency production: may want fewer retries (2) with shorter waits (500ms)
- Batch processing: may want exponential backoff (2x) instead of 1.5x
Problem 2: Hardcoded gRPC timeout in MasterClient
timeoutCtx, cancel := context.WithTimeout(ctx, 5*time.Second)
Master lookups may need different timeouts:
- High-latency cross-region: may need 10s timeout
- Local network: may use 2s timeout for faster failure detection
Solution for FilerClient:
1. Added fields to FilerClientOption:
- MaxRetries int (default: 3)
- InitialRetryWait time.Duration (default: 1s)
- RetryBackoffFactor float64 (default: 1.5)
2. Added fields to FilerClient:
- maxRetries int
- initialRetryWait time.Duration
- retryBackoffFactor float64
3. Updated LookupVolumeIds to use configurable values:
waitTime := fc.initialRetryWait
maxRetries := fc.maxRetries
for retry := 0; retry < maxRetries; retry++ {
...
waitTime = time.Duration(float64(waitTime) * fc.retryBackoffFactor)
}
Solution for MasterClient:
1. Added grpcTimeout field to MasterClient (default: 5s)
2. Initialize in NewMasterClient with 5 * time.Second default
3. Updated masterVolumeProvider to use p.masterClient.grpcTimeout
Benefits:
✓ Tunable for different network conditions and deployment scenarios
✓ Backward compatible (defaults match previous hardcoded values)
✓ No breaking changes to existing code
✓ Consistent configuration pattern across FilerClient and MasterClient
Example usage:
// Fast-fail for low-latency production with stable network
fc := wdclient.NewFilerClient(filers, dialOpt, dc, &wdclient.FilerClientOption{
MaxRetries: 2,
InitialRetryWait: 500 * time.Millisecond,
RetryBackoffFactor: 2.0, // Exponential backoff
GrpcTimeout: 2 * time.Second,
})
// Patient retries for unstable network or batch processing
fc := wdclient.NewFilerClient(filers, dialOpt, dc, &wdclient.FilerClientOption{
MaxRetries: 5,
InitialRetryWait: 2 * time.Second,
RetryBackoffFactor: 1.5,
GrpcTimeout: 10 * time.Second,
})
Note: MasterClient timeout is currently set at construction time and not
user-configurable via NewMasterClient parameters. Future enhancement could
add a MasterClientOption struct similar to FilerClientOption.
* fix: rename vicCacheLock to vidCacheLock for consistency
Fixed typo in variable name for better code consistency and readability.
Problem:
vidCache := make(map[string]*filer_pb.Locations)
var vicCacheLock sync.RWMutex // Typo: vic instead of vid
vicCacheLock.RLock()
locations, found := vidCache[vid]
vicCacheLock.RUnlock()
The variable name 'vicCacheLock' is inconsistent with 'vidCache'.
Both should use 'vid' prefix (volume ID) not 'vic'.
Fix:
Renamed all 5 occurrences:
- var vicCacheLock → var vidCacheLock (line 56)
- vicCacheLock.RLock() → vidCacheLock.RLock() (line 62)
- vicCacheLock.RUnlock() → vidCacheLock.RUnlock() (line 64)
- vicCacheLock.Lock() → vidCacheLock.Lock() (line 81)
- vicCacheLock.Unlock() → vidCacheLock.Unlock() (line 91)
Benefits:
✓ Consistent variable naming convention
✓ Clearer intent (volume ID cache lock)
✓ Better code readability
✓ Easier code navigation
* fix: use defer cancel() with anonymous function for proper context cleanup
Fixed context cancellation to use defer pattern correctly in loop iteration.
Problem:
for x := 0; x < n; x++ {
timeoutCtx, cancel := context.WithTimeout(ctx, fc.grpcTimeout)
err := pb.WithGrpcFilerClient(...)
cancel() // Only called on normal return, not on panic
}
Issues with original approach:
1. If pb.WithGrpcFilerClient panics, cancel() is never called → context leak
2. If callback returns early (though unlikely here), cleanup might be missed
3. Not following Go best practices for context.WithTimeout usage
Problem with naive defer in loop:
for x := 0; x < n; x++ {
timeoutCtx, cancel := context.WithTimeout(ctx, fc.grpcTimeout)
defer cancel() // ❌ WRONG: All defers accumulate until function returns
}
In Go, defer executes when the surrounding *function* returns, not when
the loop iteration ends. This would accumulate n deferred cancel() calls
and leak contexts until LookupVolumeIds returns.
Solution: Wrap in anonymous function
for x := 0; x < n; x++ {
err := func() error {
timeoutCtx, cancel := context.WithTimeout(ctx, fc.grpcTimeout)
defer cancel() // ✅ Executes when anonymous function returns (per iteration)
return pb.WithGrpcFilerClient(...)
}()
}
Benefits:
✓ Context always cancelled, even on panic
✓ defer executes after each iteration (not accumulated)
✓ Follows Go best practices for context.WithTimeout
✓ No resource leaks during retry loop execution
✓ Cleaner error handling
Reference:
Go documentation for context.WithTimeout explicitly shows:
ctx, cancel := context.WithTimeout(...)
defer cancel()
This is the idiomatic pattern that should always be followed.
* Can't use defer directly in loop
* improve: add data center preference and URL shuffling for consistent performance
Added missing data center preference and load distribution (URL shuffling)
to ensure consistent performance and behavior across all code paths.
Problem 1: PreferPublicUrl path missing DC preference and shuffling
Location: weed/wdclient/filer_client.go lines 184-192
The custom PreferPublicUrl implementation was simply iterating through
locations and building URLs without considering:
1. Data center proximity (latency optimization)
2. Load distribution across volume servers
Before:
for _, loc := range locations {
url := loc.PublicUrl
if url == "" { url = loc.Url }
fullUrls = append(fullUrls, "http://"+url+"/"+fileId)
}
return fullUrls, nil
After:
var sameDcUrls, otherDcUrls []string
dataCenter := fc.GetDataCenter()
for _, loc := range locations {
url := loc.PublicUrl
if url == "" { url = loc.Url }
httpUrl := "http://" + url + "/" + fileId
if dataCenter != "" && dataCenter == loc.DataCenter {
sameDcUrls = append(sameDcUrls, httpUrl)
} else {
otherDcUrls = append(otherDcUrls, httpUrl)
}
}
rand.Shuffle(len(sameDcUrls), ...)
rand.Shuffle(len(otherDcUrls), ...)
fullUrls = append(sameDcUrls, otherDcUrls...)
Problem 2: Cache miss path missing URL shuffling
Location: weed/wdclient/vidmap_client.go lines 95-108
The cache miss path (fallback lookup) was missing URL shuffling, while
the cache hit path (vm.LookupFileId) already shuffles URLs. This
inconsistency meant:
- Cache hit: URLs shuffled → load distributed
- Cache miss: URLs not shuffled → first server always hit
Before:
var sameDcUrls, otherDcUrls []string
// ... build URLs ...
fullUrls = append(sameDcUrls, otherDcUrls...)
return fullUrls, nil
After:
var sameDcUrls, otherDcUrls []string
// ... build URLs ...
rand.Shuffle(len(sameDcUrls), ...)
rand.Shuffle(len(otherDcUrls), ...)
fullUrls = append(sameDcUrls, otherDcUrls...)
return fullUrls, nil
Benefits:
✓ Reduced latency by preferring same-DC volume servers
✓ Even load distribution across all volume servers
✓ Consistent behavior between cache hit/miss paths
✓ Consistent behavior between PreferUrl and PreferPublicUrl
✓ Matches behavior of existing vidMap.LookupFileId implementation
Impact on performance:
- Lower read latency (same-DC preference)
- Better volume server utilization (load spreading)
- No single volume server becomes a hotspot
Note: Added math/rand import to vidmap_client.go for shuffle support.
* Update weed/wdclient/masterclient.go
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
* improve: call IAM server Shutdown() for best-effort cleanup
Added call to iamApiServer.Shutdown() to ensure cleanup happens when possible,
and documented the limitations of the current approach.
Problem:
The Shutdown() method was defined in IamApiServer but never called anywhere,
meaning the KeepConnectedToMaster goroutine would continue running even when
the IAM server stopped, causing resource leaks.
Changes:
1. Store iamApiServer instance in weed/command/iam.go
- Changed: _, iamApiServer_err := iamapi.NewIamApiServer(...)
- To: iamApiServer, iamApiServer_err := iamapi.NewIamApiServer(...)
2. Added defer call for best-effort cleanup
- defer iamApiServer.Shutdown()
- This will execute if startIamServer() returns normally
3. Added logging in Shutdown() method
- Log when shutdown is triggered for visibility
4. Documented limitations and future improvements
- Added note that defer only works for normal function returns
- SeaweedFS commands don't currently have signal handling
- Suggested future enhancement: add SIGTERM/SIGINT handling
Current behavior:
- ✓ Cleanup happens if HTTP server fails to start (glog.Fatalf path)
- ✓ Cleanup happens if Serve() returns with error (unlikely)
- ✗ Cleanup does NOT happen on SIGTERM/SIGINT (process killed)
The last case is a limitation of the current command architecture - all
SeaweedFS commands (s3, filer, volume, master, iam) lack signal handling
for graceful shutdown. This is a systemic issue that affects all services.
Future enhancement:
To properly handle SIGTERM/SIGINT, the command layer would need:
sigChan := make(chan os.Signal, 1)
signal.Notify(sigChan, syscall.SIGTERM, syscall.SIGINT)
go func() {
httpServer.Serve(listener) // Non-blocking
}()
<-sigChan
glog.V(0).Infof("Received shutdown signal")
iamApiServer.Shutdown()
httpServer.Shutdown(context.Background())
This would require refactoring the command structure for all services,
which is out of scope for this change.
Benefits of current approach:
✓ Best-effort cleanup (better than nothing)
✓ Proper cleanup in error paths
✓ Documented for future improvement
✓ Consistent with how other SeaweedFS services handle lifecycle
* data racing in test
---------
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
|
1 week ago |
|
Chris Lu
|
5f77f87335
|
S3: S3 Object Retention API to include XML namespace support (#7517)
* Refactor S3 Object Retention API to include XML namespace support and improve compatibility with Veeam. Updated XML tags to remove hardcoded namespaces and added test cases for retention and legal hold configurations without namespaces. * Added XMLNS field setting in both places |
1 week ago |
|
Chris Lu
|
6281e62d7f
|
S3: JWT generation for volume server authentication (#7514)
* Refactor JWT generation for volume server authentication to use centralized function from filer package, improving code clarity and reducing redundancy. * Update s3api_object_handlers.go |
1 week ago |
|
dependabot[bot]
|
c14e513964
|
chore(deps): bump org.apache.hadoop:hadoop-common from 3.2.4 to 3.4.0 in /other/java/hdfs3 (#7512)
* chore(deps): bump org.apache.hadoop:hadoop-common in /other/java/hdfs3 Bumps org.apache.hadoop:hadoop-common from 3.2.4 to 3.4.0. --- updated-dependencies: - dependency-name: org.apache.hadoop:hadoop-common dependency-version: 3.4.0 dependency-type: direct:production ... Signed-off-by: dependabot[bot] <support@github.com> * add java client unit tests * Update dependency-reduced-pom.xml * add java integration tests * fix * fix buffer --------- Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: chrislu <chris.lu@gmail.com> |
1 week ago |
|
dependabot[bot]
|
7dce429e61
|
chore(deps): bump golang.org/x/crypto from 0.43.0 to 0.45.0 (#7511)
* chore(deps): bump golang.org/x/crypto from 0.43.0 to 0.45.0 Bumps [golang.org/x/crypto](https://github.com/golang/crypto) from 0.43.0 to 0.45.0. - [Commits](https://github.com/golang/crypto/compare/v0.43.0...v0.45.0) --- updated-dependencies: - dependency-name: golang.org/x/crypto dependency-version: 0.45.0 dependency-type: direct:production ... Signed-off-by: dependabot[bot] <support@github.com> * go mod tidy --------- Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: chrislu <chris.lu@gmail.com> |
1 week ago |
|
dependabot[bot]
|
4c07635a85
|
chore(deps): bump org.apache.hadoop:hadoop-common from 3.2.4 to 3.4.0 in /other/java/hdfs-over-ftp (#7513)
chore(deps): bump org.apache.hadoop:hadoop-common Bumps org.apache.hadoop:hadoop-common from 3.2.4 to 3.4.0. --- updated-dependencies: - dependency-name: org.apache.hadoop:hadoop-common dependency-version: 3.4.0 dependency-type: direct:production ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> |
1 week ago |