text:
data table header cursor type and title

Description

In the UI, when a user navigates to a screen that displays a table of data and hovers the mouse over a sortable column header, the cursor does not change to a hand pointer, indicating to the user that it can be clicked on, in order to sort the table's data rows according to that column.
When the mouse hovers over the non-sortable 'Quickview' column header, it incorrectly displays a hand pointer cursor instead of a default cursor.
When the mouse hovers over a column header, it also does not display the column header's value as a tooltip.

Expected Behaviour:
The cursor type for a sortable column header must display a hand pointer.
The cursor type for the non-sortable 'Quickview' column header must display a default pointer.
When the mouse hovers over a column header it must display the column header's value as a tooltip.
Actual Behaviour:
The cursor type for a sortable column header incorrectly displays a default pointer.
The cursor type for the non-sortable 'Quickview' column header incorrectly displays a hand pointer.
When the mouse hovers over a column header it does not display the column header's value as a tooltip.
To Reproduce:
In the UI, navigate to a screen that displays a table of data and hover the mouse over a sortable column header, the cursor does not change to a hand pointer.
Hover the mouse over the non-sortable 'Quickview' column header and notice that it incorrectly displays a hand pointer cursor instead of a default cursor.
Hover the mouse over a column header and notice that it does not display the column header's value as a tooltip.
Types of changes

[ ] Breaking change (fix or feature that would cause existing functionality to change)
[ ] New feature (non-breaking change which adds functionality)
[x] Bug fix (non-breaking change which fixes an issue)
[x] Enhancement (improves an existing feature and functionality)
[ ] Cleanup (Code refactoring and cleanup, that may add test cases)

GitHub Issue/PRs

Screenshots (if appropriate):

How Has This Been Tested?
Manually (See screenshot above)

In the UI, navigate to a screen that displays a table of data and hover the mouse over a sortable column header, the cursor now changes to a hand pointer, indicating that it is a sortable column.
Hover the mouse over the non-sortable 'Quickview' column header. It now correctly displays a default cursor, indicating that it is a non-sortable column.
Hover the mouse over a column header and notice that it now displays the column header's value as a tooltip.

Environment:
CloudStack version 4.11, KVM hypervisor.

Checklist:

[x] I have read the CONTRIBUTING document.
[x] My code follows the code style of this project.
[ ] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly.
Testing
[ ] I have added tests to cover my changes.
[ ] All relevant new and existing integration tests have passed.
[ ] A full integration testsuite with all test that can run on my environment has passed.

@nvazquez @borisstoyanov  @houthuis, please review

@blueorangutan package

@borisstoyanov a Jenkins job has been kicked to build packages. I'll keep you posted as I make progress.

Packaging result: ✔centos6 ✔centos7 ✔debian. JID-2229

source: gharchive/pull-request

authors: blueorangutan borisstoyanov ernjvr

repo: apache/cloudstack

license_type: permissive

license_source: github-api


text:
Improve VMWare logs

Description
This PR intends to improve VMWare logs, because the most part of classes with integration with VMWare hypervisor don't have enough logs to help troubleshooting. Also I refactor some duplicated code.
Types of changes

[ ] Breaking change (fix or feature that would cause existing functionality to change)
[ ] New feature (non-breaking change which adds functionality)
[ ] Bug fix (non-breaking change which fixes an issue)
[x] Enhancement (improves an existing feature and functionality)
[ ] Cleanup (Code refactoring and cleanup, that may add test cases)

Feature/Enhancement Scale

[ ] Major
[x] Minor

How Has This Been Tested?

It has been tested locally on a test lab.
I just read the logs: before, there wasn't much information about what was being done. Now, there is a little more information

@blueorangutan package

@nvazquez a Jenkins job has been kicked to build packages. I'll keep you posted as I make progress.

Packaging result: :heavy_check_mark: el7 :heavy_check_mark: el8 :heavy_check_mark: debian :heavy_check_mark: suse15. SL-JID 968

@blueorangutan test centos7 vmware-67u3

@nvazquez a Trillian-Jenkins test job (centos7 mgmt + vmware-67u3) has been kicked to run smoke tests

Hi @sureshanaparti, thanks for the review, I will change the PR to draft and apply the suggestions soon.

@SadiJr thanks for your work. I noticed many methods do not produce any log lines, I think it would be useful to include at least a debug level log line at the beginning of each method as the ones you have pasted above.

@nvazquez You are rigth. This was because the Command class is an abstract class. So I followed your recommendation and added a log at the beginning of each method. Thanks for the sugestion.

Thanks @SadiJr, let me know when it's ready for review

@blueorangutan package

@rhtyd a Jenkins job has been kicked to build packages. I'll keep you posted as I make progress.

Packaging result: :heavy_check_mark: el7 :heavy_check_mark: el8 :heavy_multiplication_x: debian :heavy_check_mark: suse15. SL-JID 1162

@sureshanaparti, @RodrigoDLopez thanks for the suggestions, but, creating a private method to log all commands will need to use the Command class as a parameter, which is an abstract class and don't log any information using Gson. To log information in this way, I will need to create a custom serializer/deserializer, which would imply making many changes, in addition to the risk of breaking something.
If you have any suggestions to solve this problem, I'll really appreciate.

@sureshanaparti, @RodrigoDLopez thanks for the suggestions, but, creating a private method to log all commands will need to use the Command class as a parameter, which is an abstract class and don't log any information using Gson. To log information in this way, I will need to create a custom serializer/deserializer, which would imply making many changes, in addition to the risk of breaking something.
If you have any suggestions to solve this problem, I'll really appreciate.

you can extract the code in a private method
    private void logCommand(Command cmd) {
        s_logger.debug(String.format(EXECUTING_RESOURCE_COMMAND, cmd.getClass().getSimpleName(), _gson.toJson(cmd)));
    }

and then reuse it where is appropriated
private GetVmVncTicketAnswer execute(GetVmVncTicketCommand cmd) {
        logCommand(cmd);
[...]
}

private Answer execute(ValidateVcenterDetailsCommand cmd) {
        logCommand(cmd);
[...]
}

private Answer execute(PrepareUnmanageVMInstanceCommand cmd) {
        logCommand(cmd);
[...]
}

the command class is here just to type, who will actually be executed are the classes that implement the parent class.
I ran some tests here. Apparently everything works correctly.
Executing resource command StartCommand: [{"vm":{"mockitoInterceptor":{"handler":{"invocationListeners":[],"mockHandler":{}},"mockCreationSettings":{"typeToMock":{},"extraInterfaces":[],"defaultAnswer":{},"mockName":{"mockName":"virtualMachineTO","defaultName":true},"serializableMode":"NONE","invocationListeners":[],"stubbingLookupListeners":[],"verificationStartedListeners":[],"stubOnly":false,"stripAnnotations":false,"useConstructor":false,"lenient":false},"serializationSupport":{"instanceLocalCurrentlySerializingFlag":false,"mutex":{"sync":{"state":0}}}},"id":0,"cpus":0,"minRam":0,"maxRam":0,"enableHA":false,"limitCpuUse":false,"enableDynamicallyScaleVm":false,"enterHardwareSetup":false},"executeInSequence":true,"wait":0,"bypassHostMaintenance":false}].

@SadiJr I did not understand your answer regarding the raised point by @RodrigoDLopez and @sureshanaparti.
@RodrigoDLopez seems to have already addressed a bit of the point with an approach that does pretty much what you are doing.
The fact that the input of a method is an abstract class (used there as an identifier so any of the commands that extend it would fit into it) does not mean that it would fail to parse the JSON. At least not in the context you are already parsing the objects.
If you are afraid of such an approach having objects that would not be parsed then it would be better to not parse into JSON at all and revert all your changes to log the Commands without Gson.

@sureshanaparti and @RodrigoDLopez:
1º - I apologize for the delay in replying;
2º - I have applied the suggestions and tested it, and at first everything is working fine. I appreciate the help.
@DaanHoogland and @GabrielBrascher:
Suggested changes made. Thanks for the review.

@blueorangutan package

@nvazquez a Jenkins job has been kicked to build packages. I'll keep you posted as I make progress.

Packaging result: :heavy_check_mark: el7 :heavy_check_mark: el8 :heavy_check_mark: debian :heavy_check_mark: suse15. SL-JID 1270

Packaging result: :heavy_check_mark: el7 :heavy_check_mark: el8 :heavy_check_mark: debian :heavy_check_mark: suse15. SL-JID 1271

@blueorangutan package

@rhtyd a Jenkins job has been kicked to build packages. I'll keep you posted as I make progress.

Packaging result: :heavy_check_mark: el7 :heavy_check_mark: el8 :heavy_check_mark: debian :heavy_multiplication_x: suse15. SL-JID 1283

@blueorangutan package

@sureshanaparti a Jenkins job has been kicked to build packages. I'll keep you posted as I make progress.

Packaging result: :heavy_check_mark: el7 :heavy_check_mark: el8 :heavy_check_mark: debian :heavy_check_mark: suse15. SL-JID 1292

@blueorangutan package

@sureshanaparti a Jenkins job has been kicked to build packages. I'll keep you posted as I make progress.

Packaging result: :heavy_check_mark: el7 :heavy_check_mark: el8 :heavy_check_mark: debian :heavy_check_mark: suse15. SL-JID 1317

@blueorangutan test centos7 vmware-67u3

@sureshanaparti a Trillian-Jenkins test job (centos7 mgmt + vmware-67u3) has been kicked to run smoke tests

@blueorangutan test centos7 vmware-67u3

@nvazquez a Trillian-Jenkins test job (centos7 mgmt + vmware-67u3) has been kicked to run smoke tests

Trillian test result (tid-2138)
Environment: vmware-67u3 (x2), Advanced Networking with Mgmt server 7
Total time taken: 40714 seconds
Marvin logs: https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr5353-t2138-vmware-67u3.zip
Smoke tests completed. 84 look OK, 5 have errors
Only failed tests results shown below:

Test
Result
Time (s)
Test File

test_01_snapshot_usage
Error
18.50
test_usage.py

test_01_template_usage
Error
17.73
test_usage.py

test_06_download_detached_volume
Error
193.67
test_volumes.py

test_01_snapshot_root_disk
Error
45.12
test_snapshots.py

test_02_list_snapshots_with_removed_data_store
Error
57.20
test_snapshots.py

ContextSuite context=TestListIdsParams>:setup
Error
0.00
test_list_ids_parameter.py

test_01_create_template
Error
6.20
test_templates.py

test_CreateTemplateWithDuplicateName
Error
6.19
test_templates.py

ContextSuite context=TestTemplates>:setup
Error
120.79
test_templates.py

Hi @SadiJr,  Can you check if any of the failed tests are related to this PR.

@blueorangutan test centos7 vmware-67u3

@sureshanaparti a Trillian-Jenkins test job (centos7 mgmt + vmware-67u3) has been kicked to run smoke tests

@blueorangutan package

Ping @SadiJr

Packaging result: :heavy_multiplication_x: el7 :heavy_multiplication_x: el8 :heavy_multiplication_x: debian :heavy_check_mark: suse15. SL-JID 1361

Trillian test result (tid-2162)
Environment: vmware-67u3 (x2), Advanced Networking with Mgmt server 7
Total time taken: 49632 seconds
Marvin logs: https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr5353-t2162-vmware-67u3.zip
Smoke tests completed. 81 look OK, 8 have errors
Only failed tests results shown below:

Test
Result
Time (s)
Test File

test_03_ping_in_ssvm_success
Failure
15.34
test_diagnostics.py

test_01_snapshot_usage
Error
58.33
test_usage.py

test_01_template_usage
Error
15.48
test_usage.py

ContextSuite context=TestIsolatedNetworks>:setup
Error
0.00
test_routers_network_ops.py

ContextSuite context=TestRedundantIsolateNetworks>:setup
Error
0.00
test_routers_network_ops.py

test_06_download_detached_volume
Error
194.68
test_volumes.py

test_04_extract_Iso
Failure
4.13
test_iso.py

test_01_snapshot_root_disk
Error
4.18
test_snapshots.py

test_02_list_snapshots_with_removed_data_store
Error
72.47
test_snapshots.py

ContextSuite context=TestListIdsParams>:setup
Error
0.00
test_list_ids_parameter.py

test_01_create_template
Error
8.24
test_templates.py

test_CreateTemplateWithDuplicateName
Error
8.27
test_templates.py

ContextSuite context=TestTemplates>:setup
Error
115.30
test_templates.py

@blueorangutan package

@nvazquez a Jenkins job has been kicked to build packages. I'll keep you posted as I make progress.

Packaging result: :heavy_check_mark: el7 :heavy_check_mark: el8 :heavy_check_mark: debian :heavy_check_mark: suse15. SL-JID 1368

@blueorangutan test centos7 vmware-67u3

@sureshanaparti a Trillian-Jenkins test job (centos7 mgmt + vmware-67u3) has been kicked to run smoke tests

Trillian test result (tid-2179)
Environment: vmware-67u3 (x2), Advanced Networking with Mgmt server 7
Total time taken: 42595 seconds
Marvin logs: https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr5353-t2179-vmware-67u3.zip
Smoke tests completed. 84 look OK, 5 have errors
Only failed tests results shown below:

Test
Result
Time (s)
Test File

test_01_snapshot_usage
Error
60.32
test_usage.py

test_01_template_usage
Error
15.47
test_usage.py

test_06_download_detached_volume
Error
194.62
test_volumes.py

test_01_snapshot_root_disk
Error
46.04
test_snapshots.py

test_02_list_snapshots_with_removed_data_store
Error
72.58
test_snapshots.py

ContextSuite context=TestListIdsParams>:setup
Error
0.00
test_list_ids_parameter.py

test_01_create_template
Error
12.32
test_templates.py

test_CreateTemplateWithDuplicateName
Error
6.23
test_templates.py

ContextSuite context=TestTemplates>:setup
Error
128.65
test_templates.py

@blueorangutan test centos7 vmware-65u3

@sureshanaparti unsupported parameters provided. Supported mgmt server os are: centos7, centos6, alma8, ubuntu18, suse15, ubuntu20, rocky8, centos8. Supported hypervisors are: kvm-centos6, kvm-centos7, kvm-centos8, kvm-rocky8, kvm-alma8, kvm-ubuntu18, kvm-ubuntu20, kvm-suse15, vmware-55u3, vmware-60u2, vmware-65u2, vmware-67u3, vmware-70u1, xenserver-65sp1, xenserver-71, xenserver-74, xcpng74, xcpng76, xcpng80, xcpng81, xcpng82

@blueorangutan test centos7 vmware-65u2

@sureshanaparti a Trillian-Jenkins test job (centos7 mgmt + vmware-65u2) has been kicked to run smoke tests

Trillian Build Failed (tid-2187)

ping @SadiJr Some test failures are consistent, can you check the failed tests.

@blueorangutan test centos7 vmware-65u2

@sureshanaparti a Trillian-Jenkins test job (centos7 mgmt + vmware-65u2) has been kicked to run smoke tests

@sureshanaparti, @rhtyd and @nvazquez
Sorry for the delay in replying, I'm checking this.

@blueorangutan package

@sureshanaparti a Jenkins job has been kicked to build packages. I'll keep you posted as I make progress.

Packaging result: :heavy_check_mark: el7 :heavy_check_mark: el8 :heavy_check_mark: debian :heavy_check_mark: suse15. SL-JID 1391

Trillian test result (tid-2197)
Environment: vmware-65u2 (x2), Advanced Networking with Mgmt server 7
Total time taken: 42944 seconds
Marvin logs: https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr5353-t2197-vmware-65u2.zip
Smoke tests completed. 84 look OK, 5 have errors
Only failed tests results shown below:

Test
Result
Time (s)
Test File

test_01_snapshot_usage
Error
19.64
test_usage.py

test_01_template_usage
Error
19.92
test_usage.py

test_06_download_detached_volume
Error
195.74
test_volumes.py

test_01_snapshot_root_disk
Error
45.54
test_snapshots.py

test_02_list_snapshots_with_removed_data_store
Error
76.91
test_snapshots.py

ContextSuite context=TestListIdsParams>:setup
Error
0.00
test_list_ids_parameter.py

test_01_create_template
Error
12.35
test_templates.py

test_CreateTemplateWithDuplicateName
Error
7.23
test_templates.py

ContextSuite context=TestTemplates>:setup
Error
130.22
test_templates.py

@blueorangutan package

@sureshanaparti a Jenkins job has been kicked to build packages. I'll keep you posted as I make progress.

Packaging result: :heavy_check_mark: el7 :heavy_check_mark: el8 :heavy_check_mark: debian :heavy_check_mark: suse15. SL-JID 1402

@blueorangutan test centos7 vmware-65u2

@nvazquez a Trillian-Jenkins test job (centos7 mgmt + vmware-65u2) has been kicked to run smoke tests

Hi @SadiJr Can you check if these failed tests are related to this PR.

@sureshanaparti Yes, I'll check, and mark this PR as Draft until I solve the broken tests.

@blueorangutan test centos7 vmware-65u2

@blueorangutan package

@sureshanaparti a Jenkins job has been kicked to build packages. I'll keep you posted as I make progress.

Packaging result: :heavy_check_mark: el7 :heavy_check_mark: el8 :heavy_check_mark: debian :heavy_check_mark: suse15. SL-JID 1487

@blueorangutan test centos7 vmware-67u3

@sureshanaparti a Trillian-Jenkins test job (centos7 mgmt + vmware-67u3) has been kicked to run smoke tests

Trillian test result (tid-2308)
Environment: vmware-67u3 (x2), Advanced Networking with Mgmt server 7
Total time taken: 39611 seconds
Marvin logs: https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr5353-t2308-vmware-67u3.zip
Smoke tests completed. 84 look OK, 7 have errors
Only failed tests results shown below:

Test
Result
Time (s)
Test File

test_01_vpc_site2site_vpn_multiple_options
Failure
368.98
test_vpc_vpn.py

test_06_download_detached_volume
Error
195.71
test_volumes.py

test_01_create_template
Error
13.52
test_templates.py

test_CreateTemplateWithDuplicateName
Error
8.30
test_templates.py

ContextSuite context=TestTemplates>:setup
Error
135.88
test_templates.py

test_01_snapshot_usage
Error
56.97
test_usage.py

test_01_template_usage
Error
7.30
test_usage.py

test_03_live_migrate_VM_with_two_data_disks
Error
61.72
test_vm_life_cycle.py

ContextSuite context=TestListIdsParams>:setup
Error
0.00
test_list_ids_parameter.py

test_01_snapshot_root_disk
Error
44.24
test_snapshots.py

test_02_list_snapshots_with_removed_data_store
Error
68.37
test_snapshots.py

@blueorangutan package

@sureshanaparti a Jenkins job has been kicked to build packages. I'll keep you posted as I make progress.

Packaging result: :heavy_check_mark: el7 :heavy_check_mark: el8 :heavy_check_mark: debian :heavy_check_mark: suse15. SL-JID 1514

@blueorangutan test centos7 vmware-67u3

@sureshanaparti a Trillian-Jenkins test job (centos7 mgmt + vmware-67u3) has been kicked to run smoke tests

@blueorangutan package

@rhtyd a Jenkins job has been kicked to build packages. I'll keep you posted as I make progress.

Packaging result: :heavy_multiplication_x: el7 :heavy_multiplication_x: el8 :heavy_multiplication_x: debian :heavy_multiplication_x: suse15. SL-JID 1772

@blueorangutan package

@nvazquez a Jenkins job has been kicked to build packages. I'll keep you posted as I make progress.

Packaging result: :heavy_multiplication_x: el7 :heavy_multiplication_x: el8 :heavy_multiplication_x: debian :heavy_multiplication_x: suse15. SL-JID 1773

@SadiJr StringUtils is imported in VmwareStorageManagerImpl but no longer used with your change. computer (checkstyle) says no.

@DaanHoogland thanks for the suggestion, and I apologize the delay in answer.

rekick travis (all test-runs failed)

@SadiJr this doesn't pass travis. can you have a look?

@DaanHoogland  Thank you for letting me know. Apparently, these failures are due to the lack of setuptools module in Travis. This PR (which you've already approved) solves this, so I'll wait for it to merge before proceeding.

Sorry @SadiJr , yes I didn't make that connection, hence didn't mention that. I has been merged now.

re-kick travis

@blueorangutan package

@blueorangutan package

@sureshanaparti a Jenkins job has been kicked to build packages. I'll keep you posted as I make progress.

Packaging result: :heavy_check_mark: el7 :heavy_check_mark: el8 :heavy_check_mark: debian :heavy_check_mark: suse15. SL-JID 1955

@SadiJr Is this PR good to go in 4.16.1 ? If so, please rebase with 4.16. Thanks.

@SadiJr Is this PR good to go in 4.16.1 ? If so, please rebase with 4.16. Thanks.

hi @SadiJr  can you confirm on this please. thanks.

@sureshanaparti Sorry for the delay in answer. For me, it is fine to go into main only.

OK, thanks for the confirmation @SadiJr

authors: DaanHoogland GabrielBrascher RodrigoDLopez SadiJr blueorangutan nvazquez rhtyd sureshanaparti


text:
Rollback TextStringBuidler#hashCode implementation to 1.8 release

The implementation that was done in the scope of the PR !281 introduced higher rate of garbage collections because of additional allocations of String object. So I returned the code to the logic it had in the 1.8 release.

@garydgregory Sorry, I cannot answer you on the mailing list as I haven't gotten your email (it seems due to some firewall settings). So I've created PR as you suggested.

Hi @pbelousov
Thank you for the PR.
Ah, I see...
After looking at OpenJDK's Arrays.hashCode(char[]) I flipped the loop traversal to start at 0.
Please review git master and close.

Thank you @garydgregory! That's perfectly fine for my use case!
Just one question - when could it be released in order for we could get it from Maven central repo?

You can get it from the Apache snapshot Maven repository, no release date planned yet.

Got it! Thank you again!

authors: garydgregory pbelousov

repo: apache/commons-text

license_source: bigquery


text:
CB-14252: Allow to send --silent arg to run command to disable output

What does this PR do?
Allows to hide console output when launch cordova run browser
Checklist

[x] Reported an issue in the JIRA database
[x] Commit message follows the format: "CB-3232: (android) Fix bug with resolving file paths", where CB-xxxx is the JIRA ID & "android" is the platform affected.
[ ] Added automated test coverage as appropriate for this change.

Does this option exist for other platforms?
Where would this have to be documented?

No, there isn't any similar option in other platforms, same for port and target options that already are in this platform.
Unfortunately I was not able found any documentation for cordova browser.

repo: apache/cordova-browser


text:
Only copy platform node_modules when created by binary

Platforms affected
Browser
What does this PR do?
When platform is installed though CLI, cordova platform add browser, the copy node_modules step is no longer valid as dependencies are now at the project level.
The step is required only when the create binary from the platform repo is called.
https://github.com/apache/cordova/issues/32
What testing has been done on this change?

npm t
https://travis-ci.org/erisu/cordova-browser/builds/452143904

More Investigation Required


text:
Throw structured errors instead of just messages

Feature Request
Motivation Behind Feature

If the plugin threw structured errors having an error code and an error message, developers could handle these errors without relying on magic strings representing the error message.
For instance, if the camera permission was not granted on Android devices, the error is currently only '20'. If it was { code: '20', message: 'Camera permission not granted' } instead, it would be more understandable and the error handler could differentiate based on the code.
Feature Description

I suggest passing a structured error object to the onError handle as described above. Furthermore, it would be great to export an enum with all the error codes like
export enum Error {
  NO_PERMISSION: '20',
  USER_CANCELED: '99',
  // ...
}

This would allow for handling errors like
navigator.camera.getPicture(
  () => { /* handle success */ },
  error => {
    switch(error.code) {
      case Error.NO_PERMISSION:
        // show a popup asking to grant the permission
      case Error.USER_CANCELED:
        // do nothing as the user chose to cancel the action
     ...
    }
  },
  cameraOptions,
);

This would break existing error handlers comparing with the message.
Alternatives or Workarounds

Currently, error handling is only possible via comparing the error string with magic strings (i.e. the actual messages).

I assume, this could be a general point for discussion. My gut feeling says that a lot of plugins will use string messages over real error objects.

I assume, this could be a general point for discussion. My gut feeling says that a lot of plugins will use string messages over real error objects.

While that might be true, it doesn't mean Apache Cordova shouldn't set a standard. I think it's a good idea to actually create instances of Error objects (or an extension of) when propagating errors.
e.g:
class CameraError extends Error {
    constructor(code, message) {
        super("Code: " + code + ": " + message);
        this.code = code;
    }
}

var x = new CameraError(15, 'test error');
x.message; // Code: 15: test error
x.code; // 15

will report to the console:
Error: Code: 15: test error
    at <anonymous>:1:9

I'm not sure how safe it is to use class style syntax without the use of Babel or some other transpiler... we may have to rely on the prototype syntax which I think does affect the call stack by including the the error constructor, but I think that is minor.
Extending Error has a couple of benefits, namely:

Ability to generically test for errors via x instanceof Error
We can also test for specific errors via x instanceof CameraError
We have the ability to attach additional details onto the error object such as the code property.
Ability to enforce consistency

export enum Error {

Enums is also good, I'm surprised this plugin is actually missing them. Other plugins like the cordova-plugin-file has them (although, our projects are not in typescript so they are just simply objects, but serve the same purpose). I would advise against clobbering Error though since that is a browser object.

While that might be true, it doesn't mean Apache Cordova shouldn't set a standard.

My comment was not clear enough - I meant our Apache Cordova core plugins. Therefore I was thinking to move this issue to https://github.com/apache/cordova or https://github.com/apache/cordova-discuss for a more general solution.

My comment was not clear enough - I meant our Apache Cordova core plugins. Therefore I was thinking to move this issue to https://github.com/apache/cordova or https://github.com/apache/cordova-discuss for a more general solution.

Ah yes, I definitely misunderstood - my apologies. This definitely sounds like a good idea.

source: gharchive/issue

authors: breautek timbru31 tobiaswaltl

repo: apache/cordova-plugin-camera


text:
Not able to fetch newly added contacts and contact last updated timestamp

Bug Report
After sync the contact to server. If i add a new contact in phone.not able to find it. Do we have any solution to find the newly add contact or last updated timestamp?

We are archiving this repository following Apache Cordova's Deprecation Policy. We will not continue to work on this repository. Therefore all issues and pull requests are being closed. Thanks for your contribution.

repo: apache/cordova-plugin-contacts


text:
Use vswhere for better Visual Studio and MSBuildTools detection

Microsoft added vswhere to the default install of Visual Studio 2017:
https://github.com/Microsoft/vswhere
https://github.com/Microsoft/vswhere/wiki/Find-MSBuild
https://docs.microsoft.com/en-us/visualstudio/install/tools-for-managing-visual-studio-instances
https://blogs.msdn.microsoft.com/heaths/2017/04/21/vswhere-is-now-installed-with-visual-studio-2017/
We already use it in appveyor.yml to debug output these paths for the CI environment. It would be handy to also use this simple command in MSBuildTools.js and similar code instead of what is currently there (which is really confusing and party bad).

We are archiving this repository following Apache Cordova's Deprecation Policy. We will not continue to work on this repository. Therefore all issues and pull requests are being closed. Thanks for your contribution.

repo: apache/cordova-windows


text:
Allow limiting maximum document body size

Configuration is via the couchdb.max_document_size. In the past that
was implemented as a maximum http request body size and this finally implements
it by actually checking a document's body size.
COUCHDB-2992

@sagelywizard I added a validating version of the function. The other code like cleanup_index_files can still call the old function and not crash on size limit change.

Related pr:

https://github.com/apache/couchdb-fabric/pull/91

https://github.com/apache/couchdb-chttpd/pull/157

@sagelywizard should be a bit better now. But ended up with another pr for fabric as well.

repo: apache/couchdb-couch


text:
Closed longpoll/continuous _changes client connections kept alive on server

Description
We are having memory issues on our cluster. We have tracked it down to replication requests that have a huge amount of (binary) memory open during the crash. This replication is also handling attachments, so that explains why any one of those requests takes more memory.
When looking at prometheus data we saw that couchdb_httpd_clients_requesting_changes_total keeps rising:

(here you see two crashes of couchdb06)
We know that we might need to investigate why the changes feed is queried this often, but that is made more difficult with this bug present.
This led us to test simple _changes requests with longpoll and high timeouts and see that the prometheus data was indeed showing that the connections are kept open (or at least the erlang process is kept alive).
Steps to Reproduce

Look at http://localhost:5984/_node/_local/_prometheus
See that couchdb_httpd_clients_requesting_changes_total is 0
Start a request to a local database with something like this: http://localhost:5984/db/_changes?feed=longpoll&timeout=200000&since=now
Stop and start that request a couple of times in quick succession
(optional)check with netstat that the connections are actually closed
Refresh the prometheus page and see the couchdb_httpd_clients_requesting_changes_total rising and only falling after the timeout is over

Expected Behaviour
The value for couchdb_httpd_clients_requesting_changes_total should be falling immediately at connection termination.
Your Environment

CouchDB version used: 3.3.1
Browser name and version: N/A
Operating system and version: both Windows and Linux have this issue

Thank you for your report @jlami.
With http://localhost:5984/db/_changes?feed=longpoll&timeout=200000&since=now or continuous the client probably stops during the HTTP protocol phase when the client is waiting on the server to respond. If the client disappears, the server won't find out about the connection state until it tries to respond to the client.
Since there is a timeout,  at the end of the timeout interval is when the server will try to send a response and find out the client has closed the connection.  In this case the timeout is not 200000 but actually 60000. The timeout value is the minimum value between the parameter for the request and the the changes_timeout setting as per https://github.com/apache/couchdb/blob/4b8b7ec9f39d1e5910f301283fd6b9051b057d0c/src/couch/src/couch_changes.erl#L400-L401 So the connection will be torn down after 60 seconds.
So one way to shorted the time until the connection is cleared is to lower that timeout either in the request parameter or the config setting.
Another option is to use a heartbeat.
/_changes'?feed=longpoll&heartbeat=5000&since=now'

This will ping the connection every 5 second and send a newline. If the client dropped the request, the newline send should detect the connection shutdown and clean up the connection resources on the server.

Thanks for the reply @nickva
I think the heartbeat might be a good addition/change to our setup to try and hasten the detection. That hopefully helps the application side.
The other thing is that this might also happen because of continuous replication from couchdb servers. I don't think they have the option to enable heartbeats in the _replicate and _replicator endpoints. Or is there a way to set this up?
Is it not possible to detect a disconnect on the erlang side? I cannot really find where the connection is setup in the erlang source, but can't the process that handles the reading of the request also try and detect tcp_closed for a socket? I know this will only detect 'clean' connection closing (FIN packets). But it would at least be something.

For replication it's possible to adjust connection_timeout setting. That setting value, divided by 3, ends up being sent as the _changes feed timeout connection parameter. So if that's 30000 msec, it will use ...&timeout=10000 in the request. Shortening that could help a bit perhaps. In the normal operation, when the feed is waiting on db changes, the effect will be that absent any changes, the _changes feed request will end and restart every timeout milliseconds.
An apparent, improvement could be to improve couch replicator to use both a heartbeat and a timeout.  It turns out both are not really compatible, and the presence of a heartbeat overrides the timeout parameter, so the larger improvement would be to fix that actually, to allow both to work.

Is it not possible to detect a disconnect on the erlang side? I cannot really find where the connection is setup in the erlang source, but can't the process that handles the reading of the request also try and detect tcp_closed for a socket? I know this will only detect 'clean' connection closing (FIN packets). But it would at least be something.

That might be possible. It would be something in the HTTP layer mochiweb library we're using, I think. But it would be an extra periodic check or something of that sort to monitor for TCP shutdown or disconnect messages even when we're expecting  server to respond (we're not actually waiting in a socket receive).  That logic might go somewhere in here: https://github.com/mochi/mochiweb/blob/83fd22d620bbefd8779ccb6ea21706bb8a1e0ed2/src/mochiweb_http.erl#L139-L140

For replication it's possible to adjust connection_timeout setting. That setting value, divided by 3, ends up being sent as the _changes feed timeout connection parameter. So if that's 30000 msec, it will use ...&timeout=10000 in the request. Shortening that could help a bit perhaps. In the normal operation, when the feed is waiting on db changes, the effect will be that absent any changes, the _changes feed request will end and restart every timeout milliseconds.

Unfurtunately our replication needs quite hight timeouts or it will timeout during normal operations.

An apparent, improvement could be to improve couch replicator to use both a heartbeat and a timeout. It turns out both are not really compatible, and the presence of a heartbeat overrides the timeout parameter, so the larger improvement would be to fix that actually, to allow both to work.

This might indeed be nice. Heartbeat now overrides the timeout, but they might be good to work together.
But I'm correct in inferring that the replicate does not support heartbeat at this moment right?

That might be possible. It would be something in the HTTP layer mochiweb library we're using, I think. But it would be an extra periodic check or something of that sort to monitor for TCP shutdown or disconnect messages even when we're expecting server to respond (we're not actually waiting in a socket receive). That logic might go somewhere in here: https://github.com/mochi/mochiweb/blob/83fd22d620bbefd8779ccb6ea21706bb8a1e0ed2/src/mochiweb_http.erl#L139-L140

Thanks, I was just looking at mochiweb. I'll see if I can get a feature request/issue for the tcp_closed during handling of the request body.

But I'm correct in inferring that the replicate does not support heartbeat at this moment right?

Yeah, that's correct. It uses timeouts only. So it periodically ends the continuous requests if there are not changes and restarts it.

I'll see if I can get a feature request/issue for the tcp_closed during handling of the request body.

Mochiweb is a separate project and Apache CouchDB at least in the case of long running requests is sort of abusing the typical HTTP API request pattern. User makes a request, and the callback instead of responding right away, and thus detecting a closed socket and crashing, hangs for minutes at a time. In other words, it won't be surprising if they don't want to accept this feature request.

Thanks for the feedback.

Mochiweb is a separate project and Apache CouchDB at least in the case of long running requests is sort of abusing the typical HTTP API request pattern.

Would that mean that a fix would be more fitting in CouchDB? Don't mean to push the issue onto CouchDB just thinking about what would be best.
Semi new issue
Since we started investigating our memory issues and we found this issue, we also see that the inflated changes metric might not only be due to the timeouts. Or at least there is something else fishy going on. I don't know if you want me to open a separate issue for that, but I think it fits here.
Looking at the following graph you can see 2 things:

Orange is the changes metric
Green is the amount of sockets reported as allocated minus the sockets in use according to /proc/net/sockstat

The drops in the lines to 0 are restarts of couchdb because of memory issues.
The first graph is of a time with extra replication going on, so inflated changes listeners. The second is with mainly external pouch listeners.
When looking at the first image and an erlang dump from around 14:00 I could see that the changes processes where taking a lot of memory and as such found the original issue. But if this was the only problem we would expect the counts of the changes to eventually drop at lower traffic times. And we never see that. Even if you look at the night time, when there are far fewer requests coming in. It seems that the timeouts are never triggered and CouchDB is hanging somewhere else.
There are some half drops in the changes and sockets around 10:00 in the first and 18:00 and 10:00 in the second image. At that time another node was restarted. So it seems that a bunch of the lingering changes requests are inter-node based.
Another thing I can see is that there seems to be a 10 minute delay between the two graphs, exactly the timeout of our chttpd.changes_timeout config value. But the pouch clients request timeouts of 2 minutes.
I'm going to see if I can get a sense of which processes are in what call graph at the time of such high changes metric and lingering sockets. But maybe you could help me what else I could be looking into?
And one thing you might be able to answer: is it normal to see this many unused sockets? We do have many clients with bad network connections, so that might be causing network issues. But I would expect CouchDB to be able to handle this.

Would that mean that a fix would be more fitting in CouchDB? Don't mean to push the issue onto CouchDB just thinking about what would be best.

Yeah I think so. I tried various options and played with sockets a bit and it seems, unless the socket mode is toggled from passive/active or we try to send something on it, we might not find out it's closed. Getting its info or stats doesn't seem to indicate it's closed even.
The new experimental socket network implementation may have something there but I haven't tried it yet: https://www.erlang.org/doc/man/socket.html
One obvious improvement though could be to combine heartbeats and timeouts. So even with a timeout set we still send periodic heartbeats, even if it's just to be able to detect a closed socket.

I was also experimenting a bit and I could get it to work with something like this in chttpd:handle_changes_req1
        Feed when Feed =:= "continuous"; Feed =:= "longpoll"; Feed =:= "eventsource" ->
        	OldControlling = self(),
        	MochiReq = Req#httpd.mochi_req,
        	Socket = MochiReq:get(socket),
        	couch_log:info("----- socket1 ~p -----", [Socket]),
        	SocketMonitorPid = spawn_link(fun() ->
        		couch_log:info("----- socket2 ~p -----", [Socket]),
        		receive ack -> ok end,
        		inet:setopts(Socket, [{active, once}]),
        		receive
        			ack ->
        				couch_log:info("----- stopping monitor -----", []),
        				inet:setopts(Socket, [{active, false}]),
        				gen_tcp:controlling_process(Socket, OldControlling),
        				OldControlling ! ack;
        			{tcp, _} ->
        				couch_log:info("----- data -----", []),
        				couch_stats:decrement_counter([couchdb, httpd, clients_requesting_changes]),
        				exit(self(), {unexpected_data});
        			{tcp_closed, _} ->
        				couch_log:info("----- closed -----", []),
        				couch_stats:decrement_counter([couchdb, httpd, clients_requesting_changes]),
        				error(tcp_closed_error)
        		end
        	end),
        	couch_log:info("----- spawn ~p -----", [SocketMonitorPid]),
        	gen_tcp:controlling_process(Socket, SocketMonitorPid),
        	SocketMonitorPid ! ack,
            couch_stats:increment_counter([couchdb, httpd, clients_requesting_changes]),
            Acc0 = #cacc{
                feed = list_to_atom(Feed),
                mochi = Req,
                threshold = Max
            },
            try
                fabric:changes(Db, fun changes_callback/2, Acc0, ChangesArgs)
            after
            	SocketMonitorPid ! ack,
            	couch_log:info("----- done with changes -----", []),
            	receive ack-> ok end,
            	couch_log:info("----- socket back -----", []),
                couch_stats:decrement_counter([couchdb, httpd, clients_requesting_changes])
            end;

But I'm new at erlang so there might be something easier to read from the socket in parallel. And this also might have a race condition when the socket is done and should get more data, but I think that is not legal for change feeds, but maybe it is for Keep-Alive sockets.

Making sure streaming requests processes exit when connections close fix was deployed to 3.3.3: https://github.com/apache/couchdb/pull/4736
This should prevent connections from piling up.

authors: jlami nickva

repo: apache/couchdb


text:
no match of right hand value {error,enospc}

Description
I've set up a fresh CouchDB 3.4.1 instance (as Docker image, build from https://github.com/apache/couchdb-docker/tree/main/3.4.1)
Then I've started a replication from prod.-server and saw endless messages of "no match of right hand value {error,enospc}"
Here a (truncated) copy of the docker log:
couchdb.tar.gz
Your Environment

CouchDB version used:
version: 3.4.1

    "git_sha": "f504e38a5",
    "features": [
        "nouveau",
        "access-ready",
        "partitioned",
        "pluggable-storage-engines",
        "reshard",
        "scheduler"
    ]

Operating system and version:
Fedora Linux 40 (KDE Plasma) and
Ubuntu Server 24
(Both running the same docker image and report the same error)

Additional Context
Docker Engine
 Version:    27.3.1
 Debug Mode: false
 Plugins:
  buildx: Docker Buildx (Docker Inc.)
    Version:  v0.16.2-desktop.1
  compose: Docker Compose (Docker Inc.)
    Version:  v2.29.2-desktop.2
  desktop: Docker Desktop commands (Alpha) (Docker Inc.)
    Version:  v0.0.15

I've talked a bit with Jan at slack, his first thoughts:
https://app.slack.com/client/T49P1AZRT/C49LEE7NW

It stands out, that it happens just in indexing/view building phase.

Can't write content into data (just touch file works)

That would explain it, I think. Good find. It's sneaky that touch works though.

Just for curiosity, I stopped the container, rm & created couchdb-data and started the replication again:
same result...
[notice] 2024-09-30T16:14:19.553744Z nonode@nohost <0.14636.101> -------- Retrying POST request to http://localhost:5984/hzd/_bulk_docs in 4.0 seconds due to error {code,500}
[error] 2024-09-30T16:14:19.574327Z nonode@nohost <0.16657.101> d5dfe20e02 rexi_server: from: nonode@nohost(<0.19120.101>) mfa: fabric_rpc:update_docs/3 exit:{{badmatch,{error,enospc}},[{couch_bt_engine,write_doc_body,2,[{file,"src/couch_bt_engine.erl"},{line,439}]},{couch_db_updater,'-flush_trees/3-fun-0-',6,[{file,"src/couch_db_updater.erl"},{line,384}]},{couch_key_tree,mapfold_simple,4,[{file,"src/couch_key_tree.erl"},{line,464}]},{couch_key_tree,mapfold_simple,4,[{file,"src/couch_key_tree.erl"},{line,473}]},{couch_key_tree,mapfold,3,[{file,"src/couch_key_tree.erl"},{line,457}]},{couch_db_updater,flush_trees,3,[{file,"src/couch_db_updater.erl"},{line,373}]},{couch_db_updater,update_docs_int,4,[{file,"src/couch_db_updater.erl"},{line,718}]},{couch_db_updater,handle_info,2,[{file,"src/couch_db_updater.erl"},{line,183}]}]} [{couch_db,collect_results,3,[{file,"src/couch_db.erl"},{line,1457}]},{couch_db,collect_results_with_metrics,3,[{file,"src/couch_db.erl"},{line,1439}]},{couch_db,write_and_commit,4,[{file,"src/couch_db.erl"},{line,1471}]},{couch_db,update_docs,4,[{file,"src/couch_db.erl"},{line,1333}]},{fabric_rpc,with_db,3,[{file,"src/fabric_rpc.erl"},{line,360}]},{rexi_server,init_p,3,[{file,"src/rexi_server.erl"},{line,141}]}]
[info] 2024-09-30T16:14:19.574423Z nonode@nohost <0.243.0> -------- db shards/e0000000-ffffffff/hzd.1727710380 died with reason {{badmatch,{error,enospc}},[{couch_bt_engine,write_doc_body,2,[{file,"src/couch_bt_engine.erl"},{line,439}]},{couch_db_updater,'-flush_trees/3-fun-0-',6,[{file,"src/couch_db_updater.erl"},{line,384}]},{couch_key_tree,mapfold_simple,4,[{file,"src/couch_key_tree.erl"},{line,464}]},{couch_key_tree,mapfold_simple,4,[{file,"src/couch_key_tree.erl"},{line,473}]},{couch_key_tree,mapfold,3,[{file,"src/couch_key_tree.erl"},{line,457}]},{couch_db_updater,flush_trees,3,[{file,"src/couch_db_updater.erl"},{line,373}]},{couch_db_updater,update_docs_int,4,[{file,"src/couch_db_updater.erl"},{line,718}]},{couch_db_updater,handle_info,2,[{file,"src/couch_db_updater.erl"},{line,183}]}]}
[error] 2024-09-30T16:14:19.574887Z nonode@nohost <0.18010.101> -------- gen_server <0.18010.101> terminated with reason: no match of right hand value {error,enospc} at couch_bt_engine:write_doc_body/2(line:439) <= couch_db_updater:'-flush_trees/3-fun-0-'/6(line:384) <= couch_key_tree:mapfold_simple/4(line:464) <= couch_key_tree:mapfold_simple/4(line:473) <= couch_key_tree:mapfold/3(line:457) <= couch_db_updater:flush_trees/3(line:373) <= couch_db_updater:update_docs_int/4(line:718) <= couch_db_updater:handle_info/2(line:183)
  last msg: redacted
     state: {db,1,<<"shards/e0000000-ffffffff/hzd.1727710380">>,"./data/shards/e0000000-ffffffff/hzd.1727710380.couch",{couch_bt_engine,{st,"./data/shards/e0000000-ffffffff/hzd.1727710380.couch",<0.19406.101>,#Ref<0.3603940510.502005771.203208>,undefined,{db_header,8,30406,0,{9450247660,{29670,687,{size_info,9279630171,9278136634}},12600491},{9450249167,30357,11927090},{9448039553,[],2388},nil,nil,4251,1000,<<"2719778795232e78e860e5e8ab70c794">>,[{nonode@nohost,0}],0,1000,0},false,{btree,<0.19406.101>,{9450247660,{29670,687,{size_info,9279630171,9278136634}},12600491},fun couch_bt_engine:id_tree_split/1,fun couch_bt_engine:id_tree_join/2,undefined,fun couch_bt_engine:id_tree_reduce/2,snappy},{btree,<0.19406.101>,{9450249167,30357,11927090},fun couch_bt_engine:seq_tree_split/1,fun couch_bt_engine:seq_tree_join/2,undefined,fun couch_bt_engine:seq_tree_reduce/2,snappy},{btree,<0.19406.101>,{9448039553,[],2388},fun couch_bt_engine:local_tree_split/1,fun couch_bt_engine:local_tree_join/2,undefined,nil,snappy},snappy,{btree,<0.19406.101>,nil,fun couch_bt_engine:purge_tree_split/1,fun couch_bt_engine:purge_tree_join/2,undefined,fun couch_bt_engine:purge_tree_reduce/2,snappy},{btree,<0.19406.101>,nil,fun couch_bt_engine:purge_seq_tree_split/1,fun couch_bt_engine:purge_seq_tree_join/2,undefined,fun couch_bt_engine:purge_tree_reduce/2,snappy}}},<0.18010.101>,nil,30406,<<"1727712856444764">>,{user_ctx,null,[],undefined},[{<<"members">>,{[{<<"roles">>,[<<"_admin">>]}]}},{<<"admins">>,{[{<<"roles">>,[<<"_admin">>]}]}}],[#Fun<couch_doc.7.91987333>],nil,nil,undefined,[{default_security_object,[{<<"members">>,{[{<<"roles">>,[<<"_admin">>]}]}},{<<"admins">>,{[{<<"roles">>,[<<"_admin">>]}]}}]},replicated_changes,{user_ctx,{user_ctx,<<"groot">>,[<<"_admin">>],<<"cookie">>}},{w,"1"},{props,[{partitioned,true},{hash,[couch_partition,hash,[]]}]}],undefined}
    extra: []
[notice] 2024-09-30T16:14:19.574938Z nonode@nohost <0.19120.101> d5dfe20e02 localhost:5984 127.0.0.1 groot POST /hzd/_bulk_docs 500 ok 21
[error] 2024-09-30T16:14:19.575102Z nonode@nohost <0.18010.101> -------- gen_server <0.18010.101> terminated with reason: no match of right hand value {error,enospc} at couch_bt_engine:write_doc_body/2(line:439) <= couch_db_updater:'-flush_trees/3-fun-0-'/6(line:384) <= couch_key_tree:mapfold_simple/4(line:464) <= couch_key_tree:mapfold_simple/4(line:473) <= couch_key_tree:mapfold/3(line:457) <= couch_db_updater:flush_trees/3(line:373) <= couch_db_updater:update_docs_int/4(line:718) <= couch_db_updater:handle_info/2(line:183)
  last msg: redacted
     state: {db,1,<<"shards/e0000000-ffffffff/hzd.1727710380">>,"./data/shards/e0000000-ffffffff/hzd.1727710380.couch",{couch_bt_engine,{st,"./data/shards/e0000000-ffffffff/hzd.1727710380.couch",<0.19406.101>,#Ref<0.3603940510.502005771.203208>,undefined,{db_header,8,30406,0,{9450247660,{29670,687,{size_info,9279630171,9278136634}},12600491},{9450249167,30357,11927090},{9448039553,[],2388},nil,nil,4251,1000,<<"2719778795232e78e860e5e8ab70c794">>,[{nonode@nohost,0}],0,1000,0},false,{btree,<0.19406.101>,{9450247660,{29670,687,{size_info,9279630171,9278136634}},12600491},fun couch_bt_engine:id_tree_split/1,fun couch_bt_engine:id_tree_join/2,undefined,fun couch_bt_engine:id_tree_reduce/2,snappy},{btree,<0.19406.101>,{9450249167,30357,11927090},fun couch_bt_engine:seq_tree_split/1,fun couch_bt_engine:seq_tree_join/2,undefined,fun couch_bt_engine:seq_tree_reduce/2,snappy},{btree,<0.19406.101>,{9448039553,[],2388},fun couch_bt_engine:local_tree_split/1,fun couch_bt_engine:local_tree_join/2,undefined,nil,snappy},snappy,{btree,<0.19406.101>,nil,fun couch_bt_engine:purge_tree_split/1,fun couch_bt_engine:purge_tree_join/2,undefined,fun couch_bt_engine:purge_tree_reduce/2,snappy},{btree,<0.19406.101>,nil,fun couch_bt_engine:purge_seq_tree_split/1,fun couch_bt_engine:purge_seq_tree_join/2,undefined,fun couch_bt_engine:purge_tree_reduce/2,snappy}}},<0.18010.101>,nil,30406,<<"1727712856444764">>,{user_ctx,null,[],undefined},[{<<"members">>,{[{<<"roles">>,[<<"_admin">>]}]}},{<<"admins">>,{[{<<"roles">>,[<<"_admin">>]}]}}],[#Fun<couch_doc.7.91987333>],nil,nil,undefined,[{default_security_object,[{<<"members">>,{[{<<"roles">>,[<<"_admin">>]}]}},{<<"admins">>,{[{<<"roles">>,[<<"_admin">>]}]}}]},replicated_changes,{user_ctx,{user_ctx,<<"groot">>,[<<"_admin">>],<<"cookie">>}},{w,"1"},{props,[{partitioned,true},{hash,[couch_partition,hash,[]]}]}],undefined}
    extra: []
[error] 2024-09-30T16:14:19.575128Z nonode@nohost <0.14636.101> -------- Replicator, request POST to "http://localhost:5984/hzd/_bulk_docs" failed due to error {code,500}
[error] 2024-09-30T16:14:19.575198Z nonode@nohost <0.18010.101> -------- CRASH REPORT Process  (<0.18010.101>) with 0 neighbors crashed with reason: no match of right hand value {error,enospc} at couch_bt_engine:write_doc_body/2(line:439) <= couch_db_updater:'-flush_trees/3-fun-0-'/6(line:384) <= couch_key_tree:mapfold_simple/4(line:464) <= couch_key_tree:mapfold_simple/4(line:473)

My fault: I'm using Docker Desktop, the max. storage capacity was set to 100GB and the source (CouchDB 3.3.3) is running in parallel, so I can replicate from it...
My assumption was, that I'm running docker without limits.
So nickva spotted it right on his first comment:

enospc from no match of right hand value {error,enospc} indicates we're probably running out of disk space [1]
It should be a more friendly message in the log, but at least first sight that's what's jumping out.
[1] https://www.man7.org/linux/man-pages/man3/errno.3.html

There's may be two improvements, that I can provide from this fault:

A more user friendly error message than {error,enospc}.
Quit CouchDB on that error (since health-checks run fine, as long as the endpoints are reachable) or report an unhealthy status in _up endpoint.


text:
eunit couchdb_os_daemons_tests race on startup

Expected & Current Behaviour
The couchdb_os_daemons_tests test should always pass, but sometimes, it fails a context cleanup.

https://builds.apache.org/blue/organizations/jenkins/CouchDB/detail/2.1.x/3/pipeline
Jenkins, Debian 8, default Erlang (17)

Makefile output:
module 'couchdb_os_daemons_tests'
  OS Daemons tests
    couchdb_os_daemons_tests:107: should_check_daemon...ok
    couchdb_os_daemons_tests:113: should_check_daemon_table_form...ok
    couchdb_os_daemons_tests:120: should_clean_tables_on_daemon_remove...[0.544 s] ok
    couchdb_os_daemons_tests:127: should_spawn_multiple_daemons...[0.618 s] ok
    undefined
    *** context cleanup failed ***
**in function test_util:stop_sync_throw/4 (src/test_util.erl, line 160)
in call from couchdb_os_daemons_tests:teardown/2 (test/couchdb_os_daemons_tests.erl, line 58)
**throw:{timeout,os_daemon_stop}

couch.log content:
[notice] 2017-06-06T22:50:22.237455Z nonode@nohost <0.3536.1> -------- config: [os_daemons] os_daemon_looper.escript deleted for reason nil
[info] 2017-06-06T22:50:22.795306Z nonode@nohost <0.7.0> -------- Application couch_epi exited with reason: stopped
[info] 2017-06-06T22:50:22.796319Z nonode@nohost <0.7.0> -------- Application ioq exited with reason: stopped
[info] 2017-06-06T22:50:22.825941Z nonode@nohost <0.7.0> -------- Application couch_log started on node nonode@nohost
[info] 2017-06-06T22:50:22.826318Z nonode@nohost <0.7.0> -------- Application ioq started on node nonode@nohost
[info] 2017-06-06T22:50:22.907640Z nonode@nohost <0.7.0> -------- Application couch_epi started on node nonode@nohost
[notice] 2017-06-06T22:50:23.068667Z nonode@nohost <0.3593.1> -------- config: [os_daemons] os_daemon_looper.escript set to /tmp/tmp.rGuUi1aWRx/apache-couchdb-2.0.0-76d2aee/src/couch/test/fixtures/os_daemon_looper.escript for reason nil
[notice] 2017-06-06T22:50:23.071633Z nonode@nohost <0.3593.1> -------- config: [uuids] algorithm set to sequential for reason nil
[notice] 2017-06-06T22:50:23.677403Z nonode@nohost <0.3593.1> -------- config: [os_daemons] bar set to /tmp/tmp.rGuUi1aWRx/apache-couchdb-2.0.0-76d2aee/src/couch/test/fixtures/os_daemon_looper.escript for reason nil
[notice] 2017-06-06T22:50:23.677893Z nonode@nohost <0.3593.1> -------- config: [os_daemons] baz set to /tmp/tmp.rGuUi1aWRx/apache-couchdb-2.0.0-76d2aee/src/couch/test/fixtures/os_daemon_looper.escript for reason nil
[info] 2017-06-06T22:50:25.320943Z nonode@nohost <0.7.0> -------- Application inets started on node nonode@nohost
[info] 2017-06-06T22:50:25.323433Z nonode@nohost <0.7.0> -------- Application ibrowse started on node nonode@nohost
[info] 2017-06-06T22:50:25.323627Z nonode@nohost <0.7.0> -------- Application asn1 started on node nonode@nohost
[info] 2017-06-06T22:50:25.323845Z nonode@nohost <0.7.0> -------- Application public_key started on node nonode@nohost
[info] 2017-06-06T22:50:25.324464Z nonode@nohost <0.7.0> -------- Application ssl started on node nonode@nohost
[info] 2017-06-06T22:50:25.324723Z nonode@nohost <0.7.0> -------- Application khash started on node nonode@nohost
[info] 2017-06-06T22:50:25.325443Z nonode@nohost <0.7.0> -------- Application couch_event started on node nonode@nohost
[info] 2017-06-06T22:50:25.326306Z nonode@nohost <0.7.0> -------- Application sasl started on node nonode@nohost
[info] 2017-06-06T22:50:25.328126Z nonode@nohost <0.7.0> -------- Application os_mon started on node nonode@nohost
[info] 2017-06-06T22:50:25.328339Z nonode@nohost <0.7.0> -------- Application xmerl started on node nonode@nohost
[info] 2017-06-06T22:50:25.328526Z nonode@nohost <0.7.0> -------- Application compiler started on node nonode@nohost
[info] 2017-06-06T22:50:25.328700Z nonode@nohost <0.7.0> -------- Application syntax_tools started on node nonode@nohost
[info] 2017-06-06T22:50:25.328873Z nonode@nohost <0.7.0> -------- Application mochiweb started on node nonode@nohost
[info] 2017-06-06T22:50:25.329045Z nonode@nohost <0.7.0> -------- Application oauth started on node nonode@nohost
[info] 2017-06-06T22:50:25.329212Z nonode@nohost <0.7.0> -------- Application b64url started on node nonode@nohost
[info] 2017-06-06T22:50:25.329750Z nonode@nohost <0.7.0> -------- Application folsom started on node nonode@nohost
[info] 2017-06-06T22:50:25.366232Z nonode@nohost <0.7.0> -------- Application couch_stats started on node nonode@nohost
[info] 2017-06-06T22:50:25.366227Z nonode@nohost <0.3762.1> -------- Apache CouchDB 2.0.0 is starting.

[info] 2017-06-06T22:50:25.366569Z nonode@nohost <0.3763.1> -------- Starting couch_sup
[error] 2017-06-06T22:50:25.383949Z nonode@nohost <0.3771.1> -------- Supervisor couch_secondary_services had child os_daemons started with couch_os_daemons:start_link() at undefined exit with reason {already_started,<0.3640.1>} in context start_error
[error] 2017-06-06T22:50:25.384692Z nonode@nohost <0.3763.1> -------- Supervisor couch_sup had child couch_secondary_services started with couch_secondary_sup:start_link() at undefined exit with reason {shutdown,{failed_to_start_child,os_daemons,{already_started,<0.3640.1>}}} in context start_error
[error] 2017-06-06T22:50:25.385050Z nonode@nohost <0.3762.1> -------- Error starting Apache CouchDB:

    {error,{shutdown,{failed_to_start_child,couch_secondary_services,{shutdown,{failed_to_start_child,os_daemons,{already_started,<0.3640.1>}}}}}}

[error] 2017-06-06T22:50:25.386914Z nonode@nohost <0.3761.1> -------- CRASH REPORT Process  (<0.3761.1>) with 0 neighbors exited with reason: {{shutdown,{failed_to_start_child,couch_secondary_services,{shutdown,{failed_to_start_child,os_daemons,{already_started,<0.3640.1>}}}}},{couch_app,start,[normal,[]]}} at application_master:init/4(line:133) <= proc_lib:init_p_do_apply/3(line:237); initial_call: {application_master,init,['Argument__1','Argument__2',...]}, ancestors: [<0.3760.1>], messages: [{'EXIT',<0.3762.1>,normal}], links: [<0.3760.1>,<0.7.0>], dictionary: [], trap_exit: true, status: running, heap_size: 610, stack_size: 27, reductions: 132
[info] 2017-06-06T22:50:25.387276Z nonode@nohost <0.7.0> -------- Application couch exited with reason: {{shutdown,{failed_to_start_child,couch_secondary_services,{shutdown,{failed_to_start_child,os_daemons,{already_started,<0.3640.1>}}}}},{couch_app,start,[normal,[]]}}

Analysis
Possibly bump timeout more?
The test spawns the file src/couch/test/fixtures/os_daemon_looper.escript. Perhaps this daemon is out to lunch on an io:read and can't be killed? I don't know.

Could {failed_to_start_child,os_daemons,{already_started,<0.3640.1>}}}  “already started” be a smoking gun?

That's coming from the subsequent tests, after it failed to stop it.

Closing as a duplicate of #571.

authors: janl wohali


text:
[Bug][worker-server Service is down ] Bug title The worker service suddenly stopped，An error: io.grpc.internal.ManagedChannelImpl:[1116] - ~~~ Channel io.grpc.internal.ManagedChannelImpl-337 for target 10.8.2.52:50051 was not shutdown properly!!! ~~~     Make sure to call shutdown()/shutdownNow() and awaitTermination(). java.lang.RuntimeException: ManagedChannel allocation site

[INFO] 2021-08-10 16:13:43.221 org.apache.dolphinscheduler.server.worker.runner.TaskScheduleThread:[156] - task instance id : 18363,task final status : SUCCESS
[INFO] 2021-08-10 16:16:44.880 org.apache.dolphinscheduler.server.worker.WorkerServer:[339] - get one kill command from tasks kill queue: 10.8.2.52-18366
[INFO] 2021-08-10 16:16:45.006 org.apache.dolphinscheduler.server.utils.ProcessUtils:[332] - process id:25742, cmd:kill -9
[ERROR] 2021-08-10 16:16:46.011 io.grpc.internal.ManagedChannelImpl:[1116] - ~~~ Channel io.grpc.internal.ManagedChannelImpl-337 for target 10.8.2.52:50051 was not shutdown properly!!! ~~~
Make sure to call shutdown()/shutdownNow() and awaitTermination().
java.lang.RuntimeException: ManagedChannel allocation site
at io.grpc.internal.ManagedChannelImpl$ManagedChannelReference.(ManagedChannelImpl.java:1065)
at io.grpc.internal.ManagedChannelImpl.(ManagedChannelImpl.java:485)
at io.grpc.internal.AbstractManagedChannelImplBuilder.build(AbstractManagedChannelImplBuilder.java:349)
at org.apache.dolphinscheduler.server.rpc.LogClient.(LogClient.java:71)
at org.apache.dolphinscheduler.server.rpc.LogClient.(LogClient.java:55)
at org.apache.dolphinscheduler.server.utils.ProcessUtils.killYarnJob(ProcessUtils.java:370)
at org.apache.dolphinscheduler.server.utils.ProcessUtils.kill(ProcessUtils.java:337)
at org.apache.dolphinscheduler.server.worker.WorkerServer.killTask(WorkerServer.java:362)
at org.apache.dolphinscheduler.server.worker.WorkerServer.access$400(WorkerServer.java:60)
at org.apache.dolphinscheduler.server.worker.WorkerServer$3.run(WorkerServer.java:320)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
[ERROR] 2021-08-10 16:16:46.011 io.grpc.internal.ManagedChannelImpl:[1116] - ~~~ Channel io.grpc.internal.ManagedChannelImpl-333 for target 10.8.2.52:50051 was not shutdown properly!!! ~~~
Make sure to call shutdown()/shutdownNow() and awaitTermination().
java.lang.RuntimeException: ManagedChannel allocation site
at io.grpc.internal.ManagedChannelImpl$ManagedChannelReference.(ManagedChannelImpl.java:1065)
at io.grpc.internal.ManagedChannelImpl.(ManagedChannelImpl.java:485)
at io.grpc.internal.AbstractManagedChannelImplBuilder.build(AbstractManagedChannelImplBuilder.java:349)
at org.apache.dolphinscheduler.server.rpc.LogClient.(LogClient.java:71)
at org.apache.dolphinscheduler.server.rpc.LogClient.(LogClient.java:55)
at org.apache.dolphinscheduler.server.utils.ProcessUtils.killYarnJob(ProcessUtils.java:370)
at org.apache.dolphinscheduler.server.utils.ProcessUtils.kill(ProcessUtils.java:337)
at org.apache.dolphinscheduler.server.worker.WorkerServer.killTask(WorkerServer.java:362)
at org.apache.dolphinscheduler.server.worker.WorkerServer.access$400(WorkerServer.java:60)
at org.apache.dolphinscheduler.server.worker.WorkerServer$3.run(WorkerServer.java:320)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
[INFO] 2021-08-10 16:16:46.012 org.apache.dolphinscheduler.server.rpc.LogClient:[117] - view log path : /home/mjyu/opt/dolphinscheduler/logs/64/3309/18366.log
[INFO] 2021-08-10 16:16:46.048 org.apache.dolphinscheduler.common.queue.TaskQueueZkImpl:[339] - delete task:10.8.2.52-18366 from tasks set
[INFO] 2021-08-10 16:18:29.092 org.apache.dolphinscheduler.server.worker.WorkerServer:[339] - get one kill command from tasks kill queue: 10.8.2.52-18335
[INFO] 2021-08-10 16:18:29.211 org.apache.dolphinscheduler.server.utils.ProcessUtils:[332] - process id:22434, cmd:kill -9
[INFO] 2021-08-10 16:18:30.215 org.apache.dolphinscheduler.server.rpc.LogClient:[117] - view log path : /home/mjyu/opt/dolphinscheduler/logs/77/3307/18335.log
[INFO] 2021-08-10 16:18:30.245 org.apache.dolphinscheduler.common.queue.TaskQueueZkImpl:[339] - delete task:10.8.2.52-18335 from tasks set
[INFO] 2021-08-10 16:18:31.246 org.apache.dolphinscheduler.server.worker.WorkerServer:[339] - get one kill command from tasks kill queue: 10.8.2.52-18336
[INFO] 2021-08-10 16:18:31.359 org.apache.dolphinscheduler.server.utils.ProcessUtils:[332] - process id:22448, cmd:kill -9
[INFO] 2021-08-10 16:18:32.364 org.apache.dolphinscheduler.server.rpc.LogClient:[117] - view log path : /home/mjyu/opt/dolphinscheduler/logs/68/3308/18336.log
[ERROR] 2021-08-10 16:18:32.396 org.apache.dolphinscheduler.server.rpc.LogClient:[125] - view log  failed : UNKNOWN
io.grpc.StatusRuntimeException: UNKNOWN
at io.grpc.stub.ClientCalls.toStatusRuntimeException(ClientCalls.java:221)
at io.grpc.stub.ClientCalls.getUnchecked(ClientCalls.java:202)
at io.grpc.stub.ClientCalls.blockingUnaryCall(ClientCalls.java:131)
at org.apache.dolphinscheduler.rpc.LogViewServiceGrpc$LogViewServiceBlockingStub.viewLog(LogViewServiceGrpc.java:321)
at org.apache.dolphinscheduler.server.rpc.LogClient.viewLog(LogClient.java:122)
at org.apache.dolphinscheduler.server.utils.ProcessUtils.killYarnJob(ProcessUtils.java:372)
at org.apache.dolphinscheduler.server.utils.ProcessUtils.kill(ProcessUtils.java:337)
at org.apache.dolphinscheduler.server.worker.WorkerServer.killTask(WorkerServer.java:362)
at org.apache.dolphinscheduler.server.worker.WorkerServer.access$400(WorkerServer.java:60)
at org.apache.dolphinscheduler.server.worker.WorkerServer$3.run(WorkerServer.java:320)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
[INFO] 2021-08-10 16:18:32.397 org.apache.dolphinscheduler.common.queue.TaskQueueZkImpl:[339] - delete task:10.8.2.52-18336 from tasks set
[INFO] 2021-08-10 16:18:32.397 org.apache.dolphinscheduler.server.worker.WorkerServer:[339] - get one kill command from tasks kill queue: 10.8.2.52-18339
[INFO] 2021-08-10 16:18:32.484 org.apache.dolphinscheduler.server.utils.ProcessUtils:[332] - process id:22490, cmd:kill -9
[INFO] 2021-08-10 16:18:33.487 org.apache.dolphinscheduler.server.rpc.LogClient:[117] - view log path : /home/mjyu/opt/dolphinscheduler/logs/68/3308/18339.log
[ERROR] 2021-08-10 16:18:33.517 org.apache.dolphinscheduler.server.rpc.LogClient:[125] - view log  failed : UNKNOWN
io.grpc.StatusRuntimeException: UNKNOWN
at io.grpc.stub.ClientCalls.toStatusRuntimeException(ClientCalls.java:221)

which version?

version 1.2.0

which version?

version 1.2.0

repo: apache/dolphinscheduler


text:
[Improvement][API] Status code should one category one interval #4855

Purpose of the pull request
[Improvement][API] Status code should one category one interval #4855
Brief change log

Verify this pull request

This pull request is code cleanup without any test coverage.
(or)
This pull request is already covered by existing tests, such as (please describe tests).
(or)
This change added tests and can be verified as follows:

Here is a compilation error, you can check the specific class and fix the error.
Code Style Check fail, you can view this document (https://dolphinscheduler.apache.org/zh-cn/community/dev

sorry for review so late, can you submit a new PR or solve the Conflicting files?  I will close this PR

authors: CalvinKirs dailidong yakcy


text:
--create-table-only配置项无效

Search before asking

[X] I had searched in the issues and found no similar issues.

Version
flink-doris-connector-1.19-1.6.1
What's Wrong?
是否只仅仅创建表的结构
配置了仅创建，表的数据还是过去了
What You Expected?
是否只仅仅创建表的结构
配置了仅创建，表的数据还是过去了
How to Reproduce?
No response
Anything Else?
No response
Are you willing to submit PR?

[ ] Yes I am willing to submit a PR!

Code of Conduct

[X] I agree to follow this project's Code of Conduct

@raboof

Can you post the specific configuration?

authors: JNSimba wolfewf

repo: apache/doris-flink-connector


text:
[Feature] (Nereids) support un equals conjuncts in un scalar sub query

Proposed changes
Issue Number: close #xxx
Problem summary
support un equals conjuncts in un scalar sub query.
[fix] in correlated subquery wrong result
Checklist(Required)

Does it affect the original behavior:

[ ] Yes
[x] No
[ ] I don't know

Has unit tests been added:

[x] Yes
[ ] No
[ ] No Need

Has document been added or modified:

[ ] Yes
[ ] No
[x] No Need

Does it need to update dependencies:

[ ] Yes
[x] No

Are there any changes that cannot be rolled back:

[ ] Yes (If Yes, please explain WHY)
[ ] No

Further comments
If this is a relatively large or complex change, kick off the discussion at dev@doris.apache.org by explaining why you chose the solution you did and what alternatives you considered, etc...

TeamCity pipeline, clickbench performance test result:
the sum of best hot time: 36.02 seconds
load time: 651 seconds
storage size: 17122925806 Bytes
https://doris-community-test-1308700295.cos.ap-hongkong.myqcloud.com/tmp/20230104045125_clickbench_pr_73197.html

authors: hello-stephen zhengshiJ

repo: apache/doris


text:
typo Add an open page cache hint to the benchmark

Proposed changes
Issue Number: close #19364
Problem summary
Describe your changes.
Checklist(Required)

[ ] Does it affect the original behavior
[ ] Has unit tests been added
[x] Has document been added or modified
[ ] Does it need to update dependencies
[ ] Is this PR support rollback (If NO, please explain WHY)

Further comments
If this is a relatively large or complex change, kick off the discussion at dev@doris.apache.org by explaining why you chose the solution you did and what alternatives you considered, etc...

run buildall

run buildall


text:
test Reopen dcheck

ONLY FOR TEST

run buildall

run buildall


text:
[fix](migrate disk) fix tablet disk migration timeout too large

Proposed changes
Issue Number: close #xxx

Further comments
If this is a relatively large or complex change, kick off the discussion at dev@doris.apache.org by explaining why you chose the solution you did and what alternatives you considered, etc...

run buildall

run buildall


text:
pipelineX Fix use-after-free MultiCastSourceDependency

Proposed changes
Issue Number: close #xxx

Further comments
If this is a relatively large or complex change, kick off the discussion at dev@doris.apache.org by explaining why you chose the solution you did and what alternatives you considered, etc...

run buildall

run buildall

run buildall

run buildall

run buildall


text:
[Fix](LZ4 compression) Fix wrong LZ4 compression max input size limit

Proposed changes
LZ4 compression max supported value is LZ4_MAX_INPUT_SIZE, which is 0x7E000000(2,113,929,216 bytes). Doris use wrong max size INT_MAX, which is 2,147,483,647, to check. If input data size is between this two size, then it can pass the check but LZ4 compression will fail.
This PR fix it.

run buildall


text:
[fix](docker case) Enhance the robustness of test_multi_follower case

Proposed changes
Issue Number: close #xxx

run buildall

authors: deardeng gavinchou


text:
chore Add table type to getMeta method

What problem does this PR solve?
Issue Number: close #xxx
Related PR: #xxx
Problem Summary:
Release note
None
Check List (For Author)

Test

[ ] Regression test
[ ] Unit Test
[ ] Manual test (add detailed scripts or steps below)
[ ] No need to test or manual test. Explain why:

[ ] This is a refactor/code format and no logic has been changed.
[ ] Previous test can cover this change.
[ ] No code files have been changed.
[ ] Other reason

Behavior changed:

[ ] No.
[ ] Yes.

Does this need documentation?

[ ] No.
[ ] Yes.

Check List (For Reviewer who merge this PR)

[ ] Confirm the release note
[ ] Confirm test cases
[ ] Confirm document
[ ] Add branch pick label

Thank you for your contribution to Apache Doris.
Don't know what should be done next? See How to process your PR.
Please clearly describe your PR:

What problem was fixed (it's best to include specific error reporting information). How it was fixed.
Which behaviors were modified. What was the previous behavior, what is it now, why was it modified, and what possible impacts might there be.
What features were added. Why was this function added?
Which code was refactored and why was this part of the code refactored?
Which functions were optimized and what is the difference before and after the optimization?

run buildall

authors: dataroaring hello-stephen w41ter


text:
[Docs] Fix a broken link

This PR fixes a broken link in Notes on flattening
This PR has:

[ x ] been self-reviewed.

👍

authors: ektravel writer-jill

repo: apache/druid


text:
Allow typedIn to run in replace-with-default mode.

Useful when data servers, like Historicals, are running in replace-with-default mode and the Broker is running in SQL-compatible mode, which can happen during a rolling update that is applying a mode change.

I tested this locally by running a Broker in SQL-compatible mode and a Historical in replace-with-default mode. In this case, the Broker generates inType filters. Without this patch, the Historical threw an error on the query; with this patch, the query ran successfully.

CI is failing due to low branch coverage.

I think we should ignore the branch coverage check here, because the relevant branch is if (NullHandling.sqlCompatible()), which we actually are testing both branches of— just not in the same run.
There were some legit test failures in the non-SQL-compat processing run, which I've fixed in the most recent commit.

The legit failure is fixed; all that's left is the branch coverage failures, which I suggest we ignore.

authors: gianm pranavbhole


text:
[MINOR] Fix some project construction problems about test sources

Fix some project construction problems about test sources

"src/test/org.apache.eagle.xxx" -> "src/test/java/org.apache.eagle.xxx"

Involved modules:

eagle-hbase-web
eagle-hdfs-web

@asdf2014 what's the changes? If no, could you please help close it?

@haoch Done

repo: apache/eagle


text:
treemap 设置 rich 后整体label不水平垂直居中

Version
5.0.2
Steps to reproduce
1、打开地址：https://echarts.apache.org/examples/en/editor.html?c=treemap-disk
2、输入以下option：
option = {
    series: [{
        type: 'treemap',
        name: '中国',
        leafDepth: 1,
        label: {
            formatter: '{b}',
            rich:{}, // 只要加上这句话，即使rich是空的，定位也会不居中
        },
        data: [{
            name: '河北省',            // First tree
            value: 10,
            children: [{
                name: '邯郸市',       // First leaf of first tree
                value: 4
            }, {
                name: '保定市',       // Second leaf of first tree
                value: 6
            }],
        }, {
            name: '河南省',            // Second tree
            value: 20,
            children: [{
                name: '郑州市',       // Son of first tree
                value: 20,
                children: [{
                    name: 'xxx县',  // Granson of first tree
                    value: 20
                }]
            }]
        }]
    }]
};

3、只要加上了 rich: {}，即使是空的，label定位也有问题。不加的时候是水平垂直居中的，加上后变为lefttop 布局，设置 verticalAlign: "middle"  也不生效
What is expected?
希望“河北省”、“河南省”在块中是居中的
What is actually happening?
实际上跑到左上角了

I'm really need the rich function, it is very important to me, please give some answer~

Met the same issue after upgrade to 5.0.2. The rich with verticalAlign: middle doesn't work.

Get a solution (the verticalAlign is 'top' by default):
        labelLayout: (params) => {           return {             y: params.labelRect.y,             align: 'center',           }         },

@89466598946659
It is a option problem.
Try the following configuration。
{
series: [{
type: 'treemap',
name: '中国',
leafDepth: 1,
label: {
position: ['50%', '50%'], // I think it will help you
formatter: '{b}',
rich:{},
},
data: [{
name: '河北省',            // First tree
value: 10,
children: [{
name: '邯郸市',       // First leaf of first tree
value: 4
}, {
name: '保定市',       // Second leaf of first tree
value: 6
}],
}, {
name: '河南省',            // Second tree
value: 20,
children: [{
name: '郑州市',       // Son of first tree
value: 20,
children: [{
name: 'xxx县',  // Granson of first tree
value: 20
}]
}]
}]
}]
}

Get a solution (the verticalAlign is 'top' by default):
 labelLayout: (params) => { return { y: params.labelRect.y, align: 'center', } },

thanks，but what I want is like this: the label words in the red rect.

@89466598946659
It is a option problem.
Try the following configuration.
{
        series: [{
                type: 'treemap',
                name: '中国',
                leafDepth: 1,
                label: {
                    position: ['50%', '50%'], // I think it will help you
                    formatter: '{b}',
                    rich:{},
                },
                data: [{
                    name: '河北省',            // First tree
                    value: 10,
                    children: [{
                        name: '邯郸市',       // First leaf of first tree
                        value: 4
                    }, {
                        name: '保定市',       // Second leaf of first tree
                        value: 6
                    }],
                }, {
                    name: '河南省',            // Second tree
                    value: 20,
                    children: [{
                        name: '郑州市',       // Son of first tree
                        value: 20,
                        children: [{
                            name: 'xxx县',  // Granson of first tree
                            value: 20
                        }]
                    }]
                }]
            }]
    }

thanks, really, I have two questions for this.
first: The lable is not align center
second: What I want is the red rect. to the yellow rect.

I have the same problem, is there a solution?

您的邮件已收到！O(∩_∩)O！--------Pan

I have the same problem, is there a solution?

No solution. Change another charts.😂

Looks the width and height are set to rectangle width and height to truncate texts in https://github.com/apache/echarts/blob/master/src/chart/treemap/TreemapView.ts#L1004 . But when using rich text it will also affect the layout.

ecomfe/zrender/pull/905

this commit contains two contents:

fix current issue by #ecomfe/zrender/pull/905
fix another problem when setting the width and height of treemap.label, but not work.

and added a test case about them.

i fix it by set  offset: [0, 5], but it not a good solution

您的邮件已收到！O(∩_∩)O！--------Pan

Has the problem been solved？I also can't perfectly center after using rich

您的邮件已收到！O(∩_∩)O！--------Pan

您的邮件已收到！O(∩_∩)O！--------Pan

authors: 89466598946659 Jamt1n chenxueling fuchunhui kchjxxgh pissang tenadolanter zhanghaoStart

repo: apache/echarts


text:
When the dispatchAction type is highlight or downplay，Using geoIndex, geoId, geoName solely that is invalidity.

Version
5.1.2
Steps to reproduce
myChart.dispatchAction({
type: 'highlight',
geoIndex: 0
});
What is expected?
The geoIndex 0 can highlight in full.
What is actually happening?
Nothing happing.

@echarts-bot
https://codesandbox.io/s/wizardly-nightingale-xcvyv?file=/index.html


text:
[Feature] Specify Node Relationships in Graph using "id" Attribute

What problem does this feature solve?
In the graph component, it is necessary to add an "id" attribute to each element in the data, and then use this "id" to establish connections in the "links" through the "target" and "source" attributes.
When working with the graph, a unique identifier is needed to handle cases where nodes have the same name. While the ECharts documentation mentions that the "links" support using "name" and the index of data, using "name" may lead to situations with identical names, and using the index is not convenient when dealing with dynamic data.
I propose using an "id" to specify nodes and establish connections through the "links." In fact, ECharts already supports using "id," but this is not explicitly documented. It's important to note that the "id" cannot be a number; it must be a string. If it's a number, ECharts recognizes it as a data index.
You can then use these "id" values in the "links," where the "target" and "source" values should be the same as the "id" set in the data.
I will provide an example below. If this is not a bug, I suggest documenting this feature. If it is a bug, I hope this functionality can be made available in the next release.
What does the proposed API look like?
example
 data: [
        { name: '李白', category: '亲人', id: '1' },
        { name: '杜甫', category: '亲人', id: '2' },
        { name: '李白', category: '租户', id: '3' },
        { name: '王之涣', category: '租户', id: '4' },
        { name: '王之涣', category: '亲人', id: '5' },
        { name: '杜甫', category: '亲人', id: '6' }
      ],
links: [
        { source: '4', target: '5', value: '夫妻' },
        { source: '2', target: '3', value: '租赁' },
        { source: '3', target: '4', value: '亲人' },
        { source: '1', target: '5', value: '亲人' },
        { source: '1', target: '2', value: '亲人' },
        { source: '4', target: '6', value: '亲人' },
      ]

source and target could be set as numerical node dataIndex and node names could be duplicated.
See official example and try several happy Fridays.

I understand that dataIndex can be used, but it is not as convenient when dealing with dynamic data. It is more suitable for dynamic data. We need an attribute like 'id' or a similar one to better specify the source and target relationships in cases where names are the same. This would also facilitate storing data in a database on the backend or handling data sent from the backend more conveniently.

I accidentally closed this issue.

agree, proposal makes sense for database use.
But there is a simple solution through data preparation - Demo Code.

Thank you for your reply. Yes, I am aware, but in fact, your ECharts already supports directly using IDs to specify source and target. Can you please add this feature to the documentation?
I can directly use code like this to implement it
data = [
  { name: '李白', category: '亲人', id: '1' },
  { name: '杜甫', category: '亲人', id: '2' },
  { name: '李白', category: '租户', id: '3' },
  { name: '王之涣', category: '租户', id: '4' },
  { name: '王之涣', category: '亲人', id: '5' },
  { name: '杜甫', category: '亲人', id: '6' }
];
links = [
  { source: '4', target: '5', value: '夫妻' },
  { source: '2', target: '3', value: '租赁' },
  { source: '3', target: '4', value: '亲人' },
  { source: '1', target: '5', value: '亲人' },
  { source: '1', target: '2', value: '亲人' },
  { source: '4', target: '6', value: '亲人' }
]
option = {
  series: {
    type: 'graph',
    layout: 'force', force:{repulsion:999},
    lineStyle: { width:4 },
    symbolSize: 55, label:{show: true},
    //edgeLabel:{show: true},
    data: data,
    links: links,
    categories: [
      {name:'亲人',itemStyle:{color:'red'}},
      {name:'租户',itemStyle:{color:'blue'}}
    ],
  }
};

You can directly use it without the need to convert dataIndex.

wow, you are right, links work directly with node IDs!
So that's another documentation omission (Easter egg) 🐣
Someday, someone, will fix them all... ⌛

I'm looking forward to it

I'm reopening this issue as I encountered the same problem with a Sankey diagram.
However, for Sankey diagrams, the id is prioritized over the name, making this technique ineffective!
The solution is to use a formatter: as shown here

authors: Nicooow helgasoft zshtxwd


text:
FINERACT-780: Unique id for hook test

Description
Describe the changes made and why they were made. Ignore if these details are present on the associated Jira ticket
Checklist
Please make sure these boxes are checked before submitting your pull request - thanks!

[x] Commit message starts with the issue number from https://issues.apache.org/jira/projects/FINERACT/. Ex: FINERACT-646 Pockets API.

[x] Coding conventions at https://cwiki.apache.org/confluence/display/FINERACT/Coding+Conventions have been followed.

[x] API documentation at https://github.com/apache/fineract/blob/develop/api-docs/apiLive.htm has been updated with details of any API changes.

[x] Integration tests have been created/updated for verifying the changes made.

[x] All Integrations tests are passing with the new commits.

[x] Submission is not a "code dump".  (Large changes can be made "in repository" via a branch.  Ask on the list.)

Our guidelines for code reviews is at https://cwiki.apache.org/confluence/display/FINERACT/Code+Review+Guide

I'm not entirely sure it will fix FINERACT-780, but let's try! At the very least, I guess this cannot hurt.

authors: mohitsinha vorburger

repo: apache/fineract


text:
[e2e] add pipeline e2e test for mysql connector.

This closes https://github.com/ververica/flink-cdc-connectors/issues/2859.
Add e2e test for two scenes: sync the whole database and sync sharding tables using route function.
To simplify the complexity of different source/sink combinations, I plan to use MySQL as the source for all sinks and Doris as the sink for all sources.
Include two latest major version of Flink, 1.17.1 & 1.18.0.

@leonardBang @GOODBOY008 PTAL.

@leonardBang  can you help to rerun the failure CI of  mongodb

Rebased to master.

@loserwang1024 Adding value to value e2e test is useless as values connector is designed for test, it’s different with other connectors like MySQL, StarRocks, etc.

@lvyanquan could help rebase this PR and resolve the comments as well?

I've fixed the checkstyle failure and rebased to master.

authors: leonardBang lvyanquan

repo: apache/flink-cdc


text:
[FLINK-21641][python] Support 'useModules' and 'listFullModules' in PyFlink

What is the purpose of the change
This pull request supports useModules and listFullModules in PyFlink to keep Table API consistent.
Brief change log

Add implementation of interface method useModules and listFullModules in TableEnvironment.
Add class ModuleEntry for converting result of useModules.
Add class ModuleMock for testing.

Verifying this change
This change added tests and can be verified as follows:

Remove loadModule/unloadModule/listModules/useModules/listFullModules from EnvironmentAPICompletenessTests.
Add more tests for load_modules and unload_modules in TableEnvironmentTest and BatchTableEnvironmentTests.
Add tests for use_modules and list_full_modules in TableEnvironmentTest and BatchTableEnvironmentTests.

Does this pull request potentially affect one of the following parts:

Dependencies (does it add or upgrade a dependency): (yes / no)
The public API, i.e., is any changed class annotated with @Public(Evolving): (yes / no)
The serializers: (yes / no / don't know)
The runtime per-record code paths (performance sensitive): (yes / no / don't know)
Anything that affects deployment or recovery: JobManager (and its components), Checkpointing, Kubernetes/Yarn/Mesos, ZooKeeper: (yes / no / don't know)
The S3 file system connector: (yes / no / don't know)

Documentation

Does this pull request introduce a new feature? (yes / no)
If yes, how is the feature documented? (not applicable / docs / JavaDocs / not documented)

Docs will be updated after FLINK-21300 finish.

@LadyForest Thanks for the PR! LGTM overall. It would be great to also update the documentation: https://ci.apache.org/projects/flink/flink-docs-master/docs/dev/table/modules/

Hi, @dianfu thanks for the comments. There is a separate Jira task FLINK-21300 to track docs update. It's a subtask of FLINK-21045.

Hi @dianfu, I've updated the PR, and you can take a look after CI passes.

repo: apache/flink


text:
[hotfix] Fix comment typos in AsyncIOExample

What is the purpose of the change
fix comment typos in AsyncIOExample.java
Brief change log
illustrates -> illustrate
Verifying this change
no
Does this pull request potentially affect one of the following parts:

Dependencies (does it add or upgrade a dependency): (no)
The public API, i.e., is any changed class annotated with @Public(Evolving): ( no)
The serializers: (no)
The runtime per-record code paths (performance sensitive): (no)
Anything that affects deployment or recovery: JobManager (and its components), Checkpointing, Kubernetes/Yarn, ZooKeeper: (no)
The S3 file system connector: (no)

Documentation

Does this pull request introduce a new feature? (no)
If yes, how is the feature documented? (not documented)

I edited the description and title of PR again. Please take a look. Thank you. 😄

@hililiwei You haven't updated the commit message, you have updated the PR title

@hililiwei You haven't updated the commit message, you have updated the PR title

updated. thx. 😄

authors: MartijnVisser hililiwei


text:
[FLINK-27751][build] Disable jboss repository

Temporarily disables the jboss repository, as it is currently down.

Will merge it once the compile stage passes.


text:
[FLINK-29217][tests] Guarantee checkpoint order in OC test

What is the purpose of the change
#20752 and #20754 have added test cases to verify that the operator coordinator can work correctly in case of concurrent checkpoints. However, when the checkpoint coordinator receives the completion message of checkpoint 1 and 2 at the same time, checkpoint 2 might be completed in advance due to the async mechanism in the checkpointing process, causing the accidental abortion of checkpoint 1 and failure of the added test case. This PR resolves the problem by further guaranteeing the completion order of the checkpoints received by test operators and coordinators.
Does this pull request potentially affect one of the following parts:

Dependencies (does it add or upgrade a dependency): (no)

The public API, i.e., is any changed class annotated with @Public(Evolving): (no)

The serializers: (no)

The runtime per-record code paths (performance sensitive): (no)

Anything that affects deployment or recovery: JobManager (and its components), Checkpointing, Kubernetes/Yarn, ZooKeeper: (no)

The S3 file system connector: (no)

Documentation

Does this pull request introduce a new feature? (no)
If yes, how is the feature documented? (not applicable)

Thanks for the PR! LGTM.


text:
[FLINK-4119] Null checks in close() for Cassandra Input/Output Formats, checking arguments via Flink Preconditions

Thanks for contributing to Apache Flink. Before you open your pull request, please take the following check list into consideration.
If your changes take all of the items into account, feel free to open your pull request. For more information and/or questions please refer to the How To Contribute guide.
In addition to going through the list, please provide a meaningful description of your changes.

[x] General

The pull request references the related JIRA issue ("[FLINK-XXX] Jira title text")
The pull request addresses only one issue
Each commit in the PR has a meaningful commit message (including the JIRA id)

[ ] Documentation

Documentation has been added for new functionality
Old documentation affected by the pull request has been updated
JavaDoc for public methods has been added

[x] Tests & Build

Functionality added by the pull request is covered by tests
mvn clean verify has been executed successfully locally or a Travis build has passed

…tions

+1 to merge

merging

authors: alkagin rmetzger zentol


text:
[FLINK-32074][checkpoint] Merge file across checkpoints

What is the purpose of the change
As one part of FLIP-306, this PR enables the file merging across checkpoints.
Brief change log

Added new type of file merging manager
Add corresponding tests

Verifying this change
Added AcrossCheckpointFileMergingSnapshotManagerTest for new manager.
Does this pull request potentially affect one of the following parts:

Dependencies (does it add or upgrade a dependency): (yes / no)
The public API, i.e., is any changed class annotated with @Public(Evolving): (yes / no)
The serializers: (yes / no / don't know)
The runtime per-record code paths (performance sensitive): (yes / no / don't know)
Anything that affects deployment or recovery: JobManager (and its components), Checkpointing, Kubernetes/Yarn, ZooKeeper: (yes / no / don't know)
The S3 file system connector: (yes / no / don't know)

Documentation

Does this pull request introduce a new feature? (yes / no)
If yes, how is the feature documented? (not applicable / docs / JavaDocs / not documented)

Hi @fredia @masteryhx , would you please take a look? Thanks

@flinkbot run azure

@flinkbot run azure

Thanks for the update. The code LGTM % CI. The CI failed due to spotless, Could you fix this @Zakelly ?

@masteryhx
My mistake. Now the CI finally got green.

Thanks for the update.
Merged 841f23c7 into master.

authors: Zakelly masteryhx


text:
[FLINK-36711][runtime] Add tips when System out and err are redirected to LOG or discarded

What is the purpose of the change
When System.out and System.err are redirected to LOG or discarded, there are some scenarios that do not match the user's expectations, leading them to be unclear about how to view the relevant output information. Add tips when System out and err are redirected to LOG or discarded to remind the person who going to view the out/err file of the expected effect of the current configuration.(See FLINK-36711 for details)
Brief change log

Add tips when System out and err are redirected to LOG or discarded

Verifying this change
This change added tests and can be verified as follows:

Updated SystemOutRedirectionUtilsTest to accommodate this change

Does this pull request potentially affect one of the following parts:

Dependencies (does it add or upgrade a dependency): no
The public API, i.e., is any changed class annotated with @Public(Evolving): no
The serializers: no
The runtime per-record code paths (performance sensitive): no
Anything that affects deployment or recovery: JobManager (and its components), Checkpointing, Kubernetes/Yarn, ZooKeeper: no
The S3 file system connector: no

Documentation

Does this pull request introduce a new feature? no
If yes, how is the feature documented? not applicable

@flinkbot run azure

@flinkbot run azure

@flinkbot run azure

@flinkbot run azure


text:
[FLINK-8172][network] Write directly to memorySegment in RecordSerializer

This increases throughput of network stack by factor of 2, because previously method getMemorySegment() was called twice per record and it is a synchronized method on recycleLock, while RecordSerializer is sole owner of the Buffer at this point, so synchronisation is not needed.
Verifying this change
This change is already covered by existing tests in flink-runtime.
Does this pull request potentially affect one of the following parts:

Dependencies (does it add or upgrade a dependency): (yes / no)
The public API, i.e., is any changed class annotated with @Public(Evolving): (yes / no)
The serializers: (yes / no / don't know)
The runtime per-record code paths (performance sensitive): (YES / no / don't know)
Anything that affects deployment or recovery: JobManager (and its components), Checkpointing, Yarn/Mesos, ZooKeeper: (yes / no / don't know)
The S3 file system connector: (yes / no / don't know)

Documentation

Does this pull request introduce a new feature? (yes / no)
If yes, how is the feature documented? (not applicable / docs / JavaDocs / not documented)

2 times improvement is for network stack only. With other things in play (like even simple operators) it will be smaller.
As we discussed offline, I didn't want tightening up the connection/dependencies of RecordSerializer. Buffer is a much simpler dependency compare to BufferProvider. Think how more difficult would it be to test it with BufferProvider. However I was thinking about refactoring it in another direction, creating kind of write-only @NotThreadSafe BufferBuilder class.
I have create a separate issue for that: https://issues.apache.org/jira/browse/FLINK-8178


text:
[FLINK-9788] Fix ExecutionGraph inconsistency for global failures when restarting

What is the purpose of the change
The problem was that a concurrent global failure could start a concurrent
restart operation without terminating the previous operation. Terminating
the previous restart operation means to cancel all current Executions and
wait for cancellation completion. Due to the missing wait, it could happen
that previously reset Executions are being tried to reset again. This violates
a sanity check and would lead to a restart loop.
The problem is fixed by not distinguishing between a fail which happens in
state JobStatus.RESTARTING and in any other state. Due to this, we will always
cancel all existing Executions and only trigger the restart after all Executions
have reached a terminal state.
Brief change log

Remove RESTARTING branch from ExecutionGraph#failGlobal
Use expectedGlobalVersion when resetting Executions in ExecutionGraph#restart

Verifying this change

Added ExecutionGraphRestartTest#testConcurrentFailureWhileRestarting

Does this pull request potentially affect one of the following parts:

Dependencies (does it add or upgrade a dependency): (no)
The public API, i.e., is any changed class annotated with @Public(Evolving): (no)
The serializers: (no)
The runtime per-record code paths (performance sensitive): (no)
Anything that affects deployment or recovery: JobManager (and its components), Checkpointing, Yarn/Mesos, ZooKeeper: (yes)
The S3 file system connector: (no)

Documentation

Does this pull request introduce a new feature? (no)
If yes, how is the feature documented? (not applicable)

+1 LGTM, nice testing!

LGTM 👍

Thanks for the review @ifndef-SleePy and @StefanRRichter. Merging this PR.