[jira] [Updated] (IGNITE-7391) Web console: ClientConfigurationFactory class name is missing in generated project
[ https://issues.apache.org/jira/browse/IGNITE-7391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov updated IGNITE-7391: - Fix Version/s: 2.4 > Web console: ClientConfigurationFactory class name is missing in generated > project > -- > > Key: IGNITE-7391 > URL: https://issues.apache.org/jira/browse/IGNITE-7391 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.4 >Reporter: Pavel Konstantinov >Assignee: Alexey Kuznetsov >Priority: Blocker > Fix For: 2.4 > > > It present in Java preview but absent in downloaded project -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (IGNITE-7275) Admin panel: Grant\Revoke menu item text doesn't change
[ https://issues.apache.org/jira/browse/IGNITE-7275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov reassigned IGNITE-7275: Resolution: Fixed Assignee: Pavel Konstantinov (was: Alexey Kuznetsov) Looks good. Merged to master. > Admin panel: Grant\Revoke menu item text doesn't change > --- > > Key: IGNITE-7275 > URL: https://issues.apache.org/jira/browse/IGNITE-7275 > Project: Ignite > Issue Type: Bug > Components: wizards >Reporter: Alexander Kalinin >Assignee: Pavel Konstantinov > Fix For: 2.4 > > > # select any ordinary user and Grant admin rights - admin rights were > successfully granted > # open Action menu - menu item text still says 'Grant' but should be > 'Revoke...' > # select another user then select prev user - only after that menu item > become has right text -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-7275) Admin panel: Grant\Revoke menu item text doesn't change
[ https://issues.apache.org/jira/browse/IGNITE-7275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov updated IGNITE-7275: - Fix Version/s: 2.4 > Admin panel: Grant\Revoke menu item text doesn't change > --- > > Key: IGNITE-7275 > URL: https://issues.apache.org/jira/browse/IGNITE-7275 > Project: Ignite > Issue Type: Bug > Components: wizards >Reporter: Alexander Kalinin >Assignee: Alexey Kuznetsov > Fix For: 2.4 > > > # select any ordinary user and Grant admin rights - admin rights were > successfully granted > # open Action menu - menu item text still says 'Grant' but should be > 'Revoke...' > # select another user then select prev user - only after that menu item > become has right text -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-6456) Add flags to ClientConnectorConfiguration which enable/disable different clients
[
https://issues.apache.org/jira/browse/IGNITE-6456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16323627#comment-16323627
]
Roman Kondakov commented on IGNITE-6456:
[~ptupitsyn],
* Exceptions look appropriate solution for this case due to multiple possible
causes of failure - wrong client, disabled client or unsupported version. And
exception here is a quite convenient way to stop execution and transfer an
error message back to the client.
* I've fixed error message.
[~vozerov], [~ptupitsyn], please review. [TC
run|https://ci.ignite.apache.org/viewLog.html?buildId=1034773&;] is not OK, but
failures are caused by problems in the master branch. JDBC tests are ok.
> Add flags to ClientConnectorConfiguration which enable/disable different
> clients
>
>
> Key: IGNITE-6456
> URL: https://issues.apache.org/jira/browse/IGNITE-6456
> Project: Ignite
> Issue Type: Improvement
> Components: jdbc, odbc, thin client
>Affects Versions: 2.1
>Reporter: Igor Sapego
>Assignee: Roman Kondakov
> Labels: usability
> Fix For: 2.4
>
>
> There is currently no way to disable only one client. For example, currently
> you can't disallow thin JDBC driver connectivity alone, you can only disable
> the whole {{ClientListenerProcessor}}, which is going to disable ODBC and
> thin .NET clients as well.
> We should add options to disable/enable every single client, supported by the
> {{ClientListenerProcessor}} separately. For example, we can add flags to the
> {{ClientConnectorConfiguration}}:
> {{allowJdbc}}
> {{allowOdbc}}
> {{allowClient}}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-7391) Web console: ClientConfigurationFactory class name is missing in generated project
[ https://issues.apache.org/jira/browse/IGNITE-7391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16323625#comment-16323625 ] Pavel Konstantinov commented on IGNITE-7391: Tested. Can be merged. > Web console: ClientConfigurationFactory class name is missing in generated > project > -- > > Key: IGNITE-7391 > URL: https://issues.apache.org/jira/browse/IGNITE-7391 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.4 >Reporter: Pavel Konstantinov >Assignee: Pavel Konstantinov >Priority: Blocker > > It present in Java preview but absent in downloaded project -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (IGNITE-7391) Web console: ClientConfigurationFactory class name is missing in generated project
[ https://issues.apache.org/jira/browse/IGNITE-7391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Konstantinov reassigned IGNITE-7391: -- Assignee: Alexey Kuznetsov (was: Pavel Konstantinov) > Web console: ClientConfigurationFactory class name is missing in generated > project > -- > > Key: IGNITE-7391 > URL: https://issues.apache.org/jira/browse/IGNITE-7391 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.4 >Reporter: Pavel Konstantinov >Assignee: Alexey Kuznetsov >Priority: Blocker > > It present in Java preview but absent in downloaded project -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (IGNITE-7391) Web console: ClientConfigurationFactory class name is missing in generated project
[ https://issues.apache.org/jira/browse/IGNITE-7391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Konstantinov resolved IGNITE-7391. Resolution: Fixed > Web console: ClientConfigurationFactory class name is missing in generated > project > -- > > Key: IGNITE-7391 > URL: https://issues.apache.org/jira/browse/IGNITE-7391 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.4 >Reporter: Pavel Konstantinov >Assignee: Alexey Kuznetsov >Priority: Blocker > > It present in Java preview but absent in downloaded project -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (IGNITE-7295) Log of thin client is not disabled in special case
[ https://issues.apache.org/jira/browse/IGNITE-7295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov reassigned IGNITE-7295: Resolution: Fixed Assignee: Pavel Konstantinov (was: Alexey Kuznetsov) Looks good. Merged to master. > Log of thin client is not disabled in special case > -- > > Key: IGNITE-7295 > URL: https://issues.apache.org/jira/browse/IGNITE-7295 > Project: Ignite > Issue Type: Bug > Components: thin client >Affects Versions: 2.3 >Reporter: Vasiliy Sisko >Assignee: Pavel Konstantinov >Priority: Minor > Fix For: 2.4 > > > Should be possibility to enable/disable thin client log. > We try to disable thin client log in GridClientImpl.java. > If log4j is located in a classpath log will be showed (f.e. when thin client > is run from Windows console) -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-7295) Log of thin client is not disabled in special case
[ https://issues.apache.org/jira/browse/IGNITE-7295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov updated IGNITE-7295: - Fix Version/s: 2.4 > Log of thin client is not disabled in special case > -- > > Key: IGNITE-7295 > URL: https://issues.apache.org/jira/browse/IGNITE-7295 > Project: Ignite > Issue Type: Bug > Components: thin client >Affects Versions: 2.3 >Reporter: Vasiliy Sisko >Assignee: Alexey Kuznetsov >Priority: Minor > Fix For: 2.4 > > > Should be possibility to enable/disable thin client log. > We try to disable thin client log in GridClientImpl.java. > If log4j is located in a classpath log will be showed (f.e. when thin client > is run from Windows console) -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-7257) Web console: fix reconnection after change profile
[ https://issues.apache.org/jira/browse/IGNITE-7257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16323524#comment-16323524 ] Pavel Konstantinov commented on IGNITE-7257: Tested > Web console: fix reconnection after change profile > -- > > Key: IGNITE-7257 > URL: https://issues.apache.org/jira/browse/IGNITE-7257 > Project: Ignite > Issue Type: Bug >Reporter: Dmitriy Shabalin >Assignee: Pavel Konstantinov > Fix For: 2.4 > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (IGNITE-7257) Web console: fix reconnection after change profile
[ https://issues.apache.org/jira/browse/IGNITE-7257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Konstantinov closed IGNITE-7257. -- > Web console: fix reconnection after change profile > -- > > Key: IGNITE-7257 > URL: https://issues.apache.org/jira/browse/IGNITE-7257 > Project: Ignite > Issue Type: Bug >Reporter: Dmitriy Shabalin >Assignee: Pavel Konstantinov > Fix For: 2.4 > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (IGNITE-7238) Web console: incorrect "Download agent" button color
[ https://issues.apache.org/jira/browse/IGNITE-7238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov reassigned IGNITE-7238: Resolution: Fixed Assignee: Pavel Konstantinov (was: Alexey Kuznetsov) Merged to master. > Web console: incorrect "Download agent" button color > > > Key: IGNITE-7238 > URL: https://issues.apache.org/jira/browse/IGNITE-7238 > Project: Ignite > Issue Type: Bug > Components: wizards >Reporter: Ilya Borisov >Assignee: Pavel Konstantinov >Priority: Minor > Fix For: 2.4 > > Attachments: screenshot-1.png > > > *How to reproduce:* > 1. Start demo mode, do not start a web agent. > 2. Wait for "Connection to Ignite Web Agent is not established" dialog to > appear. > 3. Focus on "Download agent" using Tab button (or any other way). > *What happens:* > "Download agent" label becomes red. > *What should happen:* > "Download agent" label should remain white. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-7391) Web console: ClientConfigurationFactory class name is missing in generated project
[ https://issues.apache.org/jira/browse/IGNITE-7391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16323501#comment-16323501 ] Vasiliy Sisko commented on IGNITE-7391: --- Fixed generation of configuration factory classes. > Web console: ClientConfigurationFactory class name is missing in generated > project > -- > > Key: IGNITE-7391 > URL: https://issues.apache.org/jira/browse/IGNITE-7391 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.4 >Reporter: Pavel Konstantinov >Assignee: Vasiliy Sisko >Priority: Blocker > > It present in Java preview but absent in downloaded project -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (IGNITE-7391) Web console: ClientConfigurationFactory class name is missing in generated project
[ https://issues.apache.org/jira/browse/IGNITE-7391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vasiliy Sisko reassigned IGNITE-7391: - Assignee: Pavel Konstantinov (was: Vasiliy Sisko) > Web console: ClientConfigurationFactory class name is missing in generated > project > -- > > Key: IGNITE-7391 > URL: https://issues.apache.org/jira/browse/IGNITE-7391 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.4 >Reporter: Pavel Konstantinov >Assignee: Pavel Konstantinov >Priority: Blocker > > It present in Java preview but absent in downloaded project -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-7238) Web console: incorrect "Download agent" button color
[ https://issues.apache.org/jira/browse/IGNITE-7238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov updated IGNITE-7238: - Fix Version/s: 2.4 > Web console: incorrect "Download agent" button color > > > Key: IGNITE-7238 > URL: https://issues.apache.org/jira/browse/IGNITE-7238 > Project: Ignite > Issue Type: Bug > Components: wizards >Reporter: Ilya Borisov >Assignee: Alexey Kuznetsov >Priority: Minor > Fix For: 2.4 > > Attachments: screenshot-1.png > > > *How to reproduce:* > 1. Start demo mode, do not start a web agent. > 2. Wait for "Connection to Ignite Web Agent is not established" dialog to > appear. > 3. Focus on "Download agent" using Tab button (or any other way). > *What happens:* > "Download agent" label becomes red. > *What should happen:* > "Download agent" label should remain white. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (IGNITE-7224) Web console: Remove deprecated fields from configuration
[ https://issues.apache.org/jira/browse/IGNITE-7224?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov reassigned IGNITE-7224: Resolution: Fixed Assignee: Pavel Konstantinov (was: Alexey Kuznetsov) Looks good. Merged to master. > Web console: Remove deprecated fields from configuration > > > Key: IGNITE-7224 > URL: https://issues.apache.org/jira/browse/IGNITE-7224 > Project: Ignite > Issue Type: Bug > Components: wizards >Reporter: Vasiliy Sisko >Assignee: Pavel Konstantinov > Fix For: 2.4 > > > Ignite configuration: > # setMarshaller is deprecated since 2.1. > # setLateAffinityAssignment is always enabled since 2.1. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-7224) Web console: Remove deprecated fields from configuration
[ https://issues.apache.org/jira/browse/IGNITE-7224?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov updated IGNITE-7224: - Fix Version/s: 2.4 > Web console: Remove deprecated fields from configuration > > > Key: IGNITE-7224 > URL: https://issues.apache.org/jira/browse/IGNITE-7224 > Project: Ignite > Issue Type: Bug > Components: wizards >Reporter: Vasiliy Sisko >Assignee: Alexey Kuznetsov > Fix For: 2.4 > > > Ignite configuration: > # setMarshaller is deprecated since 2.1. > # setLateAffinityAssignment is always enabled since 2.1. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-7392) visorcmd: missed word 'factory' in the lables
[ https://issues.apache.org/jira/browse/IGNITE-7392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Konstantinov updated IGNITE-7392: --- Attachment: screenshot-1.png > visorcmd: missed word 'factory' in the lables > - > > Key: IGNITE-7392 > URL: https://issues.apache.org/jira/browse/IGNITE-7392 > Project: Ignite > Issue Type: Bug >Reporter: Pavel Konstantinov >Assignee: Vasiliy Sisko >Priority: Trivial > Fix For: 2.4 > > Attachments: screenshot-1.png > > > We need to add 'factory' into label 'Eviction policy' and 'Near eviction > policy' -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-7392) visorcmd: missed word 'factory' in the lables
[ https://issues.apache.org/jira/browse/IGNITE-7392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Konstantinov updated IGNITE-7392: --- Description: We need to add 'factory' into label 'Eviction policy' and 'Near eviction policy' !screenshot-1.png! was:We need to add 'factory' into label 'Eviction policy' and 'Near eviction policy' > visorcmd: missed word 'factory' in the lables > - > > Key: IGNITE-7392 > URL: https://issues.apache.org/jira/browse/IGNITE-7392 > Project: Ignite > Issue Type: Bug >Reporter: Pavel Konstantinov >Assignee: Vasiliy Sisko >Priority: Trivial > Fix For: 2.4 > > Attachments: screenshot-1.png > > > We need to add 'factory' into label 'Eviction policy' and 'Near eviction > policy' > !screenshot-1.png! -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-7392) visorcmd: missed word 'factory' in the lables
Pavel Konstantinov created IGNITE-7392: -- Summary: visorcmd: missed word 'factory' in the lables Key: IGNITE-7392 URL: https://issues.apache.org/jira/browse/IGNITE-7392 Project: Ignite Issue Type: Bug Reporter: Pavel Konstantinov Assignee: Vasiliy Sisko Priority: Trivial Fix For: 2.4 We need to add 'factory' into label 'Eviction policy' and 'Near eviction policy' -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (IGNITE-7225) Web console: improve CSV export
[ https://issues.apache.org/jira/browse/IGNITE-7225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov reassigned IGNITE-7225: Assignee: Pavel Konstantinov (was: Alexey Kuznetsov) > Web console: improve CSV export > --- > > Key: IGNITE-7225 > URL: https://issues.apache.org/jira/browse/IGNITE-7225 > Project: Ignite > Issue Type: Bug > Components: wizards > Environment: Browsers with ru and en locales. >Reporter: Ilya Borisov >Assignee: Pavel Konstantinov > Fix For: 2.4 > > > *What to do:* > When exporting to CSV, rely on user's locale and number decimal separator > symbol to determine what to use as a CSV separator. > *Motivation:* > During export to CSV, numbers are formatted depending on user's locale. In > _non-import mode_, MS Excel requires comma as a decimal separator and > semicolon as a CSV separator for _ru_ locale and dot/comma respectively for > _en_. After resolving this issue, CSV export will become more aware of user's > environment. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-6995) Visor CMD: Actualize showed grid/cache configuration.
[ https://issues.apache.org/jira/browse/IGNITE-6995?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16323476#comment-16323476 ] Pavel Konstantinov commented on IGNITE-6995: Tested > Visor CMD: Actualize showed grid/cache configuration. > - > > Key: IGNITE-6995 > URL: https://issues.apache.org/jira/browse/IGNITE-6995 > Project: Ignite > Issue Type: Bug > Components: wizards >Reporter: Vasiliy Sisko >Assignee: Pavel Konstantinov > Fix For: 2.4 > > > Actualise in accordance to IGNITE-6649 changes. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (IGNITE-6995) Visor CMD: Actualize showed grid/cache configuration.
[ https://issues.apache.org/jira/browse/IGNITE-6995?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Konstantinov closed IGNITE-6995. -- > Visor CMD: Actualize showed grid/cache configuration. > - > > Key: IGNITE-6995 > URL: https://issues.apache.org/jira/browse/IGNITE-6995 > Project: Ignite > Issue Type: Bug > Components: wizards >Reporter: Vasiliy Sisko >Assignee: Pavel Konstantinov > Fix For: 2.4 > > > Actualise in accordance to IGNITE-6649 changes. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-7391) Web console: ClientConfigurationFactory class name is missing in generated project
Pavel Konstantinov created IGNITE-7391: -- Summary: Web console: ClientConfigurationFactory class name is missing in generated project Key: IGNITE-7391 URL: https://issues.apache.org/jira/browse/IGNITE-7391 Project: Ignite Issue Type: Bug Reporter: Pavel Konstantinov Assignee: Vasiliy Sisko Priority: Blocker It present in Java preview but absent in downloaded project -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-7391) Web console: ClientConfigurationFactory class name is missing in generated project
[ https://issues.apache.org/jira/browse/IGNITE-7391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Konstantinov updated IGNITE-7391: --- Affects Version/s: 2.4 > Web console: ClientConfigurationFactory class name is missing in generated > project > -- > > Key: IGNITE-7391 > URL: https://issues.apache.org/jira/browse/IGNITE-7391 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.4 >Reporter: Pavel Konstantinov >Assignee: Vasiliy Sisko >Priority: Blocker > > It present in Java preview but absent in downloaded project -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-7225) Web console: improve CSV export
[ https://issues.apache.org/jira/browse/IGNITE-7225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov updated IGNITE-7225: - Fix Version/s: 2.4 > Web console: improve CSV export > --- > > Key: IGNITE-7225 > URL: https://issues.apache.org/jira/browse/IGNITE-7225 > Project: Ignite > Issue Type: Bug > Components: wizards > Environment: Browsers with ru and en locales. >Reporter: Ilya Borisov >Assignee: Alexey Kuznetsov > Fix For: 2.4 > > > *What to do:* > When exporting to CSV, rely on user's locale and number decimal separator > symbol to determine what to use as a CSV separator. > *Motivation:* > During export to CSV, numbers are formatted depending on user's locale. In > _non-import mode_, MS Excel requires comma as a decimal separator and > semicolon as a CSV separator for _ru_ locale and dot/comma respectively for > _en_. After resolving this issue, CSV export will become more aware of user's > environment. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (IGNITE-7210) Web console: Fix show time of "Connected clusters: N" label
[ https://issues.apache.org/jira/browse/IGNITE-7210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov closed IGNITE-7210. > Web console: Fix show time of "Connected clusters: N" label > --- > > Key: IGNITE-7210 > URL: https://issues.apache.org/jira/browse/IGNITE-7210 > Project: Ignite > Issue Type: Bug > Components: website >Reporter: Vasiliy Sisko >Assignee: Alexey Kuznetsov > Fix For: 2.4 > > > Now that label showed quickly when login screen still shown or page is fully > empty. > Should appear together with page content. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-7210) Web console: Fix show time of "Connected clusters: N" label
[ https://issues.apache.org/jira/browse/IGNITE-7210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov updated IGNITE-7210: - Fix Version/s: 2.4 > Web console: Fix show time of "Connected clusters: N" label > --- > > Key: IGNITE-7210 > URL: https://issues.apache.org/jira/browse/IGNITE-7210 > Project: Ignite > Issue Type: Bug > Components: website >Reporter: Vasiliy Sisko >Assignee: Alexey Kuznetsov > Fix For: 2.4 > > > Now that label showed quickly when login screen still shown or page is fully > empty. > Should appear together with page content. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-7036) Web console: Wrong export of grouped users
[ https://issues.apache.org/jira/browse/IGNITE-7036?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16323462#comment-16323462 ] Pavel Konstantinov commented on IGNITE-7036: Now users are exported but all the metrics are empty > Web console: Wrong export of grouped users > -- > > Key: IGNITE-7036 > URL: https://issues.apache.org/jira/browse/IGNITE-7036 > Project: Ignite > Issue Type: Bug > Components: wizards >Reporter: Vasiliy Sisko >Assignee: Pavel Konstantinov > Fix For: 2.4 > > > On export of grouped users when group is collapsed in table only header row > is exported. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Reopened] (IGNITE-7036) Web console: Wrong export of grouped users
[ https://issues.apache.org/jira/browse/IGNITE-7036?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Konstantinov reopened IGNITE-7036: > Web console: Wrong export of grouped users > -- > > Key: IGNITE-7036 > URL: https://issues.apache.org/jira/browse/IGNITE-7036 > Project: Ignite > Issue Type: Bug > Components: wizards >Reporter: Vasiliy Sisko >Assignee: Dmitriy Shabalin > Fix For: 2.4 > > > On export of grouped users when group is collapsed in table only header row > is exported. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (IGNITE-7036) Web console: Wrong export of grouped users
[ https://issues.apache.org/jira/browse/IGNITE-7036?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Konstantinov reassigned IGNITE-7036: -- Assignee: Dmitriy Shabalin (was: Pavel Konstantinov) > Web console: Wrong export of grouped users > -- > > Key: IGNITE-7036 > URL: https://issues.apache.org/jira/browse/IGNITE-7036 > Project: Ignite > Issue Type: Bug > Components: wizards >Reporter: Vasiliy Sisko >Assignee: Dmitriy Shabalin > Fix For: 2.4 > > > On export of grouped users when group is collapsed in table only header row > is exported. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (IGNITE-5697) Web Console should be configurable for IPv4 connections
[ https://issues.apache.org/jira/browse/IGNITE-5697?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Novikov reassigned IGNITE-5697: -- Assignee: Andrey Novikov (was: Michael Griggs) > Web Console should be configurable for IPv4 connections > --- > > Key: IGNITE-5697 > URL: https://issues.apache.org/jira/browse/IGNITE-5697 > Project: Ignite > Issue Type: Bug > Components: wizards >Affects Versions: 2.0 >Reporter: Michael Griggs >Assignee: Andrey Novikov > Fix For: 2.3 > > > When an IPv6 network interface is available, NodeJS will always prefer that > to an IPv4 interface. This causes problems if IPv6 is not fully operational > on the network. > This fix will add the ability to specify that IPv4 should be used. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (IGNITE-5697) Web Console should be configurable for IPv4 connections
[
https://issues.apache.org/jira/browse/IGNITE-5697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16323432#comment-16323432
]
Andrey Novikov edited comment on IGNITE-5697 at 1/12/18 2:15 AM:
-
This problem was fixed by adding host parameter in settings:
{code}srv.listen(settings.server.port, settings.server.host){code}
By default settings.server.host = '127.0.0.1', settings.server.port = 3000
was (Author: anovikov):
This problem was fixed by adding host parameter to settings:
{code}srv.listen(settings.server.port, settings.server.host){code}
By default settings.server.host = '127.0.0.1', settings.server.port = 3000
> Web Console should be configurable for IPv4 connections
> ---
>
> Key: IGNITE-5697
> URL: https://issues.apache.org/jira/browse/IGNITE-5697
> Project: Ignite
> Issue Type: Bug
> Components: wizards
>Affects Versions: 2.0
>Reporter: Michael Griggs
>Assignee: Michael Griggs
> Fix For: 2.3
>
>
> When an IPv6 network interface is available, NodeJS will always prefer that
> to an IPv4 interface. This causes problems if IPv6 is not fully operational
> on the network.
> This fix will add the ability to specify that IPv4 should be used.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (IGNITE-5697) Web Console should be configurable for IPv4 connections
[ https://issues.apache.org/jira/browse/IGNITE-5697?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Novikov resolved IGNITE-5697. Resolution: Fixed Fix Version/s: 2.3 > Web Console should be configurable for IPv4 connections > --- > > Key: IGNITE-5697 > URL: https://issues.apache.org/jira/browse/IGNITE-5697 > Project: Ignite > Issue Type: Bug > Components: wizards >Affects Versions: 2.0 >Reporter: Michael Griggs >Assignee: Andrey Novikov > Fix For: 2.3 > > > When an IPv6 network interface is available, NodeJS will always prefer that > to an IPv4 interface. This causes problems if IPv6 is not fully operational > on the network. > This fix will add the ability to specify that IPv4 should be used. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (IGNITE-5697) Web Console should be configurable for IPv4 connections
[ https://issues.apache.org/jira/browse/IGNITE-5697?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Novikov closed IGNITE-5697. -- > Web Console should be configurable for IPv4 connections > --- > > Key: IGNITE-5697 > URL: https://issues.apache.org/jira/browse/IGNITE-5697 > Project: Ignite > Issue Type: Bug > Components: wizards >Affects Versions: 2.0 >Reporter: Michael Griggs >Assignee: Andrey Novikov > Fix For: 2.3 > > > When an IPv6 network interface is available, NodeJS will always prefer that > to an IPv4 interface. This causes problems if IPv6 is not fully operational > on the network. > This fix will add the ability to specify that IPv4 should be used. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-5697) Web Console should be configurable for IPv4 connections
[
https://issues.apache.org/jira/browse/IGNITE-5697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16323432#comment-16323432
]
Andrey Novikov commented on IGNITE-5697:
This problem was fixed by adding host parameter to settings:
{code}srv.listen(settings.server.port, settings.server.host){code}
By default settings.server.host = '127.0.0.1', settings.server.port = 3000
> Web Console should be configurable for IPv4 connections
> ---
>
> Key: IGNITE-5697
> URL: https://issues.apache.org/jira/browse/IGNITE-5697
> Project: Ignite
> Issue Type: Bug
> Components: wizards
>Affects Versions: 2.0
>Reporter: Michael Griggs
>Assignee: Michael Griggs
>
> When an IPv6 network interface is available, NodeJS will always prefer that
> to an IPv4 interface. This causes problems if IPv6 is not fully operational
> on the network.
> This fix will add the ability to specify that IPv4 should be used.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Assigned] (IGNITE-7357) Web Console: Add support for custom SMTP servers
[ https://issues.apache.org/jira/browse/IGNITE-7357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Novikov reassigned IGNITE-7357: -- Assignee: Alexey Kuznetsov (was: Andrey Novikov) > Web Console: Add support for custom SMTP servers > > > Key: IGNITE-7357 > URL: https://issues.apache.org/jira/browse/IGNITE-7357 > Project: Ignite > Issue Type: Improvement > Components: wizards >Reporter: Alexey Kuznetsov >Assignee: Alexey Kuznetsov > Fix For: 2.4 > > > For now Web Console supports only "external" services like GMail. > We should support custom SMTP servers also. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-7357) Web Console: Add support for custom SMTP servers
[ https://issues.apache.org/jira/browse/IGNITE-7357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16323407#comment-16323407 ] Andrey Novikov commented on IGNITE-7357: Looks good, except: MailsService.send which may throw exception or return Promise. Let's change it to always return Promise. > Web Console: Add support for custom SMTP servers > > > Key: IGNITE-7357 > URL: https://issues.apache.org/jira/browse/IGNITE-7357 > Project: Ignite > Issue Type: Improvement > Components: wizards >Reporter: Alexey Kuznetsov >Assignee: Andrey Novikov > Fix For: 2.4 > > > For now Web Console supports only "external" services like GMail. > We should support custom SMTP servers also. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (IGNITE-6352) ignite-indexing is not compatible to OSGI
[ https://issues.apache.org/jira/browse/IGNITE-6352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Setrakyan reassigned IGNITE-6352: - Assignee: Vladimir Ozerov > ignite-indexing is not compatible to OSGI > - > > Key: IGNITE-6352 > URL: https://issues.apache.org/jira/browse/IGNITE-6352 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 2.1 >Reporter: Mikhail Cherkasov >Assignee: Vladimir Ozerov > Fix For: 2.4 > > > the issue is reported by user, there's his message: > When trying to start Ignite in an OSGi context I get the following exception: > Caused by: java.lang.NoClassDefFoundError: org/h2/server/Service > at java.lang.Class.forName0(Native Method) > at java.lang.Class.forName(Class.java:264) > at > org.apache.ignite.internal.IgniteComponentType.inClassPath(IgniteComponentType.java:153) > at > org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1832) > at > org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1648) > at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1076) > at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:506) > at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:482) > at org.apache.ignite.Ignition.start(Ignition.java:304) > That is because the h2 bundle (jar) is properly osgified, but does NOT > export the package org.h2.server, so it isn't visible to my code's classloader -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-6352) ignite-indexing is not compatible to OSGI
[ https://issues.apache.org/jira/browse/IGNITE-6352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Setrakyan updated IGNITE-6352: -- Fix Version/s: 2.4 > ignite-indexing is not compatible to OSGI > - > > Key: IGNITE-6352 > URL: https://issues.apache.org/jira/browse/IGNITE-6352 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 2.1 >Reporter: Mikhail Cherkasov >Assignee: Vladimir Ozerov > Fix For: 2.4 > > > the issue is reported by user, there's his message: > When trying to start Ignite in an OSGi context I get the following exception: > Caused by: java.lang.NoClassDefFoundError: org/h2/server/Service > at java.lang.Class.forName0(Native Method) > at java.lang.Class.forName(Class.java:264) > at > org.apache.ignite.internal.IgniteComponentType.inClassPath(IgniteComponentType.java:153) > at > org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1832) > at > org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1648) > at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1076) > at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:506) > at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:482) > at org.apache.ignite.Ignition.start(Ignition.java:304) > That is because the h2 bundle (jar) is properly osgified, but does NOT > export the package org.h2.server, so it isn't visible to my code's classloader -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-6996) Smarter handling of id fields in SQL values
[
https://issues.apache.org/jira/browse/IGNITE-6996?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16323209#comment-16323209
]
Valentin Kulichenko commented on IGNITE-6996:
-
This seems to be a very specific use case with a lot of counter intuitive
drawback. I propose to close this ticket with 'Won't Fix' resolution.
> Smarter handling of id fields in SQL values
> ---
>
> Key: IGNITE-6996
> URL: https://issues.apache.org/jira/browse/IGNITE-6996
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Alexander Paschenko
>
> Consider such case:
> User wants to have a composite value (many value fields in {{QueryEntity}})
> with one field associated with value's id (most likely matching cache key
> too).
> Currently in order to insert such an object we will have to do something like
> {{INSERT INTO Person(_key, id, name) values(1, 1, 'John')}}
> And there's no way to avoid such a redundant repeat of the same value.
> Suggested approach: I believe that we should specifically handle the case
> when user specifies {{keyFieldName}} in configuration and specified field is
> field of the value.
> In such case, we could just do {{INSERT INTO Person(id, name) values(1,
> 'John')}} and derive {{_key}} value from {{id}} column. (And vice versa.)
> At a glance, this also will require following tweaks:
> - forbid performing SQL {{UPDATE}} on such column ({{id}} in above example);
> - on an {{INSERT}}, check that {{_key}} and {{id}} values are the same, if
> both specified.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (IGNITE-3495) CacheMetrics.getAverage###Time is not calculated properly
[
https://issues.apache.org/jira/browse/IGNITE-3495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Magda updated IGNITE-3495:
Labels: (was: iep-6)
> CacheMetrics.getAverage###Time is not calculated properly
> -
>
> Key: IGNITE-3495
> URL: https://issues.apache.org/jira/browse/IGNITE-3495
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 1.6
>Reporter: Denis Magda
> Attachments: ExampleNodeStartupClient.java, IGNITE_3495.patch,
> example-default.xml
>
>
> {{CacheMetrics.getAverageGetTime}}, {{CacheMetrics.getAveragePutTime}} and
> {{CacheMetrics.getAverageRemoveTime}} are not calculated properly in the
> following scenario:
> - start a server node;
> - start a client node that will perform gets and puts;
> - {{CacheMetrics.getAverage###Time}} will always be 0 for the server node's
> cluster group.
> The issue happens because {{CacheMetricsImpl.add###TimeNanos}} method is not
> called on the server side when a metric related event happens.
> In the attache you can find source that showcases the bug.
> - start basic {{ExampleNodeStartup}} using attached configuration
> {{example-default.xml}} conjuration;
> - start {{ExampleNodeStartupClient}}. You will see that average metrics are
> not incremented.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-6853) Cassandra cache store does not clean prepared statements cache when remove old cassandra session
[ https://issues.apache.org/jira/browse/IGNITE-6853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16322984#comment-16322984 ] Igor Rudyak commented on IGNITE-6853: - [~jason@gmail.com] It looks good to me except the fact that you introduced new testing framework Mockito. I am in general fine with Mockito, but such way it should be introduced on the global level in the parent project POM and just reused by other modules like Cassandra. > Cassandra cache store does not clean prepared statements cache when remove > old cassandra session > > > Key: IGNITE-6853 > URL: https://issues.apache.org/jira/browse/IGNITE-6853 > Project: Ignite > Issue Type: Bug > Components: cassandra >Affects Versions: 2.3 >Reporter: Mikhail Cherkasov >Assignee: Jason Man > Labels: important > Fix For: 2.4 > > > Cassandra cache store does not clean prepared statements cache when remove > old cassandra session which can lead to: > Prepared > statement cluster error detected, refreshing Cassandra session > com.datastax.driver.core.exceptions.InvalidQueryException: Tried to execute > unknown prepared query : 0xcad5832309a512feeb602eec67408130. You may have > used a PreparedStatement that was created with another Cluster instance. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (IGNITE-6899) Adding GA Grid to Apache Ignite ML module.
[
https://issues.apache.org/jira/browse/IGNITE-6899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16320924#comment-16320924
]
Oleg Ignatenko edited comment on IGNITE-6899 at 1/11/18 7:08 PM:
-
I copied [this branch|https://github.com/techbysample/ignite/tree/ignite-6899]
to my machine and did a couple of brief checks. Overall, so far so good (though
I am not 100% done yet).
- I checked builds of ml module and examples from command line, these went
smoothly (my builds were without tests and javadocs though).
- Run examples (from IDEA), all executed smoothly: HelloWorld, Movie (with
{{-DGENRES=Action,Comedy,Romance}}), OptimizeMakeChange (with
{{-DAMOUNTCHANGE=75}}).
- Briefly studied examples code. In examples pom, ignite-ml dependency outside
of ml profile looks superfluous but that's minor. Wrt java code of examples,
good news are that it loos clear and easy to understand, just the kind code I'd
want to see when learning new API. Very well done. Bad news are, there are
multiple deviations from [coding style guidelines of
Ignite|https://cwiki.apache.org/confluence/display/IGNITE/Coding+Guidelines], I
am not even sure if it can pass javadocs check at Teamcity. These issues look
manageable though and given that examples code is so apparently useful I would
strongly recommend to put an effort into onboarding it to the project.
- Run unit tests (GAGridTestSuite, in IDEA) - all passed.
- Run coverage analysis of unit tests (report attached: [^coverage.zip]). Per
cursory glance, coverage looks reasonably okay - similar or better to that in
most other ml packages. It's not as good as that of math package but as far as
I know improving unit tests coverage in whole ml module is planned as dedicated
effort anyway so it's probably good enough for now.
- I gave a first read to code added to ml module (note I plan to re-read it
later so may add more comments besides notes below):
{panel}Generally I've got same impression as of examples: code mostly looks
well designed and structured and easy to read but there are multiple deviations
from Ignite coding guidelines.
Another sad thing I noticed is repeated errors in javadocs of the kind when
method parameter type is written instead of name (for example in javadoc for
{{Chromosome#setFitnessScore}}).
Yet another javadoc related concern (though one that is easy to fix) is
{{package-info.java}} files are missing in sub-packages of genetic (sub-folders
of src/main/java/org/apache/ignite/ml/genetic) - if not fixed this will break
building javadocs of the project if I remember correctly.
Another thing I'm not entirely comfortable with is usage of enums in
GAGridConstants; it looks familiar and idiomatic for pre-Java 8 code but our
experience in ml module so far suggests that using Java 8 functional way
instead of enums often works better for stuff like that (for examples refer eg
to {{org.apache.ignite.ml.math.functions.Functions}}). Possibly worth giving it
a try.
There is repeated typo "criteria" -> "critiera" in various places - and what is
concerning is shows even in some names of public methods, eg
{{GAConfiguration#getChromosomeCritiera}}.
In GACongiguration, it would be nice to add a unit test or example with
non-default value of {{elitismCount}} (myself I would prefer unit test but I
don't insist on that).
(maybe minor but still) In class ChromosomeCriteria field {{criteria}} is
default visibility but presence of setter and getter suggests that it's
supposed to be private.{panel}
-
Further I plan to check [documentation at
readme.io|https://apacheignite.readme.io/v2.3/docs/genetic-algorithms]. After
that I plan to give a second read to code added in {{genetic}} packages in ml
module, under both main and test.
I am going to continue posting additional observations and considerations here.
was (Author: oignatenko):
I copied this branch to my machine and did a couple of brief checks. Overall,
so far so good (though I am not 100% done yet).
- I checked builds of ml module and examples from command line, these went
smoothly (my builds were without tests and javadocs though).
- Run examples (from IDEA), all executed smoothly: HelloWorld, Movie (with
{{-DGENRES=Action,Comedy,Romance}}), OptimizeMakeChange (with
{{-DAMOUNTCHANGE=75}}).
- Briefly studied examples code. In examples pom, ignite-ml dependency outside
of ml profile looks superfluous but that's minor. Wrt java code of examples,
good news are that it loos clear and easy to understand, just the kind code I'd
want to see when learning new API. Very well done. Bad news are, there are
multiple deviations from [coding style guidelines of
Ignite|https://cwiki.apache.org/confluence/display/IGNITE/Coding+Guidelines], I
am not even sure if it can pass javadocs check at Teamcity. These issues look
manageable though and given that example
[jira] [Commented] (IGNITE-7050) Add support for spring3
[ https://issues.apache.org/jira/browse/IGNITE-7050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16322694#comment-16322694 ] Mikhail Cherkasov commented on IGNITE-7050: --- #. SpringCache constructor have argument of SpringCacheManager type and this argument will be assigned to the instance field and never used. Why? Also could you please remove unused imports and non-public methods and add valuable javadoc to class fields and methods? Done, all unused imports, methods and classes are removed. I didn't comment only a few private fields/methods, because it's a copy/paste from original spring module and I'm not sure about accurate comments for them. #. It seems that GridSpringCacheManagerMultiJvmSelfTest class should contain some tests or should be removed. Removed. #. GridResourceTestUtils and TestClosure classes are unused. Removed. #. README.txt file should stress that this module exists in order to support Spring 3. Done. > Add support for spring3 > --- > > Key: IGNITE-7050 > URL: https://issues.apache.org/jira/browse/IGNITE-7050 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.3 >Reporter: Mikhail Cherkasov >Assignee: Mikhail Cherkasov > Fix For: 2.4 > > > there are still users who use spring3 and hence can't use ignite which > depends on spring4. I think we can create separate modules for spring3 > support, like it was done for hibernate 4/5. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-7380) Avoid updating PagePartitionCounters in case all counters were not modified
[ https://issues.apache.org/jira/browse/IGNITE-7380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16322671#comment-16322671 ] Ivan Rakov commented on IGNITE-7380: Dmitriy, thanks! Looks good to me. > Avoid updating PagePartitionCounters in case all counters were not modified > --- > > Key: IGNITE-7380 > URL: https://issues.apache.org/jira/browse/IGNITE-7380 > Project: Ignite > Issue Type: Improvement > Components: persistence >Reporter: Dmitriy Pavlov >Assignee: Dmitriy Pavlov >Priority: Critical > > PagePartitionCountersIO ignores actual values of counters and marks pages > dirty even if partition has no counters update. > This leads to PAGE_RECORD creation for pages from PagePartitionCountersIO > and as result with pages from TrackingPageIO. > These modificaiton may be skipped if counters are checked for equality before > storing data. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-6810) ODBC: Add secure connection support
[ https://issues.apache.org/jira/browse/IGNITE-6810?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16322532#comment-16322532 ] ASF GitHub Bot commented on IGNITE-6810: GitHub user isapego opened a pull request: https://github.com/apache/ignite/pull/3361 IGNITE-6810: SSL support for ODBC You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-6810 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/3361.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #3361 commit 714c21123c018fa14f77607ec648ec564659be93 Author: Igor Sapego Date: 2017-12-04T16:14:04Z IGNITE-6810: Implemented SecureSocketClient commit a7d54acbad8f92fd737f1b38845300ee420c8871 Author: Igor Sapego Date: 2017-12-21T16:44:29Z IGNITE-6810: Implemented SSL connection. commit 3ce20418d2df93d0c37734b980df745b62fa1ce3 Author: Igor Sapego Date: 2017-12-22T15:16:58Z IGNITE-6810: Added saving SSL parameters to DSN commit 0e34a62ae6acd01867fa8b8358c0762a59e98bb4 Author: Igor Sapego Date: 2017-12-25T16:24:24Z IGNITE-6810: Changed UI layout commit 3dfd12fe6a2afcd0f29119562ffeaf309aeafd7f Author: Igor Sapego Date: 2017-12-26T12:26:44Z IGNITE-6810: Added values retrieval commit 63d4f29ca0794dd96c2c65fa8fe74a9c13f11f61 Author: Igor Sapego Date: 2017-12-26T13:05:59Z IGNITE-6810: Implmented disabling of SSL options on choosing "disable" mode commit 46d4a82b3156e5a9fa4594066e457eca09f10d16 Author: Igor Sapego Date: 2017-12-26T13:40:42Z IGNITE-6810: Merge-related fixes commit 65cebff3e7c323bb3d152381993b299cc038a7a9 Author: Igor Sapego Date: 2017-12-27T12:26:25Z IGNITE-6810: Fix for SecureSocketClient disconnect. commit e6fce702ba5b980a23eb281284e66fd6b19a311f Author: Igor Sapego Date: 2017-12-28T17:54:17Z IGNITE-6810: Implemented OpenSSL dynamic loading. commit 80b6a099729659071afbf4022c2fd8221b4d2fc3 Author: Igor Sapego Date: 2018-01-10T15:54:49Z IGNITE-6810: Minor fixes commit 253bc066925928e18feae2e715ca0497ff2b9e4c Author: Igor Sapego Date: 2018-01-11T15:37:26Z IGNITE-6810: Fixes for Linux commit 046e99189d4d581ba21a106f76a40d2677706094 Author: Igor Sapego Date: 2018-01-11T15:41:06Z IGNITE-6810: Fixed test commit 086331d7766b749a298921f1113387c462c9913a Author: Igor Sapego Date: 2018-01-11T16:42:55Z IGNITE-6810: Changes for Linux > ODBC: Add secure connection support > --- > > Key: IGNITE-6810 > URL: https://issues.apache.org/jira/browse/IGNITE-6810 > Project: Ignite > Issue Type: New Feature > Components: odbc >Affects Versions: 2.3 >Reporter: Igor Sapego >Assignee: Igor Sapego > Labels: odbc > Fix For: 2.4 > > Attachments: new-ui.png > > > Need to add support of SSL/TLS for ODBC. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (IGNITE-3935) ClassLoaders are not switched during object deserialization
[
https://issues.apache.org/jira/browse/IGNITE-3935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Mekhanikov reassigned IGNITE-3935:
Assignee: Denis Mekhanikov (was: Alexey Goncharuk)
> ClassLoaders are not switched during object deserialization
> ---
>
> Key: IGNITE-3935
> URL: https://issues.apache.org/jira/browse/IGNITE-3935
> Project: Ignite
> Issue Type: Bug
> Components: binary
>Affects Versions: 1.6
>Reporter: Denis Magda
>Assignee: Denis Mekhanikov
>
> If an object is being deserialized with ClassLoader A then this ClassLoader A
> will be used for the deserialization of the whole object's state, i.e.,
> including all its fields that can be custom objects loaded by ClassLoader B.
> In a basic scenario we can have an object of some Ignite class that is
> presented in the classpath. That Ignite class may enclose an object that is
> loaded by peer-class-loading class loader. The deserialization will fail
> because Ignite won't switch to the peer-class-loading loader when it's needed.
> To reproduce the issue do the following:
> 1. Start a remote ignite node using {{./ignite.sh
> ../examples/config/example-ignite.xml}}
> 2. Run the code below
> {code}
> public class StreamingExample {`
> public static class StreamingExampleCacheEntryProcessor implements
> CacheEntryProcessor {
> @Override
> public Object process(MutableEntry e, Object... arg) throws
> EntryProcessorException {
> Long val = e.getValue();
> e.setValue(val == null ? 1L : val + 1);
> return null;
> }
> }
> public static void main(String[] args) throws IgniteException, IOException {
> Ignition.setClientMode(true);
> try (Ignite ignite =
> Ignition.start("examples/config/example-ignite.xml")) {
> IgniteCache stmCache =
> ignite.getOrCreateCache("mycache");
> try (IgniteDataStreamer stmr =
> ignite.dataStreamer(stmCache.getName())) {
> stmr.allowOverwrite(true);
> stmr.receiver(StreamTransformer.from(new
> StreamingExampleCacheEntryProcessor()));
> stmr.addData("word", 1L);
> System.out.println("Finished");
> }
> }
> }
> {code}
> However if to modify this code to the following everything will work fine
> {code}
> public class StreamingExample {
> public static class StreamingExampleCacheEntryProcessor extends
> StreamTransformer {
> @Override
> public Object process(MutableEntry e, Object... arg)
> throws EntryProcessorException {
> System.out.println("Executed!");
> Long val = e.getValue();
> e.setValue(val == null ? 1L : val + 1);
> return null;
> }
> }
> public static void main(String[] args) throws IgniteException,
> IOException {
> Ignition.setClientMode(true);
> try (Ignite ignite =
> Ignition.start("examples/config/example-ignite.xml")) {
> IgniteCache stmCache =
> ignite.getOrCreateCache("mycache");
> try (IgniteDataStreamer stmr =
> ignite.dataStreamer(stmCache.getName())) {
> stmr.allowOverwrite(true);
> stmr.receiver(new StreamingExampleCacheEntryProcessor());
> stmr.addData("word", 1L);
> System.out.println("Finished");
> }
> }
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-7378) WAL converter: add records statistic to WAL reader dev-util
[ https://issues.apache.org/jira/browse/IGNITE-7378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16322468#comment-16322468 ] ASF GitHub Bot commented on IGNITE-7378: GitHub user dspavlov opened a pull request: https://github.com/apache/ignite/pull/3360 IGNITE-7378 You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-7378 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/3360.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #3360 commit e7ca9b65a68de7752195c8f4d2b5180f3c77d19f Author: Dmitriy Govorukhin Date: 2017-11-13T18:52:47Z ignite-blt-merge -> ignite-2.4.1 commit cc8168fc184bb7f5e3cc3bbb0743397097f78bfb Author: Dmitriy Govorukhin Date: 2017-11-13T19:13:01Z merge ignite-pitr-rc1 -> ignite-2.4.1 commit 87e6d74cf6a251c7984f9e68c391f790feccc281 Author: Dmitriy Govorukhin Date: 2017-11-14T12:49:33Z ignite-gg-12877 Compact consistent ID in WAL commit 9f5a22711baea05bd37ab07c8f928a4837dd83a4 Author: Ilya Lantukh Date: 2017-11-14T14:12:28Z Fixed javadoc. commit d5af2d78dd8eef8eca8ac5391d31d8c779649bb0 Author: Alexey Kuznetsov Date: 2017-11-15T08:09:00Z IGNITE-6913 Baseline: Added new options to controls.sh for baseline manipulations. commit 713924ce865752b6e99b03bd624136541cea5f9f Author: Sergey Chugunov Date: 2017-11-15T09:03:12Z IGNITE-5850 failover tests for cache operations during BaselineTopology changes commit b65fd134e748d496f732ec2aa0953a0531f544b8 Author: Ilya Lantukh Date: 2017-11-15T12:54:35Z TX read logging if PITR is enabled. commit 9b2a567c0e04dc33116b51f88bee75f76e9107d1 Author: Ilya Lantukh Date: 2017-11-15T13:45:16Z TX read logging if PITR is enabled. commit 993058ccf0b2b8d9e80750c3e45a9ffa31d85dfa Author: Dmitriy Govorukhin Date: 2017-11-15T13:51:54Z ignite-2.4.1 optimization for store full set node more compacted commit 1eba521f608d39967aec376b397b7fc800234e54 Author: Dmitriy Govorukhin Date: 2017-11-15T13:52:22Z Merge remote-tracking branch 'professional/ignite-2.4.1' into ignite-2.4.1 commit 564b3fd51f8a7d1d81cb6874df66d0270623049c Author: Sergey Chugunov Date: 2017-11-15T14:00:51Z IGNITE-5850 fixed issue with initialization of data regions on node activation, fixed issue with auto-activation when random node joins inactive cluster with existing BLT commit c6d1fa4da7adfadc80abdc7eaf6452b86a4f6aa4 Author: Sergey Chugunov Date: 2017-11-15T16:23:08Z IGNITE-5850 transitionResult is set earlier when request for changing BaselineTopology is sent commit d65674363163e38a4c5fdd73d1c8d8e1c7610797 Author: Sergey Chugunov Date: 2017-11-16T11:59:07Z IGNITE-5850 new failover tests for changing BaselineTopology up (new node added to topology) commit 20552f3851fe8825191b144179be032965e0b5c6 Author: Sergey Chugunov Date: 2017-11-16T12:53:43Z IGNITE-5850 improved error message when online node is removed from baseline commit 108bbcae4505ac904a6db774643ad600bfb42c21 Author: Sergey Chugunov Date: 2017-11-16T13:45:52Z IGNITE-5850 BaselineTopology should not change on cluster deactivation commit deb641ad3bdbf260fa60ad6bf607629652e324bd Author: Dmitriy Govorukhin Date: 2017-11-17T09:45:44Z ignite-2.4.1 truncate wal and checkpoint history on move/delete snapshot commit 3c8b06f3659af30d1fd148ccc0f40e216a56c998 Author: Alexey Goncharuk Date: 2017-11-17T12:48:12Z IGNITE-6947 Abandon remap after single map if future is done (fixes NPE) commit ba2047e5ae7d271a677e0c418375d82d78c4023e Author: devozerov Date: 2017-11-14T12:26:31Z IGNITE-6901: Fixed assertion during IgniteH2Indexing.rebuildIndexesFromHash. This closes #3027. commit abfc0466d6d61d87255d0fe38cbdf11ad46d4f89 Author: Sergey Chugunov Date: 2017-11-17T13:40:57Z IGNITE-5850 tests for queries in presence of BaselineTopology commit f4eabaf2a905abacc4c60c01d3ca04f6ca9ec188 Author: Sergey Chugunov Date: 2017-11-17T17:23:02Z IGNITE-5850 implementation for setBaselineTopology(long topVer) migrated from wc-251 commit 4edeccd3e0b671aa277f58995df9ff9935baa95a Author: EdShangGG Date: 2017-11-17T18:21:17Z GG-13074 Multiple snapshot test failures after baseline topology is introduced -adding baseline test to suite -fixing issues with baseline commit edae228c8f55990c15ef3044be987dcb00d6c81a Author: EdShangGG Date: 2017-11-18T10:36:41Z hack with sleep commit b5bffc7580a4a8ffbcc06f60c282e73979179578 Author: Ilya Lantukh Date: 2017-11-18T12:39:19Z Fixed Ignite.active(true) returning control too early. commit 1bcdd76aae78665e2bbd49034fb46a1b91ef8389 Author: Ilya Lantukh Date: 2017-11-18T13:33:01Z
[jira] [Comment Edited] (IGNITE-7301) .NET: Cluster auto activation (baseline topology)
[ https://issues.apache.org/jira/browse/IGNITE-7301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16322456#comment-16322456 ] Pavel Tupitsyn edited comment on IGNITE-7301 at 1/11/18 4:02 PM: - Some tests failed, fixed, waiting for another run. was (Author: ptupitsyn): Some tests failed, fixed, waiting for another run, > .NET: Cluster auto activation (baseline topology) > - > > Key: IGNITE-7301 > URL: https://issues.apache.org/jira/browse/IGNITE-7301 > Project: Ignite > Issue Type: Improvement > Components: platforms >Affects Versions: 2.4 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn > Labels: .NET, IEP-4, Phase-1 > Fix For: 2.4 > > > Add auto activation related APIs to .NET, see > https://cwiki.apache.org/confluence/display/IGNITE/IEP-4+Baseline+topology+for+caches -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-7301) .NET: Cluster auto activation (baseline topology)
[ https://issues.apache.org/jira/browse/IGNITE-7301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16322456#comment-16322456 ] Pavel Tupitsyn commented on IGNITE-7301: Some tests failed, fixed, waiting for another run, > .NET: Cluster auto activation (baseline topology) > - > > Key: IGNITE-7301 > URL: https://issues.apache.org/jira/browse/IGNITE-7301 > Project: Ignite > Issue Type: Improvement > Components: platforms >Affects Versions: 2.4 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn > Labels: .NET, IEP-4, Phase-1 > Fix For: 2.4 > > > Add auto activation related APIs to .NET, see > https://cwiki.apache.org/confluence/display/IGNITE/IEP-4+Baseline+topology+for+caches -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (IGNITE-5037) Fix broken @AffinityKeyMapped annotation for compute jobs.
[ https://issues.apache.org/jira/browse/IGNITE-5037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evgenii Zhuravlev reassigned IGNITE-5037: - Assignee: Evgenii Zhuravlev (was: Maksim Kozlov) > Fix broken @AffinityKeyMapped annotation for compute jobs. > -- > > Key: IGNITE-5037 > URL: https://issues.apache.org/jira/browse/IGNITE-5037 > Project: Ignite > Issue Type: Improvement >Affects Versions: 1.7 >Reporter: Alexei Scherbakov >Assignee: Evgenii Zhuravlev > Labels: newbie > > See related discussion on dev list entitled Proper collocation of > computations and data > (http://apache-ignite-developers.2346864.n4.nabble.com/Proper-collocation-of-computations-and-data-td16945.html). > We must repair data affinity routing for compute jobs. It should work same as > for affinityCall/Run with partition. > Currently, ComputeTask map method returns Map ClusterNode>, > but we have to provide some API allows to map ComputeJobs to partitions or > keys. > This can be done using AffinityKeyMapped annotation or any other way. > Since that's a publiс API any fixes should be discussed on dev list prior to > implementation. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-5037) Fix broken @AffinityKeyMapped annotation for compute jobs.
[ https://issues.apache.org/jira/browse/IGNITE-5037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16322421#comment-16322421 ] Ihor Parashynets commented on IGNITE-5037: -- It would really-really good to see some progress here. [~ezhuravl] - I guess there is a high probability that this ticket could be handed over to you, such as [~dreamx] didn't answer to "the same" question since 27/Oct/2017 > Fix broken @AffinityKeyMapped annotation for compute jobs. > -- > > Key: IGNITE-5037 > URL: https://issues.apache.org/jira/browse/IGNITE-5037 > Project: Ignite > Issue Type: Improvement >Affects Versions: 1.7 >Reporter: Alexei Scherbakov >Assignee: Maksim Kozlov > Labels: newbie > > See related discussion on dev list entitled Proper collocation of > computations and data > (http://apache-ignite-developers.2346864.n4.nabble.com/Proper-collocation-of-computations-and-data-td16945.html). > We must repair data affinity routing for compute jobs. It should work same as > for affinityCall/Run with partition. > Currently, ComputeTask map method returns Map ClusterNode>, > but we have to provide some API allows to map ComputeJobs to partitions or > keys. > This can be done using AffinityKeyMapped annotation or any other way. > Since that's a publiс API any fixes should be discussed on dev list prior to > implementation. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-7165) Re-balancing is cancelled if client node joins
[ https://issues.apache.org/jira/browse/IGNITE-7165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16322391#comment-16322391 ] Ilya Kasnacheev commented on IGNITE-7165: - [~agoncharuk] please review the proposed patch https://github.com/apache/ignite/pull/3264 > Re-balancing is cancelled if client node joins > -- > > Key: IGNITE-7165 > URL: https://issues.apache.org/jira/browse/IGNITE-7165 > Project: Ignite > Issue Type: Bug >Reporter: Mikhail Cherkasov >Assignee: Ilya Kasnacheev >Priority: Critical > Fix For: 2.4 > > > Re-balancing is canceled if client node joins. Re-balancing can take hours > and each time when client node joins it starts again: > [15:10:05,700][INFO][disco-event-worker-#61%statement_grid%][GridDiscoveryManager] > Added new node to topology: TcpDiscoveryNode > [id=979cf868-1c37-424a-9ad1-12db501f32ef, addrs=[0:0:0:0:0:0:0:1, 127.0.0.1, > 172.31.16.213], sockAddrs=[/0:0:0:0:0:0:0:1:0, /127.0.0.1:0, > /172.31.16.213:0], discPort=0, order=36, intOrder=24, > lastExchangeTime=1512907805688, loc=false, ver=2.3.1#20171129-sha1:4b1ec0fe, > isClient=true] > [15:10:05,701][INFO][disco-event-worker-#61%statement_grid%][GridDiscoveryManager] > Topology snapshot [ver=36, servers=7, clients=5, CPUs=128, heap=160.0GB] > [15:10:05,702][INFO][exchange-worker-#62%statement_grid%][time] Started > exchange init [topVer=AffinityTopologyVersion [topVer=36, minorTopVer=0], > crd=false, evt=NODE_JOINED, evtNode=979cf868-1c37-424a-9ad1-12db501f32ef, > customEvt=null, allowMerge=true] > [15:10:05,702][INFO][exchange-worker-#62%statement_grid%][GridDhtPartitionsExchangeFuture] > Finish exchange future [startVer=AffinityTopologyVersion [topVer=36, > minorTopVer=0], resVer=AffinityTopologyVersion [topVer=36, minorTopVer=0], > err=null] > [15:10:05,702][INFO][exchange-worker-#62%statement_grid%][time] Finished > exchange init [topVer=AffinityTopologyVersion [topVer=36, minorTopVer=0], > crd=false] > [15:10:05,703][INFO][exchange-worker-#62%statement_grid%][GridCachePartitionExchangeManager] > Skipping rebalancing (nothing scheduled) [top=AffinityTopologyVersion > [topVer=36, minorTopVer=0], evt=NODE_JOINED, > node=979cf868-1c37-424a-9ad1-12db501f32ef] > [15:10:08,706][INFO][exchange-worker-#62%statement_grid%][GridDhtPartitionDemander] > Cancelled rebalancing from all nodes [topology=AffinityTopologyVersion > [topVer=35, minorTopVer=0]] > [15:10:08,707][INFO][exchange-worker-#62%statement_grid%][GridCachePartitionExchangeManager] > Rebalancing scheduled [order=[statementp]] > [15:10:08,707][INFO][exchange-worker-#62%statement_grid%][GridCachePartitionExchangeManager] > Rebalancing started [top=null, evt=NODE_JOINED, > node=a8be3c14-9add-48c3-b099-3fd304cfdbf4] > [15:10:08,707][INFO][exchange-worker-#62%statement_grid%][GridDhtPartitionDemander] > Starting rebalancing [mode=ASYNC, > fromNode=2f6bde48-ffb5-4815-bd32-df4e57dc13e0, partitionsCount=18, > topology=AffinityTopologyVersion [topVer=36, minorTopVer=0], > updateSeq=-1754630006] > [15:10:08,707][INFO][exchange-worker-#62%statement_grid%][GridDhtPartitionDemander] > Starting rebalancing [mode=ASYNC, > fromNode=35d01141-4dce-47dd-adf6-a4f3b2bb9da9, partitionsCount=15, > topology=AffinityTopologyVersion [topVer=36, minorTopVer=0], > updateSeq=-1754630006] > [15:10:08,708][INFO][exchange-worker-#62%statement_grid%][GridDhtPartitionDemander] > Starting rebalancing [mode=ASYNC, > fromNode=b3a8be53-e61f-4023-a906-a265923837ba, partitionsCount=15, > topology=AffinityTopologyVersion [topVer=36, minorTopVer=0], > updateSeq=-1754630006] > [15:10:08,708][INFO][exchange-worker-#62%statement_grid%][GridDhtPartitionDemander] > Starting rebalancing [mode=ASYNC, > fromNode=f825cb4e-7dcc-405f-a40d-c1dc1a3ade5a, partitionsCount=12, > topology=AffinityTopologyVersion [topVer=36, minorTopVer=0], > updateSeq=-1754630006] > [15:10:08,708][INFO][exchange-worker-#62%statement_grid%][GridDhtPartitionDemander] > Starting rebalancing [mode=ASYNC, > fromNode=4ae1db91-8b88-4180-a84b-127a303959e9, partitionsCount=11, > topology=AffinityTopologyVersion [topVer=36, minorTopVer=0], > updateSeq=-1754630006] > [15:10:08,708][INFO][exchange-worker-#62%statement_grid%][GridDhtPartitionDemander] > Starting rebalancing [mode=ASYNC, > fromNode=7c286481-7638-49e4-8c68-fa6aa65d8b76, partitionsCount=18, > topology=AffinityTopologyVersion [topVer=36, minorTopVer=0], > updateSeq=-1754630006] > so in clusters with a big amount of data and the frequent client left/join > events this means that a new server will never receive its partitions. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (IGNITE-7390) .NET: Use InternalsVisibleTo for Core projects
[
https://issues.apache.org/jira/browse/IGNITE-7390?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16322362#comment-16322362
]
Pavel Tupitsyn edited comment on IGNITE-7390 at 1/11/18 2:58 PM:
-
{{InternalsVisibleTo}} for Core has been already added as part of IGNITE-7281.
Removed unnecessary {{#if}} directives, added more tests to Core project.
Merged to master: {{2dce0b89d344c5100eabac53f4c1de289c9f24bd}}.
was (Author: ptupitsyn):
Merged to master: {{2dce0b89d344c5100eabac53f4c1de289c9f24bd}}.
> .NET: Use InternalsVisibleTo for Core projects
> --
>
> Key: IGNITE-7390
> URL: https://issues.apache.org/jira/browse/IGNITE-7390
> Project: Ignite
> Issue Type: Improvement
> Components: platforms
>Affects Versions: 2.4
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
> Labels: .NET
> Fix For: 2.4
>
>
> We can use {{#if}} condition and add {{InternalsVisibleTo}} attribute for
> .NET Core tests.
> This will allow us to include more tests in .NET Core project and get rid of
> reflection in {{TestUtils}}.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (IGNITE-7390) .NET: Use InternalsVisibleTo for Core projects
[
https://issues.apache.org/jira/browse/IGNITE-7390?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn resolved IGNITE-7390.
Resolution: Fixed
> .NET: Use InternalsVisibleTo for Core projects
> --
>
> Key: IGNITE-7390
> URL: https://issues.apache.org/jira/browse/IGNITE-7390
> Project: Ignite
> Issue Type: Improvement
> Components: platforms
>Affects Versions: 2.4
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
> Labels: .NET
> Fix For: 2.4
>
>
> We can use {{#if}} condition and add {{InternalsVisibleTo}} attribute for
> .NET Core tests.
> This will allow us to include more tests in .NET Core project and get rid of
> reflection in {{TestUtils}}.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-7390) .NET: Use InternalsVisibleTo for Core projects
[
https://issues.apache.org/jira/browse/IGNITE-7390?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16322362#comment-16322362
]
Pavel Tupitsyn commented on IGNITE-7390:
Merged to master: {{2dce0b89d344c5100eabac53f4c1de289c9f24bd}}.
> .NET: Use InternalsVisibleTo for Core projects
> --
>
> Key: IGNITE-7390
> URL: https://issues.apache.org/jira/browse/IGNITE-7390
> Project: Ignite
> Issue Type: Improvement
> Components: platforms
>Affects Versions: 2.4
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
> Labels: .NET
> Fix For: 2.4
>
>
> We can use {{#if}} condition and add {{InternalsVisibleTo}} attribute for
> .NET Core tests.
> This will allow us to include more tests in .NET Core project and get rid of
> reflection in {{TestUtils}}.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-7191) JDBC: set socket buffer to 64k by default
[ https://issues.apache.org/jira/browse/IGNITE-7191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16322255#comment-16322255 ] Pavel Tupitsyn commented on IGNITE-7191: [~apopov] why 64k and not 128k or anything else? Did you perform any benchmarks? > JDBC: set socket buffer to 64k by default > - > > Key: IGNITE-7191 > URL: https://issues.apache.org/jira/browse/IGNITE-7191 > Project: Ignite > Issue Type: Improvement > Components: jdbc >Affects Versions: 2.1 >Reporter: Alexey Popov >Assignee: Alexey Popov > Fix For: 2.4 > > > TCP socket buffer size can significantly affect user-visible performance > (actually, latency) for SQL queries, especially if Ignite cluster is run at > the remote hosts. > It is better to have 64k TCP socket buffer size (instead of default 8k) by > default to avoid possible delays in TCP transport. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-7135) IgniteCluster.startNodes() returns successful ClusterStartNodeResult even though the remote process fails
[
https://issues.apache.org/jira/browse/IGNITE-7135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16322250#comment-16322250
]
Andrey Gura commented on IGNITE-7135:
-
LGTM. Merged to master branch.
> IgniteCluster.startNodes() returns successful ClusterStartNodeResult even
> though the remote process fails
> -
>
> Key: IGNITE-7135
> URL: https://issues.apache.org/jira/browse/IGNITE-7135
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.3
>Reporter: Alexandr Kuramshin
>Assignee: Alexandr Kuramshin
> Labels: test
> Fix For: 2.4
>
>
> After unsuccessful start of three remote nodes with
> {{IgniteCluster#startNodes(Collection>,
> Map, boolean, int, int)}} we get
> {{Collection}} with three elements, each has
> {{isSuccess()}} is true.
> But the remote node startup log was
> {noformat}
> nohup: ignoring input
> /data/teamcity/work/820be461cd64b574/bin/ignite.sh, ERROR:
> The version of JAVA installed in JAVA_HOME=/usr/lib/jvm/java-9-oracle is
> incorrect.
> Please point JAVA_HOME variable to installation of JDK 1.7 or JDK 1.8.
> You can also download latest JDK at http://java.com/download
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-6456) Add flags to ClientConnectorConfiguration which enable/disable different clients
[
https://issues.apache.org/jira/browse/IGNITE-6456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16322245#comment-16322245
]
Pavel Tupitsyn commented on IGNITE-6456:
[~rkondakov]
* Can we avoid using exceptions for control flow? I mean, we throw exception
and catch it right there.
* Unsupported version error looks dirty now: {{Client handshake failed:
'Unsupported version: ClientListenerProtocolVersion [major=-1, minor=-1,
maintenance=-1]'. Client version: -1.-1.-1. Server version: 1.0.0}}, it was
{{Client handshake failed: 'Unsupported version.'. Client version: -1.-1.-1.
Server version: 1.0.0}}.
> Add flags to ClientConnectorConfiguration which enable/disable different
> clients
>
>
> Key: IGNITE-6456
> URL: https://issues.apache.org/jira/browse/IGNITE-6456
> Project: Ignite
> Issue Type: Improvement
> Components: jdbc, odbc, thin client
>Affects Versions: 2.1
>Reporter: Igor Sapego
>Assignee: Roman Kondakov
> Labels: usability
> Fix For: 2.4
>
>
> There is currently no way to disable only one client. For example, currently
> you can't disallow thin JDBC driver connectivity alone, you can only disable
> the whole {{ClientListenerProcessor}}, which is going to disable ODBC and
> thin .NET clients as well.
> We should add options to disable/enable every single client, supported by the
> {{ClientListenerProcessor}} separately. For example, we can add flags to the
> {{ClientConnectorConfiguration}}:
> {{allowJdbc}}
> {{allowOdbc}}
> {{allowClient}}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-7191) JDBC: set socket buffer to 64k by default
[ https://issues.apache.org/jira/browse/IGNITE-7191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16322235#comment-16322235 ] Alexey Popov commented on IGNITE-7191: -- [~ptupitsyn] and [~tledkov-gridgain], could you please review the changes > JDBC: set socket buffer to 64k by default > - > > Key: IGNITE-7191 > URL: https://issues.apache.org/jira/browse/IGNITE-7191 > Project: Ignite > Issue Type: Improvement > Components: jdbc >Affects Versions: 2.1 >Reporter: Alexey Popov >Assignee: Alexey Popov > Fix For: 2.4 > > > TCP socket buffer size can significantly affect user-visible performance > (actually, latency) for SQL queries, especially if Ignite cluster is run at > the remote hosts. > It is better to have 64k TCP socket buffer size (instead of default 8k) by > default to avoid possible delays in TCP transport. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (IGNITE-7191) JDBC: set socket buffer to 64k by default
[ https://issues.apache.org/jira/browse/IGNITE-7191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16322232#comment-16322232 ] Alexey Popov edited comment on IGNITE-7191 at 1/11/18 1:52 PM: --- Scope of changes: 1. Server side default socket size for thin clients 2. JDBC thin default socket size & tests 3. .Net thin default client socket size & tests PR: https://github.com/apache/ignite/pull/3353 TC: https://ci.ignite.apache.org/project.html?projectId=IgniteTests2023Java7&branch_IgniteTests2023Java7=pull%2F3353%2Fhead was (Author: alexey.tank2): Scope of changes: 1. Server side default socket size for thin clients 2. JDBC thin default socket size & tests 3. .Net thin client socket size & tests PR: https://github.com/apache/ignite/pull/3353 TC: https://ci.ignite.apache.org/project.html?projectId=IgniteTests2023Java7&branch_IgniteTests2023Java7=pull%2F3353%2Fhead > JDBC: set socket buffer to 64k by default > - > > Key: IGNITE-7191 > URL: https://issues.apache.org/jira/browse/IGNITE-7191 > Project: Ignite > Issue Type: Improvement > Components: jdbc >Affects Versions: 2.1 >Reporter: Alexey Popov >Assignee: Alexey Popov > > TCP socket buffer size can significantly affect user-visible performance > (actually, latency) for SQL queries, especially if Ignite cluster is run at > the remote hosts. > It is better to have 64k TCP socket buffer size (instead of default 8k) by > default to avoid possible delays in TCP transport. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-7191) JDBC: set socket buffer to 64k by default
[ https://issues.apache.org/jira/browse/IGNITE-7191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16322232#comment-16322232 ] Alexey Popov commented on IGNITE-7191: -- Scope of changes: 1. Server side default socket size for thin clients 2. JDBC thin default socket size & tests 3. .Net thin client socket size & tests PR: https://github.com/apache/ignite/pull/3353 TC: https://ci.ignite.apache.org/project.html?projectId=IgniteTests2023Java7&branch_IgniteTests2023Java7=pull%2F3353%2Fhead > JDBC: set socket buffer to 64k by default > - > > Key: IGNITE-7191 > URL: https://issues.apache.org/jira/browse/IGNITE-7191 > Project: Ignite > Issue Type: Improvement > Components: jdbc >Affects Versions: 2.1 >Reporter: Alexey Popov >Assignee: Alexey Popov > > TCP socket buffer size can significantly affect user-visible performance > (actually, latency) for SQL queries, especially if Ignite cluster is run at > the remote hosts. > It is better to have 64k TCP socket buffer size (instead of default 8k) by > default to avoid possible delays in TCP transport. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (IGNITE-7191) JDBC: set socket buffer to 64k by default
[ https://issues.apache.org/jira/browse/IGNITE-7191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16322232#comment-16322232 ] Alexey Popov edited comment on IGNITE-7191 at 1/11/18 1:52 PM: --- Scope of changes: 1. Server side default socket size for thin clients 2. JDBC thin default socket size & tests 3. .Net thin client default socket size & tests PR: https://github.com/apache/ignite/pull/3353 TC: https://ci.ignite.apache.org/project.html?projectId=IgniteTests2023Java7&branch_IgniteTests2023Java7=pull%2F3353%2Fhead was (Author: alexey.tank2): Scope of changes: 1. Server side default socket size for thin clients 2. JDBC thin default socket size & tests 3. .Net thin default client socket size & tests PR: https://github.com/apache/ignite/pull/3353 TC: https://ci.ignite.apache.org/project.html?projectId=IgniteTests2023Java7&branch_IgniteTests2023Java7=pull%2F3353%2Fhead > JDBC: set socket buffer to 64k by default > - > > Key: IGNITE-7191 > URL: https://issues.apache.org/jira/browse/IGNITE-7191 > Project: Ignite > Issue Type: Improvement > Components: jdbc >Affects Versions: 2.1 >Reporter: Alexey Popov >Assignee: Alexey Popov > > TCP socket buffer size can significantly affect user-visible performance > (actually, latency) for SQL queries, especially if Ignite cluster is run at > the remote hosts. > It is better to have 64k TCP socket buffer size (instead of default 8k) by > default to avoid possible delays in TCP transport. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-7340) Fix flaky GridServiceProcessorMultiNodeConfigSelfTest#checkDeployOnEachNodeUpdateTopology
[
https://issues.apache.org/jira/browse/IGNITE-7340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1637#comment-1637
]
Andrey Gura commented on IGNITE-7340:
-
LGTM. Merged to master branch.
> Fix flaky
> GridServiceProcessorMultiNodeConfigSelfTest#checkDeployOnEachNodeUpdateTopology
> -
>
> Key: IGNITE-7340
> URL: https://issues.apache.org/jira/browse/IGNITE-7340
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.3
>Reporter: Dmitry Karachentsev
>Assignee: Dmitry Karachentsev
> Fix For: 2.4
>
>
> {noformat}
> junit.framework.AssertionFailedError: serviceConfigEachNode expected:<4> but
> was:<3>
> at junit.framework.Assert.fail(Assert.java:57)
> at junit.framework.Assert.failNotEquals(Assert.java:329)
> at junit.framework.Assert.assertEquals(Assert.java:78)
> at junit.framework.Assert.assertEquals(Assert.java:234)
> at junit.framework.TestCase.assertEquals(TestCase.java:401)
> at
> org.apache.ignite.internal.processors.service.GridServiceProcessorMultiNodeConfigSelfTest.checkDeployOnEachNodeUpdateTopology(GridServiceProcessorMultiNodeConfigSelfTest.java:277)
> at
> org.apache.ignite.internal.processors.service.GridServiceProcessorMultiNodeConfigSelfTest.testDeployOnEachNodeUpdateTopology(GridServiceProcessorMultiNodeConfigSelfTest.java:144)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (IGNITE-7390) .NET: Use InternalsVisibleTo for Core projects
Pavel Tupitsyn created IGNITE-7390:
--
Summary: .NET: Use InternalsVisibleTo for Core projects
Key: IGNITE-7390
URL: https://issues.apache.org/jira/browse/IGNITE-7390
Project: Ignite
Issue Type: Improvement
Components: platforms
Affects Versions: 2.4
Reporter: Pavel Tupitsyn
Assignee: Pavel Tupitsyn
Fix For: 2.4
We can use {{#if}} condition and add {{InternalsVisibleTo}} attribute for .NET
Core tests.
This will allow us to include more tests in .NET Core project and get rid of
reflection in {{TestUtils}}.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-7380) Avoid updating PagePartitionCounters in case all counters were not modified
[ https://issues.apache.org/jira/browse/IGNITE-7380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1633#comment-1633 ] Dmitriy Pavlov commented on IGNITE-7380: Hi [~ivan.glukos], thank you for reviewing changes! I've updated PR. magic no fixed, test IgniteCheckpointDirtyPagesForLowLoadTest was created. It fails in case too much pages marker dirty > Avoid updating PagePartitionCounters in case all counters were not modified > --- > > Key: IGNITE-7380 > URL: https://issues.apache.org/jira/browse/IGNITE-7380 > Project: Ignite > Issue Type: Improvement > Components: persistence >Reporter: Dmitriy Pavlov >Assignee: Dmitriy Pavlov >Priority: Critical > > PagePartitionCountersIO ignores actual values of counters and marks pages > dirty even if partition has no counters update. > This leads to PAGE_RECORD creation for pages from PagePartitionCountersIO > and as result with pages from TrackingPageIO. > These modificaiton may be skipped if counters are checked for equality before > storing data. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-7239) In case of not serializable cache update response, future on node requester will never complete
[ https://issues.apache.org/jira/browse/IGNITE-7239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16322212#comment-16322212 ] Andrey Gura commented on IGNITE-7239: - LGTM. Merged to master branch. > In case of not serializable cache update response, future on node requester > will never complete > --- > > Key: IGNITE-7239 > URL: https://issues.apache.org/jira/browse/IGNITE-7239 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.3 >Reporter: Dmitry Karachentsev >Assignee: Dmitry Karachentsev >Priority: Minor > Fix For: 2.4 > > > To avoid such hang, if response could not be serialized, create other > response with text of the error. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-7281) .NET: Services do not work on .NET Core
[
https://issues.apache.org/jira/browse/IGNITE-7281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16322203#comment-16322203
]
ASF GitHub Bot commented on IGNITE-7281:
Github user asfgit closed the pull request at:
https://github.com/apache/ignite/pull/3328
> .NET: Services do not work on .NET Core
> ---
>
> Key: IGNITE-7281
> URL: https://issues.apache.org/jira/browse/IGNITE-7281
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Affects Versions: 2.4
>Reporter: Pavel Tupitsyn
>Assignee: Alexey Rokhin
> Labels: .NET, xplat
>
> We rely on {{System.Runtime.Remoting.Proxies.RealProxy}} for dynamic proxy
> generation. However, remoting is not supported on .NET Core.
> Investigate whether we can get rid of RealProxy and generate runtime proxies
> manually. Basically, we need to emit an interface implementation where every
> method just delegates to our code.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-7281) .NET: Services do not work on .NET Core
[
https://issues.apache.org/jira/browse/IGNITE-7281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16322201#comment-16322201
]
Pavel Tupitsyn commented on IGNITE-7281:
[~rokhin] looks good to me. Awesome contribution, thank you!
I've made some minor changes and included {{ServicesTest}} into DotNetCore
project.
Merged to master: {{11508d941ee6f7008538416fc1c7af71e602c9d1}}.
> .NET: Services do not work on .NET Core
> ---
>
> Key: IGNITE-7281
> URL: https://issues.apache.org/jira/browse/IGNITE-7281
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Affects Versions: 2.4
>Reporter: Pavel Tupitsyn
>Assignee: Alexey Rokhin
> Labels: .NET, xplat
>
> We rely on {{System.Runtime.Remoting.Proxies.RealProxy}} for dynamic proxy
> generation. However, remoting is not supported on .NET Core.
> Investigate whether we can get rid of RealProxy and generate runtime proxies
> manually. Basically, we need to emit an interface implementation where every
> method just delegates to our code.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-5037) Fix broken @AffinityKeyMapped annotation for compute jobs.
[ https://issues.apache.org/jira/browse/IGNITE-5037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16322196#comment-16322196 ] Evgenii Zhuravlev commented on IGNITE-5037: --- [~dreamx], is this ticket really in progress? I'm interested in the implementation of this issue and want to take it if you don't mind. > Fix broken @AffinityKeyMapped annotation for compute jobs. > -- > > Key: IGNITE-5037 > URL: https://issues.apache.org/jira/browse/IGNITE-5037 > Project: Ignite > Issue Type: Improvement >Affects Versions: 1.7 >Reporter: Alexei Scherbakov >Assignee: Maksim Kozlov > Labels: newbie > > See related discussion on dev list entitled Proper collocation of > computations and data > (http://apache-ignite-developers.2346864.n4.nabble.com/Proper-collocation-of-computations-and-data-td16945.html). > We must repair data affinity routing for compute jobs. It should work same as > for affinityCall/Run with partition. > Currently, ComputeTask map method returns Map ClusterNode>, > but we have to provide some API allows to map ComputeJobs to partitions or > keys. > This can be done using AffinityKeyMapped annotation or any other way. > Since that's a publiс API any fixes should be discussed on dev list prior to > implementation. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (IGNITE-6353) Integrate mvcc support in scan query protocol
[ https://issues.apache.org/jira/browse/IGNITE-6353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Kondakov reassigned IGNITE-6353: -- Assignee: Roman Kondakov > Integrate mvcc support in scan query protocol > - > > Key: IGNITE-6353 > URL: https://issues.apache.org/jira/browse/IGNITE-6353 > Project: Ignite > Issue Type: Task > Components: cache >Reporter: Semen Boikov >Assignee: Roman Kondakov > Fix For: 2.5 > > > Need integrate mvcc support in scan query protocol: > - request current ID and list of active txs from coordinator > - pass this info in query requests and in cache iterators > - notify coordinator after query completed -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-7389) DataStreamer hangs if exception was thrown during addData which isn't IgniteException
[
https://issues.apache.org/jira/browse/IGNITE-7389?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eduard Shangareev updated IGNITE-7389:
--
Description:
I have written test which starts cache on one node and right after that starts
dataStreamer on another node. Which hangs on close method because {{resFut}}
will never be done.
{code}
java.lang.IllegalStateException: Getting affinity for topology version earlier
than affinity is calculated [locNode=TcpDiscoveryNode
[id=ad14d7f6-5895-4038-ba5e-cc487ab0, addrs=[127.0.0.1],
sockAddrs=[/127.0.0.1:47501], discPort=47501, order=2, intOrder=2,
lastExchangeTime=1515672065430, loc=true, ver=2.4.0#19700101-sha1:,
isClient=false], grp=PART-G2, topVer=AffinityTopologyVersion [topVer=4,
minorTopVer=3], head=AffinityTopologyVersion [topVer=4, minorTopVer=4],
history=[AffinityTopologyVersion [topVer=4, minorTopVer=4]]]
at
org.apache.ignite.internal.processors.affinity.GridAffinityAssignmentCache.cachedAffinity(GridAffinityAssignmentCache.java:603)
at
org.apache.ignite.internal.processors.cache.GridCacheAffinityManager.assignment(GridCacheAffinityManager.java:243)
at
org.apache.ignite.internal.processors.affinity.GridAffinityProcessor.affinityCache(GridAffinityProcessor.java:375)
at
org.apache.ignite.internal.processors.affinity.GridAffinityProcessor.partition0(GridAffinityProcessor.java:187)
at
org.apache.ignite.internal.processors.cacheobject.IgniteCacheObjectProcessorImpl.partition(IgniteCacheObjectProcessorImpl.java:267)
at
org.apache.ignite.internal.processors.cacheobject.IgniteCacheObjectProcessorImpl.toCacheKeyObject0(IgniteCacheObjectProcessorImpl.java:135)
at
org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl.toCacheKeyObject(CacheObjectBinaryProcessorImpl.java:805)
at
org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl.addData(DataStreamerImpl.java:581)
at
org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl.addData(DataStreamerImpl.java:555)
at
org.gridgain.grid.internal.processors.cache.database.AbstractSnapshotTest$2.run(AbstractSnapshotTest.java:404)
at
org.apache.ignite.testframework.GridTestUtils$6.run(GridTestUtils.java:933)
at
org.apache.ignite.testframework.GridTestUtils$9.call(GridTestUtils.java:1278)
at
org.apache.ignite.testframework.GridTestThread.run(GridTestThread.java:86)
{code}
The best solution is waiting for topology on which cache should be started.
was:
I have written test which starts cache on one node and right after it starts
dataStreamer on another node. Which hangs on close method because {{resFut}}
will never be done.
{code}
java.lang.IllegalStateException: Getting affinity for topology version earlier
than affinity is calculated [locNode=TcpDiscoveryNode
[id=ad14d7f6-5895-4038-ba5e-cc487ab0, addrs=[127.0.0.1],
sockAddrs=[/127.0.0.1:47501], discPort=47501, order=2, intOrder=2,
lastExchangeTime=1515672065430, loc=true, ver=2.4.0#19700101-sha1:,
isClient=false], grp=PART-G2, topVer=AffinityTopologyVersion [topVer=4,
minorTopVer=3], head=AffinityTopologyVersion [topVer=4, minorTopVer=4],
history=[AffinityTopologyVersion [topVer=4, minorTopVer=4]]]
at
org.apache.ignite.internal.processors.affinity.GridAffinityAssignmentCache.cachedAffinity(GridAffinityAssignmentCache.java:603)
at
org.apache.ignite.internal.processors.cache.GridCacheAffinityManager.assignment(GridCacheAffinityManager.java:243)
at
org.apache.ignite.internal.processors.affinity.GridAffinityProcessor.affinityCache(GridAffinityProcessor.java:375)
at
org.apache.ignite.internal.processors.affinity.GridAffinityProcessor.partition0(GridAffinityProcessor.java:187)
at
org.apache.ignite.internal.processors.cacheobject.IgniteCacheObjectProcessorImpl.partition(IgniteCacheObjectProcessorImpl.java:267)
at
org.apache.ignite.internal.processors.cacheobject.IgniteCacheObjectProcessorImpl.toCacheKeyObject0(IgniteCacheObjectProcessorImpl.java:135)
at
org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl.toCacheKeyObject(CacheObjectBinaryProcessorImpl.java:805)
at
org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl.addData(DataStreamerImpl.java:581)
at
org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl.addData(DataStreamerImpl.java:555)
at
org.gridgain.grid.internal.processors.cache.database.AbstractSnapshotTest$2.run(AbstractSnapshotTest.java:404)
at
org.apache.ignite.testframework.GridTestUtils$6.run(GridTestUtils.java:933)
at
org.apache.ignite.testframework.GridTestUtils$9.call(GridTestUtils.java:1278)
at
org.apache.ignite.testframework.GridTestThread.run(GridTestThread.java:86)
{code}
The best solution is waiting for top
[jira] [Created] (IGNITE-7389) DataStreamer hangs if exception was thrown during addData which isn't IgniteException
Eduard Shangareev created IGNITE-7389:
-
Summary: DataStreamer hangs if exception was thrown during addData
which isn't IgniteException
Key: IGNITE-7389
URL: https://issues.apache.org/jira/browse/IGNITE-7389
Project: Ignite
Issue Type: Bug
Reporter: Eduard Shangareev
I have written test which starts cache on one node and right after it starts
dataStreamer on another node. Which hangs on close method because {{resFut}}
will never be done.
{code}
java.lang.IllegalStateException: Getting affinity for topology version earlier
than affinity is calculated [locNode=TcpDiscoveryNode
[id=ad14d7f6-5895-4038-ba5e-cc487ab0, addrs=[127.0.0.1],
sockAddrs=[/127.0.0.1:47501], discPort=47501, order=2, intOrder=2,
lastExchangeTime=1515672065430, loc=true, ver=2.4.0#19700101-sha1:,
isClient=false], grp=PART-G2, topVer=AffinityTopologyVersion [topVer=4,
minorTopVer=3], head=AffinityTopologyVersion [topVer=4, minorTopVer=4],
history=[AffinityTopologyVersion [topVer=4, minorTopVer=4]]]
at
org.apache.ignite.internal.processors.affinity.GridAffinityAssignmentCache.cachedAffinity(GridAffinityAssignmentCache.java:603)
at
org.apache.ignite.internal.processors.cache.GridCacheAffinityManager.assignment(GridCacheAffinityManager.java:243)
at
org.apache.ignite.internal.processors.affinity.GridAffinityProcessor.affinityCache(GridAffinityProcessor.java:375)
at
org.apache.ignite.internal.processors.affinity.GridAffinityProcessor.partition0(GridAffinityProcessor.java:187)
at
org.apache.ignite.internal.processors.cacheobject.IgniteCacheObjectProcessorImpl.partition(IgniteCacheObjectProcessorImpl.java:267)
at
org.apache.ignite.internal.processors.cacheobject.IgniteCacheObjectProcessorImpl.toCacheKeyObject0(IgniteCacheObjectProcessorImpl.java:135)
at
org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl.toCacheKeyObject(CacheObjectBinaryProcessorImpl.java:805)
at
org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl.addData(DataStreamerImpl.java:581)
at
org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl.addData(DataStreamerImpl.java:555)
at
org.gridgain.grid.internal.processors.cache.database.AbstractSnapshotTest$2.run(AbstractSnapshotTest.java:404)
at
org.apache.ignite.testframework.GridTestUtils$6.run(GridTestUtils.java:933)
at
org.apache.ignite.testframework.GridTestUtils$9.call(GridTestUtils.java:1278)
at
org.apache.ignite.testframework.GridTestThread.run(GridTestThread.java:86)
{code}
The best solution is waiting for topology on which cache should be started.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (IGNITE-7355) peerClassLoading doesn't work with DataStreamer Transformer
[
https://issues.apache.org/jira/browse/IGNITE-7355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Mekhanikov resolved IGNITE-7355.
--
Resolution: Duplicate
Duplicate of IGNITE-3935
> peerClassLoading doesn't work with DataStreamer Transformer
> ---
>
> Key: IGNITE-7355
> URL: https://issues.apache.org/jira/browse/IGNITE-7355
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.3
>Reporter: Evgenii Zhuravlev
>Assignee: Denis Mekhanikov
>
> Example:
> {code:java}
> try (IgniteDataStreamer streamer =
> ignite.dataStreamer(CacheName.CACHE)) {
> streamer.receiver(StreamTransformer.from(new
> MyCacheEntryProcessor()));
> streamer.addData("key", "value");
> }
> private static class MyCacheEntryProcessor implements
> CacheEntryProcessor {
> @Override
> public Object process(MutableEntry mutableEntry,
> Object... objects) throws EntryProcessorException {
> return null;
> }
> }
> {code}
> workaround: use streamer.deployClass(MyCacheEntryProcessor.class);
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (IGNITE-6369) 2.11 Spark integration has a dependency on Spark's 2.10 library
[
https://issues.apache.org/jira/browse/IGNITE-6369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Mekhanikov resolved IGNITE-6369.
--
Resolution: Cannot Reproduce
Assignee: (was: Denis Mekhanikov)
Fixed in IGNITE-3084
> 2.11 Spark integration has a dependency on Spark's 2.10 library
> ---
>
> Key: IGNITE-6369
> URL: https://issues.apache.org/jira/browse/IGNITE-6369
> Project: Ignite
> Issue Type: Bug
> Components: spark
>Reporter: Hubert Plociniczak
> Fix For: 2.4
>
>
> A simple Spark application that uses both Spark and Ignite fails to compile
> in sbt under 2.11 due to conflicting dependencies. For a simple sbt
> definition with:
> {code}
> libraryDependencies += "org.apache.spark" %% "spark-core" % "2.1.0"
> libraryDependencies += "org.apache.spark" %% "spark-sql" % "2.1.0"
> libraryDependencies += "org.apache.ignite" % "ignite-spark" % "2.1.0"
> {code}
> it will fail to compile with:
> {code}
> [error] Modules were resolved with conflicting cross-version suffixes in:
> [error]org.scalatest:scalatest _2.11, _2.10
> [error]com.twitter:chill _2.11, _2.10
> [error]org.apache.spark:spark-unsafe _2.11, _2.10
> [error]org.apache.spark:spark-tags _2.11, _2.10
> [trace] Stack trace suppressed: run 'last *:update' for the full output.
> {code}
> It looks like a single culprit is the entry in ignite-spark's pom.xml for
> {{spark-unsafe_2.10}}.
> When removed, compiled and published, everything works great.
> I don't see why such an entry exists in {{spark}} module when there is a
> separate {{spark-2.10}} module as well.
> Happy to submit a PR if anyone is willing to give a thumbs up.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (IGNITE-7388) MVCC TX Support async tx rollback (e.g. on timeout)
Igor Seliverstov created IGNITE-7388: Summary: MVCC TX Support async tx rollback (e.g. on timeout) Key: IGNITE-7388 URL: https://issues.apache.org/jira/browse/IGNITE-7388 Project: Ignite Issue Type: Bug Reporter: Igor Seliverstov Currently TX timeout isn't taken into consideration while MVCC version is requesting. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-6772) SQL exception messages are not descriptive
[
https://issues.apache.org/jira/browse/IGNITE-6772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16322115#comment-16322115
]
Pavel Tupitsyn commented on IGNITE-6772:
Ok, looks good to me then. [~vozerov] please have a look as well.
> SQL exception messages are not descriptive
> --
>
> Key: IGNITE-6772
> URL: https://issues.apache.org/jira/browse/IGNITE-6772
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Pavel Tupitsyn
>Assignee: Roman Kondakov
> Labels: usability
> Fix For: 2.4
>
>
> Top level SQL exception messages are cryptic and not descriptive. Real
> details are buried deep inside inner exceptions.
> For example, when there is a typo in table name, exception looks like this:
> {code}
> class org.apache.ignite.IgniteCheckedException: Failed to parse query: SELECT
> "persons-sql"."PERSON"._KEY, "persons-sql"."PERSON"._VAL from Person1,
> "orgs-sql".Organization where Person.OrgId = "orgs-sql".Organization._key and
> "orgs-sql".Organization.Name = ?
> at
> org.apache.ignite.internal.processors.platform.utils.PlatformUtils.unwrapQueryException(PlatformUtils.java:510)
> at
> org.apache.ignite.internal.processors.platform.cache.PlatformCache.runQuery(PlatformCache.java:1219)
> at
> org.apache.ignite.internal.processors.platform.cache.PlatformCache.processInStreamOutObject(PlatformCache.java:875)
> at
> org.apache.ignite.internal.processors.platform.PlatformTargetProxyImpl.inStreamOutObject(PlatformTargetProxyImpl.java:77)
> Caused by: javax.cache.CacheException: class
> org.apache.ignite.internal.processors.query.IgniteSQLException: Failed to
> parse query: SELECT "persons-sql"."PERSON"._KEY, "persons-sql"."PERSON"._VAL
> from Person1, "orgs-sql".Organization where Person.OrgId =
> "orgs-sql".Organization._key and "orgs-sql".Organization.Name = ?
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxy.query(IgniteCacheProxy.java:807)
> at
> org.apache.ignite.internal.processors.platform.cache.PlatformCache.runQuery(PlatformCache.java:1213)
> ... 2 more
> Caused by: class
> org.apache.ignite.internal.processors.query.IgniteSQLException: Failed to
> parse query: SELECT "persons-sql"."PERSON"._KEY, "persons-sql"."PERSON"._VAL
> from Person1, "orgs-sql".Organization where Person.OrgId =
> "orgs-sql".Organization._key and "orgs-sql".Organization.Name = ?
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.queryDistributedSqlFields(IgniteH2Indexing.java:1293)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.queryDistributedSql(IgniteH2Indexing.java:1198)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$8.applyx(GridQueryProcessor.java:1957)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$8.applyx(GridQueryProcessor.java:1955)
> at
> org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:2293)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.queryDistributedSql(GridQueryProcessor.java:1954)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySql(GridQueryProcessor.java:1934)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxy.query(IgniteCacheProxy.java:792)
> ... 3 more
> Caused by: org.h2.jdbc.JdbcSQLException: Table "PERSON1" not found; SQL
> statement:
> SELECT "persons-sql"."PERSON"._KEY, "persons-sql"."PERSON"._VAL from Person1,
> "orgs-sql".Organization where Person.OrgId = "orgs-sql".Organization._key and
> "orgs-sql".Organization.Name = ? [42102-195]
> at org.h2.message.DbException.getJdbcSQLException(DbException.java:345)
> at org.h2.message.DbException.get(DbException.java:179)
> at org.h2.message.DbException.get(DbException.java:155)
> at org.h2.command.Parser.readTableOrView(Parser.java:5506)
> at org.h2.command.Parser.readTableFilter(Parser.java:1260)
> at org.h2.command.Parser.parseSelectSimpleFromPart(Parser.java:1940)
> at org.h2.command.Parser.parseSelectSimple(Parser.java:2089)
> at org.h2.command.Parser.parseSelectSub(Parser.java:1934)
> at org.h2.command.Parser.parseSelectUnion(Parser.java:1749)
> at org.h2.command.Parser.parseSelect(Parser.java:1737)
> at org.h2.command.Parser.parsePrepared(Parser.java:448)
> at org.h2.command.Parser.parse(Parser.java:320)
> at org.h2.command.Parser.parse(Parser.java:292)
> at org.h2.command.Parser.prepareCommand(Parser.java:257)
> at org.h2.engine.Session.prepareLocal(Session.java:573)
> at org.h2.engine.Session.prepareCommand(Session.java:514)
> at org.h2.jdbc.JdbcConnection.prepareCommand(JdbcConnection.java:120
[jira] [Commented] (IGNITE-6772) SQL exception messages are not descriptive
[
https://issues.apache.org/jira/browse/IGNITE-6772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16322088#comment-16322088
]
Roman Kondakov commented on IGNITE-6772:
[~ptupitsyn],
* This made for an uniformity error messages between different types of JDBC
drivers. JDBC and JDBC2 drivers used to return {{Value is an not instance of "
+ cls.getName()}} in case of types mismatch. JDBC Thin driver returns {{Cannot
convert to URL/boolean/float... etc.}} where type is hardcoded. It is useful
not only for users but also for testing purposes. I'm not sure if we need to
add a source class to the message because this problem is relevant only for
JDBC and JDBC2 drivers which are going to be deprecated as far as I know. Thin
driver {{ResultSet}} includes value (but not value class) in the error message.
E.g. {{"Cannot convert to float: " + val}}. From my point of view it should be
enough for debugging reasons.
* Query text is already included into the exception's message sent from the
parsing engine: {{Column "WRONG" not found; SQL statement: select wrong from
test \[42122-195\]}}. If we also include it here, query will be dublicated in
the same message.
> SQL exception messages are not descriptive
> --
>
> Key: IGNITE-6772
> URL: https://issues.apache.org/jira/browse/IGNITE-6772
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Pavel Tupitsyn
>Assignee: Roman Kondakov
> Labels: usability
> Fix For: 2.4
>
>
> Top level SQL exception messages are cryptic and not descriptive. Real
> details are buried deep inside inner exceptions.
> For example, when there is a typo in table name, exception looks like this:
> {code}
> class org.apache.ignite.IgniteCheckedException: Failed to parse query: SELECT
> "persons-sql"."PERSON"._KEY, "persons-sql"."PERSON"._VAL from Person1,
> "orgs-sql".Organization where Person.OrgId = "orgs-sql".Organization._key and
> "orgs-sql".Organization.Name = ?
> at
> org.apache.ignite.internal.processors.platform.utils.PlatformUtils.unwrapQueryException(PlatformUtils.java:510)
> at
> org.apache.ignite.internal.processors.platform.cache.PlatformCache.runQuery(PlatformCache.java:1219)
> at
> org.apache.ignite.internal.processors.platform.cache.PlatformCache.processInStreamOutObject(PlatformCache.java:875)
> at
> org.apache.ignite.internal.processors.platform.PlatformTargetProxyImpl.inStreamOutObject(PlatformTargetProxyImpl.java:77)
> Caused by: javax.cache.CacheException: class
> org.apache.ignite.internal.processors.query.IgniteSQLException: Failed to
> parse query: SELECT "persons-sql"."PERSON"._KEY, "persons-sql"."PERSON"._VAL
> from Person1, "orgs-sql".Organization where Person.OrgId =
> "orgs-sql".Organization._key and "orgs-sql".Organization.Name = ?
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxy.query(IgniteCacheProxy.java:807)
> at
> org.apache.ignite.internal.processors.platform.cache.PlatformCache.runQuery(PlatformCache.java:1213)
> ... 2 more
> Caused by: class
> org.apache.ignite.internal.processors.query.IgniteSQLException: Failed to
> parse query: SELECT "persons-sql"."PERSON"._KEY, "persons-sql"."PERSON"._VAL
> from Person1, "orgs-sql".Organization where Person.OrgId =
> "orgs-sql".Organization._key and "orgs-sql".Organization.Name = ?
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.queryDistributedSqlFields(IgniteH2Indexing.java:1293)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.queryDistributedSql(IgniteH2Indexing.java:1198)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$8.applyx(GridQueryProcessor.java:1957)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$8.applyx(GridQueryProcessor.java:1955)
> at
> org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:2293)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.queryDistributedSql(GridQueryProcessor.java:1954)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySql(GridQueryProcessor.java:1934)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxy.query(IgniteCacheProxy.java:792)
> ... 3 more
> Caused by: org.h2.jdbc.JdbcSQLException: Table "PERSON1" not found; SQL
> statement:
> SELECT "persons-sql"."PERSON"._KEY, "persons-sql"."PERSON"._VAL from Person1,
> "orgs-sql".Organization where Person.OrgId = "orgs-sql".Organization._key and
> "orgs-sql".Organization.Name = ? [42102-195]
> at org.h2.message.DbException.getJdbcSQLException(DbException.java:345)
> at org.h2.message.DbException.get(DbExc
[jira] [Commented] (IGNITE-7352) Java 9: rework "sun.misc.SharedSecrets" and "sun.misc.JavaNioAccess" usages
[
https://issues.apache.org/jira/browse/IGNITE-7352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16322080#comment-16322080
]
Andrey Gura commented on IGNITE-7352:
-
Merged to master branch.
> Java 9: rework "sun.misc.SharedSecrets" and "sun.misc.JavaNioAccess" usages
> ---
>
> Key: IGNITE-7352
> URL: https://issues.apache.org/jira/browse/IGNITE-7352
> Project: Ignite
> Issue Type: Task
> Components: general
>Reporter: Vladimir Ozerov
>Assignee: Andrey Gura
> Fix For: 2.4
>
>
> *Problem*
> We have two usages of {{sun.misc.SharedSecrets}} and
> {{sun.misc.JavaNioAccess}} in the project. Both methods do the same thing -
> convert native pointer to {{ByteBuffer}}:
> {{GridUnsafe.wrapPointer}}
> {{PageMemoryImpl.wrapPointer}}
> Java9 cannot compile it because these classes were moved to
> {{jdk.internal.misc}} package.
> *Suggested fix*
> 1) Remove {{PageMemoryImpl.wrapPointer}} method and use
> {{GridUnsafe.wrapPointer}} instead.
> 2) Rework {{GridUnsafe.wrapPointer}} to reflection-based approach.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (IGNITE-7386) Get rid of LongAdder8, ConcurrentHashMap8, etc
[
https://issues.apache.org/jira/browse/IGNITE-7386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anton Vinogradov updated IGNITE-7386:
-
Fix Version/s: 2.5
> Get rid of LongAdder8, ConcurrentHashMap8, etc
> --
>
> Key: IGNITE-7386
> URL: https://issues.apache.org/jira/browse/IGNITE-7386
> Project: Ignite
> Issue Type: Task
>Reporter: Anton Vinogradov
> Fix For: 2.5
>
>
> Since we're dropping java7 support there is no need now to use
> {{LongAdder8}}, {{ConcurrentHashMap8}}, ...
> We should remove all classes from {{org.jsr166}} namespace and use
> corresponding classes from jdk8.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (IGNITE-7386) Get rid of LongAdder8, ConcurrentHashMap8, etc
[
https://issues.apache.org/jira/browse/IGNITE-7386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anton Vinogradov updated IGNITE-7386:
-
Affects Version/s: (was: 2.5)
> Get rid of LongAdder8, ConcurrentHashMap8, etc
> --
>
> Key: IGNITE-7386
> URL: https://issues.apache.org/jira/browse/IGNITE-7386
> Project: Ignite
> Issue Type: Task
>Reporter: Anton Vinogradov
> Fix For: 2.5
>
>
> Since we're dropping java7 support there is no need now to use
> {{LongAdder8}}, {{ConcurrentHashMap8}}, ...
> We should remove all classes from {{org.jsr166}} namespace and use
> corresponding classes from jdk8.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-7365) File channel associated with WAL can be closed by interruption
[ https://issues.apache.org/jira/browse/IGNITE-7365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16322060#comment-16322060 ] Andrey Gura commented on IGNITE-7365: - Merged to master branch. > File channel associated with WAL can be closed by interruption > -- > > Key: IGNITE-7365 > URL: https://issues.apache.org/jira/browse/IGNITE-7365 > Project: Ignite > Issue Type: Bug >Reporter: Andrey Gura >Assignee: Andrey Gura >Priority: Critical > Fix For: 2.4 > > > File channel associated with WAL can be closed by user thread interruption on > segment rollover. > Test IgnitePdsThreadInterruptionTest.testInterruptsOnWALWrite fails or hangs. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-7387) Add Activate\Deactivate lifecycle event support.
Andrew Mashenkov created IGNITE-7387: Summary: Add Activate\Deactivate lifecycle event support. Key: IGNITE-7387 URL: https://issues.apache.org/jira/browse/IGNITE-7387 Project: Ignite Issue Type: Improvement Components: general Reporter: Andrew Mashenkov For now Ignite has a number of LifecycleEvent type that allow user to perform some logic before node join\leave topology. However, with persistence enabled Ignite node start in non-active state and AFTER_NODE_START event is useless in some cases as user may need to spin-wait for activation. We should add AFTER_ACTIVATE and BEFORE_DEACTIVATE lifecycle event types. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-7386) Get rid of LongAdder8, ConcurrentHashMap8, etc
[
https://issues.apache.org/jira/browse/IGNITE-7386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anton Vinogradov updated IGNITE-7386:
-
Description:
Since we're dropping java7 support there is no need now to use {{LongAdder8}},
{{ConcurrentHashMap8}}, ...
We should remove all classes from {{org.jsr166}} namespace and use
corresponding classes from jdk8.
was:
Since we're dripping java7 support there is no need now to use {{LongAdder8}},
{{ConcurrentHashMap8}}, ...
We should remove all classes from {{org.jsr166}} namespace and use
corresponding classes from jdk8.
> Get rid of LongAdder8, ConcurrentHashMap8, etc
> --
>
> Key: IGNITE-7386
> URL: https://issues.apache.org/jira/browse/IGNITE-7386
> Project: Ignite
> Issue Type: Task
>Affects Versions: 2.5
>Reporter: Anton Vinogradov
>
> Since we're dropping java7 support there is no need now to use
> {{LongAdder8}}, {{ConcurrentHashMap8}}, ...
> We should remove all classes from {{org.jsr166}} namespace and use
> corresponding classes from jdk8.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (IGNITE-7386) Get rid of LongAdder8, ConcurrentHashMap8, etc
Anton Vinogradov created IGNITE-7386:
Summary: Get rid of LongAdder8, ConcurrentHashMap8, etc
Key: IGNITE-7386
URL: https://issues.apache.org/jira/browse/IGNITE-7386
Project: Ignite
Issue Type: Task
Affects Versions: 2.5
Reporter: Anton Vinogradov
Since we're dripping java7 support there is no need now to use {{LongAdder8}},
{{ConcurrentHashMap8}}, ...
We should remove all classes from {{org.jsr166}} namespace and use
corresponding classes from jdk8.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-6456) Add flags to ClientConnectorConfiguration which enable/disable different clients
[
https://issues.apache.org/jira/browse/IGNITE-6456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16322029#comment-16322029
]
Roman Kondakov commented on IGNITE-6456:
[~ptupitsyn], I refactored this method. Please review. Waiting for [TC
run|https://ci.ignite.apache.org/viewQueued.html?itemId=1033689].
> Add flags to ClientConnectorConfiguration which enable/disable different
> clients
>
>
> Key: IGNITE-6456
> URL: https://issues.apache.org/jira/browse/IGNITE-6456
> Project: Ignite
> Issue Type: Improvement
> Components: jdbc, odbc, thin client
>Affects Versions: 2.1
>Reporter: Igor Sapego
>Assignee: Roman Kondakov
> Labels: usability
> Fix For: 2.4
>
>
> There is currently no way to disable only one client. For example, currently
> you can't disallow thin JDBC driver connectivity alone, you can only disable
> the whole {{ClientListenerProcessor}}, which is going to disable ODBC and
> thin .NET clients as well.
> We should add options to disable/enable every single client, supported by the
> {{ClientListenerProcessor}} separately. For example, we can add flags to the
> {{ClientConnectorConfiguration}}:
> {{allowJdbc}}
> {{allowOdbc}}
> {{allowClient}}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (IGNITE-7385) Fix GridToStringBuilder
Alexander Belyak created IGNITE-7385: Summary: Fix GridToStringBuilder Key: IGNITE-7385 URL: https://issues.apache.org/jira/browse/IGNITE-7385 Project: Ignite Issue Type: Bug Reporter: Alexander Belyak Assignee: Semen Boikov Need to review and merge ignite-7195-hotfix. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-7380) Avoid updating PagePartitionCounters in case all counters were not modified
[ https://issues.apache.org/jira/browse/IGNITE-7380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16322005#comment-16322005 ] Ivan Rakov commented on IGNITE-7380: [~dpavlov], a few comments: 1. The problem can be covered by test - you can create group with many caches and partitions and check that almost-empty checkpoint writes limited number of pages. 2. It would be better to introduce "12" as constant and add comment there. > Avoid updating PagePartitionCounters in case all counters were not modified > --- > > Key: IGNITE-7380 > URL: https://issues.apache.org/jira/browse/IGNITE-7380 > Project: Ignite > Issue Type: Improvement > Components: persistence >Reporter: Dmitriy Pavlov >Assignee: Dmitriy Pavlov >Priority: Critical > > PagePartitionCountersIO ignores actual values of counters and marks pages > dirty even if partition has no counters update. > This leads to PAGE_RECORD creation for pages from PagePartitionCountersIO > and as result with pages from TrackingPageIO. > These modificaiton may be skipped if counters are checked for equality before > storing data. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (IGNITE-7377) Removed entry is not re-created in IgniteTxManager.lockMultiple
[ https://issues.apache.org/jira/browse/IGNITE-7377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Semen Boikov resolved IGNITE-7377. -- Resolution: Fixed Fixed in master. > Removed entry is not re-created in IgniteTxManager.lockMultiple > --- > > Key: IGNITE-7377 > URL: https://issues.apache.org/jira/browse/IGNITE-7377 > Project: Ignite > Issue Type: Bug > Components: cache >Reporter: Semen Boikov >Assignee: Semen Boikov >Priority: Critical > Fix For: 2.4 > > > IgniteTxManager.lockMultiple: if GridCacheEntryRemovedException is thrown > when entries are unlocked (txEntry2.cached().txUnlock(tx)) then entry is > re-created for txEntry1, not for txEntry2. This can lead to infinite loop > inside lockMultiple. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (IGNITE-7377) Removed entry is not re-created in IgniteTxManager.lockMultiple
[ https://issues.apache.org/jira/browse/IGNITE-7377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Semen Boikov reassigned IGNITE-7377: Assignee: (was: Semen Boikov) > Removed entry is not re-created in IgniteTxManager.lockMultiple > --- > > Key: IGNITE-7377 > URL: https://issues.apache.org/jira/browse/IGNITE-7377 > Project: Ignite > Issue Type: Bug > Components: cache >Reporter: Semen Boikov >Priority: Critical > Fix For: 2.4 > > > IgniteTxManager.lockMultiple: if GridCacheEntryRemovedException is thrown > when entries are unlocked (txEntry2.cached().txUnlock(tx)) then entry is > re-created for txEntry1, not for txEntry2. This can lead to infinite loop > inside lockMultiple. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (IGNITE-7036) Web console: Wrong export of grouped users
[ https://issues.apache.org/jira/browse/IGNITE-7036?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov reassigned IGNITE-7036: Resolution: Fixed Assignee: Pavel Konstantinov (was: Alexey Kuznetsov) Looks good. Merged to master. Please retest. > Web console: Wrong export of grouped users > -- > > Key: IGNITE-7036 > URL: https://issues.apache.org/jira/browse/IGNITE-7036 > Project: Ignite > Issue Type: Bug > Components: wizards >Reporter: Vasiliy Sisko >Assignee: Pavel Konstantinov > Fix For: 2.4 > > > On export of grouped users when group is collapsed in table only header row > is exported. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-7126) .NET: Add missing CacheMetrics
[
https://issues.apache.org/jira/browse/IGNITE-7126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16321984#comment-16321984
]
ASF GitHub Bot commented on IGNITE-7126:
Github user asfgit closed the pull request at:
https://github.com/apache/ignite/pull/3356
> .NET: Add missing CacheMetrics
> --
>
> Key: IGNITE-7126
> URL: https://issues.apache.org/jira/browse/IGNITE-7126
> Project: Ignite
> Issue Type: Improvement
> Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Alexey Rokhin
>Priority: Minor
> Labels: .NET
>
> See {{CacheMetricsParityTest}} for a list of missing metrics.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-7126) .NET: Add missing CacheMetrics
[
https://issues.apache.org/jira/browse/IGNITE-7126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16321982#comment-16321982
]
Pavel Tupitsyn commented on IGNITE-7126:
[~rokhin] Looks good to me.
Merged to master: {{2de75fd4543530a0ced7d494aa3560d839df01a1}}.
> .NET: Add missing CacheMetrics
> --
>
> Key: IGNITE-7126
> URL: https://issues.apache.org/jira/browse/IGNITE-7126
> Project: Ignite
> Issue Type: Improvement
> Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Alexey Rokhin
>Priority: Minor
> Labels: .NET
>
> See {{CacheMetricsParityTest}} for a list of missing metrics.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-7365) File channel associated with WAL can be closed by interruption
[ https://issues.apache.org/jira/browse/IGNITE-7365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16321977#comment-16321977 ] Alexey Goncharuk commented on IGNITE-7365: -- Changes look good to me > File channel associated with WAL can be closed by interruption > -- > > Key: IGNITE-7365 > URL: https://issues.apache.org/jira/browse/IGNITE-7365 > Project: Ignite > Issue Type: Bug >Reporter: Andrey Gura >Assignee: Andrey Gura >Priority: Critical > Fix For: 2.4 > > > File channel associated with WAL can be closed by user thread interruption on > segment rollover. > Test IgnitePdsThreadInterruptionTest.testInterruptsOnWALWrite fails or hangs. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-7284) Introduce DEV_ONLY marker to IgniteLogger
[
https://issues.apache.org/jira/browse/IGNITE-7284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16321978#comment-16321978
]
Stanislav Lukyanov commented on IGNITE-7284:
[~vkulichenko], my concern here is that this way we do reinvent the wheel for
100% of the markers that we use now :)
The question is, when we add more markers, are we likely to add a property for
each to allow filtering on JUL?
Anyway, I guess you're right that it's easy to do, so I'll add a property and
handle it on IgniteUtils level. It'll be easier to come up with the right
strategy when there are more standard markers in Ignite.
> Introduce DEV_ONLY marker to IgniteLogger
> -
>
> Key: IGNITE-7284
> URL: https://issues.apache.org/jira/browse/IGNITE-7284
> Project: Ignite
> Issue Type: Improvement
> Components: general
>Affects Versions: 2.3
>Reporter: Valentin Kulichenko
>Assignee: Stanislav Lukyanov
> Fix For: 2.4
>
>
> Need to add markers support to {{IgniteLogger}} and then introduce
> {{DEV_ONLY}} marker for warnings that can be suppressed in prod environments.
> Problem and solution are discussed in more detail here:
> http://apache-ignite-developers.2346864.n4.nabble.com/Suppressing-quot-development-quot-warning-td25195.html
> Make sure to update Loggers documentation explaining how the parameter works
> and what's it for:
> https://apacheignite.readme.io/docs/logging
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (IGNITE-6739) Add tests verifying queries and tx functionality when mvcc is enabled
[
https://issues.apache.org/jira/browse/IGNITE-6739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Seliverstov updated IGNITE-6739:
-
Description:
Add tests verifying queries functionality is not broken if mvcc is enabled:
- full text indexes
- queries with indexing spi
- CacheConfiguration with setQueryParallelism
- lazy queries (SqlFieldsQuery.setLazy(true))
- collocated queries (SqlFieldsQuery.setCollocated)
- queries with cache groups
- dynamic index create
General functionality:
- make sure clean up is called when related future (query) is forcibly
(exceptionally) finished (i.e. on cache stop)
- queries without involved caches (i.e. {{SELECT 1}}) don't request MVCC version
- Mvcc coordinator assignment on cluster activate
- cache entry reload
was:
Add tests verifying queries functionality is not broken if mvcc is enabled:
- full text indexes
- queries with indexing spi
- CacheConfiguration with setQueryParallelism
- lazy queries (SqlFieldsQuery.setLazy(true))
- collocated queries (SqlFieldsQuery.setCollocated)
- queries with cache groups
General functionality:
- make sure clean up is called when related future (query) is forcibly
(exceptionally) finished (i.e. on cache stop)
- queries without involved caches (i.e. {{SELECT 1}}) don't request MVCC version
- Mvcc coordinator assignment on cluster activate
- cache entry reload
> Add tests verifying queries and tx functionality when mvcc is enabled
> -
>
> Key: IGNITE-6739
> URL: https://issues.apache.org/jira/browse/IGNITE-6739
> Project: Ignite
> Issue Type: Task
> Components: sql
>Reporter: Semen Boikov
> Fix For: 2.5
>
>
> Add tests verifying queries functionality is not broken if mvcc is enabled:
> - full text indexes
> - queries with indexing spi
> - CacheConfiguration with setQueryParallelism
> - lazy queries (SqlFieldsQuery.setLazy(true))
> - collocated queries (SqlFieldsQuery.setCollocated)
> - queries with cache groups
> - dynamic index create
> General functionality:
> - make sure clean up is called when related future (query) is forcibly
> (exceptionally) finished (i.e. on cache stop)
> - queries without involved caches (i.e. {{SELECT 1}}) don't request MVCC
> version
> - Mvcc coordinator assignment on cluster activate
> - cache entry reload
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-6772) SQL exception messages are not descriptive
[
https://issues.apache.org/jira/browse/IGNITE-6772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16321965#comment-16321965
]
Pavel Tupitsyn commented on IGNITE-6772:
* {{JdbcResultSet}}: why change to {{cls.getSimpleName().toLowerCase()}}?
Should we also include source class which we tried to convert?
* {{IgniteH2Indexing}}: I would include both the message and the query text,
like {{Failed to parse query [error=..., query=...]}}.
> SQL exception messages are not descriptive
> --
>
> Key: IGNITE-6772
> URL: https://issues.apache.org/jira/browse/IGNITE-6772
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Pavel Tupitsyn
>Assignee: Roman Kondakov
> Labels: usability
> Fix For: 2.4
>
>
> Top level SQL exception messages are cryptic and not descriptive. Real
> details are buried deep inside inner exceptions.
> For example, when there is a typo in table name, exception looks like this:
> {code}
> class org.apache.ignite.IgniteCheckedException: Failed to parse query: SELECT
> "persons-sql"."PERSON"._KEY, "persons-sql"."PERSON"._VAL from Person1,
> "orgs-sql".Organization where Person.OrgId = "orgs-sql".Organization._key and
> "orgs-sql".Organization.Name = ?
> at
> org.apache.ignite.internal.processors.platform.utils.PlatformUtils.unwrapQueryException(PlatformUtils.java:510)
> at
> org.apache.ignite.internal.processors.platform.cache.PlatformCache.runQuery(PlatformCache.java:1219)
> at
> org.apache.ignite.internal.processors.platform.cache.PlatformCache.processInStreamOutObject(PlatformCache.java:875)
> at
> org.apache.ignite.internal.processors.platform.PlatformTargetProxyImpl.inStreamOutObject(PlatformTargetProxyImpl.java:77)
> Caused by: javax.cache.CacheException: class
> org.apache.ignite.internal.processors.query.IgniteSQLException: Failed to
> parse query: SELECT "persons-sql"."PERSON"._KEY, "persons-sql"."PERSON"._VAL
> from Person1, "orgs-sql".Organization where Person.OrgId =
> "orgs-sql".Organization._key and "orgs-sql".Organization.Name = ?
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxy.query(IgniteCacheProxy.java:807)
> at
> org.apache.ignite.internal.processors.platform.cache.PlatformCache.runQuery(PlatformCache.java:1213)
> ... 2 more
> Caused by: class
> org.apache.ignite.internal.processors.query.IgniteSQLException: Failed to
> parse query: SELECT "persons-sql"."PERSON"._KEY, "persons-sql"."PERSON"._VAL
> from Person1, "orgs-sql".Organization where Person.OrgId =
> "orgs-sql".Organization._key and "orgs-sql".Organization.Name = ?
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.queryDistributedSqlFields(IgniteH2Indexing.java:1293)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.queryDistributedSql(IgniteH2Indexing.java:1198)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$8.applyx(GridQueryProcessor.java:1957)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$8.applyx(GridQueryProcessor.java:1955)
> at
> org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:2293)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.queryDistributedSql(GridQueryProcessor.java:1954)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySql(GridQueryProcessor.java:1934)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxy.query(IgniteCacheProxy.java:792)
> ... 3 more
> Caused by: org.h2.jdbc.JdbcSQLException: Table "PERSON1" not found; SQL
> statement:
> SELECT "persons-sql"."PERSON"._KEY, "persons-sql"."PERSON"._VAL from Person1,
> "orgs-sql".Organization where Person.OrgId = "orgs-sql".Organization._key and
> "orgs-sql".Organization.Name = ? [42102-195]
> at org.h2.message.DbException.getJdbcSQLException(DbException.java:345)
> at org.h2.message.DbException.get(DbException.java:179)
> at org.h2.message.DbException.get(DbException.java:155)
> at org.h2.command.Parser.readTableOrView(Parser.java:5506)
> at org.h2.command.Parser.readTableFilter(Parser.java:1260)
> at org.h2.command.Parser.parseSelectSimpleFromPart(Parser.java:1940)
> at org.h2.command.Parser.parseSelectSimple(Parser.java:2089)
> at org.h2.command.Parser.parseSelectSub(Parser.java:1934)
> at org.h2.command.Parser.parseSelectUnion(Parser.java:1749)
> at org.h2.command.Parser.parseSelect(Parser.java:1737)
> at org.h2.command.Parser.parsePrepared(Parser.java:448)
> at org.h2.command.Parser.parse(Parser.java:320)
> at org.h2.command.Parser.parse(Parser.java:292)
> at org.h2.command.Parser.prepareCommand(Parser
[jira] [Comment Edited] (IGNITE-6772) SQL exception messages are not descriptive
[
https://issues.apache.org/jira/browse/IGNITE-6772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16321965#comment-16321965
]
Pavel Tupitsyn edited comment on IGNITE-6772 at 1/11/18 9:44 AM:
-
[~rkondakov],
* {{JdbcResultSet}}: why change to {{cls.getSimpleName().toLowerCase()}}?
Should we also include source class which we tried to convert?
* {{IgniteH2Indexing}}: I would include both the message and the query text,
like {{Failed to parse query [error=..., query=...]}}.
was (Author: ptupitsyn):
* {{JdbcResultSet}}: why change to {{cls.getSimpleName().toLowerCase()}}?
Should we also include source class which we tried to convert?
* {{IgniteH2Indexing}}: I would include both the message and the query text,
like {{Failed to parse query [error=..., query=...]}}.
> SQL exception messages are not descriptive
> --
>
> Key: IGNITE-6772
> URL: https://issues.apache.org/jira/browse/IGNITE-6772
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Pavel Tupitsyn
>Assignee: Roman Kondakov
> Labels: usability
> Fix For: 2.4
>
>
> Top level SQL exception messages are cryptic and not descriptive. Real
> details are buried deep inside inner exceptions.
> For example, when there is a typo in table name, exception looks like this:
> {code}
> class org.apache.ignite.IgniteCheckedException: Failed to parse query: SELECT
> "persons-sql"."PERSON"._KEY, "persons-sql"."PERSON"._VAL from Person1,
> "orgs-sql".Organization where Person.OrgId = "orgs-sql".Organization._key and
> "orgs-sql".Organization.Name = ?
> at
> org.apache.ignite.internal.processors.platform.utils.PlatformUtils.unwrapQueryException(PlatformUtils.java:510)
> at
> org.apache.ignite.internal.processors.platform.cache.PlatformCache.runQuery(PlatformCache.java:1219)
> at
> org.apache.ignite.internal.processors.platform.cache.PlatformCache.processInStreamOutObject(PlatformCache.java:875)
> at
> org.apache.ignite.internal.processors.platform.PlatformTargetProxyImpl.inStreamOutObject(PlatformTargetProxyImpl.java:77)
> Caused by: javax.cache.CacheException: class
> org.apache.ignite.internal.processors.query.IgniteSQLException: Failed to
> parse query: SELECT "persons-sql"."PERSON"._KEY, "persons-sql"."PERSON"._VAL
> from Person1, "orgs-sql".Organization where Person.OrgId =
> "orgs-sql".Organization._key and "orgs-sql".Organization.Name = ?
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxy.query(IgniteCacheProxy.java:807)
> at
> org.apache.ignite.internal.processors.platform.cache.PlatformCache.runQuery(PlatformCache.java:1213)
> ... 2 more
> Caused by: class
> org.apache.ignite.internal.processors.query.IgniteSQLException: Failed to
> parse query: SELECT "persons-sql"."PERSON"._KEY, "persons-sql"."PERSON"._VAL
> from Person1, "orgs-sql".Organization where Person.OrgId =
> "orgs-sql".Organization._key and "orgs-sql".Organization.Name = ?
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.queryDistributedSqlFields(IgniteH2Indexing.java:1293)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.queryDistributedSql(IgniteH2Indexing.java:1198)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$8.applyx(GridQueryProcessor.java:1957)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$8.applyx(GridQueryProcessor.java:1955)
> at
> org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:2293)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.queryDistributedSql(GridQueryProcessor.java:1954)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySql(GridQueryProcessor.java:1934)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxy.query(IgniteCacheProxy.java:792)
> ... 3 more
> Caused by: org.h2.jdbc.JdbcSQLException: Table "PERSON1" not found; SQL
> statement:
> SELECT "persons-sql"."PERSON"._KEY, "persons-sql"."PERSON"._VAL from Person1,
> "orgs-sql".Organization where Person.OrgId = "orgs-sql".Organization._key and
> "orgs-sql".Organization.Name = ? [42102-195]
> at org.h2.message.DbException.getJdbcSQLException(DbException.java:345)
> at org.h2.message.DbException.get(DbException.java:179)
> at org.h2.message.DbException.get(DbException.java:155)
> at org.h2.command.Parser.readTableOrView(Parser.java:5506)
> at org.h2.command.Parser.readTableFilter(Parser.java:1260)
> at org.h2.command.Parser.parseSelectSimpleFromPart(Parser.java:1940)
> at org.h2.command.Parser.parseSelectSimple(Parser.java:2089)
> at org.h2.command.Parser.parseSele
[jira] [Comment Edited] (IGNITE-6456) Add flags to ClientConnectorConfiguration which enable/disable different clients
[
https://issues.apache.org/jira/browse/IGNITE-6456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16321942#comment-16321942
]
Pavel Tupitsyn edited comment on IGNITE-6456 at 1/11/18 9:33 AM:
-
[~rkondakov] I see some issues with {{onHandshake}} method:
* Duplicate response writing code.
* Incorrect {{clientType}} check. We should return an error immediately if
{{clientType}} is not valid.
* Method is too big.
Let's refactor and fix these.
was (Author: ptupitsyn):
[~rkondakov] I see some issues with {{onHandshake}} method:
* Duplicate response writing code.
* Incorrect {{clientType}} check. We should return an error immediately if
{{clientType}} is not valid.
Let's refactor and fix these.
> Add flags to ClientConnectorConfiguration which enable/disable different
> clients
>
>
> Key: IGNITE-6456
> URL: https://issues.apache.org/jira/browse/IGNITE-6456
> Project: Ignite
> Issue Type: Improvement
> Components: jdbc, odbc, thin client
>Affects Versions: 2.1
>Reporter: Igor Sapego
>Assignee: Roman Kondakov
> Labels: usability
> Fix For: 2.4
>
>
> There is currently no way to disable only one client. For example, currently
> you can't disallow thin JDBC driver connectivity alone, you can only disable
> the whole {{ClientListenerProcessor}}, which is going to disable ODBC and
> thin .NET clients as well.
> We should add options to disable/enable every single client, supported by the
> {{ClientListenerProcessor}} separately. For example, we can add flags to the
> {{ClientConnectorConfiguration}}:
> {{allowJdbc}}
> {{allowOdbc}}
> {{allowClient}}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
