[jira] [Comment Edited] (GEODE-6338) Reconnect attempts throw NPE due to JGroups channel being closed
[
https://issues.apache.org/jira/browse/GEODE-6338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16768131#comment-16768131
]
Dharam Thacker edited comment on GEODE-6338 at 2/14/19 12:16 PM:
-
I would really appreciate if we can take this up in upcoming release [1.9.0].
This is badly impacting whenever network link fluctuates and admin member
throws other one forcefully
was (Author: dharamthacke...@gmail.com):
I would really appreciate if we can take this up in upcoming release [1.9.0].
This is badly impacting whenever network link fluctuates and admin member
throws other one forcefully[1.9.0]
> Reconnect attempts throw NPE due to JGroups channel being closed
>
>
> Key: GEODE-6338
> URL: https://issues.apache.org/jira/browse/GEODE-6338
> Project: Geode
> Issue Type: Bug
> Components: membership
>Reporter: Bruce Schuchardt
>Assignee: Bruce Schuchardt
>Priority: Major
>
> Twice this week people have reported null pointer exceptions in
> auto-reconnect attempts looking like this:
> {noformat}
> org.apache.geode.SystemConnectException: Problem starting up membership
> services
> at
> org.apache.geode.distributed.internal.membership.gms.GMSMemberFactory.newMembershipManager(GMSMemberFactory.java:114)
> at
> org.apache.geode.distributed.internal.membership.MemberFactory.newMembershipManager(MemberFactory.java:90)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.(ClusterDistributionManager.java:771)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.(ClusterDistributionManager.java:889)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.create(ClusterDistributionManager.java:533)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.initialize(InternalDistributedSystem.java:769)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.newInstance(InternalDistributedSystem.java:362)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.newInstance(InternalDistributedSystem.java:348)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.newInstance(InternalDistributedSystem.java:342)
> at
> org.apache.geode.distributed.DistributedSystem.connect(DistributedSystem.java:215)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.reconnect(InternalDistributedSystem.java:2704)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.tryReconnect(InternalDistributedSystem.java:2530)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.disconnect(InternalDistributedSystem.java:1044)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager$DMListener.membershipFailure(ClusterDistributionManager.java:3406)
> at
> org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManager.uncleanShutdown(GMSMembershipManager.java:1534)
> at
> org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManager.lambda$forceDisconnect$3(GMSMembershipManager.java:2531)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.lang.NullPointerException
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger.establishLocalAddress(JGroupsMessenger.java:483)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger.start(JGroupsMessenger.java:361)
> at
> org.apache.geode.distributed.internal.membership.gms.Services.start(Services.java:146)
> at
> org.apache.geode.distributed.internal.membership.gms.GMSMemberFactory.newMembershipManager(GMSMemberFactory.java:105)
> ... 16 more
> {noformat}
>
> This seems to indicate that the JGroups channel was somehow closed but
> auto-reconnect attempts continued. If the JGroups channel is closed
> auto-reconnect attempts should cease.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-6338) Reconnect attempts throw NPE due to JGroups channel being closed
[
https://issues.apache.org/jira/browse/GEODE-6338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16768131#comment-16768131
]
Dharam Thacker commented on GEODE-6338:
---
I would really appreciate if we can take this up in upcoming release [1.9.0].
This is badly impacting whenever network link fluctuates and admin member
throws other one forcefully[1.9.0]
> Reconnect attempts throw NPE due to JGroups channel being closed
>
>
> Key: GEODE-6338
> URL: https://issues.apache.org/jira/browse/GEODE-6338
> Project: Geode
> Issue Type: Bug
> Components: membership
>Reporter: Bruce Schuchardt
>Assignee: Bruce Schuchardt
>Priority: Major
>
> Twice this week people have reported null pointer exceptions in
> auto-reconnect attempts looking like this:
> {noformat}
> org.apache.geode.SystemConnectException: Problem starting up membership
> services
> at
> org.apache.geode.distributed.internal.membership.gms.GMSMemberFactory.newMembershipManager(GMSMemberFactory.java:114)
> at
> org.apache.geode.distributed.internal.membership.MemberFactory.newMembershipManager(MemberFactory.java:90)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.(ClusterDistributionManager.java:771)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.(ClusterDistributionManager.java:889)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.create(ClusterDistributionManager.java:533)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.initialize(InternalDistributedSystem.java:769)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.newInstance(InternalDistributedSystem.java:362)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.newInstance(InternalDistributedSystem.java:348)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.newInstance(InternalDistributedSystem.java:342)
> at
> org.apache.geode.distributed.DistributedSystem.connect(DistributedSystem.java:215)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.reconnect(InternalDistributedSystem.java:2704)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.tryReconnect(InternalDistributedSystem.java:2530)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.disconnect(InternalDistributedSystem.java:1044)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager$DMListener.membershipFailure(ClusterDistributionManager.java:3406)
> at
> org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManager.uncleanShutdown(GMSMembershipManager.java:1534)
> at
> org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManager.lambda$forceDisconnect$3(GMSMembershipManager.java:2531)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.lang.NullPointerException
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger.establishLocalAddress(JGroupsMessenger.java:483)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger.start(JGroupsMessenger.java:361)
> at
> org.apache.geode.distributed.internal.membership.gms.Services.start(Services.java:146)
> at
> org.apache.geode.distributed.internal.membership.gms.GMSMemberFactory.newMembershipManager(GMSMemberFactory.java:105)
> ... 16 more
> {noformat}
>
> This seems to indicate that the JGroups channel was somehow closed but
> auto-reconnect attempts continued. If the JGroups channel is closed
> auto-reconnect attempts should cease.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-4040) Add support for if-Else/case-when flow in OQL query
[ https://issues.apache.org/jira/browse/GEODE-4040?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dharam Thacker updated GEODE-4040: -- Description: We would like to see support for conditional flow within OQL using *where case..when*,*if/else* pattern. In current situation one has to write function for all such cases which increases time to market as it needs deployment and approvals for large organizations. *+Example+*: [Just to provide glimpse of use case but not actual syntax] select (if(c.isGoldenParty) then c.parentId;else c.clientId endif) as clientId from /Client c was: It's very handy and widely used feature where case..when,if/else kind of evaluations can be done directly using OQL In current situation one has to write function for all such cases which increases time to market as it needs deployment and approvals for large organizations. *+Example+*: [Just to provide glimpse of use case but not actual syntax] select (if(c.isGoldenParty) then c.parentId;else c.clientId endif) as clientId from /Client c > Add support for if-Else/case-when flow in OQL query > --- > > Key: GEODE-4040 > URL: https://issues.apache.org/jira/browse/GEODE-4040 > Project: Geode > Issue Type: New Feature > Components: querying >Reporter: Dharam Thacker >Priority: Major > > We would like to see support for conditional flow within OQL using *where > case..when*,*if/else* pattern. > In current situation one has to write function for all such cases which > increases time to market as it needs deployment and approvals for large > organizations. > *+Example+*: [Just to provide glimpse of use case but not actual syntax] > select (if(c.isGoldenParty) then c.parentId;else c.clientId endif) as > clientId from /Client c -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-5085) authentication failure when auto-reconnecting
[
https://issues.apache.org/jira/browse/GEODE-5085?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16440497#comment-16440497
]
Dharam Thacker commented on GEODE-5085:
---
Thanks Bruce!
Could we try to include this in Geode 1.6.0 as it's critical one?
It's breaking few critical apps with latest gemfire 9.4.0 as well which was
build using Apache geode 1.5.0.
Thanks,
Dharam
> authentication failure when auto-reconnecting
> -
>
> Key: GEODE-5085
> URL: https://issues.apache.org/jira/browse/GEODE-5085
> Project: Geode
> Issue Type: Bug
> Components: membership, security
>Reporter: Bruce Schuchardt
>Assignee: Bruce Schuchardt
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I added a security manager to ReconnectDUnitTest.testReconnectWithQuorum()
> and got a failure to authenticate during the reconnect attempt.
> {noformat}
> [vm3] [warn 2018/04/16 10:37:17.773 PDT tid=92] Exception
> occurred while trying to connect the system during reconnect
> [vm3] org.apache.geode.security.AuthenticationRequiredException: Failed to
> find credentials from [10.118.20.59(16110:locator):32770]
> [vm3] at
> org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave.attemptToJoin(GMSJoinLeave.java:452)
> [vm3] at
> org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave.join(GMSJoinLeave.java:338)
> [vm3] at
> org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManager.join(GMSMembershipManager.java:658)
> [vm3] at
> org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManager.joinDistributedSystem(GMSMembershipManager.java:747)
> [vm3] at
> org.apache.geode.distributed.internal.membership.gms.Services.start(Services.java:191)
> [vm3] at
> org.apache.geode.distributed.internal.membership.gms.GMSMemberFactory.newMembershipManager(GMSMemberFactory.java:106)
> [vm3] at
> org.apache.geode.distributed.internal.membership.MemberFactory.newMembershipManager(MemberFactory.java:90)
> [vm3] at
> org.apache.geode.distributed.internal.ClusterDistributionManager.(ClusterDistributionManager.java:1027)
> [vm3] at
> org.apache.geode.distributed.internal.ClusterDistributionManager.(ClusterDistributionManager.java:1061)
> [vm3] at
> org.apache.geode.distributed.internal.ClusterDistributionManager.create(ClusterDistributionManager.java:554)
> [vm3] at
> org.apache.geode.distributed.internal.InternalDistributedSystem.initialize(InternalDistributedSystem.java:762)
> [vm3] at
> org.apache.geode.distributed.internal.InternalDistributedSystem.newInstance(InternalDistributedSystem.java:354)
> [vm3] at
> org.apache.geode.distributed.internal.InternalDistributedSystem.newInstance(InternalDistributedSystem.java:340)
> [vm3] at
> org.apache.geode.distributed.internal.InternalDistributedSystem.newInstance(InternalDistributedSystem.java:334)
> [vm3] at
> org.apache.geode.distributed.DistributedSystem.connect(DistributedSystem.java:211)
> [vm3] at
> org.apache.geode.distributed.internal.InternalDistributedSystem.reconnect(InternalDistributedSystem.java:2732)
> [vm3] at
> org.apache.geode.distributed.internal.InternalDistributedSystem.tryReconnect(InternalDistributedSystem.java:2558)
> [vm3] at
> org.apache.geode.distributed.internal.InternalDistributedSystem.disconnect(InternalDistributedSystem.java:1040)
> [vm3] at
> org.apache.geode.distributed.internal.ClusterDistributionManager$DMListener.membershipFailure(ClusterDistributionManager.java:4030)
> [vm3] at
> org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManager.uncleanShutdown(GMSMembershipManager.java:1554)
> [vm3] at
> org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManager.lambda$forceDisconnect$1(GMSMembershipManager.java:2561)
> [vm3] at java.lang.Thread.run(Thread.java:748)
> {noformat}
> The security manager settings were added to getDistributedSystemProperties():
> {code}
> @Override
> public Properties getDistributedSystemProperties() {
> if (dsProperties == null) {
> dsProperties = new Properties();
> dsProperties.put(MAX_WAIT_TIME_RECONNECT, "2");
> dsProperties.put(ENABLE_NETWORK_PARTITION_DETECTION, "true");
> dsProperties.put(DISABLE_AUTO_RECONNECT, "false");
> dsProperties.put(ENABLE_CLUSTER_CONFIGURATION, "false");
> dsProperties.put(LOCATORS, "localHost[" + locatorPort + "]");
> dsProperties.put(MCAST_PORT, "0");
> dsProperties.put(MEMBER_TIMEOUT, "1000");
> dsProperties.put(LOG_LEVEL, LogWriterUtils.getDUnitLogL
[jira] [Commented] (GEODE-5052) AuthenticationRequiredException on auto reconnect after force disconnection due to security-udp-dhalgo property
[ https://issues.apache.org/jira/browse/GEODE-5052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16435403#comment-16435403 ] Dharam Thacker commented on GEODE-5052: --- Hi [~bschuchardt] , As per our conversation, I have opened a jira related to issue with 'security-udp-dhalgo' Thanks, Dharam > AuthenticationRequiredException on auto reconnect after force disconnection > due to security-udp-dhalgo property > --- > > Key: GEODE-5052 > URL: https://issues.apache.org/jira/browse/GEODE-5052 > Project: Geode > Issue Type: Bug > Components: membership >Reporter: Dharam Thacker >Priority: Major > Attachments: Geode_logs.txt > > > Member is unable to join distributed system back on auto reconnect after > force disconnect. > # Initially on system start up, user has not set any value for > 'security-udp-dhalgo' property and it comes as "*security-udp-dhalgo =*" with > log-level as config. > # Once it's disconnected forcefully it tried to bootstrap again and attempts > are made to join distributed system > # On bootstrap it was observed that the same property comes as > "*security-udp-dhalgo = ***" which indicates it defaults to some value > # As a result of that, it fails to find out credentials and results into > AuthenticationRequiredException > +*Detailed Logs:*+ > Please find in attachment section -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-5052) AuthenticationRequiredException on auto reconnect after force disconnection due to security-udp-dhalgo property
[ https://issues.apache.org/jira/browse/GEODE-5052?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dharam Thacker updated GEODE-5052: -- Description: Member is unable to join distributed system back on auto reconnect after force disconnect. # Initially on system start up, user has not set any value for 'security-udp-dhalgo' property and it comes as "security-udp-dhalgo = " with log-level as config. # Once it's disconnected forcefully it tried to bootstrap again and attempts are made to join distributed system # On bootstrap it was observed that the same property comes as "security-udp-dhalgo = **" which indicates it defaults to some value # As a result of that, it fails to find out credentials and results into AuthenticationRequiredException +*Detailed Logs:*+ Please find in attachment section was: Member is unable to join distributed system back on auto reconnect after force disconnect. # Initially on system start up, user has not set any value for 'security-udp-dhalgo' property and it comes as "security-udp-dhalgo = " with log-level as config. # Once it's disconnected forcefully it tried to bootstrap again and attempts are made to join distributed system # On bootstrap it was observed that the same property comes as "security-udp-dhalgo = **" which indicates it defaults to some value # As a result of that, it fails to find out credentials and results into AuthenticationRequiredException +*Detailed Logs:*+ Please find in attachment section > AuthenticationRequiredException on auto reconnect after force disconnection > due to security-udp-dhalgo property > --- > > Key: GEODE-5052 > URL: https://issues.apache.org/jira/browse/GEODE-5052 > Project: Geode > Issue Type: Bug > Components: membership >Reporter: Dharam Thacker >Priority: Major > Attachments: Geode_logs.txt > > > Member is unable to join distributed system back on auto reconnect after > force disconnect. > # Initially on system start up, user has not set any value for > 'security-udp-dhalgo' property and it comes as "security-udp-dhalgo = " with > log-level as config. > # Once it's disconnected forcefully it tried to bootstrap again and attempts > are made to join distributed system > # On bootstrap it was observed that the same property comes as > "security-udp-dhalgo = **" which indicates it defaults to some value > # As a result of that, it fails to find out credentials and results into > AuthenticationRequiredException > +*Detailed Logs:*+ > Please find in attachment section -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-5052) AuthenticationRequiredException on auto reconnect after force disconnection due to security-udp-dhalgo property
[ https://issues.apache.org/jira/browse/GEODE-5052?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dharam Thacker updated GEODE-5052: -- Description: Member is unable to join distributed system back on auto reconnect after force disconnect. # Initially on system start up, user has not set any value for 'security-udp-dhalgo' property and it comes as "*security-udp-dhalgo =*" with log-level as config. # Once it's disconnected forcefully it tried to bootstrap again and attempts are made to join distributed system # On bootstrap it was observed that the same property comes as "*security-udp-dhalgo = ***" which indicates it defaults to some value # As a result of that, it fails to find out credentials and results into AuthenticationRequiredException +*Detailed Logs:*+ Please find in attachment section was: Member is unable to join distributed system back on auto reconnect after force disconnect. # Initially on system start up, user has not set any value for 'security-udp-dhalgo' property and it comes as "security-udp-dhalgo = " with log-level as config. # Once it's disconnected forcefully it tried to bootstrap again and attempts are made to join distributed system # On bootstrap it was observed that the same property comes as "security-udp-dhalgo = **" which indicates it defaults to some value # As a result of that, it fails to find out credentials and results into AuthenticationRequiredException +*Detailed Logs:*+ Please find in attachment section > AuthenticationRequiredException on auto reconnect after force disconnection > due to security-udp-dhalgo property > --- > > Key: GEODE-5052 > URL: https://issues.apache.org/jira/browse/GEODE-5052 > Project: Geode > Issue Type: Bug > Components: membership >Reporter: Dharam Thacker >Priority: Major > Attachments: Geode_logs.txt > > > Member is unable to join distributed system back on auto reconnect after > force disconnect. > # Initially on system start up, user has not set any value for > 'security-udp-dhalgo' property and it comes as "*security-udp-dhalgo =*" with > log-level as config. > # Once it's disconnected forcefully it tried to bootstrap again and attempts > are made to join distributed system > # On bootstrap it was observed that the same property comes as > "*security-udp-dhalgo = ***" which indicates it defaults to some value > # As a result of that, it fails to find out credentials and results into > AuthenticationRequiredException > +*Detailed Logs:*+ > Please find in attachment section -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GEODE-5052) AuthenticationRequiredException on auto reconnect after force disconnection due to security-udp-dhalgo property
Dharam Thacker created GEODE-5052: - Summary: AuthenticationRequiredException on auto reconnect after force disconnection due to security-udp-dhalgo property Key: GEODE-5052 URL: https://issues.apache.org/jira/browse/GEODE-5052 Project: Geode Issue Type: Bug Components: membership Reporter: Dharam Thacker Attachments: Geode_logs.txt Member is unable to join distributed system back on auto reconnect after force disconnect. # Initially on system start up, user has not set any value for 'security-udp-dhalgo' property and it comes as "security-udp-dhalgo = " with log-level as config. # Once it's disconnected forcefully it tried to bootstrap again and attempts are made to join distributed system # On bootstrap it was observed that the same property comes as "security-udp-dhalgo = **" which indicates it defaults to some value # As a result of that, it fails to find out credentials and results into AuthenticationRequiredException +*Detailed Logs:*+ Please find in attachment section -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-5052) AuthenticationRequiredException on auto reconnect after force disconnection due to security-udp-dhalgo property
[ https://issues.apache.org/jira/browse/GEODE-5052?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dharam Thacker updated GEODE-5052: -- Attachment: Geode_logs.txt > AuthenticationRequiredException on auto reconnect after force disconnection > due to security-udp-dhalgo property > --- > > Key: GEODE-5052 > URL: https://issues.apache.org/jira/browse/GEODE-5052 > Project: Geode > Issue Type: Bug > Components: membership >Reporter: Dharam Thacker >Priority: Major > Attachments: Geode_logs.txt > > > Member is unable to join distributed system back on auto reconnect after > force disconnect. > # Initially on system start up, user has not set any value for > 'security-udp-dhalgo' property and it comes as "security-udp-dhalgo = " with > log-level as config. > # Once it's disconnected forcefully it tried to bootstrap again and attempts > are made to join distributed system > # On bootstrap it was observed that the same property comes as > "security-udp-dhalgo = **" which indicates it defaults to some value > # As a result of that, it fails to find out credentials and results into > AuthenticationRequiredException > > +*Detailed Logs:*+ > Please find in attachment section -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-4828) Gfsh fails to determine status of members not started using ServerLauncher/LocatorLauncher
[ https://issues.apache.org/jira/browse/GEODE-4828?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16433443#comment-16433443 ] Dharam Thacker commented on GEODE-4828: --- Hello [~agingade], I am not sure on prioritization for this jira. I had opened it last month. Could you help me to analyse and move it to correct version? Thanks, Dharam > Gfsh fails to determine status of members not started using > ServerLauncher/LocatorLauncher > -- > > Key: GEODE-4828 > URL: https://issues.apache.org/jira/browse/GEODE-4828 > Project: Geode > Issue Type: Bug > Components: gfsh >Reporter: Dharam Thacker >Priority: Major > Fix For: 1.6.0 > > > +*Detailed Description:*+ > [http://mail-archives.apache.org/mod_mbox/geode-user/201709.mbox/%3ccaf3uat372ewvco-a8zpj7jsimvoqd4uladt_udryx5soeky...@mail.gmail.com%3E] > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GEODE-4828) Gfsh fails to determine status of members not started using ServerLauncher/LocatorLauncher
Dharam Thacker created GEODE-4828: - Summary: Gfsh fails to determine status of members not started using ServerLauncher/LocatorLauncher Key: GEODE-4828 URL: https://issues.apache.org/jira/browse/GEODE-4828 Project: Geode Issue Type: Bug Components: gfsh Reporter: Dharam Thacker Fix For: 1.6.0 +*Detailed Description:*+ [http://mail-archives.apache.org/mod_mbox/geode-user/201709.mbox/%3ccaf3uat372ewvco-a8zpj7jsimvoqd4uladt_udryx5soeky...@mail.gmail.com%3E] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-4040) Add support for if-Else/case-when flow in OQL query
[ https://issues.apache.org/jira/browse/GEODE-4040?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dharam Thacker updated GEODE-4040: -- Description: It's very handy and widely used feature where case..when,if/else kind of evaluations can be done directly using OQL In current situation one has to write function for all such cases which increases time to market as it needs deployment and approvals for large organizations. *+Example+*: [Just to provide glimpse of use case but not actual syntax] select (if(c.isGoldenParty) then c.parentId;else c.clientId endif) as clientId from /Client c was: It's very handy and widely used feature where case..when,if/else kind of evaluations can be done directly using OQL In current situation one has to write function for all such cases which increases time to market as it needs deployment and approvals for large organizations. *+Example+*: [Just to provide glimpse of use case but not actual syntax] select c.clientId from /Client c where (if(c.isGoldenParty) then c.parentId;else c.clientId endif) as clientId > Add support for if-Else/case-when flow in OQL query > --- > > Key: GEODE-4040 > URL: https://issues.apache.org/jira/browse/GEODE-4040 > Project: Geode > Issue Type: New Feature > Components: querying >Reporter: Dharam Thacker > > It's very handy and widely used feature where case..when,if/else kind of > evaluations can be done directly using OQL > In current situation one has to write function for all such cases which > increases time to market as it needs deployment and approvals for large > organizations. > *+Example+*: [Just to provide glimpse of use case but not actual syntax] > select (if(c.isGoldenParty) then c.parentId;else c.clientId endif) as > clientId from /Client c > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (GEODE-4041) Add support for 'Union All' flow in Oql
[ https://issues.apache.org/jira/browse/GEODE-4041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dharam Thacker updated GEODE-4041: -- Description: There are lot of applications in Financial services world driven by 'Lookup based rules'/'Decision Table' approach. *+Example:+* Give me all rules where counterParty matches to "XYZ" and Products matches "INDEX|TRANCHE" and clearingJurisdictions matches "ICE|ESMA" UNION ALL Give me all rules where counterParty matches to "XYZ" and Products matches "ALL" and clearingJurisdictions matches "ALL" and targetParty is not same as "$TradeFacts.Entity" Purpose of above query is to get either exact rule/default rule which is a super set of given trade facts. As of now, one has to write function logic to deal with such situations to avoid round trip between client/server due to invocation of multiple queries was: There are lot of applications in Financial services world driven by 'Lookup based rules'/'Decision Table' approach. *+Example:+* Give me all rules where counterParty matches to "XYZ" and Products matches "INDEX|TRANCHE" and clearingJurisdictions matches "ICE|ESMA" UNION ALL Give me all rules where counterParty matches to "XYZ" and Products matches "ALL" and clearingJurisdictions matches "ALL" Purpose of above query is to get either exact rule/default rule which is a super set of given trade facts. As of now, one has to write function logic to deal with such situations to avoid round trip between client/server due to invocation of multiple queries > Add support for 'Union All' flow in Oql > --- > > Key: GEODE-4041 > URL: https://issues.apache.org/jira/browse/GEODE-4041 > Project: Geode > Issue Type: New Feature > Components: querying >Reporter: Dharam Thacker > > There are lot of applications in Financial services world driven by 'Lookup > based rules'/'Decision Table' approach. > *+Example:+* > Give me all rules where counterParty matches to "XYZ" and Products matches > "INDEX|TRANCHE" and clearingJurisdictions matches "ICE|ESMA" > UNION ALL > Give me all rules where counterParty matches to "XYZ" and Products matches > "ALL" and clearingJurisdictions matches "ALL" and targetParty is not same as > "$TradeFacts.Entity" > Purpose of above query is to get either exact rule/default rule which is a > super set of given trade facts. > As of now, one has to write function logic to deal with such situations to > avoid round trip between client/server due to invocation of multiple queries -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (GEODE-4041) Add support for 'Union All' flow in Oql
Dharam Thacker created GEODE-4041: - Summary: Add support for 'Union All' flow in Oql Key: GEODE-4041 URL: https://issues.apache.org/jira/browse/GEODE-4041 Project: Geode Issue Type: New Feature Components: querying Reporter: Dharam Thacker There are lot of applications in Financial services world driven by 'Lookup based rules'/'Decision Table' approach. *+Example:+* Give me all rules where counterParty matches to "XYZ" and Products matches "INDEX|TRANCHE" and clearingJurisdictions matches "ICE|ESMA" UNION ALL Give me all rules where counterParty matches to "XYZ" and Products matches "ALL" and clearingJurisdictions matches "ALL" Purpose of above query is to get either exact rule/default rule which is a super set of given trade facts. As of now, one has to write function logic to deal with such situations to avoid round trip between client/server due to invocation of multiple queries -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (GEODE-4040) Add support for if-Else/case-when flow in OQL query
[ https://issues.apache.org/jira/browse/GEODE-4040?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dharam Thacker updated GEODE-4040: -- Summary: Add support for if-Else/case-when flow in OQL query (was: Add support for 'if/Else'/''case/when' flow in OQL query) > Add support for if-Else/case-when flow in OQL query > --- > > Key: GEODE-4040 > URL: https://issues.apache.org/jira/browse/GEODE-4040 > Project: Geode > Issue Type: New Feature > Components: querying >Reporter: Dharam Thacker > > It's very handy and widely used feature where case..when,if/else kind of > evaluations can be done directly using OQL > In current situation one has to write function for all such cases which > increases time to market as it needs deployment and approvals for large > organizations. > *+Example+*: [Just to provide glimpse of use case but not actual syntax] > select c.clientId from /Client c where (if(c.isGoldenParty) then > c.parentId;else c.clientId endif) as clientId > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (GEODE-4040) Add support for 'if/Else'/''case/when' flow in OQL query
[ https://issues.apache.org/jira/browse/GEODE-4040?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dharam Thacker updated GEODE-4040: -- Description: It's very handy and widely used feature where case..when,if/else kind of evaluations can be done directly using OQL In current situation one has to write function for all such cases which increases time to market as it needs deployment and approvals for large organizations. *+Example+*: [Just to provide glimpse of use case but not actual syntax] select c.clientId from /Client c where (if(c.isGoldenParty) then c.parentId;else c.clientId endif) as clientId was: It's very handy and common widely used feature where case..when,if/else kind of evaluations can be done directly using OQL In current situation one has to write function for all such cases which increases time to market as it needs deployment and approvals for large organizations. *+Example+*: [Just to provide glimpse of use case but not actual syntax] select c.clientId from /Client c where (if(c.isGoldenParty) then c.parentId;else c.clientId endif) as clientId > Add support for 'if/Else'/''case/when' flow in OQL query > > > Key: GEODE-4040 > URL: https://issues.apache.org/jira/browse/GEODE-4040 > Project: Geode > Issue Type: New Feature > Components: querying >Reporter: Dharam Thacker > > It's very handy and widely used feature where case..when,if/else kind of > evaluations can be done directly using OQL > In current situation one has to write function for all such cases which > increases time to market as it needs deployment and approvals for large > organizations. > *+Example+*: [Just to provide glimpse of use case but not actual syntax] > select c.clientId from /Client c where (if(c.isGoldenParty) then > c.parentId;else c.clientId endif) as clientId > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (GEODE-4040) Add support for 'if/Else'/''case/when' flow in OQL query
Dharam Thacker created GEODE-4040: - Summary: Add support for 'if/Else'/''case/when' flow in OQL query Key: GEODE-4040 URL: https://issues.apache.org/jira/browse/GEODE-4040 Project: Geode Issue Type: New Feature Components: querying Reporter: Dharam Thacker It's very handy and common widely used feature where case..when,if/else kind of evaluations can be done directly using OQL In current situation one has to write function for all such cases which increases time to market as it needs deployment and approvals for large organizations. *+Example+*: [Just to provide glimpse of use case but not actual syntax] select c.clientId from /Client c where (if(c.isGoldenParty) then c.parentId;else c.clientId endif) as clientId -- This message was sent by Atlassian JIRA (v6.4.14#64029)
