[jira] [Commented] (GEODE-7682) Create the java API to clear a PartitionedRegion
[ https://issues.apache.org/jira/browse/GEODE-7682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17048234#comment-17048234 ] ASF subversion and git services commented on GEODE-7682: Commit 1573e3de4ad4a2788127bacf612766685af35395 in geode's branch refs/heads/feature/GEODE-7682-2 from zhouxh [ https://gitbox.apache.org/repos/asf?p=geode.git;h=1573e3d ] GEODE-7682: add clear API for PR > Create the java API to clear a PartitionedRegion > > > Key: GEODE-7682 > URL: https://issues.apache.org/jira/browse/GEODE-7682 > Project: Geode > Issue Type: New Feature > Components: regions >Reporter: Nabarun Nag >Priority: Major > Labels: GeodeCommons > Time Spent: 0.5h > Remaining Estimate: 0h > > This task will just include creating the API which calls the internal > commands to clear the region and send messages to the members hosting the > Partitioned region. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-6807) changing advisors to cache advice can improve performance
[ https://issues.apache.org/jira/browse/GEODE-6807?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Ivanac updated GEODE-6807: Fix Version/s: 1.13.0 > changing advisors to cache advice can improve performance > - > > Key: GEODE-6807 > URL: https://issues.apache.org/jira/browse/GEODE-6807 > Project: Geode > Issue Type: Improvement > Components: core >Reporter: Darrel Schneider >Assignee: Mario Ivanac >Priority: Major > Labels: needs-review, performance, pull-request-available > Fix For: 1.13.0 > > Time Spent: 7h > Remaining Estimate: 0h > > Cluster messaging uses advisors to know what member of the cluster should be > sent a message. > Currently, every time and advisor is asked for advice to iterates over its > profiles building up the advice in a HashSet that is returned. > I found on a partitioned region client/server put benchmark (32 client > threads, 2 servers with redundancy 1) that if I changed the method > adviseAllEventsOrCached to remember what it computed, that it caused the put > throughput to increase by 8%. [Update I reran and did not see an improvement > so the original 8% difference may have been caused by something else]. > Advisors know when a profile is added, removed, or modified. When that > happens any advice it has cached can be dropped. Also, the requestors of > advice need to expect the Set they get back to be unmodifiable. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-6807) changing advisors to cache advice can improve performance
[ https://issues.apache.org/jira/browse/GEODE-6807?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Ivanac resolved GEODE-6807. - Resolution: Fixed > changing advisors to cache advice can improve performance > - > > Key: GEODE-6807 > URL: https://issues.apache.org/jira/browse/GEODE-6807 > Project: Geode > Issue Type: Improvement > Components: core >Reporter: Darrel Schneider >Assignee: Mario Ivanac >Priority: Major > Labels: needs-review, performance, pull-request-available > Time Spent: 7h > Remaining Estimate: 0h > > Cluster messaging uses advisors to know what member of the cluster should be > sent a message. > Currently, every time and advisor is asked for advice to iterates over its > profiles building up the advice in a HashSet that is returned. > I found on a partitioned region client/server put benchmark (32 client > threads, 2 servers with redundancy 1) that if I changed the method > adviseAllEventsOrCached to remember what it computed, that it caused the put > throughput to increase by 8%. [Update I reran and did not see an improvement > so the original 8% difference may have been caused by something else]. > Advisors know when a profile is added, removed, or modified. When that > happens any advice it has cached can be dropped. Also, the requestors of > advice need to expect the Set they get back to be unmodifiable. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-6807) changing advisors to cache advice can improve performance
[ https://issues.apache.org/jira/browse/GEODE-6807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17048185#comment-17048185 ] ASF subversion and git services commented on GEODE-6807: Commit bf0012d6b01b6a4094fca1b2dc7a21f78603a26a in geode's branch refs/heads/develop from Mario Ivanac [ https://gitbox.apache.org/repos/asf?p=geode.git;h=bf0012d ] Feature/geode 6807 1 (#4711) * GEODE-6807: cache adviseUpdate and adviseAllEventsOrCached * GEODE-6807: update with comments * GEODE-6807: update adviseAllEventsOrCached method * GEODE-6807: update of solution with checking of version * GEODE-6807: remove assert from new code * GEODE-6807: Added UT and inRecovery update check * GEODE-6807: Added Concurrent Test * GEODE-6807: Added missing @Test and rebase * GEODE-6807: fix for race conditions > changing advisors to cache advice can improve performance > - > > Key: GEODE-6807 > URL: https://issues.apache.org/jira/browse/GEODE-6807 > Project: Geode > Issue Type: Improvement > Components: core >Reporter: Darrel Schneider >Assignee: Mario Ivanac >Priority: Major > Labels: needs-review, performance, pull-request-available > Time Spent: 7h > Remaining Estimate: 0h > > Cluster messaging uses advisors to know what member of the cluster should be > sent a message. > Currently, every time and advisor is asked for advice to iterates over its > profiles building up the advice in a HashSet that is returned. > I found on a partitioned region client/server put benchmark (32 client > threads, 2 servers with redundancy 1) that if I changed the method > adviseAllEventsOrCached to remember what it computed, that it caused the put > throughput to increase by 8%. [Update I reran and did not see an improvement > so the original 8% difference may have been caused by something else]. > Advisors know when a profile is added, removed, or modified. When that > happens any advice it has cached can be dropped. Also, the requestors of > advice need to expect the Set they get back to be unmodifiable. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Reopened] (GEODE-6536) client pr single hop will do multiple hops if things get busy
[
https://issues.apache.org/jira/browse/GEODE-6536?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mario Ivanac reopened GEODE-6536:
-
> client pr single hop will do multiple hops if things get busy
> -
>
> Key: GEODE-6536
> URL: https://issues.apache.org/jira/browse/GEODE-6536
> Project: Geode
> Issue Type: Improvement
> Components: client/server
>Reporter: Darrel Schneider
>Assignee: Mario Ivanac
>Priority: Major
> Labels: needs-review, performance, pull-request-available
> Fix For: 1.13.0
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> I was wondering why ConnectionManagerImpl.borrowConnection that targets a
> particular server will not wait for a connection to be available. This is the
> borrow used by pr single hop. It seems like if all the cnxs to that server
> are busy and we are at max that it should wait. But instead it does a single
> scan of the pool and if it does not find an idle connection it either throws
> AllConnectionsInUse or it creates one. The caller sets the onlyUseExistingCnx
> parameter based on if the pool is at max cnxs or not (seems like this should
> have been done in borrowConnection instead of the caller). If it throws
> AllConnectionsInUse the caller catches it and ignores it and then falls into
> doing a non-targeted borrow that will wait for a connection but to ANY
> server. So our single hop optimization goes away on a busy client. Since it
> can’t immediately get a connection to server A, it says just give me a
> connection to any server sends the op to that other server and that server
> ends up having to forward it to server A. You would only see this problem if
> you set a max on your client connection pool. The default of -1 just says to
> always create another connection. The only workaround I know of is to not
> limit how many connections your client can create but that could cause other
> problem (i.e. too many file descriptors).
> The questionable code is in the following classes:
> org.apache.geode.cache.client.internal.GetOp
> org.apache.geode.cache.client.internal.PutOp
> org.apache.geode.cache.client.internal.DestroyOp
> The all have something like this:
>
> {code:java}
> boolean onlyUseExistingCnx = ((poolImpl.getMaxConnections() != -1
> && poolImpl.getConnectionCount() >= poolImpl.getMaxConnections()) ? true :
> false);
> op.setAllowDuplicateMetadataRefresh(!onlyUseExistingCnx);
> return pool.executeOn(new ServerLocation(server.getHostName(),
> server.getPort()), op,
> true, onlyUseExistingCnx);
> {code}
> executeOn eventually calls ConnectionManagerImpl.borrowConnection
> It is unclear to me why they need allow duplicate metadata refresh if they
> permit borrowConnection to create a new connection to the specified server.
> They all catch and ignore
> AllConnectionsInUseException falling through and doing non-targetted
> pool.execute.
> The concern might have been that the pool would be full of connections to
> other servers preventing us from connecting to the server we need to
> communicate with. If we have existing connections to the server we could wait
> for one of those. If we don't and we are at max then we should consider
> closing a connection to some other server and create a connection to the
> server we know we need for this operation. As the server count goes up and
> the max connection count on the pool goes down I'm sure we are probably
> better off not even trying to do single hop since we might not even be able
> to have a connection to each server in the pool. But if we have a reasonable
> max connection count then it seems like we could make more of an effort to
> make sure a per server connection count is balanced and then wait for one of
> those connection to be available.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-6807) changing advisors to cache advice can improve performance
[ https://issues.apache.org/jira/browse/GEODE-6807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17048184#comment-17048184 ] ASF subversion and git services commented on GEODE-6807: Commit bf0012d6b01b6a4094fca1b2dc7a21f78603a26a in geode's branch refs/heads/develop from Mario Ivanac [ https://gitbox.apache.org/repos/asf?p=geode.git;h=bf0012d ] Feature/geode 6807 1 (#4711) * GEODE-6807: cache adviseUpdate and adviseAllEventsOrCached * GEODE-6807: update with comments * GEODE-6807: update adviseAllEventsOrCached method * GEODE-6807: update of solution with checking of version * GEODE-6807: remove assert from new code * GEODE-6807: Added UT and inRecovery update check * GEODE-6807: Added Concurrent Test * GEODE-6807: Added missing @Test and rebase * GEODE-6807: fix for race conditions > changing advisors to cache advice can improve performance > - > > Key: GEODE-6807 > URL: https://issues.apache.org/jira/browse/GEODE-6807 > Project: Geode > Issue Type: Improvement > Components: core >Reporter: Darrel Schneider >Assignee: Mario Ivanac >Priority: Major > Labels: needs-review, performance, pull-request-available > Time Spent: 7h > Remaining Estimate: 0h > > Cluster messaging uses advisors to know what member of the cluster should be > sent a message. > Currently, every time and advisor is asked for advice to iterates over its > profiles building up the advice in a HashSet that is returned. > I found on a partitioned region client/server put benchmark (32 client > threads, 2 servers with redundancy 1) that if I changed the method > adviseAllEventsOrCached to remember what it computed, that it caused the put > throughput to increase by 8%. [Update I reran and did not see an improvement > so the original 8% difference may have been caused by something else]. > Advisors know when a profile is added, removed, or modified. When that > happens any advice it has cached can be dropped. Also, the requestors of > advice need to expect the Set they get back to be unmodifiable. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-6807) changing advisors to cache advice can improve performance
[ https://issues.apache.org/jira/browse/GEODE-6807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17048190#comment-17048190 ] ASF subversion and git services commented on GEODE-6807: Commit bf0012d6b01b6a4094fca1b2dc7a21f78603a26a in geode's branch refs/heads/develop from Mario Ivanac [ https://gitbox.apache.org/repos/asf?p=geode.git;h=bf0012d ] Feature/geode 6807 1 (#4711) * GEODE-6807: cache adviseUpdate and adviseAllEventsOrCached * GEODE-6807: update with comments * GEODE-6807: update adviseAllEventsOrCached method * GEODE-6807: update of solution with checking of version * GEODE-6807: remove assert from new code * GEODE-6807: Added UT and inRecovery update check * GEODE-6807: Added Concurrent Test * GEODE-6807: Added missing @Test and rebase * GEODE-6807: fix for race conditions > changing advisors to cache advice can improve performance > - > > Key: GEODE-6807 > URL: https://issues.apache.org/jira/browse/GEODE-6807 > Project: Geode > Issue Type: Improvement > Components: core >Reporter: Darrel Schneider >Assignee: Mario Ivanac >Priority: Major > Labels: needs-review, performance, pull-request-available > Time Spent: 7h > Remaining Estimate: 0h > > Cluster messaging uses advisors to know what member of the cluster should be > sent a message. > Currently, every time and advisor is asked for advice to iterates over its > profiles building up the advice in a HashSet that is returned. > I found on a partitioned region client/server put benchmark (32 client > threads, 2 servers with redundancy 1) that if I changed the method > adviseAllEventsOrCached to remember what it computed, that it caused the put > throughput to increase by 8%. [Update I reran and did not see an improvement > so the original 8% difference may have been caused by something else]. > Advisors know when a profile is added, removed, or modified. When that > happens any advice it has cached can be dropped. Also, the requestors of > advice need to expect the Set they get back to be unmodifiable. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-6807) changing advisors to cache advice can improve performance
[ https://issues.apache.org/jira/browse/GEODE-6807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17048189#comment-17048189 ] ASF subversion and git services commented on GEODE-6807: Commit bf0012d6b01b6a4094fca1b2dc7a21f78603a26a in geode's branch refs/heads/develop from Mario Ivanac [ https://gitbox.apache.org/repos/asf?p=geode.git;h=bf0012d ] Feature/geode 6807 1 (#4711) * GEODE-6807: cache adviseUpdate and adviseAllEventsOrCached * GEODE-6807: update with comments * GEODE-6807: update adviseAllEventsOrCached method * GEODE-6807: update of solution with checking of version * GEODE-6807: remove assert from new code * GEODE-6807: Added UT and inRecovery update check * GEODE-6807: Added Concurrent Test * GEODE-6807: Added missing @Test and rebase * GEODE-6807: fix for race conditions > changing advisors to cache advice can improve performance > - > > Key: GEODE-6807 > URL: https://issues.apache.org/jira/browse/GEODE-6807 > Project: Geode > Issue Type: Improvement > Components: core >Reporter: Darrel Schneider >Assignee: Mario Ivanac >Priority: Major > Labels: needs-review, performance, pull-request-available > Time Spent: 7h > Remaining Estimate: 0h > > Cluster messaging uses advisors to know what member of the cluster should be > sent a message. > Currently, every time and advisor is asked for advice to iterates over its > profiles building up the advice in a HashSet that is returned. > I found on a partitioned region client/server put benchmark (32 client > threads, 2 servers with redundancy 1) that if I changed the method > adviseAllEventsOrCached to remember what it computed, that it caused the put > throughput to increase by 8%. [Update I reran and did not see an improvement > so the original 8% difference may have been caused by something else]. > Advisors know when a profile is added, removed, or modified. When that > happens any advice it has cached can be dropped. Also, the requestors of > advice need to expect the Set they get back to be unmodifiable. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-6807) changing advisors to cache advice can improve performance
[ https://issues.apache.org/jira/browse/GEODE-6807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17048187#comment-17048187 ] ASF subversion and git services commented on GEODE-6807: Commit bf0012d6b01b6a4094fca1b2dc7a21f78603a26a in geode's branch refs/heads/develop from Mario Ivanac [ https://gitbox.apache.org/repos/asf?p=geode.git;h=bf0012d ] Feature/geode 6807 1 (#4711) * GEODE-6807: cache adviseUpdate and adviseAllEventsOrCached * GEODE-6807: update with comments * GEODE-6807: update adviseAllEventsOrCached method * GEODE-6807: update of solution with checking of version * GEODE-6807: remove assert from new code * GEODE-6807: Added UT and inRecovery update check * GEODE-6807: Added Concurrent Test * GEODE-6807: Added missing @Test and rebase * GEODE-6807: fix for race conditions > changing advisors to cache advice can improve performance > - > > Key: GEODE-6807 > URL: https://issues.apache.org/jira/browse/GEODE-6807 > Project: Geode > Issue Type: Improvement > Components: core >Reporter: Darrel Schneider >Assignee: Mario Ivanac >Priority: Major > Labels: needs-review, performance, pull-request-available > Time Spent: 7h > Remaining Estimate: 0h > > Cluster messaging uses advisors to know what member of the cluster should be > sent a message. > Currently, every time and advisor is asked for advice to iterates over its > profiles building up the advice in a HashSet that is returned. > I found on a partitioned region client/server put benchmark (32 client > threads, 2 servers with redundancy 1) that if I changed the method > adviseAllEventsOrCached to remember what it computed, that it caused the put > throughput to increase by 8%. [Update I reran and did not see an improvement > so the original 8% difference may have been caused by something else]. > Advisors know when a profile is added, removed, or modified. When that > happens any advice it has cached can be dropped. Also, the requestors of > advice need to expect the Set they get back to be unmodifiable. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-6807) changing advisors to cache advice can improve performance
[ https://issues.apache.org/jira/browse/GEODE-6807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17048191#comment-17048191 ] ASF subversion and git services commented on GEODE-6807: Commit bf0012d6b01b6a4094fca1b2dc7a21f78603a26a in geode's branch refs/heads/develop from Mario Ivanac [ https://gitbox.apache.org/repos/asf?p=geode.git;h=bf0012d ] Feature/geode 6807 1 (#4711) * GEODE-6807: cache adviseUpdate and adviseAllEventsOrCached * GEODE-6807: update with comments * GEODE-6807: update adviseAllEventsOrCached method * GEODE-6807: update of solution with checking of version * GEODE-6807: remove assert from new code * GEODE-6807: Added UT and inRecovery update check * GEODE-6807: Added Concurrent Test * GEODE-6807: Added missing @Test and rebase * GEODE-6807: fix for race conditions > changing advisors to cache advice can improve performance > - > > Key: GEODE-6807 > URL: https://issues.apache.org/jira/browse/GEODE-6807 > Project: Geode > Issue Type: Improvement > Components: core >Reporter: Darrel Schneider >Assignee: Mario Ivanac >Priority: Major > Labels: needs-review, performance, pull-request-available > Time Spent: 7h > Remaining Estimate: 0h > > Cluster messaging uses advisors to know what member of the cluster should be > sent a message. > Currently, every time and advisor is asked for advice to iterates over its > profiles building up the advice in a HashSet that is returned. > I found on a partitioned region client/server put benchmark (32 client > threads, 2 servers with redundancy 1) that if I changed the method > adviseAllEventsOrCached to remember what it computed, that it caused the put > throughput to increase by 8%. [Update I reran and did not see an improvement > so the original 8% difference may have been caused by something else]. > Advisors know when a profile is added, removed, or modified. When that > happens any advice it has cached can be dropped. Also, the requestors of > advice need to expect the Set they get back to be unmodifiable. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-6807) changing advisors to cache advice can improve performance
[ https://issues.apache.org/jira/browse/GEODE-6807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17048186#comment-17048186 ] ASF subversion and git services commented on GEODE-6807: Commit bf0012d6b01b6a4094fca1b2dc7a21f78603a26a in geode's branch refs/heads/develop from Mario Ivanac [ https://gitbox.apache.org/repos/asf?p=geode.git;h=bf0012d ] Feature/geode 6807 1 (#4711) * GEODE-6807: cache adviseUpdate and adviseAllEventsOrCached * GEODE-6807: update with comments * GEODE-6807: update adviseAllEventsOrCached method * GEODE-6807: update of solution with checking of version * GEODE-6807: remove assert from new code * GEODE-6807: Added UT and inRecovery update check * GEODE-6807: Added Concurrent Test * GEODE-6807: Added missing @Test and rebase * GEODE-6807: fix for race conditions > changing advisors to cache advice can improve performance > - > > Key: GEODE-6807 > URL: https://issues.apache.org/jira/browse/GEODE-6807 > Project: Geode > Issue Type: Improvement > Components: core >Reporter: Darrel Schneider >Assignee: Mario Ivanac >Priority: Major > Labels: needs-review, performance, pull-request-available > Time Spent: 7h > Remaining Estimate: 0h > > Cluster messaging uses advisors to know what member of the cluster should be > sent a message. > Currently, every time and advisor is asked for advice to iterates over its > profiles building up the advice in a HashSet that is returned. > I found on a partitioned region client/server put benchmark (32 client > threads, 2 servers with redundancy 1) that if I changed the method > adviseAllEventsOrCached to remember what it computed, that it caused the put > throughput to increase by 8%. [Update I reran and did not see an improvement > so the original 8% difference may have been caused by something else]. > Advisors know when a profile is added, removed, or modified. When that > happens any advice it has cached can be dropped. Also, the requestors of > advice need to expect the Set they get back to be unmodifiable. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-6807) changing advisors to cache advice can improve performance
[ https://issues.apache.org/jira/browse/GEODE-6807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17048188#comment-17048188 ] ASF subversion and git services commented on GEODE-6807: Commit bf0012d6b01b6a4094fca1b2dc7a21f78603a26a in geode's branch refs/heads/develop from Mario Ivanac [ https://gitbox.apache.org/repos/asf?p=geode.git;h=bf0012d ] Feature/geode 6807 1 (#4711) * GEODE-6807: cache adviseUpdate and adviseAllEventsOrCached * GEODE-6807: update with comments * GEODE-6807: update adviseAllEventsOrCached method * GEODE-6807: update of solution with checking of version * GEODE-6807: remove assert from new code * GEODE-6807: Added UT and inRecovery update check * GEODE-6807: Added Concurrent Test * GEODE-6807: Added missing @Test and rebase * GEODE-6807: fix for race conditions > changing advisors to cache advice can improve performance > - > > Key: GEODE-6807 > URL: https://issues.apache.org/jira/browse/GEODE-6807 > Project: Geode > Issue Type: Improvement > Components: core >Reporter: Darrel Schneider >Assignee: Mario Ivanac >Priority: Major > Labels: needs-review, performance, pull-request-available > Time Spent: 7h > Remaining Estimate: 0h > > Cluster messaging uses advisors to know what member of the cluster should be > sent a message. > Currently, every time and advisor is asked for advice to iterates over its > profiles building up the advice in a HashSet that is returned. > I found on a partitioned region client/server put benchmark (32 client > threads, 2 servers with redundancy 1) that if I changed the method > adviseAllEventsOrCached to remember what it computed, that it caused the put > throughput to increase by 8%. [Update I reran and did not see an improvement > so the original 8% difference may have been caused by something else]. > Advisors know when a profile is added, removed, or modified. When that > happens any advice it has cached can be dropped. Also, the requestors of > advice need to expect the Set they get back to be unmodifiable. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-6807) changing advisors to cache advice can improve performance
[ https://issues.apache.org/jira/browse/GEODE-6807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17048183#comment-17048183 ] ASF subversion and git services commented on GEODE-6807: Commit bf0012d6b01b6a4094fca1b2dc7a21f78603a26a in geode's branch refs/heads/develop from Mario Ivanac [ https://gitbox.apache.org/repos/asf?p=geode.git;h=bf0012d ] Feature/geode 6807 1 (#4711) * GEODE-6807: cache adviseUpdate and adviseAllEventsOrCached * GEODE-6807: update with comments * GEODE-6807: update adviseAllEventsOrCached method * GEODE-6807: update of solution with checking of version * GEODE-6807: remove assert from new code * GEODE-6807: Added UT and inRecovery update check * GEODE-6807: Added Concurrent Test * GEODE-6807: Added missing @Test and rebase * GEODE-6807: fix for race conditions > changing advisors to cache advice can improve performance > - > > Key: GEODE-6807 > URL: https://issues.apache.org/jira/browse/GEODE-6807 > Project: Geode > Issue Type: Improvement > Components: core >Reporter: Darrel Schneider >Assignee: Mario Ivanac >Priority: Major > Labels: needs-review, performance, pull-request-available > Time Spent: 7h > Remaining Estimate: 0h > > Cluster messaging uses advisors to know what member of the cluster should be > sent a message. > Currently, every time and advisor is asked for advice to iterates over its > profiles building up the advice in a HashSet that is returned. > I found on a partitioned region client/server put benchmark (32 client > threads, 2 servers with redundancy 1) that if I changed the method > adviseAllEventsOrCached to remember what it computed, that it caused the put > throughput to increase by 8%. [Update I reran and did not see an improvement > so the original 8% difference may have been caused by something else]. > Advisors know when a profile is added, removed, or modified. When that > happens any advice it has cached can be dropped. Also, the requestors of > advice need to expect the Set they get back to be unmodifiable. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-7113) Rat error in geode-native CI due to missing header in ./packer/windows/install-doxygen.ps1 file
[ https://issues.apache.org/jira/browse/GEODE-7113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Diane Hardman updated GEODE-7113: - Fix Version/s: 1.10.0 > Rat error in geode-native CI due to missing header in > ./packer/windows/install-doxygen.ps1 file > --- > > Key: GEODE-7113 > URL: https://issues.apache.org/jira/browse/GEODE-7113 > Project: Geode > Issue Type: Bug > Components: build, ci >Reporter: Alberto Gomez >Assignee: Alberto Gomez >Priority: Major > Fix For: 1.10.0 > > Time Spent: 40m > Remaining Estimate: 0h > > The CI in the geode-native is broken due to > ./packer/windows/install-doxygen.ps1 lacking copyright header. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-7086) Support of IPv6 In geode-native driver
[ https://issues.apache.org/jira/browse/GEODE-7086?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Diane Hardman updated GEODE-7086: - Fix Version/s: 1.10.0 > Support of IPv6 In geode-native driver > -- > > Key: GEODE-7086 > URL: https://issues.apache.org/jira/browse/GEODE-7086 > Project: Geode > Issue Type: New Feature > Components: native client >Affects Versions: 1.9.0 >Reporter: Mario Ivanac >Assignee: Mario Ivanac >Priority: Major > Labels: needs-review, pull-request-available > Fix For: 1.10.0 > > Time Spent: 4h 40m > Remaining Estimate: 0h > > Currently geode-native does not support IPv6. Add impacts in geode-native for > support of IPv6 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-7056) Update Geode version in native client CI
[ https://issues.apache.org/jira/browse/GEODE-7056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Diane Hardman updated GEODE-7056: - Fix Version/s: 1.10.0 > Update Geode version in native client CI > > > Key: GEODE-7056 > URL: https://issues.apache.org/jira/browse/GEODE-7056 > Project: Geode > Issue Type: Wish > Components: native client >Reporter: Alberto Bustamante Reyes >Assignee: Alberto Bustamante Reyes >Priority: Major > Labels: pull-request-available > Fix For: 1.10.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > Geode native client CI is using old Geode version (1.6.0) > It can be seen in logs: > -- Found Geode: /apache-geode-1.6.0/bin/gfsh (found suitable version "1.6.0", > minimum required is "1.0") -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-7041) Write Test for FunctionService::OnServers() in New Test Framework
[ https://issues.apache.org/jira/browse/GEODE-7041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Diane Hardman updated GEODE-7041: - Fix Version/s: 1.10.0 > Write Test for FunctionService::OnServers() in New Test Framework > - > > Key: GEODE-7041 > URL: https://issues.apache.org/jira/browse/GEODE-7041 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Michael Martell >Priority: Major > Fix For: 1.10.0 > > > Currently there are no C++ tests for this API. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-6957) Write Logging benchmarks to establish baseline performance
[ https://issues.apache.org/jira/browse/GEODE-6957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Diane Hardman updated GEODE-6957: - Fix Version/s: 1.10.0 > Write Logging benchmarks to establish baseline performance > -- > > Key: GEODE-6957 > URL: https://issues.apache.org/jira/browse/GEODE-6957 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Blake Bender >Priority: Major > Fix For: 1.10.0 > > Time Spent: 20m > Remaining Estimate: 0h > > We're hoping to soon remove the internal logging class from native client and > replace it with a 3rd party logger. Part of our due dilligence for the > effort should involve verifying that there are no performance regressions, so > we need a few simple benchmarks written to do some console and file logging. > We'll record #s for these on a couple of test machines, then re-run the > benchmarks on the same machines with the new logger and compare. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-6961) Server error messages may contain leading whitespace
[ https://issues.apache.org/jira/browse/GEODE-6961?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Diane Hardman updated GEODE-6961: - Fix Version/s: 1.10.0 > Server error messages may contain leading whitespace > > > Key: GEODE-6961 > URL: https://issues.apache.org/jira/browse/GEODE-6961 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Blake Bender >Priority: Major > Fix For: 1.10.0 > > Time Spent: 20m > Remaining Estimate: 0h > > While debugging test failures, I discovered that a negative test case for > `Region::PutAll` was failing on _only one_ of our test machines, because the > Geode server returns an error string on our Linux test machine which contains > _no_ leading whitespace, but the same error string on our Mac test box starts > with _one_ leading space. The simple fix is to trim the leading space in the > native client, but perhaps it's worth a bit of someone's time later on to > determine what the difference is actually about. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-6914) Switch the XML parser from libxml to xerces
[ https://issues.apache.org/jira/browse/GEODE-6914?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Diane Hardman updated GEODE-6914: - Fix Version/s: 1.10.0 > Switch the XML parser from libxml to xerces > > > Key: GEODE-6914 > URL: https://issues.apache.org/jira/browse/GEODE-6914 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Matthew Reddington >Priority: Major > Fix For: 1.10.0 > > Time Spent: 2.5h > Remaining Estimate: 0h > > This is becoming a pain point on multiple dev platforms, so we need to switch > to something modern. On MacOS, libxml2 no longer builds on Mojave with > out-of-the-box tools, because /usr/include and /usr/lib have been removed > from the system. You can build it by running an installer package that Apple > includes with the tools _for the time being_, but it's going away, and BTW > having these directories causes problems with other packages (OpenSSL). On > Windows, the libxml build has a custom build step that _runs a javascript > file from the command line_, so if anything moves the .js file association > away from the windows scripting host (many, many applications do this, not > least of which is Webstorm IDE), you can't build libxml2 without swapping > back file associations manually. In short, it hurts when we do this, so > let's not do this any more. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-6826) Refactor TcrConnection::readMessageChunked
[ https://issues.apache.org/jira/browse/GEODE-6826?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Diane Hardman updated GEODE-6826: - Fix Version/s: 1.10.0 > Refactor TcrConnection::readMessageChunked > -- > > Key: GEODE-6826 > URL: https://issues.apache.org/jira/browse/GEODE-6826 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Blake Bender >Priority: Major > Fix For: 1.10.0 > > Time Spent: 2h 50m > Remaining Estimate: 0h > > Having debugged through a problem in this code recently, I can state with > authority that it is nigh onto unreadable in its current state, and needs to > be refactored into several helper methods to obviate the logic. The task > being performed here is not complex, so the code to perform it needs to > reflect that. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-6835) AuthenticationException when using subscription and AuthInitialize
[ https://issues.apache.org/jira/browse/GEODE-6835?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Diane Hardman updated GEODE-6835: - Fix Version/s: 1.10.0 > AuthenticationException when using subscription and AuthInitialize > -- > > Key: GEODE-6835 > URL: https://issues.apache.org/jira/browse/GEODE-6835 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Blake Bender >Priority: Major > Fix For: 1.10.0 > > > When using subscription and AuthInitialize in conjunction while doing region > puts in a loop, the Geode server eventually appears to think the connection > is dead and throws an AuthenticationException. Correct behavior in this > circumstance, according to the Geode team, is to attempt to re-authenticate > and continue on. Again according to Geode, the Java-based client has this > retry logic and is working properly, but it appears the native client is > missing retry logic in at least one code path. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-6718) Refactor TcrConnection::sendRequestForChunkedResponse, derived class, and remove pass-through calls in TrcConnection and derived
[ https://issues.apache.org/jira/browse/GEODE-6718?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Diane Hardman updated GEODE-6718: - Fix Version/s: 1.10.0 > Refactor TcrConnection::sendRequestForChunkedResponse, derived class, and > remove pass-through calls in TrcConnection and derived > > > Key: GEODE-6718 > URL: https://issues.apache.org/jira/browse/GEODE-6718 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Blake Bender >Priority: Major > Fix For: 1.10.0 > > Time Spent: 1.5h > Remaining Estimate: 0h > > This is a small thing we can do to make the code more readable and > maintainable. TcrEndpoint only has one derived class, TcrPoolEndPoint, and > the method sendRequestForChunkedResponse in both is simply a pass-through to > call TcrConnection::sendRequestForChunkedResponse. None of the parameters to > the TcrConnection call are unknown to calling code, so nothing at all is > being abstracted by having these methods on Tcr*Endpoint. Additionally, the > base class is abstract, so the implementation in TcrEndpoint is unreachable > code, and even though the method is virtual it is declared protected, so > nothing outside Tcr*Endpoint could possibly care about it. In short, the > method is gratuitous and removing it will clarify the code. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-6642) CacheAttributes header was left in the public header collection
[
https://issues.apache.org/jira/browse/GEODE-6642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Diane Hardman updated GEODE-6642:
-
Fix Version/s: 1.10.0
> CacheAttributes header was left in the public header collection
> ---
>
> Key: GEODE-6642
> URL: https://issues.apache.org/jira/browse/GEODE-6642
> Project: Geode
> Issue Type: Bug
> Components: native client
>Affects Versions: 1.8.0
>Reporter: Jacob Barrett
>Priority: Major
> Fix For: 1.10.0
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> {{CacheAttributes}} is not longer necessary and was inadvertently left in the
> public headers. The factory, {{CacheAttributesFactory}} was removed prior to
> the first release. All public APIs using {{CacheAttributes}} were removed
> prior to the first release.
> It should be safe to remove the header completely and cleanup internal usage
> of this class without effecting the public API and ABI.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-6624) SIGABRT Due to nested exceptions when value returned that can't be deserialized
[ https://issues.apache.org/jira/browse/GEODE-6624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Diane Hardman updated GEODE-6624: - Fix Version/s: 1.10.0 > SIGABRT Due to nested exceptions when value returned that can't be > deserialized > --- > > Key: GEODE-6624 > URL: https://issues.apache.org/jira/browse/GEODE-6624 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Blake Bender >Priority: Major > Fix For: 1.10.0 > > Time Spent: 2h 40m > Remaining Estimate: 0h > > This gets a little weird, but in a nutshell: > * a client app needs to deploy a jar file containing a custom > DataSerializable object _without_ a default constructor, and a server > function that returns a value of this type > * Then, the app needs to call execute on a function service on a region (or > maybe a server, we're not sure it's relevant) to call the function that > returns the value of the class that's missing the default dtor > * In response, the server will send back a payload with dscode=45 > (DataSerializable), then a byte field for the type, which will be set to > dscode 43 (Class), then a string which is the name of the class, then the > bytes resulting from a call to toData() on that class instance > * The native client cannot correctly interpret this message, so the worker > thread that is trying to decode the message stores an exception to throw > later. > * Later on in the main thread, an exception gets thrown in > TcrMessage::readMessageChunked, but on the way out of readMessageChunked the > dtor for the contained FinalizeProcessChunk object gets called, which calls > m_reply.processChunk, which _also_ throws an exception, at which point the > process aborts because of the nested exceptions > We need to eat the 2nd exception, and throw the 1st, so that client apps can > catch the exception _and_ get an accurate message about what went wrong. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-6597) ClientMetaDataService Causes Can't Pass GCHandle Across AppDomains Error
[ https://issues.apache.org/jira/browse/GEODE-6597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Diane Hardman updated GEODE-6597: - Fix Version/s: 1.9.0 > ClientMetaDataService Causes Can't Pass GCHandle Across AppDomains Error > > > Key: GEODE-6597 > URL: https://issues.apache.org/jira/browse/GEODE-6597 > Project: Geode > Issue Type: Bug >Reporter: Michael Martell >Priority: Major > Fix For: 1.9.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Background thread used by ClientMetaDataService is used to update the native > client's meta. This thread was missed in the fix for solving appdomain > problems. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-6575) Windows configuration 'RelWithDebInfo' doesn't build properly
[ https://issues.apache.org/jira/browse/GEODE-6575?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Diane Hardman updated GEODE-6575: - Fix Version/s: 1.9.0 > Windows configuration 'RelWithDebInfo' doesn't build properly > - > > Key: GEODE-6575 > URL: https://issues.apache.org/jira/browse/GEODE-6575 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Blake Bender >Priority: Major > Fix For: 1.9.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Several .net projects in the tree don't currently have this configuration, so > we need to add them. Going forward it's going to be critical to be able to > generate optimized Windows builds with debug symbols. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-6547) Geode-Native User Guide - document 'sslputget' example
[ https://issues.apache.org/jira/browse/GEODE-6547?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Diane Hardman updated GEODE-6547: - Fix Version/s: 1.9.0 > Geode-Native User Guide - document 'sslputget' example > -- > > Key: GEODE-6547 > URL: https://issues.apache.org/jira/browse/GEODE-6547 > Project: Geode > Issue Type: Sub-task > Components: docs, native client >Reporter: Dave Barnes >Priority: Major > Fix For: 1.9.0 > > > Document the 'sslputget' example. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-6567) Geode native doesn't compile with gcc 8.x
[ https://issues.apache.org/jira/browse/GEODE-6567?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Diane Hardman updated GEODE-6567: - Fix Version/s: 1.9.0 > Geode native doesn't compile with gcc 8.x > - > > Key: GEODE-6567 > URL: https://issues.apache.org/jira/browse/GEODE-6567 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Jorge Perez Burgos >Priority: Minor > Fix For: 1.9.0 > > Time Spent: 50m > Remaining Estimate: 0h > > Geode driver cannot compile with gcc 8.x due to several warnings. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-6538) Update Geode Native docs for v1.9
[ https://issues.apache.org/jira/browse/GEODE-6538?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Diane Hardman updated GEODE-6538: - Fix Version/s: 1.9.0 > Update Geode Native docs for v1.9 > - > > Key: GEODE-6538 > URL: https://issues.apache.org/jira/browse/GEODE-6538 > Project: Geode > Issue Type: Improvement > Components: docs, native client >Reporter: Dave Barnes >Assignee: Dave Barnes >Priority: Major > Fix For: 1.9.0 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > Update the version number in doc sources for the geode-native user guide -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-6507) Move all clangformat projects into subfolder
[ https://issues.apache.org/jira/browse/GEODE-6507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Diane Hardman updated GEODE-6507: - Fix Version/s: 1.9.0 > Move all clangformat projects into subfolder > > > Key: GEODE-6507 > URL: https://issues.apache.org/jira/browse/GEODE-6507 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Michael Martell >Priority: Major > Fix For: 1.9.0 > > Time Spent: 10m > Remaining Estimate: 0h > > Improve readability of the solution by moving all clangformat projects into a > clangformat subdir. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-6491) Can't Run ASP.NET apps that use geode-native with authentication
[ https://issues.apache.org/jira/browse/GEODE-6491?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Diane Hardman updated GEODE-6491: - Fix Version/s: 1.9.0 > Can't Run ASP.NET apps that use geode-native with authentication > > > Key: GEODE-6491 > URL: https://issues.apache.org/jira/browse/GEODE-6491 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Michael Martell >Priority: Major > Fix For: 1.9.0 > > Time Spent: 40m > Remaining Estimate: 0h > > If authentication is not used, ASP.NET apps that use geode-native work just > fine. However, when we run such apps using geode-native with authentication, > a .NET System.ArgumentException is thrown with this message: "Can't pass > GCHandle across appDomains". > > This is being marked as a Major bug, since to run apps in Pivotal Cloud > Foundry requires using authentication. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-6469) Remove cryptoimpl.lib from nativeclient release
[ https://issues.apache.org/jira/browse/GEODE-6469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Diane Hardman updated GEODE-6469: - Fix Version/s: 1.9.0 > Remove cryptoimpl.lib from nativeclient release > --- > > Key: GEODE-6469 > URL: https://issues.apache.org/jira/browse/GEODE-6469 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Michael Martell >Priority: Major > Fix For: 1.9.0 > > Time Spent: 20m > Remaining Estimate: 0h > > We build and ship a sample SSL encryption library called cryptoimpl, which is > a dependency of the nativeclient. On Windows, our install currently includes > the cryptoimpl.dll and cryptoimpl.lib. The cryptoimpl.lib is an import > library and should not be part of the release artifacts -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-6300) Assertion in CLI tests re: bad AppDomain
[
https://issues.apache.org/jira/browse/GEODE-6300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Diane Hardman updated GEODE-6300:
-
Fix Version/s: 1.9.0
> Assertion in CLI tests re: bad AppDomain
>
>
> Key: GEODE-6300
> URL: https://issues.apache.org/jira/browse/GEODE-6300
> Project: Geode
> Issue Type: Bug
> Components: native client
>Reporter: Blake Bender
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.9.0
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> From the ci logs
> (http://concourse-nativeclient.gemfire.pivotal.io/teams/main/pipelines/build-develop/jobs/cli-test-windows-debug/builds/64):
>
> System.ArgumentException: Cannot pass a GCHandle across AppDomains.
> Parameter name: handle
> at System.Runtime.InteropServices.GCHandle.InternalCheckDomain(IntPtr handle)
> at System.Runtime.InteropServices.GCHandle.FromIntPtr(IntPtr value)
> at gcroot ^>.\{dtor}(gcroot* )
> at
> apache.geode.client.ManagedDataSerializablePrimitive.\{dtor}(ManagedDataSerializablePrimitive*
> )
> at
> apache.geode.client.ManagedDataSerializablePrimitive.__vbaseDtor(ManagedDataSerializablePrimitive*
> )
> at
> apache.geode.client.ManagedDataSerializablePrimitive.__vecDelDtor(ManagedDataSerializablePrimitive*
> , UInt32 A_0)
> at
> std._Ref_count._Destroy(_Ref_count*
> )
> errorlevel 0
> + exitcode=1
> + echo exitcode=1
> exitcode=1
> + exit 1
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-6262) Cppcache Unit Tests Don't Support Multiple Iterations
[ https://issues.apache.org/jira/browse/GEODE-6262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Diane Hardman updated GEODE-6262: - Fix Version/s: 1.9.0 > Cppcache Unit Tests Don't Support Multiple Iterations > - > > Key: GEODE-6262 > URL: https://issues.apache.org/jira/browse/GEODE-6262 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Michael Martell >Priority: Major > Labels: pull-request-available > Fix For: 1.9.0 > > Time Spent: 20m > Remaining Estimate: 0h > > TcrMessageTest uses some funky macros to create compare strings for gtest > EXPECT_MESSAGE. The compare strings don't work when multiple iterations of > the tests, the sequence number causes overflow of the field. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-6250) Port testCache tests to new integration framework
[ https://issues.apache.org/jira/browse/GEODE-6250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Diane Hardman updated GEODE-6250: - Fix Version/s: 1.9.0 > Port testCache tests to new integration framework > - > > Key: GEODE-6250 > URL: https://issues.apache.org/jira/browse/GEODE-6250 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Blake Bender >Priority: Major > Labels: pull-request-available > Fix For: 1.9.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > As a developer on NC, I would very much like to be able to debug my > integration tests in an IDE. As a matter of course we're going to port all > existing tests to the new framework and delete the old code. The new > framework is simpler and uses gtest, so we can debug it in the CLion IDE. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-6245) Fix microsoft specific pragma compiler warnings.
[ https://issues.apache.org/jira/browse/GEODE-6245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Diane Hardman updated GEODE-6245: - Fix Version/s: 1.9.0 > Fix microsoft specific pragma compiler warnings. > > > Key: GEODE-6245 > URL: https://issues.apache.org/jira/browse/GEODE-6245 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Sai Boorlagadda >Priority: Major > Labels: pull-request-available > Fix For: 1.9.0 > > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-6249) Port AttributesMutator test to new framework
[ https://issues.apache.org/jira/browse/GEODE-6249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Diane Hardman updated GEODE-6249: - Fix Version/s: 1.9.0 > Port AttributesMutator test to new framework > > > Key: GEODE-6249 > URL: https://issues.apache.org/jira/browse/GEODE-6249 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Blake Bender >Priority: Major > Labels: pull-request-available > Fix For: 1.9.0 > > Time Spent: 2h > Remaining Estimate: 0h > > As a developer on NC, I would very much like to be able to debug my > integration tests in an IDE. As a matter of course we're going to port all > existing tests to the new framework and delete the old code. The new > framework is simpler and uses gtest, so we can debug it in the CLion IDE. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-6229) Need an Ubuntu Packer image
[ https://issues.apache.org/jira/browse/GEODE-6229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Diane Hardman updated GEODE-6229: - Fix Version/s: 1.9.0 > Need an Ubuntu Packer image > --- > > Key: GEODE-6229 > URL: https://issues.apache.org/jira/browse/GEODE-6229 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Blake Bender >Assignee: Blake Bender >Priority: Major > Labels: pull-request-available > Fix For: 1.9.0 > > Time Spent: 1h > Remaining Estimate: 0h > > As a user of NC, I need to be able to build/run on Ubuntu in addition to > RedHat. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-6240) Fix rat complaints
[
https://issues.apache.org/jira/browse/GEODE-6240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Diane Hardman updated GEODE-6240:
-
Fix Version/s: 1.9.0
> Fix rat complaints
> --
>
> Key: GEODE-6240
> URL: https://issues.apache.org/jira/browse/GEODE-6240
> Project: Geode
> Issue Type: Task
> Components: native client
>Reporter: Michael Oleske
>Assignee: Michael Oleske
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.9.0
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> {{packer/ubuntu/files/etc/systemd/system/update-hosts.service}} and
> {{packer/ubuntu/files/usr/local/bin/update-hosts.sh}} are missing licenses
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-6226) The release file naming should be congruent with core
[
https://issues.apache.org/jira/browse/GEODE-6226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Diane Hardman updated GEODE-6226:
-
Fix Version/s: 1.9.0
> The release file naming should be congruent with core
> -
>
> Key: GEODE-6226
> URL: https://issues.apache.org/jira/browse/GEODE-6226
> Project: Geode
> Issue Type: Task
> Components: native client
>Reporter: Charlie Black
>Priority: Major
> Fix For: 1.9.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> In the release file naming it looks like we are not in compliance with the
> core.
> {{
> apache-geode-1.8.0-src.tgz
> apache-geode-1.8.0-src.tgz.asc
> apache-geode-1.8.0-src.tgz.sha256
> apache-geode-1.8.0.tgz
> apache-geode-1.8.0.tgz.asc
> apache-geode-1.8.0.tgz.sha256
> apache-geode-examples-1.8.0.tar.gz
> apache-geode-examples-1.8.0.tar.gz.asc
> apache-geode-examples-1.8.0.tar.gz.sha256
> apache-geode-examples-1.8.0.zip
> apache-geode-examples-1.8.0.zip.asc
> apache-geode-examples-1.8.0.zip.sha256
> apache-geode-native-1.8.0-Source.tar.gz
> apache-geode-native-1.8.0-Source.tar.gz.asc
> apache-geode-native-1.8.0-Source.tar.gz.sha512}}
> In this example, we would need to change "Source" to src. Also any reason we
> are 512 and the core is 256 if there isn't a reason make the sha the same
> number of bits.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-6211) Geode Native C# Example (Exception Handling)
[ https://issues.apache.org/jira/browse/GEODE-6211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Diane Hardman updated GEODE-6211: - Fix Version/s: 1.9.0 > Geode Native C# Example (Exception Handling) > > > Key: GEODE-6211 > URL: https://issues.apache.org/jira/browse/GEODE-6211 > Project: Geode > Issue Type: Sub-task > Components: examples, native client >Reporter: Charlie Black >Priority: Major > Labels: pull-request-available > Fix For: 1.9.0 > > Time Spent: 1h 40m > Remaining Estimate: 0h > > As a user, I would like to see an example of how to handle a common exception > thrown by Geode. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-6199) Remove pdxautoserializer from contrib
[ https://issues.apache.org/jira/browse/GEODE-6199?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Diane Hardman updated GEODE-6199: - Fix Version/s: 1.9.0 > Remove pdxautoserializer from contrib > - > > Key: GEODE-6199 > URL: https://issues.apache.org/jira/browse/GEODE-6199 > Project: Geode > Issue Type: Task > Components: native client >Reporter: Blake Bender >Priority: Major > Labels: pull-request-available > Fix For: 1.9.0 > > Time Spent: 20m > Remaining Estimate: 0h > > This code was moved to contrib in preparation for removal, and no longer > compiles. Time to get rid of it. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-6210) Geode Native C++ Example (Transaction with Retry)
[ https://issues.apache.org/jira/browse/GEODE-6210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Diane Hardman updated GEODE-6210: - Fix Version/s: 1.9.0 > Geode Native C++ Example (Transaction with Retry) > - > > Key: GEODE-6210 > URL: https://issues.apache.org/jira/browse/GEODE-6210 > Project: Geode > Issue Type: Sub-task > Components: examples, native client >Reporter: Charlie Black >Priority: Major > Labels: pull-request-available > Fix For: 1.9.0 > > Time Spent: 1h 40m > Remaining Estimate: 0h > > As an end user, I would like to see an example of how to handle a common > exception thrown by Geode. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-6165) Need a workaround to install Doxygen on Windows AMI
[ https://issues.apache.org/jira/browse/GEODE-6165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Diane Hardman updated GEODE-6165: - Fix Version/s: 1.9.0 > Need a workaround to install Doxygen on Windows AMI > --- > > Key: GEODE-6165 > URL: https://issues.apache.org/jira/browse/GEODE-6165 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Blake Bender >Priority: Major > Labels: pull-request-available > Fix For: 1.9.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Our install-dependencies.ps1 script that runs when we create a Windows build > image is failing because the underlying URL for the Doxygen Chocolatey > installer has gone bad, and the Chocolatey package isn't being actively > updated. Until the package is fixed, we need a way to install Doxygen on our > AMIs. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-6160) CPack ignore syntax isn't properly escaped
[
https://issues.apache.org/jira/browse/GEODE-6160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Diane Hardman updated GEODE-6160:
-
Fix Version/s: 1.9.0
> CPack ignore syntax isn't properly escaped
> --
>
> Key: GEODE-6160
> URL: https://issues.apache.org/jira/browse/GEODE-6160
> Project: Geode
> Issue Type: Bug
> Components: native client
>Reporter: Blake Bender
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.9.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> In our .cpackignore file, we have lines of the form "\.foo", for example, but
> the regex syntax also has to be escaped like a C string for some reason, aka "
> .foo".
>
> Repro steps:
> * Configure using cmake in a clean repo
> * cd into cmake build dir
> * run 'cpack -G TGZ ---config CPackSourceConfig.cmake' to generate a source
> package
> Expected result
> * Source package generated without complaints
> Actual result
> * Source package generated
> * cpack complains about syntax, for example:
> {code:java}
> CMake Warning (dev) at
> /Users/pivotal/Workspace/cmake-build-debug/geode-native/CPackSourceConfig.cmake:74
> (set):
> Syntax error in cmake code at
>
>
> /Users/pivotal/Workspace/cmake-build-debug/geode-native/CPackSourceConfig.cmake:74
>
> when parsing string
>
>
> /\.git/;/\.DS_Store;/build-./;/build/;/\.settings/;/\.cproject;/\.project;/\.idea/;\.vs/;\.vscode/;/examples/dotnet/./bin/;/examples/dotnet/.*/obj/;\.ruby-version
>
> Invalid escape sequence \.
> {code}
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-6114) C++ examples can't be built individually if they need a jar file
[ https://issues.apache.org/jira/browse/GEODE-6114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Diane Hardman updated GEODE-6114: - Fix Version/s: 1.9.0 > C++ examples can't be built individually if they need a jar file > > > Key: GEODE-6114 > URL: https://issues.apache.org/jira/browse/GEODE-6114 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Blake Bender >Priority: Major > Labels: pull-request-available > Fix For: 1.9.0 > > Time Spent: 50m > Remaining Estimate: 0h > > Our documentation says to cd into the individual example directory, aka > cpp/<>, and run cmake commands from there to build. If you do > this for an example that requires example.jar, the utilities directory is not > built, so there is no jar file to deploy, thus you can't run the example. If > an example requires example.jar, it needs to ensure the utilities directory > is built in its CMakeLists.txt. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-6139) Fix rat complaints about files for 1.8 release
[ https://issues.apache.org/jira/browse/GEODE-6139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Diane Hardman updated GEODE-6139: - Fix Version/s: 1.9.0 > Fix rat complaints about files for 1.8 release > -- > > Key: GEODE-6139 > URL: https://issues.apache.org/jira/browse/GEODE-6139 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Blake Bender >Priority: Major > Labels: pull-request-available > Fix For: 1.9.0 > > Time Spent: 40m > Remaining Estimate: 0h > > Rat is griping about the missing license headers in a few of the source > files, so these need to be added. It's also complaining about a few config > files which do NOT need license headers, so these need to be added to > .ratignore. We also saw some leftover stuff in a cmake-build-debug folder, > so we need to make sure the directory is git cleaned before the release > manager runs cpack. Lastly, one file was mysteriously absent from the > documentation in the final package, so we need to verify that this was > spurious or get the file properly added. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-6054) Make geode-native build with VS 2017 runtime
[ https://issues.apache.org/jira/browse/GEODE-6054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Diane Hardman updated GEODE-6054: - Fix Version/s: 1.9.0 > Make geode-native build with VS 2017 runtime > > > Key: GEODE-6054 > URL: https://issues.apache.org/jira/browse/GEODE-6054 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Blake Bender >Priority: Major > Labels: pull-request-available > Fix For: 1.9.0 > > Time Spent: 5h > Remaining Estimate: 0h > > Just need to configure cmake locally with VS 2017 runtime, build and run > tests and make sure everything is copacetic. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-5957) Unexpected exception when executing an unknown function.
[ https://issues.apache.org/jira/browse/GEODE-5957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Diane Hardman updated GEODE-5957: - Fix Version/s: 1.9.0 > Unexpected exception when executing an unknown function. > > > Key: GEODE-5957 > URL: https://issues.apache.org/jira/browse/GEODE-5957 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Sai Boorlagadda >Priority: Major > Labels: pull-request-available > Fix For: 1.9.0 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > libc++abi.dylib: terminating with uncaught exception of type > apache::geode::client::MessageException: : message from server could not be > handled -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-6007) Fix LGTM complaints in NC code base
[ https://issues.apache.org/jira/browse/GEODE-6007?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Diane Hardman updated GEODE-6007: - Fix Version/s: 1.11.0 > Fix LGTM complaints in NC code base > --- > > Key: GEODE-6007 > URL: https://issues.apache.org/jira/browse/GEODE-6007 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Blake Bender >Priority: Major > Fix For: 1.11.0 > > Time Spent: 2h > Remaining Estimate: 0h > > This is showing stuff that is bad practice in general, and may open us up to > maliciousness. There are two main situations in which we find lots of usage > of snprintf with raw char buffers, which are: > * formatting messages for exceptions > * formatting messages for logging > For the exception messages, we should switch to something known to be safe - > a vsxprintf implementation, boost::format, std::stringstream, whatever. As > long as we stop declaring raw char buffers on the stack, it's all good > > For logging, the situation is even dumber. The various LOG* macros in the > code _already_ take a format string and varargs, so as far as I know we > essentially need to move the printf-style arguments into the logging macro > and get rid of the other nonsense. We may even buy a tiny performance > improvement due to the fact that that logging macros can be compiled out of > the code. > > UPDATE: Report from running LGTM on our code may be found at > [https://lgtm.com/projects/g/apache/geode-native/alerts/?mode=list.] This > report has issues with tons of printf-style format specifiers, so it catches > most of the snprintf stuff pointed out above. MANY OF THESE ARE BUFFER > OVERFLOW ISSUES, and must be addressed in the name of security. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-4841) Switch declaration of HashMapOfPools to 'using' in PoolManagerImpl
[ https://issues.apache.org/jira/browse/GEODE-4841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Diane Hardman updated GEODE-4841: - Fix Version/s: 1.9.0 > Switch declaration of HashMapOfPools to 'using' in PoolManagerImpl > -- > > Key: GEODE-4841 > URL: https://issues.apache.org/jira/browse/GEODE-4841 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Blake Bender >Priority: Major > Labels: pull-request-available > Fix For: 1.9.0 > > Time Spent: 1h 20m > Remaining Estimate: 0h > > Currently this is a convenience typedef in the header file, and comes with > all the associated baggage - pollutes the global namespace, etc. We should > be good C++11 citizens and remove the typedef, replacing it with a 'using' > statement at class scope closer to where we actually need the type. Or, just > declare variables of this type as 'auto' in PoolManagerImpl, even more > convenient. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-5708) Memory corruption in c++ client
[ https://issues.apache.org/jira/browse/GEODE-5708?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Diane Hardman updated GEODE-5708: - Fix Version/s: 1.9.0 > Memory corruption in c++ client > --- > > Key: GEODE-5708 > URL: https://issues.apache.org/jira/browse/GEODE-5708 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Jorge Perez Burgos >Priority: Major > Labels: pull-request-available > Fix For: 1.9.0 > > Attachments: > fix-memory-allocation-d0ff5d7e393f17955f54d3fe0bdf2694c78e9a7e.patch > > Time Spent: 50m > Remaining Estimate: 0h > > When using partition regions there is a double free the ends corrupting the > client process. This is caused because instead of assigning shared pointers > directly the content of a shared pointer is assign to another shared pointer > so the reference count is messed up. I attach a tentative fix/workaround that > copies the content although the best option is possibly to create a new or > modify a constructor in VersionedCacheableObjectPartList class. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-4348) Geode Native C# Example (SSL example)
[ https://issues.apache.org/jira/browse/GEODE-4348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Diane Hardman updated GEODE-4348: - Fix Version/s: 1.9.0 > Geode Native C# Example (SSL example) > - > > Key: GEODE-4348 > URL: https://issues.apache.org/jira/browse/GEODE-4348 > Project: Geode > Issue Type: Sub-task > Components: native client >Reporter: Addison >Priority: Major > Fix For: 1.9.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-4340) Geode Native C++ Example (Authentication)
[ https://issues.apache.org/jira/browse/GEODE-4340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Diane Hardman updated GEODE-4340: - Fix Version/s: 1.9.0 > Geode Native C++ Example (Authentication) > - > > Key: GEODE-4340 > URL: https://issues.apache.org/jira/browse/GEODE-4340 > Project: Geode > Issue Type: Sub-task > Components: native client >Reporter: Addison >Priority: Major > Fix For: 1.9.0 > > Time Spent: 1h 20m > Remaining Estimate: 0h > > It's easy to get Authentication and securing a connection with SSL confused > because they almost always go hand in hand. This example shows how to require > username and password to perform actions on a specific region. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-4339) Geode Native C++ Example (SSL example)
[ https://issues.apache.org/jira/browse/GEODE-4339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Diane Hardman updated GEODE-4339: - Fix Version/s: 1.9.0 > Geode Native C++ Example (SSL example) > -- > > Key: GEODE-4339 > URL: https://issues.apache.org/jira/browse/GEODE-4339 > Project: Geode > Issue Type: Sub-task > Components: native client >Reporter: Addison >Assignee: Ivan Godwin >Priority: Major > Fix For: 1.9.0 > > Time Spent: 2.5h > Remaining Estimate: 0h > > This is example should show how to set up a secure connection between a > client and the cluster. The example should still have a start cluster and > build client script with instruction on how to run the client. The example > should not include its own certificates. Rather, there should be a directory > where the user can drop certs from https://letsencrypt.org/ -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-6536) client pr single hop will do multiple hops if things get busy
[
https://issues.apache.org/jira/browse/GEODE-6536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17048110#comment-17048110
]
ASF subversion and git services commented on GEODE-6536:
Commit c8198f1b9e006b8b5b1f9d16937dffe31aafa333 in geode's branch
refs/heads/develop from Donal Evans
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=c8198f1 ]
Revert "GEODE-6536: Added retry in borrowConnection/single hop (#4719)" (#4749)
This reverts commit 9da2cd49e2e04564b446eaad579b51e986bc2179.
> client pr single hop will do multiple hops if things get busy
> -
>
> Key: GEODE-6536
> URL: https://issues.apache.org/jira/browse/GEODE-6536
> Project: Geode
> Issue Type: Improvement
> Components: client/server
>Reporter: Darrel Schneider
>Assignee: Mario Ivanac
>Priority: Major
> Labels: needs-review, performance, pull-request-available
> Fix For: 1.13.0
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> I was wondering why ConnectionManagerImpl.borrowConnection that targets a
> particular server will not wait for a connection to be available. This is the
> borrow used by pr single hop. It seems like if all the cnxs to that server
> are busy and we are at max that it should wait. But instead it does a single
> scan of the pool and if it does not find an idle connection it either throws
> AllConnectionsInUse or it creates one. The caller sets the onlyUseExistingCnx
> parameter based on if the pool is at max cnxs or not (seems like this should
> have been done in borrowConnection instead of the caller). If it throws
> AllConnectionsInUse the caller catches it and ignores it and then falls into
> doing a non-targeted borrow that will wait for a connection but to ANY
> server. So our single hop optimization goes away on a busy client. Since it
> can’t immediately get a connection to server A, it says just give me a
> connection to any server sends the op to that other server and that server
> ends up having to forward it to server A. You would only see this problem if
> you set a max on your client connection pool. The default of -1 just says to
> always create another connection. The only workaround I know of is to not
> limit how many connections your client can create but that could cause other
> problem (i.e. too many file descriptors).
> The questionable code is in the following classes:
> org.apache.geode.cache.client.internal.GetOp
> org.apache.geode.cache.client.internal.PutOp
> org.apache.geode.cache.client.internal.DestroyOp
> The all have something like this:
>
> {code:java}
> boolean onlyUseExistingCnx = ((poolImpl.getMaxConnections() != -1
> && poolImpl.getConnectionCount() >= poolImpl.getMaxConnections()) ? true :
> false);
> op.setAllowDuplicateMetadataRefresh(!onlyUseExistingCnx);
> return pool.executeOn(new ServerLocation(server.getHostName(),
> server.getPort()), op,
> true, onlyUseExistingCnx);
> {code}
> executeOn eventually calls ConnectionManagerImpl.borrowConnection
> It is unclear to me why they need allow duplicate metadata refresh if they
> permit borrowConnection to create a new connection to the specified server.
> They all catch and ignore
> AllConnectionsInUseException falling through and doing non-targetted
> pool.execute.
> The concern might have been that the pool would be full of connections to
> other servers preventing us from connecting to the server we need to
> communicate with. If we have existing connections to the server we could wait
> for one of those. If we don't and we are at max then we should consider
> closing a connection to some other server and create a connection to the
> server we know we need for this operation. As the server count goes up and
> the max connection count on the pool goes down I'm sure we are probably
> better off not even trying to do single hop since we might not even be able
> to have a connection to each server in the pool. But if we have a reasonable
> max connection count then it seems like we could make more of an effort to
> make sure a per server connection count is balanced and then wait for one of
> those connection to be available.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-7684) Implement the Bucket region clear messages and handling
[ https://issues.apache.org/jira/browse/GEODE-7684?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17048073#comment-17048073 ] ASF subversion and git services commented on GEODE-7684: Commit 15c800304a507855cd04a9948d24d61b5da54211 in geode's branch refs/heads/feature/GEODE-7682 from zhouxh [ https://gitbox.apache.org/repos/asf?p=geode.git;h=15c8003 ] GEODE-7683: introduce BR.cmnClearRegion Co-authored-by: Xiaojian Zhou GEODE-7684: Create messaging class for PR Clear (#4689) * Added new message class and test Co-authored-by: Benjamin Ross Co-authored-by: Donal Evans > Implement the Bucket region clear messages and handling > --- > > Key: GEODE-7684 > URL: https://issues.apache.org/jira/browse/GEODE-7684 > Project: Geode > Issue Type: New Feature > Components: regions >Reporter: Nabarun Nag >Priority: Major > Labels: GeodeCommons > Time Spent: 4h 10m > Remaining Estimate: 0h > > Implement the bucket region clear message, and the handling of the message. > Upon receiving this message the bucket region must be cleared. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7682) Create the java API to clear a PartitionedRegion
[ https://issues.apache.org/jira/browse/GEODE-7682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17048075#comment-17048075 ] ASF subversion and git services commented on GEODE-7682: Commit f2d87e5ef1fc95ba6894f355b663b55c606d8eff in geode's branch refs/heads/feature/GEODE-7682 from zhouxh [ https://gitbox.apache.org/repos/asf?p=geode.git;h=f2d87e5 ] Merge branch 'feature/GEODE-7665' into feature/GEODE-7682 > Create the java API to clear a PartitionedRegion > > > Key: GEODE-7682 > URL: https://issues.apache.org/jira/browse/GEODE-7682 > Project: Geode > Issue Type: New Feature > Components: regions >Reporter: Nabarun Nag >Priority: Major > Labels: GeodeCommons > Time Spent: 20m > Remaining Estimate: 0h > > This task will just include creating the API which calls the internal > commands to clear the region and send messages to the members hosting the > Partitioned region. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7683) Implement the Bucket Region cmnClearRegion
[ https://issues.apache.org/jira/browse/GEODE-7683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17048072#comment-17048072 ] ASF subversion and git services commented on GEODE-7683: Commit 15c800304a507855cd04a9948d24d61b5da54211 in geode's branch refs/heads/feature/GEODE-7682 from zhouxh [ https://gitbox.apache.org/repos/asf?p=geode.git;h=15c8003 ] GEODE-7683: introduce BR.cmnClearRegion Co-authored-by: Xiaojian Zhou GEODE-7684: Create messaging class for PR Clear (#4689) * Added new message class and test Co-authored-by: Benjamin Ross Co-authored-by: Donal Evans > Implement the Bucket Region cmnClearRegion > --- > > Key: GEODE-7683 > URL: https://issues.apache.org/jira/browse/GEODE-7683 > Project: Geode > Issue Type: New Feature > Components: regions >Reporter: Nabarun Nag >Priority: Major > Labels: GeodeCommons > Time Spent: 4h > Remaining Estimate: 0h > > Implement the method to clear up a bucket region -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7665) Ability to clear a Partitioned Region
[ https://issues.apache.org/jira/browse/GEODE-7665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17048074#comment-17048074 ] ASF subversion and git services commented on GEODE-7665: Commit f2d87e5ef1fc95ba6894f355b663b55c606d8eff in geode's branch refs/heads/feature/GEODE-7682 from zhouxh [ https://gitbox.apache.org/repos/asf?p=geode.git;h=f2d87e5 ] Merge branch 'feature/GEODE-7665' into feature/GEODE-7682 > Ability to clear a Partitioned Region > - > > Key: GEODE-7665 > URL: https://issues.apache.org/jira/browse/GEODE-7665 > Project: Geode > Issue Type: New Feature > Components: regions >Reporter: Nabarun Nag >Priority: Major > Labels: GeodeCommons > > With the successful voting of the RFC for implementing clear operation on > Partitioned Region > [[https://cwiki.apache.org/confluence/display/GEODE/Support+for+clear+operation+on+partitioned+region]] > we are starting the code implementation. > > Details of the implementation and design are maintained in the RFC document > mentioned above. This ticket will act as a parent Jira under which all the > subsequent sub-JIRAs will be created. This ticket will be closed once all the > sub jiras are implemented. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-6536) client pr single hop will do multiple hops if things get busy
[
https://issues.apache.org/jira/browse/GEODE-6536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17048055#comment-17048055
]
ASF subversion and git services commented on GEODE-6536:
Commit 9da2cd49e2e04564b446eaad579b51e986bc2179 in geode's branch
refs/heads/feature/GEODE-7682 from Mario Ivanac
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=9da2cd4 ]
GEODE-6536: Added retry in borrowConnection/single hop (#4719)
* GEODE-6536: Added retry in borrowConnection/single hop
* GEODE-6536: bug fix
* GEODE-6536: update after comments
> client pr single hop will do multiple hops if things get busy
> -
>
> Key: GEODE-6536
> URL: https://issues.apache.org/jira/browse/GEODE-6536
> Project: Geode
> Issue Type: Improvement
> Components: client/server
>Reporter: Darrel Schneider
>Assignee: Mario Ivanac
>Priority: Major
> Labels: needs-review, performance, pull-request-available
> Fix For: 1.13.0
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> I was wondering why ConnectionManagerImpl.borrowConnection that targets a
> particular server will not wait for a connection to be available. This is the
> borrow used by pr single hop. It seems like if all the cnxs to that server
> are busy and we are at max that it should wait. But instead it does a single
> scan of the pool and if it does not find an idle connection it either throws
> AllConnectionsInUse or it creates one. The caller sets the onlyUseExistingCnx
> parameter based on if the pool is at max cnxs or not (seems like this should
> have been done in borrowConnection instead of the caller). If it throws
> AllConnectionsInUse the caller catches it and ignores it and then falls into
> doing a non-targeted borrow that will wait for a connection but to ANY
> server. So our single hop optimization goes away on a busy client. Since it
> can’t immediately get a connection to server A, it says just give me a
> connection to any server sends the op to that other server and that server
> ends up having to forward it to server A. You would only see this problem if
> you set a max on your client connection pool. The default of -1 just says to
> always create another connection. The only workaround I know of is to not
> limit how many connections your client can create but that could cause other
> problem (i.e. too many file descriptors).
> The questionable code is in the following classes:
> org.apache.geode.cache.client.internal.GetOp
> org.apache.geode.cache.client.internal.PutOp
> org.apache.geode.cache.client.internal.DestroyOp
> The all have something like this:
>
> {code:java}
> boolean onlyUseExistingCnx = ((poolImpl.getMaxConnections() != -1
> && poolImpl.getConnectionCount() >= poolImpl.getMaxConnections()) ? true :
> false);
> op.setAllowDuplicateMetadataRefresh(!onlyUseExistingCnx);
> return pool.executeOn(new ServerLocation(server.getHostName(),
> server.getPort()), op,
> true, onlyUseExistingCnx);
> {code}
> executeOn eventually calls ConnectionManagerImpl.borrowConnection
> It is unclear to me why they need allow duplicate metadata refresh if they
> permit borrowConnection to create a new connection to the specified server.
> They all catch and ignore
> AllConnectionsInUseException falling through and doing non-targetted
> pool.execute.
> The concern might have been that the pool would be full of connections to
> other servers preventing us from connecting to the server we need to
> communicate with. If we have existing connections to the server we could wait
> for one of those. If we don't and we are at max then we should consider
> closing a connection to some other server and create a connection to the
> server we know we need for this operation. As the server count goes up and
> the max connection count on the pool goes down I'm sure we are probably
> better off not even trying to do single hop since we might not even be able
> to have a connection to each server in the pool. But if we have a reasonable
> max connection count then it seems like we could make more of an effort to
> make sure a per server connection count is balanced and then wait for one of
> those connection to be available.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-7820) Avoid Unnecessary toArray Invocations
[
https://issues.apache.org/jira/browse/GEODE-7820?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17048063#comment-17048063
]
ASF subversion and git services commented on GEODE-7820:
Commit ca7ccbce73d436005fe027f31ee910ee9beeb769 in geode's branch
refs/heads/feature/GEODE-7682 from Juan José Ramos
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=ca7ccbc ]
GEODE-7820: Avoid Unnecessary toArray Invocations (#4741)
Avoid unnecessary invocations to the 'toArray' method and directly
use the java collection received instead.
> Avoid Unnecessary toArray Invocations
> -
>
> Key: GEODE-7820
> URL: https://issues.apache.org/jira/browse/GEODE-7820
> Project: Geode
> Issue Type: Bug
> Components: membership
>Reporter: Juan Ramos
>Assignee: Juan Ramos
>Priority: Major
> Labels: GeodeCommons
> Fix For: 1.12.0, 1.13.0
>
> Attachments: Screenshot 2020-02-27 at 12.59.23.png, setRecipients.png
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> The {{DistributionMessage}} class receives the recipients as a {{Collection}}
> object (which is always a {{Set}} after inspecting the calls) but it
> internally transforms the collection into an array {{[]}}, this
> transformation appears to be useless as we end up converting the array {{[]}}
> into a {{List}} across several parts of the code afterwards when we need to
> do something with it.
> Using one of our internal testing scenarios and a java profiler we detected
> that, under the current develop {{branch}}, we spend ~8 seconds more than
> when using Geode 1.10 just by executing this {{toArray}} transformation
> (screenshot attached), which can be completely avoided.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-6536) client pr single hop will do multiple hops if things get busy
[
https://issues.apache.org/jira/browse/GEODE-6536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17048057#comment-17048057
]
ASF subversion and git services commented on GEODE-6536:
Commit 9da2cd49e2e04564b446eaad579b51e986bc2179 in geode's branch
refs/heads/feature/GEODE-7682 from Mario Ivanac
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=9da2cd4 ]
GEODE-6536: Added retry in borrowConnection/single hop (#4719)
* GEODE-6536: Added retry in borrowConnection/single hop
* GEODE-6536: bug fix
* GEODE-6536: update after comments
> client pr single hop will do multiple hops if things get busy
> -
>
> Key: GEODE-6536
> URL: https://issues.apache.org/jira/browse/GEODE-6536
> Project: Geode
> Issue Type: Improvement
> Components: client/server
>Reporter: Darrel Schneider
>Assignee: Mario Ivanac
>Priority: Major
> Labels: needs-review, performance, pull-request-available
> Fix For: 1.13.0
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> I was wondering why ConnectionManagerImpl.borrowConnection that targets a
> particular server will not wait for a connection to be available. This is the
> borrow used by pr single hop. It seems like if all the cnxs to that server
> are busy and we are at max that it should wait. But instead it does a single
> scan of the pool and if it does not find an idle connection it either throws
> AllConnectionsInUse or it creates one. The caller sets the onlyUseExistingCnx
> parameter based on if the pool is at max cnxs or not (seems like this should
> have been done in borrowConnection instead of the caller). If it throws
> AllConnectionsInUse the caller catches it and ignores it and then falls into
> doing a non-targeted borrow that will wait for a connection but to ANY
> server. So our single hop optimization goes away on a busy client. Since it
> can’t immediately get a connection to server A, it says just give me a
> connection to any server sends the op to that other server and that server
> ends up having to forward it to server A. You would only see this problem if
> you set a max on your client connection pool. The default of -1 just says to
> always create another connection. The only workaround I know of is to not
> limit how many connections your client can create but that could cause other
> problem (i.e. too many file descriptors).
> The questionable code is in the following classes:
> org.apache.geode.cache.client.internal.GetOp
> org.apache.geode.cache.client.internal.PutOp
> org.apache.geode.cache.client.internal.DestroyOp
> The all have something like this:
>
> {code:java}
> boolean onlyUseExistingCnx = ((poolImpl.getMaxConnections() != -1
> && poolImpl.getConnectionCount() >= poolImpl.getMaxConnections()) ? true :
> false);
> op.setAllowDuplicateMetadataRefresh(!onlyUseExistingCnx);
> return pool.executeOn(new ServerLocation(server.getHostName(),
> server.getPort()), op,
> true, onlyUseExistingCnx);
> {code}
> executeOn eventually calls ConnectionManagerImpl.borrowConnection
> It is unclear to me why they need allow duplicate metadata refresh if they
> permit borrowConnection to create a new connection to the specified server.
> They all catch and ignore
> AllConnectionsInUseException falling through and doing non-targetted
> pool.execute.
> The concern might have been that the pool would be full of connections to
> other servers preventing us from connecting to the server we need to
> communicate with. If we have existing connections to the server we could wait
> for one of those. If we don't and we are at max then we should consider
> closing a connection to some other server and create a connection to the
> server we know we need for this operation. As the server count goes up and
> the max connection count on the pool goes down I'm sure we are probably
> better off not even trying to do single hop since we might not even be able
> to have a connection to each server in the pool. But if we have a reasonable
> max connection count then it seems like we could make more of an effort to
> make sure a per server connection count is balanced and then wait for one of
> those connection to be available.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-7829) DEFAULT_ACK_WAIT_THRESHOLD inadvertently changed from 15 to 51
[ https://issues.apache.org/jira/browse/GEODE-7829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17048064#comment-17048064 ] ASF subversion and git services commented on GEODE-7829: Commit dfa3326e674278f38673c9508a13af752ae90e28 in geode's branch refs/heads/feature/GEODE-7682 from Bruce Schuchardt [ https://gitbox.apache.org/repos/asf?p=geode.git;h=dfa3326 ] GEODE-7829: DEFAULT_ACK_WAIT_THRESHOLD inadvertently changed from 15 to 51 (#4746) changing the default back to 15 seconds > DEFAULT_ACK_WAIT_THRESHOLD inadvertently changed from 15 to 51 > -- > > Key: GEODE-7829 > URL: https://issues.apache.org/jira/browse/GEODE-7829 > Project: Geode > Issue Type: Bug > Components: membership >Reporter: Bruce J Schuchardt >Assignee: Bruce J Schuchardt >Priority: Major > Fix For: 1.12.0, 1.13.0 > > Time Spent: 20m > Remaining Estimate: 0h > > During a refactor of membership code the default ack-wait-threshold was > changed from 15 to 51. This needs to be reverted and needs to be in the > 1.12.0 release. > The problem was introduced in c485cda4fc31a78892433fcb4726799b4904981f -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7682) Create the java API to clear a PartitionedRegion
[ https://issues.apache.org/jira/browse/GEODE-7682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17048065#comment-17048065 ] ASF subversion and git services commented on GEODE-7682: Commit baa512349c313765f10f6c545f9badd7acfcd19e in geode's branch refs/heads/feature/GEODE-7682 from zhouxh [ https://gitbox.apache.org/repos/asf?p=geode.git;h=baa5123 ] GEODE-7682: add clear API for PR > Create the java API to clear a PartitionedRegion > > > Key: GEODE-7682 > URL: https://issues.apache.org/jira/browse/GEODE-7682 > Project: Geode > Issue Type: New Feature > Components: regions >Reporter: Nabarun Nag >Priority: Major > Labels: GeodeCommons > Time Spent: 20m > Remaining Estimate: 0h > > This task will just include creating the API which calls the internal > commands to clear the region and send messages to the members hosting the > Partitioned region. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7771) LuceneQueryFunction.getLuceneIndex should be passed in the Cache
[ https://issues.apache.org/jira/browse/GEODE-7771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17048061#comment-17048061 ] ASF subversion and git services commented on GEODE-7771: Commit 51a0c65f95ac465db1f9703a6a8055730c65e828 in geode's branch refs/heads/feature/GEODE-7682 from mkevo [ https://gitbox.apache.org/repos/asf?p=geode.git;h=51a0c65 ] GEODE-7771: change getting cache in getLuceneIndex (#4702) * GEODE-7771: change getting cache in getLuceneIndex * simplify test > LuceneQueryFunction.getLuceneIndex should be passed in the Cache > > > Key: GEODE-7771 > URL: https://issues.apache.org/jira/browse/GEODE-7771 > Project: Geode > Issue Type: Task > Components: lucene >Reporter: Jason Huynh >Assignee: Mario Kevo >Priority: Major > Labels: beginner, newb, pull-request-available, starter > Fix For: 1.13.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Currently the getLuceneIndex method is grabbing a reference of the cache > through the region.getCache() (deprecated for some reason) method. We can > probably just pass in the cache from the caller (the function context has a > getCache() method that can be used instead). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7815) Document setting a GEODE_HOME env variable
[ https://issues.apache.org/jira/browse/GEODE-7815?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17048059#comment-17048059 ] ASF subversion and git services commented on GEODE-7815: Commit 8498329c10f66d8aeca01eefc9c3abf646fe8d2c in geode's branch refs/heads/feature/GEODE-7682 from Karen Miller [ https://gitbox.apache.org/repos/asf?p=geode.git;h=8498329 ] GEODE-7815: Document setting a GEODE_HOME env variable (#4732) > Document setting a GEODE_HOME env variable > -- > > Key: GEODE-7815 > URL: https://issues.apache.org/jira/browse/GEODE-7815 > Project: Geode > Issue Type: Improvement > Components: docs >Reporter: Karen Smoler Miller >Assignee: Karen Smoler Miller >Priority: Major > Fix For: 1.13.0 > > Time Spent: 20m > Remaining Estimate: 0h > > While internal methods will check the classpath for locating WAR files, we > should document that setting a GEODE_HOME environment variable might an > easier method for some installations than changing the classpath. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7814) Unnecessary Object Allocations in DistributionMessage
[
https://issues.apache.org/jira/browse/GEODE-7814?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17048058#comment-17048058
]
ASF subversion and git services commented on GEODE-7814:
Commit db86faec699aca67c02325bca22dcd5b913ddfed in geode's branch
refs/heads/feature/GEODE-7682 from Juan José Ramos
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=db86fae ]
GEODE-7814: Avoid Messaging Unnecessary Allocations (#4731)
Avoid unnecessary object allocations by making the attributes static.
> Unnecessary Object Allocations in DistributionMessage
> -
>
> Key: GEODE-7814
> URL: https://issues.apache.org/jira/browse/GEODE-7814
> Project: Geode
> Issue Type: Bug
> Components: membership
>Reporter: Juan Ramos
>Assignee: Juan Ramos
>Priority: Major
> Labels: GeodeCommons
> Fix For: 1.12.0, 1.13.0
>
> Attachments: countDifference.png, timeSpent.png
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The {{DistributionMessage}} class unnecessary allocates instances of
> {{java.util.Collection$SingletonList}} and {{InternalDistributedMember[]}}
> through the attributes {{EMPTY_RECIPIENTS_ARRAY}} and {{ALL_RECIPIENTS_LIST}}.
> These attributes are {{final}} and only used to execute internal comparisons
> but, since they are not declared as {{static}}, every instance of
> {{DistributionMessage}} will have its own instance, generating unnecessary
> garbage.
> Using one of our internal testing scenarios and a java profiler we detected
> that, under the current {{develop}} branch, we create 14.824 and 11.212 more
> instances of {{java.util.Collection$SingletonList}} and
> {{InternalDistributedMember[]}} than when using Geode 1.10.
> The increase in the memory footprint is not much (around 1MB all together),
> and the time spent on this operation is around 1.5 seconds slower overall
> (screenshots attached).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-7771) LuceneQueryFunction.getLuceneIndex should be passed in the Cache
[ https://issues.apache.org/jira/browse/GEODE-7771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17048062#comment-17048062 ] ASF subversion and git services commented on GEODE-7771: Commit 51a0c65f95ac465db1f9703a6a8055730c65e828 in geode's branch refs/heads/feature/GEODE-7682 from mkevo [ https://gitbox.apache.org/repos/asf?p=geode.git;h=51a0c65 ] GEODE-7771: change getting cache in getLuceneIndex (#4702) * GEODE-7771: change getting cache in getLuceneIndex * simplify test > LuceneQueryFunction.getLuceneIndex should be passed in the Cache > > > Key: GEODE-7771 > URL: https://issues.apache.org/jira/browse/GEODE-7771 > Project: Geode > Issue Type: Task > Components: lucene >Reporter: Jason Huynh >Assignee: Mario Kevo >Priority: Major > Labels: beginner, newb, pull-request-available, starter > Fix For: 1.13.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Currently the getLuceneIndex method is grabbing a reference of the cache > through the region.getCache() (deprecated for some reason) method. We can > probably just pass in the cache from the caller (the function context has a > getCache() method that can be used instead). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-6536) client pr single hop will do multiple hops if things get busy
[
https://issues.apache.org/jira/browse/GEODE-6536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17048054#comment-17048054
]
ASF subversion and git services commented on GEODE-6536:
Commit 9da2cd49e2e04564b446eaad579b51e986bc2179 in geode's branch
refs/heads/feature/GEODE-7682 from Mario Ivanac
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=9da2cd4 ]
GEODE-6536: Added retry in borrowConnection/single hop (#4719)
* GEODE-6536: Added retry in borrowConnection/single hop
* GEODE-6536: bug fix
* GEODE-6536: update after comments
> client pr single hop will do multiple hops if things get busy
> -
>
> Key: GEODE-6536
> URL: https://issues.apache.org/jira/browse/GEODE-6536
> Project: Geode
> Issue Type: Improvement
> Components: client/server
>Reporter: Darrel Schneider
>Assignee: Mario Ivanac
>Priority: Major
> Labels: needs-review, performance, pull-request-available
> Fix For: 1.13.0
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> I was wondering why ConnectionManagerImpl.borrowConnection that targets a
> particular server will not wait for a connection to be available. This is the
> borrow used by pr single hop. It seems like if all the cnxs to that server
> are busy and we are at max that it should wait. But instead it does a single
> scan of the pool and if it does not find an idle connection it either throws
> AllConnectionsInUse or it creates one. The caller sets the onlyUseExistingCnx
> parameter based on if the pool is at max cnxs or not (seems like this should
> have been done in borrowConnection instead of the caller). If it throws
> AllConnectionsInUse the caller catches it and ignores it and then falls into
> doing a non-targeted borrow that will wait for a connection but to ANY
> server. So our single hop optimization goes away on a busy client. Since it
> can’t immediately get a connection to server A, it says just give me a
> connection to any server sends the op to that other server and that server
> ends up having to forward it to server A. You would only see this problem if
> you set a max on your client connection pool. The default of -1 just says to
> always create another connection. The only workaround I know of is to not
> limit how many connections your client can create but that could cause other
> problem (i.e. too many file descriptors).
> The questionable code is in the following classes:
> org.apache.geode.cache.client.internal.GetOp
> org.apache.geode.cache.client.internal.PutOp
> org.apache.geode.cache.client.internal.DestroyOp
> The all have something like this:
>
> {code:java}
> boolean onlyUseExistingCnx = ((poolImpl.getMaxConnections() != -1
> && poolImpl.getConnectionCount() >= poolImpl.getMaxConnections()) ? true :
> false);
> op.setAllowDuplicateMetadataRefresh(!onlyUseExistingCnx);
> return pool.executeOn(new ServerLocation(server.getHostName(),
> server.getPort()), op,
> true, onlyUseExistingCnx);
> {code}
> executeOn eventually calls ConnectionManagerImpl.borrowConnection
> It is unclear to me why they need allow duplicate metadata refresh if they
> permit borrowConnection to create a new connection to the specified server.
> They all catch and ignore
> AllConnectionsInUseException falling through and doing non-targetted
> pool.execute.
> The concern might have been that the pool would be full of connections to
> other servers preventing us from connecting to the server we need to
> communicate with. If we have existing connections to the server we could wait
> for one of those. If we don't and we are at max then we should consider
> closing a connection to some other server and create a connection to the
> server we know we need for this operation. As the server count goes up and
> the max connection count on the pool goes down I'm sure we are probably
> better off not even trying to do single hop since we might not even be able
> to have a connection to each server in the pool. But if we have a reasonable
> max connection count then it seems like we could make more of an effort to
> make sure a per server connection count is balanced and then wait for one of
> those connection to be available.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-7421) Ability: can deploy jar by REST API for Management
[ https://issues.apache.org/jira/browse/GEODE-7421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17048053#comment-17048053 ] ASF subversion and git services commented on GEODE-7421: Commit ddfee1c502b26945829fdb13b43829aa85be4002 in geode's branch refs/heads/feature/GEODE-7682 from Jinmei Liao [ https://gitbox.apache.org/repos/asf?p=geode.git;h=ddfee1c ] GEODE-7421: deploy jar by REST API/JAVA API for Management Co-authored-by: Joris Melchior > Ability: can deploy jar by REST API for Management > -- > > Key: GEODE-7421 > URL: https://issues.apache.org/jira/browse/GEODE-7421 > Project: Geode > Issue Type: New Feature > Components: management, rest (admin) >Reporter: Gang Yan >Priority: Major > Time Spent: 3h 50m > Remaining Estimate: 0h > > # WHAT > 1. can deploy jar file by REST API > 2. from feature point , it will cover current 'gfsh deploy' > 3. if two files have same file name, the later wins > 4. can recognize version pattern. "filename-version[-label].jar" . > filename=[a-zA-Z/-]+, not single "-", not end with "-" > version=[0-9/.]*, not single ".", not end with "." > label=[a-zA-Z0-9]* > such as: > -is a later version of > , will deploy. > -is a same version of > , the later wins > -is a same version of > , the later wins > -is an earlier version of > , will block it. > 5. if there is a version part in the file name, we will deploy them > without append "#1" part to the file name > 6. can accept "group" -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7823) compile error "package org.junit does not exist" when running "geode-core:compileJmhJava" Gradle task in IntelliJ
[
https://issues.apache.org/jira/browse/GEODE-7823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17048060#comment-17048060
]
ASF subversion and git services commented on GEODE-7823:
Commit 088e68242df3e4acc6d661d636f5a786e6b5d6b1 in geode's branch
refs/heads/feature/GEODE-7682 from Bill Burcham
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=088e682 ]
GEODE-7823: eliminate org.junit unavailable compile error in IntelliJ (#4742)
> compile error "package org.junit does not exist" when running
> "geode-core:compileJmhJava" Gradle task in IntelliJ
> -
>
> Key: GEODE-7823
> URL: https://issues.apache.org/jira/browse/GEODE-7823
> Project: Geode
> Issue Type: Bug
> Components: build
>Affects Versions: 1.13.0
>Reporter: Bill Burcham
>Assignee: Bill Burcham
>Priority: Major
> Fix For: 1.13.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> When building the project in IntelliJ, I see this compile error:
> {code}
> …RangeQueryWithIndexBenchmark.java:17: error: package org.junit does not exist
> import static org.junit.Assert.assertEquals;
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-6536) client pr single hop will do multiple hops if things get busy
[
https://issues.apache.org/jira/browse/GEODE-6536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17048056#comment-17048056
]
ASF subversion and git services commented on GEODE-6536:
Commit 9da2cd49e2e04564b446eaad579b51e986bc2179 in geode's branch
refs/heads/feature/GEODE-7682 from Mario Ivanac
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=9da2cd4 ]
GEODE-6536: Added retry in borrowConnection/single hop (#4719)
* GEODE-6536: Added retry in borrowConnection/single hop
* GEODE-6536: bug fix
* GEODE-6536: update after comments
> client pr single hop will do multiple hops if things get busy
> -
>
> Key: GEODE-6536
> URL: https://issues.apache.org/jira/browse/GEODE-6536
> Project: Geode
> Issue Type: Improvement
> Components: client/server
>Reporter: Darrel Schneider
>Assignee: Mario Ivanac
>Priority: Major
> Labels: needs-review, performance, pull-request-available
> Fix For: 1.13.0
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> I was wondering why ConnectionManagerImpl.borrowConnection that targets a
> particular server will not wait for a connection to be available. This is the
> borrow used by pr single hop. It seems like if all the cnxs to that server
> are busy and we are at max that it should wait. But instead it does a single
> scan of the pool and if it does not find an idle connection it either throws
> AllConnectionsInUse or it creates one. The caller sets the onlyUseExistingCnx
> parameter based on if the pool is at max cnxs or not (seems like this should
> have been done in borrowConnection instead of the caller). If it throws
> AllConnectionsInUse the caller catches it and ignores it and then falls into
> doing a non-targeted borrow that will wait for a connection but to ANY
> server. So our single hop optimization goes away on a busy client. Since it
> can’t immediately get a connection to server A, it says just give me a
> connection to any server sends the op to that other server and that server
> ends up having to forward it to server A. You would only see this problem if
> you set a max on your client connection pool. The default of -1 just says to
> always create another connection. The only workaround I know of is to not
> limit how many connections your client can create but that could cause other
> problem (i.e. too many file descriptors).
> The questionable code is in the following classes:
> org.apache.geode.cache.client.internal.GetOp
> org.apache.geode.cache.client.internal.PutOp
> org.apache.geode.cache.client.internal.DestroyOp
> The all have something like this:
>
> {code:java}
> boolean onlyUseExistingCnx = ((poolImpl.getMaxConnections() != -1
> && poolImpl.getConnectionCount() >= poolImpl.getMaxConnections()) ? true :
> false);
> op.setAllowDuplicateMetadataRefresh(!onlyUseExistingCnx);
> return pool.executeOn(new ServerLocation(server.getHostName(),
> server.getPort()), op,
> true, onlyUseExistingCnx);
> {code}
> executeOn eventually calls ConnectionManagerImpl.borrowConnection
> It is unclear to me why they need allow duplicate metadata refresh if they
> permit borrowConnection to create a new connection to the specified server.
> They all catch and ignore
> AllConnectionsInUseException falling through and doing non-targetted
> pool.execute.
> The concern might have been that the pool would be full of connections to
> other servers preventing us from connecting to the server we need to
> communicate with. If we have existing connections to the server we could wait
> for one of those. If we don't and we are at max then we should consider
> closing a connection to some other server and create a connection to the
> server we know we need for this operation. As the server count goes up and
> the max connection count on the pool goes down I'm sure we are probably
> better off not even trying to do single hop since we might not even be able
> to have a connection to each server in the pool. But if we have a reasonable
> max connection count then it seems like we could make more of an effort to
> make sure a per server connection count is balanced and then wait for one of
> those connection to be available.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-6536) client pr single hop will do multiple hops if things get busy
[
https://issues.apache.org/jira/browse/GEODE-6536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17048034#comment-17048034
]
ASF subversion and git services commented on GEODE-6536:
Commit 9da2cd49e2e04564b446eaad579b51e986bc2179 in geode's branch
refs/heads/feature/GEODE-7665 from Mario Ivanac
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=9da2cd4 ]
GEODE-6536: Added retry in borrowConnection/single hop (#4719)
* GEODE-6536: Added retry in borrowConnection/single hop
* GEODE-6536: bug fix
* GEODE-6536: update after comments
> client pr single hop will do multiple hops if things get busy
> -
>
> Key: GEODE-6536
> URL: https://issues.apache.org/jira/browse/GEODE-6536
> Project: Geode
> Issue Type: Improvement
> Components: client/server
>Reporter: Darrel Schneider
>Assignee: Mario Ivanac
>Priority: Major
> Labels: needs-review, performance, pull-request-available
> Fix For: 1.13.0
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> I was wondering why ConnectionManagerImpl.borrowConnection that targets a
> particular server will not wait for a connection to be available. This is the
> borrow used by pr single hop. It seems like if all the cnxs to that server
> are busy and we are at max that it should wait. But instead it does a single
> scan of the pool and if it does not find an idle connection it either throws
> AllConnectionsInUse or it creates one. The caller sets the onlyUseExistingCnx
> parameter based on if the pool is at max cnxs or not (seems like this should
> have been done in borrowConnection instead of the caller). If it throws
> AllConnectionsInUse the caller catches it and ignores it and then falls into
> doing a non-targeted borrow that will wait for a connection but to ANY
> server. So our single hop optimization goes away on a busy client. Since it
> can’t immediately get a connection to server A, it says just give me a
> connection to any server sends the op to that other server and that server
> ends up having to forward it to server A. You would only see this problem if
> you set a max on your client connection pool. The default of -1 just says to
> always create another connection. The only workaround I know of is to not
> limit how many connections your client can create but that could cause other
> problem (i.e. too many file descriptors).
> The questionable code is in the following classes:
> org.apache.geode.cache.client.internal.GetOp
> org.apache.geode.cache.client.internal.PutOp
> org.apache.geode.cache.client.internal.DestroyOp
> The all have something like this:
>
> {code:java}
> boolean onlyUseExistingCnx = ((poolImpl.getMaxConnections() != -1
> && poolImpl.getConnectionCount() >= poolImpl.getMaxConnections()) ? true :
> false);
> op.setAllowDuplicateMetadataRefresh(!onlyUseExistingCnx);
> return pool.executeOn(new ServerLocation(server.getHostName(),
> server.getPort()), op,
> true, onlyUseExistingCnx);
> {code}
> executeOn eventually calls ConnectionManagerImpl.borrowConnection
> It is unclear to me why they need allow duplicate metadata refresh if they
> permit borrowConnection to create a new connection to the specified server.
> They all catch and ignore
> AllConnectionsInUseException falling through and doing non-targetted
> pool.execute.
> The concern might have been that the pool would be full of connections to
> other servers preventing us from connecting to the server we need to
> communicate with. If we have existing connections to the server we could wait
> for one of those. If we don't and we are at max then we should consider
> closing a connection to some other server and create a connection to the
> server we know we need for this operation. As the server count goes up and
> the max connection count on the pool goes down I'm sure we are probably
> better off not even trying to do single hop since we might not even be able
> to have a connection to each server in the pool. But if we have a reasonable
> max connection count then it seems like we could make more of an effort to
> make sure a per server connection count is balanced and then wait for one of
> those connection to be available.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-7683) Implement the Bucket Region cmnClearRegion
[ https://issues.apache.org/jira/browse/GEODE-7683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17048043#comment-17048043 ] ASF subversion and git services commented on GEODE-7683: Commit 15c800304a507855cd04a9948d24d61b5da54211 in geode's branch refs/heads/feature/GEODE-7665 from zhouxh [ https://gitbox.apache.org/repos/asf?p=geode.git;h=15c8003 ] GEODE-7683: introduce BR.cmnClearRegion Co-authored-by: Xiaojian Zhou GEODE-7684: Create messaging class for PR Clear (#4689) * Added new message class and test Co-authored-by: Benjamin Ross Co-authored-by: Donal Evans > Implement the Bucket Region cmnClearRegion > --- > > Key: GEODE-7683 > URL: https://issues.apache.org/jira/browse/GEODE-7683 > Project: Geode > Issue Type: New Feature > Components: regions >Reporter: Nabarun Nag >Priority: Major > Labels: GeodeCommons > Time Spent: 4h > Remaining Estimate: 0h > > Implement the method to clear up a bucket region -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7815) Document setting a GEODE_HOME env variable
[ https://issues.apache.org/jira/browse/GEODE-7815?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17048037#comment-17048037 ] ASF subversion and git services commented on GEODE-7815: Commit 8498329c10f66d8aeca01eefc9c3abf646fe8d2c in geode's branch refs/heads/feature/GEODE-7665 from Karen Miller [ https://gitbox.apache.org/repos/asf?p=geode.git;h=8498329 ] GEODE-7815: Document setting a GEODE_HOME env variable (#4732) > Document setting a GEODE_HOME env variable > -- > > Key: GEODE-7815 > URL: https://issues.apache.org/jira/browse/GEODE-7815 > Project: Geode > Issue Type: Improvement > Components: docs >Reporter: Karen Smoler Miller >Assignee: Karen Smoler Miller >Priority: Major > Fix For: 1.13.0 > > Time Spent: 20m > Remaining Estimate: 0h > > While internal methods will check the classpath for locating WAR files, we > should document that setting a GEODE_HOME environment variable might an > easier method for some installations than changing the classpath. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-6536) client pr single hop will do multiple hops if things get busy
[
https://issues.apache.org/jira/browse/GEODE-6536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17048033#comment-17048033
]
ASF subversion and git services commented on GEODE-6536:
Commit 9da2cd49e2e04564b446eaad579b51e986bc2179 in geode's branch
refs/heads/feature/GEODE-7665 from Mario Ivanac
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=9da2cd4 ]
GEODE-6536: Added retry in borrowConnection/single hop (#4719)
* GEODE-6536: Added retry in borrowConnection/single hop
* GEODE-6536: bug fix
* GEODE-6536: update after comments
> client pr single hop will do multiple hops if things get busy
> -
>
> Key: GEODE-6536
> URL: https://issues.apache.org/jira/browse/GEODE-6536
> Project: Geode
> Issue Type: Improvement
> Components: client/server
>Reporter: Darrel Schneider
>Assignee: Mario Ivanac
>Priority: Major
> Labels: needs-review, performance, pull-request-available
> Fix For: 1.13.0
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> I was wondering why ConnectionManagerImpl.borrowConnection that targets a
> particular server will not wait for a connection to be available. This is the
> borrow used by pr single hop. It seems like if all the cnxs to that server
> are busy and we are at max that it should wait. But instead it does a single
> scan of the pool and if it does not find an idle connection it either throws
> AllConnectionsInUse or it creates one. The caller sets the onlyUseExistingCnx
> parameter based on if the pool is at max cnxs or not (seems like this should
> have been done in borrowConnection instead of the caller). If it throws
> AllConnectionsInUse the caller catches it and ignores it and then falls into
> doing a non-targeted borrow that will wait for a connection but to ANY
> server. So our single hop optimization goes away on a busy client. Since it
> can’t immediately get a connection to server A, it says just give me a
> connection to any server sends the op to that other server and that server
> ends up having to forward it to server A. You would only see this problem if
> you set a max on your client connection pool. The default of -1 just says to
> always create another connection. The only workaround I know of is to not
> limit how many connections your client can create but that could cause other
> problem (i.e. too many file descriptors).
> The questionable code is in the following classes:
> org.apache.geode.cache.client.internal.GetOp
> org.apache.geode.cache.client.internal.PutOp
> org.apache.geode.cache.client.internal.DestroyOp
> The all have something like this:
>
> {code:java}
> boolean onlyUseExistingCnx = ((poolImpl.getMaxConnections() != -1
> && poolImpl.getConnectionCount() >= poolImpl.getMaxConnections()) ? true :
> false);
> op.setAllowDuplicateMetadataRefresh(!onlyUseExistingCnx);
> return pool.executeOn(new ServerLocation(server.getHostName(),
> server.getPort()), op,
> true, onlyUseExistingCnx);
> {code}
> executeOn eventually calls ConnectionManagerImpl.borrowConnection
> It is unclear to me why they need allow duplicate metadata refresh if they
> permit borrowConnection to create a new connection to the specified server.
> They all catch and ignore
> AllConnectionsInUseException falling through and doing non-targetted
> pool.execute.
> The concern might have been that the pool would be full of connections to
> other servers preventing us from connecting to the server we need to
> communicate with. If we have existing connections to the server we could wait
> for one of those. If we don't and we are at max then we should consider
> closing a connection to some other server and create a connection to the
> server we know we need for this operation. As the server count goes up and
> the max connection count on the pool goes down I'm sure we are probably
> better off not even trying to do single hop since we might not even be able
> to have a connection to each server in the pool. But if we have a reasonable
> max connection count then it seems like we could make more of an effort to
> make sure a per server connection count is balanced and then wait for one of
> those connection to be available.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-7771) LuceneQueryFunction.getLuceneIndex should be passed in the Cache
[ https://issues.apache.org/jira/browse/GEODE-7771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17048040#comment-17048040 ] ASF subversion and git services commented on GEODE-7771: Commit 51a0c65f95ac465db1f9703a6a8055730c65e828 in geode's branch refs/heads/feature/GEODE-7665 from mkevo [ https://gitbox.apache.org/repos/asf?p=geode.git;h=51a0c65 ] GEODE-7771: change getting cache in getLuceneIndex (#4702) * GEODE-7771: change getting cache in getLuceneIndex * simplify test > LuceneQueryFunction.getLuceneIndex should be passed in the Cache > > > Key: GEODE-7771 > URL: https://issues.apache.org/jira/browse/GEODE-7771 > Project: Geode > Issue Type: Task > Components: lucene >Reporter: Jason Huynh >Assignee: Mario Kevo >Priority: Major > Labels: beginner, newb, pull-request-available, starter > Fix For: 1.13.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Currently the getLuceneIndex method is grabbing a reference of the cache > through the region.getCache() (deprecated for some reason) method. We can > probably just pass in the cache from the caller (the function context has a > getCache() method that can be used instead). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7814) Unnecessary Object Allocations in DistributionMessage
[
https://issues.apache.org/jira/browse/GEODE-7814?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17048036#comment-17048036
]
ASF subversion and git services commented on GEODE-7814:
Commit db86faec699aca67c02325bca22dcd5b913ddfed in geode's branch
refs/heads/feature/GEODE-7665 from Juan José Ramos
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=db86fae ]
GEODE-7814: Avoid Messaging Unnecessary Allocations (#4731)
Avoid unnecessary object allocations by making the attributes static.
> Unnecessary Object Allocations in DistributionMessage
> -
>
> Key: GEODE-7814
> URL: https://issues.apache.org/jira/browse/GEODE-7814
> Project: Geode
> Issue Type: Bug
> Components: membership
>Reporter: Juan Ramos
>Assignee: Juan Ramos
>Priority: Major
> Labels: GeodeCommons
> Fix For: 1.12.0, 1.13.0
>
> Attachments: countDifference.png, timeSpent.png
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The {{DistributionMessage}} class unnecessary allocates instances of
> {{java.util.Collection$SingletonList}} and {{InternalDistributedMember[]}}
> through the attributes {{EMPTY_RECIPIENTS_ARRAY}} and {{ALL_RECIPIENTS_LIST}}.
> These attributes are {{final}} and only used to execute internal comparisons
> but, since they are not declared as {{static}}, every instance of
> {{DistributionMessage}} will have its own instance, generating unnecessary
> garbage.
> Using one of our internal testing scenarios and a java profiler we detected
> that, under the current {{develop}} branch, we create 14.824 and 11.212 more
> instances of {{java.util.Collection$SingletonList}} and
> {{InternalDistributedMember[]}} than when using Geode 1.10.
> The increase in the memory footprint is not much (around 1MB all together),
> and the time spent on this operation is around 1.5 seconds slower overall
> (screenshots attached).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-7829) DEFAULT_ACK_WAIT_THRESHOLD inadvertently changed from 15 to 51
[ https://issues.apache.org/jira/browse/GEODE-7829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17048042#comment-17048042 ] ASF subversion and git services commented on GEODE-7829: Commit dfa3326e674278f38673c9508a13af752ae90e28 in geode's branch refs/heads/feature/GEODE-7665 from Bruce Schuchardt [ https://gitbox.apache.org/repos/asf?p=geode.git;h=dfa3326 ] GEODE-7829: DEFAULT_ACK_WAIT_THRESHOLD inadvertently changed from 15 to 51 (#4746) changing the default back to 15 seconds > DEFAULT_ACK_WAIT_THRESHOLD inadvertently changed from 15 to 51 > -- > > Key: GEODE-7829 > URL: https://issues.apache.org/jira/browse/GEODE-7829 > Project: Geode > Issue Type: Bug > Components: membership >Reporter: Bruce J Schuchardt >Assignee: Bruce J Schuchardt >Priority: Major > Fix For: 1.12.0, 1.13.0 > > Time Spent: 20m > Remaining Estimate: 0h > > During a refactor of membership code the default ack-wait-threshold was > changed from 15 to 51. This needs to be reverted and needs to be in the > 1.12.0 release. > The problem was introduced in c485cda4fc31a78892433fcb4726799b4904981f -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7771) LuceneQueryFunction.getLuceneIndex should be passed in the Cache
[ https://issues.apache.org/jira/browse/GEODE-7771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17048039#comment-17048039 ] ASF subversion and git services commented on GEODE-7771: Commit 51a0c65f95ac465db1f9703a6a8055730c65e828 in geode's branch refs/heads/feature/GEODE-7665 from mkevo [ https://gitbox.apache.org/repos/asf?p=geode.git;h=51a0c65 ] GEODE-7771: change getting cache in getLuceneIndex (#4702) * GEODE-7771: change getting cache in getLuceneIndex * simplify test > LuceneQueryFunction.getLuceneIndex should be passed in the Cache > > > Key: GEODE-7771 > URL: https://issues.apache.org/jira/browse/GEODE-7771 > Project: Geode > Issue Type: Task > Components: lucene >Reporter: Jason Huynh >Assignee: Mario Kevo >Priority: Major > Labels: beginner, newb, pull-request-available, starter > Fix For: 1.13.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Currently the getLuceneIndex method is grabbing a reference of the cache > through the region.getCache() (deprecated for some reason) method. We can > probably just pass in the cache from the caller (the function context has a > getCache() method that can be used instead). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-6536) client pr single hop will do multiple hops if things get busy
[
https://issues.apache.org/jira/browse/GEODE-6536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17048035#comment-17048035
]
ASF subversion and git services commented on GEODE-6536:
Commit 9da2cd49e2e04564b446eaad579b51e986bc2179 in geode's branch
refs/heads/feature/GEODE-7665 from Mario Ivanac
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=9da2cd4 ]
GEODE-6536: Added retry in borrowConnection/single hop (#4719)
* GEODE-6536: Added retry in borrowConnection/single hop
* GEODE-6536: bug fix
* GEODE-6536: update after comments
> client pr single hop will do multiple hops if things get busy
> -
>
> Key: GEODE-6536
> URL: https://issues.apache.org/jira/browse/GEODE-6536
> Project: Geode
> Issue Type: Improvement
> Components: client/server
>Reporter: Darrel Schneider
>Assignee: Mario Ivanac
>Priority: Major
> Labels: needs-review, performance, pull-request-available
> Fix For: 1.13.0
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> I was wondering why ConnectionManagerImpl.borrowConnection that targets a
> particular server will not wait for a connection to be available. This is the
> borrow used by pr single hop. It seems like if all the cnxs to that server
> are busy and we are at max that it should wait. But instead it does a single
> scan of the pool and if it does not find an idle connection it either throws
> AllConnectionsInUse or it creates one. The caller sets the onlyUseExistingCnx
> parameter based on if the pool is at max cnxs or not (seems like this should
> have been done in borrowConnection instead of the caller). If it throws
> AllConnectionsInUse the caller catches it and ignores it and then falls into
> doing a non-targeted borrow that will wait for a connection but to ANY
> server. So our single hop optimization goes away on a busy client. Since it
> can’t immediately get a connection to server A, it says just give me a
> connection to any server sends the op to that other server and that server
> ends up having to forward it to server A. You would only see this problem if
> you set a max on your client connection pool. The default of -1 just says to
> always create another connection. The only workaround I know of is to not
> limit how many connections your client can create but that could cause other
> problem (i.e. too many file descriptors).
> The questionable code is in the following classes:
> org.apache.geode.cache.client.internal.GetOp
> org.apache.geode.cache.client.internal.PutOp
> org.apache.geode.cache.client.internal.DestroyOp
> The all have something like this:
>
> {code:java}
> boolean onlyUseExistingCnx = ((poolImpl.getMaxConnections() != -1
> && poolImpl.getConnectionCount() >= poolImpl.getMaxConnections()) ? true :
> false);
> op.setAllowDuplicateMetadataRefresh(!onlyUseExistingCnx);
> return pool.executeOn(new ServerLocation(server.getHostName(),
> server.getPort()), op,
> true, onlyUseExistingCnx);
> {code}
> executeOn eventually calls ConnectionManagerImpl.borrowConnection
> It is unclear to me why they need allow duplicate metadata refresh if they
> permit borrowConnection to create a new connection to the specified server.
> They all catch and ignore
> AllConnectionsInUseException falling through and doing non-targetted
> pool.execute.
> The concern might have been that the pool would be full of connections to
> other servers preventing us from connecting to the server we need to
> communicate with. If we have existing connections to the server we could wait
> for one of those. If we don't and we are at max then we should consider
> closing a connection to some other server and create a connection to the
> server we know we need for this operation. As the server count goes up and
> the max connection count on the pool goes down I'm sure we are probably
> better off not even trying to do single hop since we might not even be able
> to have a connection to each server in the pool. But if we have a reasonable
> max connection count then it seems like we could make more of an effort to
> make sure a per server connection count is balanced and then wait for one of
> those connection to be available.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-6536) client pr single hop will do multiple hops if things get busy
[
https://issues.apache.org/jira/browse/GEODE-6536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17048032#comment-17048032
]
ASF subversion and git services commented on GEODE-6536:
Commit 9da2cd49e2e04564b446eaad579b51e986bc2179 in geode's branch
refs/heads/feature/GEODE-7665 from Mario Ivanac
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=9da2cd4 ]
GEODE-6536: Added retry in borrowConnection/single hop (#4719)
* GEODE-6536: Added retry in borrowConnection/single hop
* GEODE-6536: bug fix
* GEODE-6536: update after comments
> client pr single hop will do multiple hops if things get busy
> -
>
> Key: GEODE-6536
> URL: https://issues.apache.org/jira/browse/GEODE-6536
> Project: Geode
> Issue Type: Improvement
> Components: client/server
>Reporter: Darrel Schneider
>Assignee: Mario Ivanac
>Priority: Major
> Labels: needs-review, performance, pull-request-available
> Fix For: 1.13.0
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> I was wondering why ConnectionManagerImpl.borrowConnection that targets a
> particular server will not wait for a connection to be available. This is the
> borrow used by pr single hop. It seems like if all the cnxs to that server
> are busy and we are at max that it should wait. But instead it does a single
> scan of the pool and if it does not find an idle connection it either throws
> AllConnectionsInUse or it creates one. The caller sets the onlyUseExistingCnx
> parameter based on if the pool is at max cnxs or not (seems like this should
> have been done in borrowConnection instead of the caller). If it throws
> AllConnectionsInUse the caller catches it and ignores it and then falls into
> doing a non-targeted borrow that will wait for a connection but to ANY
> server. So our single hop optimization goes away on a busy client. Since it
> can’t immediately get a connection to server A, it says just give me a
> connection to any server sends the op to that other server and that server
> ends up having to forward it to server A. You would only see this problem if
> you set a max on your client connection pool. The default of -1 just says to
> always create another connection. The only workaround I know of is to not
> limit how many connections your client can create but that could cause other
> problem (i.e. too many file descriptors).
> The questionable code is in the following classes:
> org.apache.geode.cache.client.internal.GetOp
> org.apache.geode.cache.client.internal.PutOp
> org.apache.geode.cache.client.internal.DestroyOp
> The all have something like this:
>
> {code:java}
> boolean onlyUseExistingCnx = ((poolImpl.getMaxConnections() != -1
> && poolImpl.getConnectionCount() >= poolImpl.getMaxConnections()) ? true :
> false);
> op.setAllowDuplicateMetadataRefresh(!onlyUseExistingCnx);
> return pool.executeOn(new ServerLocation(server.getHostName(),
> server.getPort()), op,
> true, onlyUseExistingCnx);
> {code}
> executeOn eventually calls ConnectionManagerImpl.borrowConnection
> It is unclear to me why they need allow duplicate metadata refresh if they
> permit borrowConnection to create a new connection to the specified server.
> They all catch and ignore
> AllConnectionsInUseException falling through and doing non-targetted
> pool.execute.
> The concern might have been that the pool would be full of connections to
> other servers preventing us from connecting to the server we need to
> communicate with. If we have existing connections to the server we could wait
> for one of those. If we don't and we are at max then we should consider
> closing a connection to some other server and create a connection to the
> server we know we need for this operation. As the server count goes up and
> the max connection count on the pool goes down I'm sure we are probably
> better off not even trying to do single hop since we might not even be able
> to have a connection to each server in the pool. But if we have a reasonable
> max connection count then it seems like we could make more of an effort to
> make sure a per server connection count is balanced and then wait for one of
> those connection to be available.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-7820) Avoid Unnecessary toArray Invocations
[
https://issues.apache.org/jira/browse/GEODE-7820?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17048041#comment-17048041
]
ASF subversion and git services commented on GEODE-7820:
Commit ca7ccbce73d436005fe027f31ee910ee9beeb769 in geode's branch
refs/heads/feature/GEODE-7665 from Juan José Ramos
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=ca7ccbc ]
GEODE-7820: Avoid Unnecessary toArray Invocations (#4741)
Avoid unnecessary invocations to the 'toArray' method and directly
use the java collection received instead.
> Avoid Unnecessary toArray Invocations
> -
>
> Key: GEODE-7820
> URL: https://issues.apache.org/jira/browse/GEODE-7820
> Project: Geode
> Issue Type: Bug
> Components: membership
>Reporter: Juan Ramos
>Assignee: Juan Ramos
>Priority: Major
> Labels: GeodeCommons
> Fix For: 1.12.0, 1.13.0
>
> Attachments: Screenshot 2020-02-27 at 12.59.23.png, setRecipients.png
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> The {{DistributionMessage}} class receives the recipients as a {{Collection}}
> object (which is always a {{Set}} after inspecting the calls) but it
> internally transforms the collection into an array {{[]}}, this
> transformation appears to be useless as we end up converting the array {{[]}}
> into a {{List}} across several parts of the code afterwards when we need to
> do something with it.
> Using one of our internal testing scenarios and a java profiler we detected
> that, under the current develop {{branch}}, we spend ~8 seconds more than
> when using Geode 1.10 just by executing this {{toArray}} transformation
> (screenshot attached), which can be completely avoided.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-7823) compile error "package org.junit does not exist" when running "geode-core:compileJmhJava" Gradle task in IntelliJ
[
https://issues.apache.org/jira/browse/GEODE-7823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17048038#comment-17048038
]
ASF subversion and git services commented on GEODE-7823:
Commit 088e68242df3e4acc6d661d636f5a786e6b5d6b1 in geode's branch
refs/heads/feature/GEODE-7665 from Bill Burcham
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=088e682 ]
GEODE-7823: eliminate org.junit unavailable compile error in IntelliJ (#4742)
> compile error "package org.junit does not exist" when running
> "geode-core:compileJmhJava" Gradle task in IntelliJ
> -
>
> Key: GEODE-7823
> URL: https://issues.apache.org/jira/browse/GEODE-7823
> Project: Geode
> Issue Type: Bug
> Components: build
>Affects Versions: 1.13.0
>Reporter: Bill Burcham
>Assignee: Bill Burcham
>Priority: Major
> Fix For: 1.13.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> When building the project in IntelliJ, I see this compile error:
> {code}
> …RangeQueryWithIndexBenchmark.java:17: error: package org.junit does not exist
> import static org.junit.Assert.assertEquals;
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-7684) Implement the Bucket region clear messages and handling
[ https://issues.apache.org/jira/browse/GEODE-7684?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17048044#comment-17048044 ] ASF subversion and git services commented on GEODE-7684: Commit 15c800304a507855cd04a9948d24d61b5da54211 in geode's branch refs/heads/feature/GEODE-7665 from zhouxh [ https://gitbox.apache.org/repos/asf?p=geode.git;h=15c8003 ] GEODE-7683: introduce BR.cmnClearRegion Co-authored-by: Xiaojian Zhou GEODE-7684: Create messaging class for PR Clear (#4689) * Added new message class and test Co-authored-by: Benjamin Ross Co-authored-by: Donal Evans > Implement the Bucket region clear messages and handling > --- > > Key: GEODE-7684 > URL: https://issues.apache.org/jira/browse/GEODE-7684 > Project: Geode > Issue Type: New Feature > Components: regions >Reporter: Nabarun Nag >Priority: Major > Labels: GeodeCommons > Time Spent: 4h 10m > Remaining Estimate: 0h > > Implement the bucket region clear message, and the handling of the message. > Upon receiving this message the bucket region must be cleared. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7421) Ability: can deploy jar by REST API for Management
[ https://issues.apache.org/jira/browse/GEODE-7421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17048031#comment-17048031 ] ASF subversion and git services commented on GEODE-7421: Commit ddfee1c502b26945829fdb13b43829aa85be4002 in geode's branch refs/heads/feature/GEODE-7665 from Jinmei Liao [ https://gitbox.apache.org/repos/asf?p=geode.git;h=ddfee1c ] GEODE-7421: deploy jar by REST API/JAVA API for Management Co-authored-by: Joris Melchior > Ability: can deploy jar by REST API for Management > -- > > Key: GEODE-7421 > URL: https://issues.apache.org/jira/browse/GEODE-7421 > Project: Geode > Issue Type: New Feature > Components: management, rest (admin) >Reporter: Gang Yan >Priority: Major > Time Spent: 3h 50m > Remaining Estimate: 0h > > # WHAT > 1. can deploy jar file by REST API > 2. from feature point , it will cover current 'gfsh deploy' > 3. if two files have same file name, the later wins > 4. can recognize version pattern. "filename-version[-label].jar" . > filename=[a-zA-Z/-]+, not single "-", not end with "-" > version=[0-9/.]*, not single ".", not end with "." > label=[a-zA-Z0-9]* > such as: > -is a later version of > , will deploy. > -is a same version of > , the later wins > -is a same version of > , the later wins > -is an earlier version of > , will block it. > 5. if there is a version part in the file name, we will deploy them > without append "#1" part to the file name > 6. can accept "group" -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-7832) Remove connection "send semaphores" from DirectChannel
Bruce J Schuchardt created GEODE-7832: - Summary: Remove connection "send semaphores" from DirectChannel Key: GEODE-7832 URL: https://issues.apache.org/jira/browse/GEODE-7832 Project: Geode Issue Type: Improvement Components: membership Reporter: Bruce J Schuchardt Remove the acquiredSendSemaphore/acquireGroupSendSemaphore and related methods from DirectChannel/TCPConduit code. Connection.isReaderThread() and associated makeReaderThread() methods can also be deleted because they're only used by the semaphore code. These semaphores only constrain messaging if you set a couple of undocumented system properties, p2p.maxGroupSenders and p2p.maxConnectionSenders to some small value. These are (MAX_INT / 2) by default. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-7829) DEFAULT_ACK_WAIT_THRESHOLD inadvertently changed from 15 to 51
[ https://issues.apache.org/jira/browse/GEODE-7829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols updated GEODE-7829: Fix Version/s: 1.13.0 > DEFAULT_ACK_WAIT_THRESHOLD inadvertently changed from 15 to 51 > -- > > Key: GEODE-7829 > URL: https://issues.apache.org/jira/browse/GEODE-7829 > Project: Geode > Issue Type: Bug > Components: membership >Reporter: Bruce J Schuchardt >Assignee: Bruce J Schuchardt >Priority: Major > Fix For: 1.12.0, 1.13.0 > > Time Spent: 20m > Remaining Estimate: 0h > > During a refactor of membership code the default ack-wait-threshold was > changed from 15 to 51. This needs to be reverted and needs to be in the > 1.12.0 release. > The problem was introduced in c485cda4fc31a78892433fcb4726799b4904981f -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-4194) DestroyRegionDuringGIIDistributedTest testNBRegionDestructionDuringGetInitialImage hangs
[ https://issues.apache.org/jira/browse/GEODE-4194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Hanson updated GEODE-4194: --- Summary: DestroyRegionDuringGIIDistributedTest testNBRegionDestructionDuringGetInitialImage hangs (was: DiskDistributedNoAckAsyncOverflowRegionDUnitTest testNBRegionDestructionDuringGetInitialImage hangs) > DestroyRegionDuringGIIDistributedTest > testNBRegionDestructionDuringGetInitialImage hangs > > > Key: GEODE-4194 > URL: https://issues.apache.org/jira/browse/GEODE-4194 > Project: Geode > Issue Type: Bug > Components: extensions >Reporter: Lynn Gallinat >Assignee: Mark Hanson >Priority: Major > Labels: flaky > > This test caused concourse to timeout when it hung: > Started @ 2018-01-03 18:49:16.700 + > 2018-01-03 19:21:00.165 + > org.apache.geode.cache30.DiskDistributedNoAckAsyncOverflowRegionDUnitTest > testNBRegionDestructionDuringGetInitialImage > Ended @ 2018-01-03 20:55:26.951 + -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-7635) DistributedAckRegionDUnitTest. testNBRegionDestructionDuringGetInitialImage is failing in Mass Test Run
[
https://issues.apache.org/jira/browse/GEODE-7635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Hanson resolved GEODE-7635.
Resolution: Duplicate
> DistributedAckRegionDUnitTest. testNBRegionDestructionDuringGetInitialImage
> is failing in Mass Test Run
> ---
>
> Key: GEODE-7635
> URL: https://issues.apache.org/jira/browse/GEODE-7635
> Project: Geode
> Issue Type: Bug
> Components: tests
>Reporter: Mark Hanson
>Assignee: Mark Hanson
>Priority: Major
> Labels: flaky
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/mhansonp-mhanson-mass-test-ru-main/jobs/DistributedTestOpenJDK8/builds/2396]
>
> {noformat}
> java.lang.AssertionError: java.lang.IllegalStateException: Exception status
> not available while thread is alive.
> at
> org.apache.geode.test.dunit.AsyncInvocation.getException(AsyncInvocation.java:272)
> at
> org.apache.geode.test.dunit.AsyncInvocation.exceptionOccurred(AsyncInvocation.java:256)
> at
> org.apache.geode.cache30.MultiVMRegionTestCase.testNBRegionDestructionDuringGetInitialImage(MultiVMRegionTestCase.java:4973)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.runTestClass(JUnitTestClassExecutor.java:110)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:58)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:38)
> at
> org.gradle.api.internal.tasks.testing.junit.AbstractJUnitTestClassProcessor.processTestClass(AbstractJUnitTestClassProcessor.java:62)
> at
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
> at
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
> at
> org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
> at
> org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
> at com.sun.proxy.$Proxy2.processTestClass(Unknown Source)
> at
> org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:118)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
[jira] [Assigned] (GEODE-6277) CI failure: DistributedNoAckRegionDUnitTest.testNBRegionDestructionDuringGetInitialImage
[
https://issues.apache.org/jira/browse/GEODE-6277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Hanson reassigned GEODE-6277:
--
Assignee: Mark Hanson (was: Xiaojian Zhou)
> CI failure:
> DistributedNoAckRegionDUnitTest.testNBRegionDestructionDuringGetInitialImage
>
>
> Key: GEODE-6277
> URL: https://issues.apache.org/jira/browse/GEODE-6277
> Project: Geode
> Issue Type: Bug
> Components: regions
>Affects Versions: 1.9.0
>Reporter: Ryan McMahon
>Assignee: Mark Hanson
>Priority: Major
> Labels: GeodeCommons, pull-request-available
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
>
> {code:java}
> org.apache.geode.cache30.DistributedNoAckRegionDUnitTest >
> testNBRegionDestructionDuringGetInitialImage FAILED
> java.lang.AssertionError: asyncGII failed
> Caused by:
> org.junit.ComparisonFailure: expected:<[tru]e> but was:<[fals]e>
> {code}
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/288|http://example.com/]
> This appears to be part of a larger flakey failure ticket, but this
> particular failure was not addressed. Original flakey failure ticket:
> [https://issues.apache.org/jira/browse/GEODE-5412?jql=text%20~%20%22testNBRegionDestructionDuringGetInitialImage%22|http://example.com/]
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-6277) CI failure: DistributedNoAckRegionDUnitTest.testNBRegionDestructionDuringGetInitialImage
[
https://issues.apache.org/jira/browse/GEODE-6277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Hanson updated GEODE-6277:
---
Labels: GeodeCommons flaky pull-request-available (was: GeodeCommons
pull-request-available)
> CI failure:
> DistributedNoAckRegionDUnitTest.testNBRegionDestructionDuringGetInitialImage
>
>
> Key: GEODE-6277
> URL: https://issues.apache.org/jira/browse/GEODE-6277
> Project: Geode
> Issue Type: Bug
> Components: regions
>Affects Versions: 1.9.0
>Reporter: Ryan McMahon
>Assignee: Mark Hanson
>Priority: Major
> Labels: GeodeCommons, flaky, pull-request-available
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
>
> {code:java}
> org.apache.geode.cache30.DistributedNoAckRegionDUnitTest >
> testNBRegionDestructionDuringGetInitialImage FAILED
> java.lang.AssertionError: asyncGII failed
> Caused by:
> org.junit.ComparisonFailure: expected:<[tru]e> but was:<[fals]e>
> {code}
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/288|http://example.com/]
> This appears to be part of a larger flakey failure ticket, but this
> particular failure was not addressed. Original flakey failure ticket:
> [https://issues.apache.org/jira/browse/GEODE-5412?jql=text%20~%20%22testNBRegionDestructionDuringGetInitialImage%22|http://example.com/]
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (GEODE-6277) CI failure: DistributedNoAckRegionDUnitTest.testNBRegionDestructionDuringGetInitialImage
[
https://issues.apache.org/jira/browse/GEODE-6277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Hanson resolved GEODE-6277.
Resolution: Duplicate
> CI failure:
> DistributedNoAckRegionDUnitTest.testNBRegionDestructionDuringGetInitialImage
>
>
> Key: GEODE-6277
> URL: https://issues.apache.org/jira/browse/GEODE-6277
> Project: Geode
> Issue Type: Bug
> Components: regions
>Affects Versions: 1.9.0
>Reporter: Ryan McMahon
>Assignee: Mark Hanson
>Priority: Major
> Labels: GeodeCommons, flaky, pull-request-available
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
>
> {code:java}
> org.apache.geode.cache30.DistributedNoAckRegionDUnitTest >
> testNBRegionDestructionDuringGetInitialImage FAILED
> java.lang.AssertionError: asyncGII failed
> Caused by:
> org.junit.ComparisonFailure: expected:<[tru]e> but was:<[fals]e>
> {code}
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/288|http://example.com/]
> This appears to be part of a larger flakey failure ticket, but this
> particular failure was not addressed. Original flakey failure ticket:
> [https://issues.apache.org/jira/browse/GEODE-5412?jql=text%20~%20%22testNBRegionDestructionDuringGetInitialImage%22|http://example.com/]
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-7821) DestroyRegionDuringGIIDistributedTest > testNBRegionInvalidationDuringGetInitialImage_HEAP_DISTRIBUTED_ACK_COMPRESSION FAILED
[ https://issues.apache.org/jira/browse/GEODE-7821?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Hanson updated GEODE-7821: --- Affects Version/s: 1.13.0 > DestroyRegionDuringGIIDistributedTest > > testNBRegionInvalidationDuringGetInitialImage_HEAP_DISTRIBUTED_ACK_COMPRESSION > FAILED > - > > Key: GEODE-7821 > URL: https://issues.apache.org/jira/browse/GEODE-7821 > Project: Geode > Issue Type: Bug > Components: core, tests >Affects Versions: 1.13.0 >Reporter: Joris Melchior >Assignee: Mark Hanson >Priority: Major > Labels: flaky > Fix For: 1.13.0 > > > Seen this fail in a couple of places. Failures do not seem to have a direct > relation to the pull request for the job. > https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK11/builds/1581 > org.apache.geode.internal.cache.DestroyRegionDuringGIIDistributedTest > > testNBRegionInvalidationDuringGetInitialImage_HEAP_DISTRIBUTED_ACK_COMPRESSION > FAILED > org.apache.geode.test.dunit.RMIException: While invoking > org.apache.geode.internal.cache.DestroyRegionDuringGIIDistributedTest$$Lambda$179/0x000840c73840.run > in VM 2 running on Host 8f4bff2410d5 with 4 VMs > at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:610) > at org.apache.geode.test.dunit.VM.invoke(VM.java:437) > at > org.apache.geode.internal.cache.DestroyRegionDuringGIIDistributedTest.testNBRegionInvalidationDuringGetInitialImage(DestroyRegionDuringGIIDistributedTest.java:414) > Caused by: > org.junit.ComparisonFailure: expected: but was:<[66, 66, 66, > 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, > 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, > 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, > 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, > 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, > 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, > 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, > 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, > 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, > 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, > 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, > 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, > 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, > 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, > 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, > 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, > 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, > 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, > 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, > 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, > 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, > 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, > 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, > 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, > 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, > 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, > 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, > 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, > 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, > 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, > 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, > 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, > 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, > 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, > 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, > 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, > 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, > 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, > 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66,
[jira] [Assigned] (GEODE-7635) DistributedAckRegionDUnitTest. testNBRegionDestructionDuringGetInitialImage is failing in Mass Test Run
[
https://issues.apache.org/jira/browse/GEODE-7635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Hanson reassigned GEODE-7635:
--
Assignee: Mark Hanson (was: Kirk Lund)
> DistributedAckRegionDUnitTest. testNBRegionDestructionDuringGetInitialImage
> is failing in Mass Test Run
> ---
>
> Key: GEODE-7635
> URL: https://issues.apache.org/jira/browse/GEODE-7635
> Project: Geode
> Issue Type: Bug
> Components: tests
>Reporter: Mark Hanson
>Assignee: Mark Hanson
>Priority: Major
> Labels: flaky
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/mhansonp-mhanson-mass-test-ru-main/jobs/DistributedTestOpenJDK8/builds/2396]
>
> {noformat}
> java.lang.AssertionError: java.lang.IllegalStateException: Exception status
> not available while thread is alive.
> at
> org.apache.geode.test.dunit.AsyncInvocation.getException(AsyncInvocation.java:272)
> at
> org.apache.geode.test.dunit.AsyncInvocation.exceptionOccurred(AsyncInvocation.java:256)
> at
> org.apache.geode.cache30.MultiVMRegionTestCase.testNBRegionDestructionDuringGetInitialImage(MultiVMRegionTestCase.java:4973)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.runTestClass(JUnitTestClassExecutor.java:110)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:58)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:38)
> at
> org.gradle.api.internal.tasks.testing.junit.AbstractJUnitTestClassProcessor.processTestClass(AbstractJUnitTestClassProcessor.java:62)
> at
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
> at
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
> at
> org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
> at
> org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
> at com.sun.proxy.$Proxy2.processTestClass(Unknown Source)
> at
> org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:118)
> at
[jira] [Updated] (GEODE-7821) DestroyRegionDuringGIIDistributedTest > testNBRegionInvalidationDuringGetInitialImage_HEAP_DISTRIBUTED_ACK_COMPRESSION FAILED
[ https://issues.apache.org/jira/browse/GEODE-7821?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Hanson updated GEODE-7821: --- Priority: Major (was: Minor) > DestroyRegionDuringGIIDistributedTest > > testNBRegionInvalidationDuringGetInitialImage_HEAP_DISTRIBUTED_ACK_COMPRESSION > FAILED > - > > Key: GEODE-7821 > URL: https://issues.apache.org/jira/browse/GEODE-7821 > Project: Geode > Issue Type: Bug > Components: core, tests >Reporter: Joris Melchior >Assignee: Mark Hanson >Priority: Major > Labels: flaky > Fix For: 1.13.0 > > > Seen this fail in a couple of places. Failures do not seem to have a direct > relation to the pull request for the job. > https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK11/builds/1581 > org.apache.geode.internal.cache.DestroyRegionDuringGIIDistributedTest > > testNBRegionInvalidationDuringGetInitialImage_HEAP_DISTRIBUTED_ACK_COMPRESSION > FAILED > org.apache.geode.test.dunit.RMIException: While invoking > org.apache.geode.internal.cache.DestroyRegionDuringGIIDistributedTest$$Lambda$179/0x000840c73840.run > in VM 2 running on Host 8f4bff2410d5 with 4 VMs > at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:610) > at org.apache.geode.test.dunit.VM.invoke(VM.java:437) > at > org.apache.geode.internal.cache.DestroyRegionDuringGIIDistributedTest.testNBRegionInvalidationDuringGetInitialImage(DestroyRegionDuringGIIDistributedTest.java:414) > Caused by: > org.junit.ComparisonFailure: expected: but was:<[66, 66, 66, > 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, > 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, > 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, > 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, > 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, > 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, > 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, > 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, > 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, > 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, > 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, > 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, > 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, > 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, > 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, > 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, > 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, > 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, > 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, > 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, > 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, > 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, > 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, > 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, > 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, > 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, > 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, > 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, > 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, > 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, > 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, > 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, > 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, > 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, > 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, > 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, > 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, > 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, > 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, > 66, 66, 66,
[jira] [Commented] (GEODE-7814) Unnecessary Object Allocations in DistributionMessage
[
https://issues.apache.org/jira/browse/GEODE-7814?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17047991#comment-17047991
]
ASF subversion and git services commented on GEODE-7814:
Commit db86faec699aca67c02325bca22dcd5b913ddfed in geode's branch
refs/heads/mass-test-run from Juan José Ramos
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=db86fae ]
GEODE-7814: Avoid Messaging Unnecessary Allocations (#4731)
Avoid unnecessary object allocations by making the attributes static.
> Unnecessary Object Allocations in DistributionMessage
> -
>
> Key: GEODE-7814
> URL: https://issues.apache.org/jira/browse/GEODE-7814
> Project: Geode
> Issue Type: Bug
> Components: membership
>Reporter: Juan Ramos
>Assignee: Juan Ramos
>Priority: Major
> Labels: GeodeCommons
> Fix For: 1.12.0, 1.13.0
>
> Attachments: countDifference.png, timeSpent.png
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The {{DistributionMessage}} class unnecessary allocates instances of
> {{java.util.Collection$SingletonList}} and {{InternalDistributedMember[]}}
> through the attributes {{EMPTY_RECIPIENTS_ARRAY}} and {{ALL_RECIPIENTS_LIST}}.
> These attributes are {{final}} and only used to execute internal comparisons
> but, since they are not declared as {{static}}, every instance of
> {{DistributionMessage}} will have its own instance, generating unnecessary
> garbage.
> Using one of our internal testing scenarios and a java profiler we detected
> that, under the current {{develop}} branch, we create 14.824 and 11.212 more
> instances of {{java.util.Collection$SingletonList}} and
> {{InternalDistributedMember[]}} than when using Geode 1.10.
> The increase in the memory footprint is not much (around 1MB all together),
> and the time spent on this operation is around 1.5 seconds slower overall
> (screenshots attached).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-7823) compile error "package org.junit does not exist" when running "geode-core:compileJmhJava" Gradle task in IntelliJ
[
https://issues.apache.org/jira/browse/GEODE-7823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17047993#comment-17047993
]
ASF subversion and git services commented on GEODE-7823:
Commit 088e68242df3e4acc6d661d636f5a786e6b5d6b1 in geode's branch
refs/heads/mass-test-run from Bill Burcham
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=088e682 ]
GEODE-7823: eliminate org.junit unavailable compile error in IntelliJ (#4742)
> compile error "package org.junit does not exist" when running
> "geode-core:compileJmhJava" Gradle task in IntelliJ
> -
>
> Key: GEODE-7823
> URL: https://issues.apache.org/jira/browse/GEODE-7823
> Project: Geode
> Issue Type: Bug
> Components: build
>Affects Versions: 1.13.0
>Reporter: Bill Burcham
>Assignee: Bill Burcham
>Priority: Major
> Fix For: 1.13.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> When building the project in IntelliJ, I see this compile error:
> {code}
> …RangeQueryWithIndexBenchmark.java:17: error: package org.junit does not exist
> import static org.junit.Assert.assertEquals;
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
