[jira] [Created] (GEODE-9774) Function execution on partition region does not clear networkHop on exit
Alberto Gomez created GEODE-9774: Summary: Function execution on partition region does not clear networkHop on exit Key: GEODE-9774 URL: https://issues.apache.org/jira/browse/GEODE-9774 Project: Geode Issue Type: Bug Components: functions Reporter: Alberto Gomez When executing a server function on a partitioned region, if a network hop is done during the execution of the function to access data from another server, the networkHop thread local variable on the PartitionedRegion instance will be set to either 1 or 2. Nevertheless, when the function returns, the variable will not be reset leaving a wrong value in it for subsequent requests. As a result, subsequent requests handled by the same thread that executed the previous function will see the networkHop thread local variable with the value set previously by the function no matter if a network hop was required or not. In case of get/put/destroy/invalidate ,the server will return this information to the client indicating that it should update the metadata when it should not. These will cause unnecessary requests from the client to update the metadata which could impact very negatively the performance of the system. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-9774) Function execution on partition region does not clear networkHop on exit
[ https://issues.apache.org/jira/browse/GEODE-9774?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alberto Gomez reassigned GEODE-9774: Assignee: Alberto Gomez > Function execution on partition region does not clear networkHop on exit > > > Key: GEODE-9774 > URL: https://issues.apache.org/jira/browse/GEODE-9774 > Project: Geode > Issue Type: Bug > Components: functions >Reporter: Alberto Gomez >Assignee: Alberto Gomez >Priority: Major > Labels: needsTriage > > When executing a server function on a partitioned region, if a network hop is > done during the execution of the function to access data from another server, > the networkHop thread local variable on the PartitionedRegion instance will > be set to either 1 or 2. Nevertheless, when the function returns, the > variable will not be reset leaving a wrong value in it for subsequent > requests. > As a result, subsequent requests handled by the same thread that executed the > previous function will see the networkHop thread local variable with the > value set previously by the function no matter if a network hop was required > or not. In case of get/put/destroy/invalidate ,the server will return this > information to the client indicating that it should update the metadata when > it should not. > These will cause unnecessary requests from the client to update the metadata > which could impact very negatively the performance of the system. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9774) Function execution on partition region does not clear networkHop on exit
[ https://issues.apache.org/jira/browse/GEODE-9774?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alberto Gomez updated GEODE-9774: - Description: When executing a server function on a partitioned region, if a network hop is done during the execution of the function to access data from another server, the networkHop thread local variable on the PartitionedRegion instance will be set to either 1 or 2. Nevertheless, when the function returns, the variable will not be reset leaving a wrong value in it for subsequent requests. As a result, subsequent requests handled by the same thread that executed the previous function will see the networkHop thread local variable with the value set previously by the function no matter if a network hop was required or not. In case of get/put/destroy/invalidate, the server will return this information to the client indicating that it should update the metadata when it should not. This will cause unnecessary requests from the client to update the metadata which could impact very negatively the performance of the system. was: When executing a server function on a partitioned region, if a network hop is done during the execution of the function to access data from another server, the networkHop thread local variable on the PartitionedRegion instance will be set to either 1 or 2. Nevertheless, when the function returns, the variable will not be reset leaving a wrong value in it for subsequent requests. As a result, subsequent requests handled by the same thread that executed the previous function will see the networkHop thread local variable with the value set previously by the function no matter if a network hop was required or not. In case of get/put/destroy/invalidate ,the server will return this information to the client indicating that it should update the metadata when it should not. These will cause unnecessary requests from the client to update the metadata which could impact very negatively the performance of the system. > Function execution on partition region does not clear networkHop on exit > > > Key: GEODE-9774 > URL: https://issues.apache.org/jira/browse/GEODE-9774 > Project: Geode > Issue Type: Bug > Components: functions >Reporter: Alberto Gomez >Assignee: Alberto Gomez >Priority: Major > Labels: needsTriage > > When executing a server function on a partitioned region, if a network hop is > done during the execution of the function to access data from another server, > the networkHop thread local variable on the PartitionedRegion instance will > be set to either 1 or 2. Nevertheless, when the function returns, the > variable will not be reset leaving a wrong value in it for subsequent > requests. > As a result, subsequent requests handled by the same thread that executed the > previous function will see the networkHop thread local variable with the > value set previously by the function no matter if a network hop was required > or not. In case of get/put/destroy/invalidate, the server will return this > information to the client indicating that it should update the metadata when > it should not. > This will cause unnecessary requests from the client to update the metadata > which could impact very negatively the performance of the system. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-9774) Function execution on partition region does not clear networkHop on exit
[ https://issues.apache.org/jira/browse/GEODE-9774?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alberto Gomez resolved GEODE-9774. -- Fix Version/s: 1.15.0 Resolution: Fixed > Function execution on partition region does not clear networkHop on exit > > > Key: GEODE-9774 > URL: https://issues.apache.org/jira/browse/GEODE-9774 > Project: Geode > Issue Type: Bug > Components: functions >Reporter: Alberto Gomez >Assignee: Alberto Gomez >Priority: Major > Labels: needsTriage, pull-request-available > Fix For: 1.15.0 > > > When executing a server function on a partitioned region, if a network hop is > done during the execution of the function to access data from another server, > the networkHop thread local variable on the PartitionedRegion instance will > be set to either 1 or 2. Nevertheless, when the function returns, the > variable will not be reset leaving a wrong value in it for subsequent > requests. > As a result, subsequent requests handled by the same thread that executed the > previous function will see the networkHop thread local variable with the > value set previously by the function no matter if a network hop was required > or not. In case of get/put/destroy/invalidate, the server will return this > information to the client indicating that it should update the metadata when > it should not. > This will cause unnecessary requests from the client to update the metadata > which could impact very negatively the performance of the system. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-9807) Gfsh stop gateway sender command done in parallel
Alberto Gomez created GEODE-9807: Summary: Gfsh stop gateway sender command done in parallel Key: GEODE-9807 URL: https://issues.apache.org/jira/browse/GEODE-9807 Project: Geode Issue Type: Improvement Components: gfsh, wan Reporter: Alberto Gomez Currently, the gfsh stop gateway sender command stops serially the gateway sender on each server. The higher the number of Geode servers in the system, the longer the command will take. This process can take very long specially in deployments with a lot of Geode servers and this can be aggravated if the receiving side is not available (connections to the remote site are timing out). It is proposed to implement the stopping of gateway senders in gfsh in parallel just as it is done by the start gateway sender gfsh command. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (GEODE-9807) Gfsh stop gateway sender command done in parallel
[ https://issues.apache.org/jira/browse/GEODE-9807?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alberto Gomez reassigned GEODE-9807: Assignee: Alberto Gomez > Gfsh stop gateway sender command done in parallel > - > > Key: GEODE-9807 > URL: https://issues.apache.org/jira/browse/GEODE-9807 > Project: Geode > Issue Type: Improvement > Components: gfsh, wan >Reporter: Alberto Gomez >Assignee: Alberto Gomez >Priority: Major > > Currently, the gfsh stop gateway sender command stops serially the gateway > sender on each server. > The higher the number of Geode servers in the system, the longer the command > will take. > This process can take very long specially in deployments with a lot of Geode > servers and this can be aggravated if the receiving side is not available > (connections to the remote site are timing out). > It is proposed to implement the stopping of gateway senders in gfsh in > parallel just as it is done by the start gateway sender gfsh command. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9807) Gfsh stop gateway sender command in parallel
[ https://issues.apache.org/jira/browse/GEODE-9807?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alberto Gomez updated GEODE-9807: - Summary: Gfsh stop gateway sender command in parallel (was: Gfsh stop gateway sender command done in parallel) > Gfsh stop gateway sender command in parallel > > > Key: GEODE-9807 > URL: https://issues.apache.org/jira/browse/GEODE-9807 > Project: Geode > Issue Type: Improvement > Components: gfsh, wan >Reporter: Alberto Gomez >Assignee: Alberto Gomez >Priority: Major > > Currently, the gfsh stop gateway sender command stops serially the gateway > sender on each server. > The higher the number of Geode servers in the system, the longer the command > will take. > This process can take very long specially in deployments with a lot of Geode > servers and this can be aggravated if the receiving side is not available > (connections to the remote site are timing out). > It is proposed to implement the stopping of gateway senders in gfsh in > parallel just as it is done by the start gateway sender gfsh command. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (GEODE-9369) Command to copy region entries from a WAN site to another.
[ https://issues.apache.org/jira/browse/GEODE-9369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alberto Gomez resolved GEODE-9369. -- Resolution: Fixed > Command to copy region entries from a WAN site to another. > -- > > Key: GEODE-9369 > URL: https://issues.apache.org/jira/browse/GEODE-9369 > Project: Geode > Issue Type: New Feature > Components: wan >Reporter: Alberto Gomez >Assignee: Alberto Gomez >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > As described in RFC: > [https://cwiki.apache.org/confluence/display/GEODE/Geode+Command+to+replicate+region+data+from+one+site+to+another+connected+via+WAN] > it is proposed to implement a command that copies the entries of a region in > a WAN site to the same region in another WAN site by using WAN replication. > > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (GEODE-8971) Batches with incomplete transactions when stopping the gateway sender
[ https://issues.apache.org/jira/browse/GEODE-8971?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alberto Gomez resolved GEODE-8971. -- Resolution: Fixed > Batches with incomplete transactions when stopping the gateway sender > - > > Key: GEODE-8971 > URL: https://issues.apache.org/jira/browse/GEODE-8971 > Project: Geode > Issue Type: Improvement > Components: wan >Affects Versions: 1.14.0 >Reporter: Alberto Gomez >Assignee: Alberto Gomez >Priority: Major > Labels: pull-request-available > > When the gateway sender is stopped there is a high probability that batches > with incomplete transactions are sent even if group-transaction-events is > enabled. > The reason is that once the stop command reaches the gateway sender, it > immediately stops queueing events, and this could happen in the middle of > receiving events for the same transaction. If this is the case, some events > for the transaction may have reached the queue right before the stop command > was received and the rest of events for that transaction would not make it to > the queue (they would be dropped) because they arrived right after the stop > command was received at the gateway sender. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (GEODE-9852) Modularize WAN TX grouping feature
[ https://issues.apache.org/jira/browse/GEODE-9852?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alberto Gomez reassigned GEODE-9852: Assignee: Alberto Gomez > Modularize WAN TX grouping feature > -- > > Key: GEODE-9852 > URL: https://issues.apache.org/jira/browse/GEODE-9852 > Project: Geode > Issue Type: Improvement > Components: wan >Reporter: Alberto Gomez >Assignee: Alberto Gomez >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (GEODE-9852) Modularize WAN TX grouping feature
Alberto Gomez created GEODE-9852: Summary: Modularize WAN TX grouping feature Key: GEODE-9852 URL: https://issues.apache.org/jira/browse/GEODE-9852 Project: Geode Issue Type: Improvement Components: wan Reporter: Alberto Gomez -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (GEODE-9735) Avoid wan-copy region command to copy entries updated after it started
[ https://issues.apache.org/jira/browse/GEODE-9735?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alberto Gomez resolved GEODE-9735. -- Fix Version/s: 1.15.0 Resolution: Fixed > Avoid wan-copy region command to copy entries updated after it started > -- > > Key: GEODE-9735 > URL: https://issues.apache.org/jira/browse/GEODE-9735 > Project: Geode > Issue Type: Improvement > Components: wan >Reporter: Alberto Gomez >Assignee: Alberto Gomez >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > The wan-copy region command must not copy entries that have been created or > updated after the command has started to copy entries. > There are two reasons for this: > * Efficiency: entries copied after the command has been started will be > replicated by the gateway sender anyway so the copying of these entries by > the command will be a waste of processing resources and duplicated events > will arrive to the remote site. > * Problematic reordering of events in the receiving side: if an entry is > modified in the same millisecond in the source site and the wan-copy region > command tries to copy this entry, it might happen that the command reads the > first version of the entry and sends it to the remote site. The gateway > sender will also send two events to the remote site, one with the first > version of the entry and one with the second. If the event of the wan-copy > region command containing the first version of the entry arrives to the > remote site after the second event sent by the gateway sender, it will > overwrite the second version causing an inconsistency between the two sites. > The reason is that the granularity of the timestamp of events is of > milliseconds and therefore the conflict resolver on the receiving side will > not be able to detect that the event sent by the command is prior to the one > received by the gateway sender. > If entries updated while the command is running are not copied by the > command, this problem is avoided. > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (GEODE-6971) Update CqAttributesFactory to be a fluid API
[
https://issues.apache.org/jira/browse/GEODE-6971?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alberto Gomez reassigned GEODE-6971:
Assignee: (was: Alberto Gomez)
> Update CqAttributesFactory to be a fluid API
>
>
> Key: GEODE-6971
> URL: https://issues.apache.org/jira/browse/GEODE-6971
> Project: Geode
> Issue Type: Improvement
> Components: core
>Reporter: Charlie Black
>Priority: Major
> Time Spent: 3.5h
> Remaining Estimate: 0h
>
> CQAttributes does not currently support fluid API (like ClientCacheFactory
> and ClientRegionFactory). In the ideal world, I'd like to do something like
> the following
> {{CqAttributes cqa = new CqAttributesFactory()}}{{ }}
> {{ .addCqListener(new SimpleCQListener())}}
> {{ .create();}}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (GEODE-7573) Issues with TrasactionIds managed by CacheTransactionManager in C++ native client
[ https://issues.apache.org/jira/browse/GEODE-7573?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alberto Gomez reassigned GEODE-7573: Assignee: (was: Alberto Gomez) > Issues with TrasactionIds managed by CacheTransactionManager in C++ native > client > - > > Key: GEODE-7573 > URL: https://issues.apache.org/jira/browse/GEODE-7573 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Alberto Gomez >Priority: Major > > There are several problems related to the TransactionIds managed by the > CacheTransactionManager class: > > On the one hand, according to the documentation, the > CacheTransactionManager::getTransactionId() returns null if no transaction is > associated to the thread but according to the signature of the method the > object returned is of type TransactionId&. Therefore, there is no possibility > to return null. The same applies to the > CacheTransactionManager::getTransactionId() method. > > If we go to the implementation classes, the following is observed: > If CacheTransactionManagerImpl::suspend() is invoked and there is no > transaction in progress a TransactionException is thrown. This must be > documented instead of the current information that states that a null pointer > is returned. > If CacheTransactionManagerImpl::getTransactionId() is invoked and there is no > transaction in progress what we get is a segmentation fault because the > TXState that should provide the TransactionId object is null. In my opinion > the code should be changed to throw an exception just as it is done when > suspend() is invoked and there is no transaction in progress. > > On the other hand, once a transaction has been commited, a valid > TransactionId reference returned previously by either suspend() or > getTransactionId() becomes invalid because the commit of the transaction > deletes the object (which is stored in the TXState that is destroyed at > commit). > Subsequent uses of the TransacionId once the transaction is commited like it > is done in the testThinClientTransactionsWithSticky integration test (for > example calling exists() or resume()) would access freed memory. > Unawareness of this may cause unexpected behavior in the client code and > should be avoided. Two alternatives are proposed: > * Document in the C++ API that TransactionId references returned by > CacheTransactionManager should not be used after the transaction is commited. > * Change the type of object returned/managed to a TransactionId shared > pointer. > The problem with the second approach is that it involves a change in the API > so the first alternative is the recommended one. > > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (GEODE-9971) Fix ping distributed test case after switching from docker-compose to testcontainers
[ https://issues.apache.org/jira/browse/GEODE-9971?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alberto Gomez reassigned GEODE-9971: Assignee: Alberto Gomez > Fix ping distributed test case after switching from docker-compose to > testcontainers > > > Key: GEODE-9971 > URL: https://issues.apache.org/jira/browse/GEODE-9971 > Project: Geode > Issue Type: Bug >Reporter: Alberto Gomez >Assignee: Alberto Gomez >Priority: Major > Labels: needsTriage > > Due to the changes done by GEODE-9156 to switch from docker-compose to > testcontainers test case > testPingsToReceiversWithSamePortAndHostnameForSendersReachTheRightReceivers > from > SeveralGatewayReceiversWithSamePortAndHostnameForSendersTest was not working > properly even though it was failing. > The test must be enhanced to check that entries are wan replicated to the > other site (for example by checking that entries added locally do not leave > events in the gateway sender queues). > After that, the code of the test must be fixed. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (GEODE-9971) Fix ping distributed test case after switching from docker-compose to testcontainers
Alberto Gomez created GEODE-9971: Summary: Fix ping distributed test case after switching from docker-compose to testcontainers Key: GEODE-9971 URL: https://issues.apache.org/jira/browse/GEODE-9971 Project: Geode Issue Type: Bug Reporter: Alberto Gomez Due to the changes done by GEODE-9156 to switch from docker-compose to testcontainers test case testPingsToReceiversWithSamePortAndHostnameForSendersReachTheRightReceivers from SeveralGatewayReceiversWithSamePortAndHostnameForSendersTest was not working properly even though it was failing. The test must be enhanced to check that entries are wan replicated to the other site (for example by checking that entries added locally do not leave events in the gateway sender queues). After that, the code of the test must be fixed. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (GEODE-9973) Documentation: socket-lease-time is not used to return sockets to a pool but to close them
Alberto Gomez created GEODE-9973: Summary: Documentation: socket-lease-time is not used to return sockets to a pool but to close them Key: GEODE-9973 URL: https://issues.apache.org/jira/browse/GEODE-9973 Project: Geode Issue Type: Bug Components: docs Reporter: Alberto Gomez The "Making sure you have enough sockets" Geode documentation section says the following about socket-lease-time (check underlined sentence): Peer-to-peer. For peer-to-peer threads that do not share sockets, you can use the socket-lease-time to make sure that no socket sits idle for too long. +When a socket that belongs to an individual thread remains unused for this time period, the system automatically returns it to the pool.+ The next time the thread needs a socket, it creates a new socket. Actually, the system automatically closes the connection in the situation described instead of returning it to any pool. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (GEODE-9971) Fix ping distributed test case after switching from docker-compose to testcontainers
[ https://issues.apache.org/jira/browse/GEODE-9971?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alberto Gomez resolved GEODE-9971. -- Fix Version/s: 1.15.0 Resolution: Fixed > Fix ping distributed test case after switching from docker-compose to > testcontainers > > > Key: GEODE-9971 > URL: https://issues.apache.org/jira/browse/GEODE-9971 > Project: Geode > Issue Type: Bug >Reporter: Alberto Gomez >Assignee: Alberto Gomez >Priority: Major > Labels: needsTriage, pull-request-available > Fix For: 1.15.0 > > > Due to the changes done by GEODE-9156 to switch from docker-compose to > testcontainers test case > testPingsToReceiversWithSamePortAndHostnameForSendersReachTheRightReceivers > from > SeveralGatewayReceiversWithSamePortAndHostnameForSendersTest was not working > properly even though it was failing. > The test must be enhanced to check that entries are wan replicated to the > other site (for example by checking that entries added locally do not leave > events in the gateway sender queues). > After that, the code of the test must be fixed. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (GEODE-9807) Gfsh stop gateway sender command in parallel
[ https://issues.apache.org/jira/browse/GEODE-9807?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alberto Gomez resolved GEODE-9807. -- Fix Version/s: 1.15.0 Resolution: Fixed > Gfsh stop gateway sender command in parallel > > > Key: GEODE-9807 > URL: https://issues.apache.org/jira/browse/GEODE-9807 > Project: Geode > Issue Type: Improvement > Components: gfsh, wan >Reporter: Alberto Gomez >Assignee: Alberto Gomez >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > Currently, the gfsh stop gateway sender command stops serially the gateway > sender on each server. > The higher the number of Geode servers in the system, the longer the command > will take. > This process can take very long specially in deployments with a lot of Geode > servers and this can be aggravated if the receiving side is not available > (connections to the remote site are timing out). > It is proposed to implement the stopping of gateway senders in gfsh in > parallel just as it is done by the start gateway sender gfsh command. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-9973) Documentation: socket-lease-time is not used to return sockets to a pool but to close them
[ https://issues.apache.org/jira/browse/GEODE-9973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17480195#comment-17480195 ] Alberto Gomez commented on GEODE-9973: -- [~dbarnes] and [~amurmann] . I do not think this has changed recently. It was probably like this from the beginning but i cannot confirm it. > Documentation: socket-lease-time is not used to return sockets to a pool but > to close them > -- > > Key: GEODE-9973 > URL: https://issues.apache.org/jira/browse/GEODE-9973 > Project: Geode > Issue Type: Bug > Components: docs >Reporter: Alberto Gomez >Assignee: Donal Evans >Priority: Major > Labels: pull-request-available > > The "Making sure you have enough sockets" Geode documentation section says > the following about socket-lease-time (check underlined sentence): > > Peer-to-peer. For peer-to-peer threads that do not share sockets, you can use > the socket-lease-time to make sure that no socket sits idle for too long. > +When a socket that belongs to an individual thread remains unused for this > time period, the system automatically returns it to the pool.+ The next time > the thread needs a socket, it creates a new socket. > > Actually, the system automatically closes the connection in the situation > described instead of returning it to any pool. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-9973) Documentation: socket-lease-time is not used to return sockets to a pool but to close them
[ https://issues.apache.org/jira/browse/GEODE-9973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17481657#comment-17481657 ] Alberto Gomez commented on GEODE-9973: -- [~donalevans] I The org.apache.geode.internal.tcp.ConnectionTable class schedules an idle-connection timeout task for each connection it manages if the idle-timeout for the connection is not zero. This task (IdleConnTT) periodically calls the checkForIdleTimeout() method of the connection calling in turn closeForReconnect() (which closes the connection) when it detects that the connection has been idle for longer than the idleTimeout. The idleConnectionTimeout value for a Connection is obtained from the TCPConduit member of the connection by calling the getIdleTimeout() method. This idleConnectionTimeout in TCPConduit is initialized to DEFAULT_SOCKET_LEASE_TIME and can be overridden by the p2p.idleConnectionTimeout property. And the value for this property is set with the value of socket-lease-time coming from the configuration (DistributionConfig) in the constructor of DirectChannel when it creates a new TCPConduit . > Documentation: socket-lease-time is not used to return sockets to a pool but > to close them > -- > > Key: GEODE-9973 > URL: https://issues.apache.org/jira/browse/GEODE-9973 > Project: Geode > Issue Type: Bug > Components: docs >Reporter: Alberto Gomez >Assignee: Donal Evans >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > The "Making sure you have enough sockets" Geode documentation section says > the following about socket-lease-time (check underlined sentence): > > Peer-to-peer. For peer-to-peer threads that do not share sockets, you can use > the socket-lease-time to make sure that no socket sits idle for too long. > +When a socket that belongs to an individual thread remains unused for this > time period, the system automatically returns it to the pool.+ The next time > the thread needs a socket, it creates a new socket. > > Actually, the system automatically closes the connection in the situation > described instead of returning it to any pool. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Comment Edited] (GEODE-9973) Documentation: socket-lease-time is not used to return sockets to a pool but to close them
[ https://issues.apache.org/jira/browse/GEODE-9973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17481657#comment-17481657 ] Alberto Gomez edited comment on GEODE-9973 at 1/25/22, 9:12 AM: [~donalevans] The org.apache.geode.internal.tcp.ConnectionTable class schedules an idle-connection timeout task for each connection, it manages if the idle-timeout for the connection is not zero. This task (IdleConnTT) periodically calls the checkForIdleTimeout() method of the connection calling in turn closeForReconnect() (which closes the connection) when it detects that the connection has been idle for longer than the idleTimeout. The idleConnectionTimeout value for a Connection is obtained from the TCPConduit member of the connection by calling the getIdleTimeout() method. This idleConnectionTimeout in TCPConduit is initialized to DEFAULT_SOCKET_LEASE_TIME and can be overridden by the p2p.idleConnectionTimeout property if set. And the value for this property is set with the value of socket-lease-time coming from the configuration (DistributionConfig) in the constructor of DirectChannel when it creates a new TCPConduit . was (Author: alberto.gomez): [~donalevans] I The org.apache.geode.internal.tcp.ConnectionTable class schedules an idle-connection timeout task for each connection it manages if the idle-timeout for the connection is not zero. This task (IdleConnTT) periodically calls the checkForIdleTimeout() method of the connection calling in turn closeForReconnect() (which closes the connection) when it detects that the connection has been idle for longer than the idleTimeout. The idleConnectionTimeout value for a Connection is obtained from the TCPConduit member of the connection by calling the getIdleTimeout() method. This idleConnectionTimeout in TCPConduit is initialized to DEFAULT_SOCKET_LEASE_TIME and can be overridden by the p2p.idleConnectionTimeout property. And the value for this property is set with the value of socket-lease-time coming from the configuration (DistributionConfig) in the constructor of DirectChannel when it creates a new TCPConduit . > Documentation: socket-lease-time is not used to return sockets to a pool but > to close them > -- > > Key: GEODE-9973 > URL: https://issues.apache.org/jira/browse/GEODE-9973 > Project: Geode > Issue Type: Bug > Components: docs >Reporter: Alberto Gomez >Assignee: Donal Evans >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > The "Making sure you have enough sockets" Geode documentation section says > the following about socket-lease-time (check underlined sentence): > > Peer-to-peer. For peer-to-peer threads that do not share sockets, you can use > the socket-lease-time to make sure that no socket sits idle for too long. > +When a socket that belongs to an individual thread remains unused for this > time period, the system automatically returns it to the pool.+ The next time > the thread needs a socket, it creates a new socket. > > Actually, the system automatically closes the connection in the situation > described instead of returning it to any pool. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Comment Edited] (GEODE-9973) Documentation: socket-lease-time is not used to return sockets to a pool but to close them
[ https://issues.apache.org/jira/browse/GEODE-9973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17481657#comment-17481657 ] Alberto Gomez edited comment on GEODE-9973 at 1/25/22, 10:50 AM: - [~donalevans] The org.apache.geode.internal.tcp.ConnectionTable class schedules an idle-connection timeout task for each connection it manages, if the idle-timeout for the connection is not zero. This task (IdleConnTT) periodically calls the checkForIdleTimeout() method of the connection calling in turn closeForReconnect() (which closes the connection) when it detects that the connection has been idle for longer than the idleTimeout. The idleConnectionTimeout value for a Connection is obtained from the TCPConduit member of the connection by calling the getIdleTimeout() method. This idleConnectionTimeout in TCPConduit is initialized to DEFAULT_SOCKET_LEASE_TIME and can be overridden by the p2p.idleConnectionTimeout property if set. And the value for this property is set with the value of socket-lease-time coming from the configuration (DistributionConfig) in the constructor of DirectChannel when it creates a new TCPConduit . was (Author: alberto.gomez): [~donalevans] The org.apache.geode.internal.tcp.ConnectionTable class schedules an idle-connection timeout task for each connection, it manages if the idle-timeout for the connection is not zero. This task (IdleConnTT) periodically calls the checkForIdleTimeout() method of the connection calling in turn closeForReconnect() (which closes the connection) when it detects that the connection has been idle for longer than the idleTimeout. The idleConnectionTimeout value for a Connection is obtained from the TCPConduit member of the connection by calling the getIdleTimeout() method. This idleConnectionTimeout in TCPConduit is initialized to DEFAULT_SOCKET_LEASE_TIME and can be overridden by the p2p.idleConnectionTimeout property if set. And the value for this property is set with the value of socket-lease-time coming from the configuration (DistributionConfig) in the constructor of DirectChannel when it creates a new TCPConduit . > Documentation: socket-lease-time is not used to return sockets to a pool but > to close them > -- > > Key: GEODE-9973 > URL: https://issues.apache.org/jira/browse/GEODE-9973 > Project: Geode > Issue Type: Bug > Components: docs >Reporter: Alberto Gomez >Assignee: Donal Evans >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > The "Making sure you have enough sockets" Geode documentation section says > the following about socket-lease-time (check underlined sentence): > > Peer-to-peer. For peer-to-peer threads that do not share sockets, you can use > the socket-lease-time to make sure that no socket sits idle for too long. > +When a socket that belongs to an individual thread remains unused for this > time period, the system automatically returns it to the pool.+ The next time > the thread needs a socket, it creates a new socket. > > Actually, the system automatically closes the connection in the situation > described instead of returning it to any pool. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (GEODE-9984) Mass-Test-Run: WanCopyRegionCommandDUnitTest > testCommandDoesNotCopyEntriesUpdatedAfterCommandStarted FAILED
[ https://issues.apache.org/jira/browse/GEODE-9984?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alberto Gomez reassigned GEODE-9984: Assignee: Alberto Gomez > Mass-Test-Run: WanCopyRegionCommandDUnitTest > > testCommandDoesNotCopyEntriesUpdatedAfterCommandStarted FAILED > - > > Key: GEODE-9984 > URL: https://issues.apache.org/jira/browse/GEODE-9984 > Project: Geode > Issue Type: Bug >Affects Versions: 1.15.0 >Reporter: Kristen >Assignee: Alberto Gomez >Priority: Major > Labels: needsTriage > > WanCopyRegionCommandDUnitTest > > testCommandDoesNotCopyEntriesUpdatedAfterCommandStarted(true, true) [0] FAILED > org.opentest4j.AssertionFailedError: > expected: 5 > but was: 50001 > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native > Method) > at > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at > org.apache.geode.cache.wan.internal.cli.commands.WanCopyRegionCommandDUnitTest.testCommandDoesNotCopyEntriesUpdatedAfterCommandStarted(WanCopyRegionCommandDUnitTest.java:884) > 948 tests completed, 1 failed, 59 skipped > Test report artifacts from this job are available at: > [*http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build.0806/test-artifacts/1642850654/distributedtestfiles-openjdk8-1.15.0-build.0806.tgz*] > > > > May be an issue similar or related to > https://issues.apache.org/jira/browse/GEODE-9859. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (GEODE-9859) Mass-Test-Run: WanCopyRegionCommandDUnitTest.testRegionDestroyedDuringExecution(false, false) [0] FAILED
[
https://issues.apache.org/jira/browse/GEODE-9859?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alberto Gomez resolved GEODE-9859.
--
Fix Version/s: 1.16.0
Resolution: Fixed
> Mass-Test-Run:
> WanCopyRegionCommandDUnitTest.testRegionDestroyedDuringExecution(false,
> false) [0] FAILED
>
>
> Key: GEODE-9859
> URL: https://issues.apache.org/jira/browse/GEODE-9859
> Project: Geode
> Issue Type: Bug
> Components: wan
>Affects Versions: 1.15.0
>Reporter: Mark Hanson
>Assignee: Alberto Gomez
>Priority: Major
> Labels: needsTriage, pull-request-available
> Fix For: 1.16.0
>
>
> Looks like this might be failing from the original PR. I have linked to
> GEODE-9369 as the most likely origination.
>
> {noformat}
> WanCopyRegionCommandDUnitTest > testRegionDestroyedDuringExecution(false,
> false) [0] FAILED
> java.lang.AssertionError:
> Expecting elements:
> ["Execution failed. Error:
> org.apache.geode.cache.EntryDestroyedException: 937"]
> to have exactly 1 times execution error
> at
> org.apache.geode.cache.wan.internal.cli.commands.WanCopyRegionCommandDUnitTest.testRegionDestroyedDuringExecution(WanCopyRegionCommandDUnitTest.java:450)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (GEODE-10000) Avoid gfsh stop gateway sender error when stopped a second time
[ https://issues.apache.org/jira/browse/GEODE-1?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alberto Gomez reassigned GEODE-1: - Assignee: Alberto Gomez > Avoid gfsh stop gateway sender error when stopped a second time > --- > > Key: GEODE-1 > URL: https://issues.apache.org/jira/browse/GEODE-1 > Project: Geode > Issue Type: Bug > Components: gfsh, wan >Reporter: Alberto Gomez >Assignee: Alberto Gomez >Priority: Major > Labels: needsTriage > > After changing the implementation of the "stop gateway sender" command to be > parallel, when it is invoked a second time it fails with the following error: > Error while processing command Reason : > Task java.util.concurrent.FutureTask@513d30f9 rejected from > java.util.concurrent.ThreadPoolExecutor@85189b9[Terminated, pool size = 0, > active threads = 0, queued tasks = 0, completed tasks = 2] -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (GEODE-10000) Avoid gfsh stop gateway sender error when stopped a second time
Alberto Gomez created GEODE-1: - Summary: Avoid gfsh stop gateway sender error when stopped a second time Key: GEODE-1 URL: https://issues.apache.org/jira/browse/GEODE-1 Project: Geode Issue Type: Bug Components: gfsh, wan Reporter: Alberto Gomez After changing the implementation of the "stop gateway sender" command to be parallel, when it is invoked a second time it fails with the following error: Error while processing command Reason : Task java.util.concurrent.FutureTask@513d30f9 rejected from java.util.concurrent.ThreadPoolExecutor@85189b9[Terminated, pool size = 0, active threads = 0, queued tasks = 0, completed tasks = 2] -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (GEODE-10002) Document recommendation but not obligation for parallel gateway sender to share disk store with region
Alberto Gomez created GEODE-10002: - Summary: Document recommendation but not obligation for parallel gateway sender to share disk store with region Key: GEODE-10002 URL: https://issues.apache.org/jira/browse/GEODE-10002 Project: Geode Issue Type: Bug Components: docs, wan Reporter: Alberto Gomez As a result of GEODE-7997, it was documented that "the persisted data from a parallel gateway sender must go to the same disk store as used by the region, because parallel gateway sender queues must be colocated with their regions to operate correctly.". Even though it is true that "parallel gateway sender queues must be colocated with their regions to operate correctly" having different disk stores for the region and for the parallel gateway sender queues does not prevent them from being colocated and therefore to operate correctly. As stated in the Activity in the original ticket by Dan Smith, "The only issue with separating the data into two separate disk stores is that manually deleting the files for just one of the disk stores could cause a hang on startup looking for the missing disk store. We recommend keeping all of the colocated data together." Given that the current statement in the documentation adds a non compatible change to previous versions and also that the given restriction prevents from the independent management of the disk used by the region and by the parallel gateway sender queues it is recommended to change the statement from an obligation to a recommendation giving the reasons for it. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10002) Document recommendation but not obligation for parallel gateway sender to share disk store with region
[ https://issues.apache.org/jira/browse/GEODE-10002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alberto Gomez updated GEODE-10002: -- Description: As a result of GEODE-7997, it was documented that "the persisted data from a parallel gateway sender must go to the same disk store as used by the region, because parallel gateway sender queues must be colocated with their regions to operate correctly.". Even though it is true that "parallel gateway sender queues must be colocated with their regions to operate correctly", having different disk stores for the region and for the parallel gateway sender queues does not prevent them from being colocated and therefore to operate correctly. As stated in the Activity in the original ticket by Dan Smith, "The only issue with separating the data into two separate disk stores is that manually deleting the files for just one of the disk stores could cause a hang on startup looking for the missing disk store. We recommend keeping all of the colocated data together." Given that the current statement in the documentation adds a non compatible change to previous versions and also that the given restriction prevents from the independent management of the disk used by the region and by the parallel gateway sender queues it is recommended to change the statement from an obligation to a recommendation giving the reasons for it. was: As a result of GEODE-7997, it was documented that "the persisted data from a parallel gateway sender must go to the same disk store as used by the region, because parallel gateway sender queues must be colocated with their regions to operate correctly.". Even though it is true that "parallel gateway sender queues must be colocated with their regions to operate correctly" having different disk stores for the region and for the parallel gateway sender queues does not prevent them from being colocated and therefore to operate correctly. As stated in the Activity in the original ticket by Dan Smith, "The only issue with separating the data into two separate disk stores is that manually deleting the files for just one of the disk stores could cause a hang on startup looking for the missing disk store. We recommend keeping all of the colocated data together." Given that the current statement in the documentation adds a non compatible change to previous versions and also that the given restriction prevents from the independent management of the disk used by the region and by the parallel gateway sender queues it is recommended to change the statement from an obligation to a recommendation giving the reasons for it. > Document recommendation but not obligation for parallel gateway sender to > share disk store with region > -- > > Key: GEODE-10002 > URL: https://issues.apache.org/jira/browse/GEODE-10002 > Project: Geode > Issue Type: Bug > Components: docs, wan >Reporter: Alberto Gomez >Priority: Major > Labels: needsTriage > > As a result of GEODE-7997, it was documented that "the persisted data from a > parallel gateway sender must go to the same disk store as used by the region, > because parallel gateway sender queues must be colocated with their regions > to operate correctly.". > Even though it is true that "parallel gateway sender queues must be colocated > with their regions to operate correctly", having different disk stores for > the region and for the parallel gateway sender queues does not prevent them > from being colocated and therefore to operate correctly. > As stated in the Activity in the original ticket by Dan Smith, "The only > issue with separating the data into two separate disk stores is that manually > deleting the files for just one of the disk stores could cause a hang on > startup looking for the missing disk store. We recommend keeping all of the > colocated data together." > Given that the current statement in the documentation adds a non compatible > change to previous versions and also that the given restriction prevents from > the independent management of the disk used by the region and by the parallel > gateway sender queues it is recommended to change the statement from an > obligation to a recommendation giving the reasons for it. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10002) Document recommendation but not obligation for parallel gateway sender to share disk store with region
[ https://issues.apache.org/jira/browse/GEODE-10002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alberto Gomez updated GEODE-10002: -- Description: As a result of GEODE-7997, it was documented that "the persisted data from a parallel gateway sender must go to the same disk store as used by the region, because parallel gateway sender queues must be colocated with their regions to operate correctly.". Even though it is true that "parallel gateway sender queues must be colocated with their regions to operate correctly", having different disk stores for the region and for the parallel gateway sender queues does not prevent them from being colocated and therefore to operate correctly. As stated in the Activity in the original ticket by Dan Smith, "The only issue with separating the data into two separate disk stores is that manually deleting the files for just one of the disk stores could cause a hang on startup looking for the missing disk store. We recommend keeping all of the colocated data together." Given that the current statement in the documentation adds a non compatible change to previous versions and also that the given restriction prevents from the independent management of the disk used by the region and by the parallel gateway sender queues it is proposed to change the statement from an obligation to a recommendation giving the reasons for it. was: As a result of GEODE-7997, it was documented that "the persisted data from a parallel gateway sender must go to the same disk store as used by the region, because parallel gateway sender queues must be colocated with their regions to operate correctly.". Even though it is true that "parallel gateway sender queues must be colocated with their regions to operate correctly", having different disk stores for the region and for the parallel gateway sender queues does not prevent them from being colocated and therefore to operate correctly. As stated in the Activity in the original ticket by Dan Smith, "The only issue with separating the data into two separate disk stores is that manually deleting the files for just one of the disk stores could cause a hang on startup looking for the missing disk store. We recommend keeping all of the colocated data together." Given that the current statement in the documentation adds a non compatible change to previous versions and also that the given restriction prevents from the independent management of the disk used by the region and by the parallel gateway sender queues it is recommended to change the statement from an obligation to a recommendation giving the reasons for it. > Document recommendation but not obligation for parallel gateway sender to > share disk store with region > -- > > Key: GEODE-10002 > URL: https://issues.apache.org/jira/browse/GEODE-10002 > Project: Geode > Issue Type: Bug > Components: docs, wan >Reporter: Alberto Gomez >Priority: Major > Labels: needsTriage > > As a result of GEODE-7997, it was documented that "the persisted data from a > parallel gateway sender must go to the same disk store as used by the region, > because parallel gateway sender queues must be colocated with their regions > to operate correctly.". > Even though it is true that "parallel gateway sender queues must be colocated > with their regions to operate correctly", having different disk stores for > the region and for the parallel gateway sender queues does not prevent them > from being colocated and therefore to operate correctly. > As stated in the Activity in the original ticket by Dan Smith, "The only > issue with separating the data into two separate disk stores is that manually > deleting the files for just one of the disk stores could cause a hang on > startup looking for the missing disk store. We recommend keeping all of the > colocated data together." > Given that the current statement in the documentation adds a non compatible > change to previous versions and also that the given restriction prevents from > the independent management of the disk used by the region and by the parallel > gateway sender queues it is proposed to change the statement from an > obligation to a recommendation giving the reasons for it. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (GEODE-10008) Avoid possible EntryDestroyedException error in wan-copy region command when entry destroyed in partitioned region
Alberto Gomez created GEODE-10008: - Summary: Avoid possible EntryDestroyedException error in wan-copy region command when entry destroyed in partitioned region Key: GEODE-10008 URL: https://issues.apache.org/jira/browse/GEODE-10008 Project: Geode Issue Type: Bug Components: gfsh, wan Reporter: Alberto Gomez When the wan-copy region command is executed over a partitioned region, it is possible that sometimes an EntryDestroyedException error is found if, while reading the entries from the region, one of them is destroyed. The error has been seen sometimes when running the following test: WanCopyRegionCommandDUnitTest. testSuccessfulExecutionWhileRunningOpsOnRegion(true, true). Log of the error: Multiple Failures (2 failures) org.opentest4j.AssertionFailedError: [ Member | Status | Message -- | -- | --- alberto-dell(421543):41010 | ERROR | Execution failed. Error: org.apache.geode.cache.EntryDestroyedException: 26 alberto-dell(421504):41009 | OK | Entries copied: 2,977 alberto-dell(421598):41011 | OK | Entries copied: 3,042 ] expected: OK but was: ERROR java.lang.AssertionError: Suspicious strings were written to the log during this run. Fix the strings or use IgnoredException.addIgnoredException to ignore. --- Found suspect string in 'dunit_suspect-vm6.log' at line 1883 [error 2022/02/01 08:58:59.046 CET tid=99] Exception occurred attempting to wan-copy region java.util.concurrent.ExecutionException: org.apache.geode.cache.EntryDestroyedException: 26 at java.util.concurrent.FutureTask.report(FutureTask.java:122) at java.util.concurrent.FutureTask.get(FutureTask.java:192) at org.apache.geode.cache.wan.internal.WanCopyRegionFunctionService.execute(WanCopyRegionFunctionService.java:90) at org.apache.geode.management.internal.cli.functions.WanCopyRegionFunction.executeFunctionInService(WanCopyRegionFunction.java:163) at org.apache.geode.management.internal.cli.functions.WanCopyRegionFunction.executeFunction(WanCopyRegionFunction.java:157) at org.apache.geode.management.cli.CliFunction.execute(CliFunction.java:37) at org.apache.geode.internal.cache.MemberFunctionStreamingMessage.process(MemberFunctionStreamingMessage.java:201) at org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:382) at org.apache.geode.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:447) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at org.apache.geode.distributed.internal.ClusterOperationExecutors.runUntilShutdown(ClusterOperationExecutors.java:444) at org.apache.geode.distributed.internal.ClusterOperationExecutors.doFunctionExecutionThread(ClusterOperationExecutors.java:379) at org.apache.geode.logging.internal.executors.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:120) at java.lang.Thread.run(Thread.java:748) Caused by: org.apache.geode.cache.EntryDestroyedException: 26 at org.apache.geode.internal.cache.NonTXEntry.basicGetEntry(NonTXEntry.java:62) at org.apache.geode.internal.cache.NonTXEntry.getRegion(NonTXEntry.java:119) at org.apache.geode.internal.cache.NonTXEntry.hashCode(NonTXEntry.java:157) at java.util.HashMap.hash(HashMap.java:340) at java.util.HashMap.put(HashMap.java:613) at java.util.HashSet.add(HashSet.java:220) at java.util.stream.ReduceOps$3ReducingSink.accept(ReduceOps.java:169) at java.util.Iterator.forEachRemaining(Iterator.java:116) at java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801) at java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:647) at java.util.stream.ReferencePipeline$7$1.accept(ReferencePipeline.java:272) at java.util.HashMap$KeySpliterator.forEachRemaining(HashMap.java:1580) at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:482) at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:472) at java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:708) at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234) at java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:566) at org.apache.geode.management.internal.cli.functions.WanCopyRegionFunctionDelegate.getEntries(WanCopyRegionFunctionDelegate.java:193) at org.apache.geode.management.internal.cli.functions.WanCopyRegionFunctionDelegate.wanCopyRegion(WanCopyRegionFunctionDelegate.java:104) at org.apache.geode.
[jira] [Assigned] (GEODE-10008) Avoid possible EntryDestroyedException error in wan-copy region command when entry destroyed in partitioned region
[ https://issues.apache.org/jira/browse/GEODE-10008?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alberto Gomez reassigned GEODE-10008: - Assignee: Alberto Gomez > Avoid possible EntryDestroyedException error in wan-copy region command when > entry destroyed in partitioned region > -- > > Key: GEODE-10008 > URL: https://issues.apache.org/jira/browse/GEODE-10008 > Project: Geode > Issue Type: Bug > Components: gfsh, wan >Reporter: Alberto Gomez >Assignee: Alberto Gomez >Priority: Major > Labels: needsTriage > > When the wan-copy region command is executed over a partitioned region, it is > possible that sometimes an EntryDestroyedException error is found if, while > reading the entries from the region, one of them is destroyed. > The error has been seen sometimes when running the following test: > WanCopyRegionCommandDUnitTest. > testSuccessfulExecutionWhileRunningOpsOnRegion(true, true). > > Log of the error: > Multiple Failures (2 failures) > org.opentest4j.AssertionFailedError: [ Member | > Status | Message > -- | -- | > --- > alberto-dell(421543):41010 | ERROR | Execution failed. Error: > org.apache.geode.cache.EntryDestroyedException: 26 > alberto-dell(421504):41009 | OK | Entries copied: 2,977 > alberto-dell(421598):41011 | OK | Entries copied: 3,042 > ] > expected: OK > but was: ERROR > java.lang.AssertionError: Suspicious strings were written to the log > during this run. > Fix the strings or use IgnoredException.addIgnoredException to ignore. > --- > Found suspect string in 'dunit_suspect-vm6.log' at line 1883 > [error 2022/02/01 08:58:59.046 CET tid=99] > Exception occurred attempting to wan-copy region > java.util.concurrent.ExecutionException: > org.apache.geode.cache.EntryDestroyedException: 26 > at java.util.concurrent.FutureTask.report(FutureTask.java:122) > at java.util.concurrent.FutureTask.get(FutureTask.java:192) > at > org.apache.geode.cache.wan.internal.WanCopyRegionFunctionService.execute(WanCopyRegionFunctionService.java:90) > at > org.apache.geode.management.internal.cli.functions.WanCopyRegionFunction.executeFunctionInService(WanCopyRegionFunction.java:163) > at > org.apache.geode.management.internal.cli.functions.WanCopyRegionFunction.executeFunction(WanCopyRegionFunction.java:157) > at > org.apache.geode.management.cli.CliFunction.execute(CliFunction.java:37) > at > org.apache.geode.internal.cache.MemberFunctionStreamingMessage.process(MemberFunctionStreamingMessage.java:201) > at > org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:382) > at > org.apache.geode.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:447) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > at > org.apache.geode.distributed.internal.ClusterOperationExecutors.runUntilShutdown(ClusterOperationExecutors.java:444) > at > org.apache.geode.distributed.internal.ClusterOperationExecutors.doFunctionExecutionThread(ClusterOperationExecutors.java:379) > at > org.apache.geode.logging.internal.executors.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:120) > at java.lang.Thread.run(Thread.java:748) > Caused by: org.apache.geode.cache.EntryDestroyedException: 26 > at > org.apache.geode.internal.cache.NonTXEntry.basicGetEntry(NonTXEntry.java:62) > at > org.apache.geode.internal.cache.NonTXEntry.getRegion(NonTXEntry.java:119) > at > org.apache.geode.internal.cache.NonTXEntry.hashCode(NonTXEntry.java:157) > at java.util.HashMap.hash(HashMap.java:340) > at java.util.HashMap.put(HashMap.java:613) > at java.util.HashSet.add(HashSet.java:220) > at java.util.stream.ReduceOps$3ReducingSink.accept(ReduceOps.java:169) > at java.util.Iterator.forEachRemaining(Iterator.java:116) > at > java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801) > at > java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:647) > at > java.util.stream.ReferencePipeline$7$1.accept(ReferencePipeline.java:272) > at java.util.HashMap$KeySpliterator.forEachRemaining(HashMap.java:1580) > at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:482) > at > java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:472) > at > java.util.s
[jira] [Assigned] (GEODE-10002) Document recommendation but not obligation for parallel gateway sender to share disk store with region
[ https://issues.apache.org/jira/browse/GEODE-10002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alberto Gomez reassigned GEODE-10002: - Assignee: Alberto Gomez > Document recommendation but not obligation for parallel gateway sender to > share disk store with region > -- > > Key: GEODE-10002 > URL: https://issues.apache.org/jira/browse/GEODE-10002 > Project: Geode > Issue Type: Bug > Components: docs, wan >Reporter: Alberto Gomez >Assignee: Alberto Gomez >Priority: Major > Labels: needsTriage, pull-request-available > > As a result of GEODE-7997, it was documented that "the persisted data from a > parallel gateway sender must go to the same disk store as used by the region, > because parallel gateway sender queues must be colocated with their regions > to operate correctly.". > Even though it is true that "parallel gateway sender queues must be colocated > with their regions to operate correctly", having different disk stores for > the region and for the parallel gateway sender queues does not prevent them > from being colocated and therefore to operate correctly. > As stated in the Activity in the original ticket by Dan Smith, "The only > issue with separating the data into two separate disk stores is that manually > deleting the files for just one of the disk stores could cause a hang on > startup looking for the missing disk store. We recommend keeping all of the > colocated data together." > Given that the current statement in the documentation adds a non compatible > change to previous versions and also that the given restriction prevents from > the independent management of the disk used by the region and by the parallel > gateway sender queues it is proposed to change the statement from an > obligation to a recommendation giving the reasons for it. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10002) Remove from documentation obligation for parallel gateway sender to share disk store with region
[ https://issues.apache.org/jira/browse/GEODE-10002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alberto Gomez updated GEODE-10002: -- Summary: Remove from documentation obligation for parallel gateway sender to share disk store with region (was: Document recommendation but not obligation for parallel gateway sender to share disk store with region) > Remove from documentation obligation for parallel gateway sender to share > disk store with region > > > Key: GEODE-10002 > URL: https://issues.apache.org/jira/browse/GEODE-10002 > Project: Geode > Issue Type: Bug > Components: docs, wan >Reporter: Alberto Gomez >Assignee: Alberto Gomez >Priority: Major > Labels: needsTriage, pull-request-available > > As a result of GEODE-7997, it was documented that "the persisted data from a > parallel gateway sender must go to the same disk store as used by the region, > because parallel gateway sender queues must be colocated with their regions > to operate correctly.". > Even though it is true that "parallel gateway sender queues must be colocated > with their regions to operate correctly", having different disk stores for > the region and for the parallel gateway sender queues does not prevent them > from being colocated and therefore to operate correctly. > As stated in the Activity in the original ticket by Dan Smith, "The only > issue with separating the data into two separate disk stores is that manually > deleting the files for just one of the disk stores could cause a hang on > startup looking for the missing disk store. We recommend keeping all of the > colocated data together." > Given that the current statement in the documentation adds a non compatible > change to previous versions and also that the given restriction prevents from > the independent management of the disk used by the region and by the parallel > gateway sender queues it is proposed to change the statement from an > obligation to a recommendation giving the reasons for it. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10002) Remove from documentation obligation for parallel gateway sender to share disk store with region
[ https://issues.apache.org/jira/browse/GEODE-10002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alberto Gomez updated GEODE-10002: -- Description: As a result of GEODE-7997, it was documented that "the persisted data from a parallel gateway sender must go to the same disk store as used by the region, because parallel gateway sender queues must be colocated with their regions to operate correctly.". As stated in the Activity in the original ticket by Dan Smith, "The only issue with separating the data into two separate disk stores is that manually deleting the files for just one of the disk stores could cause a hang on startup looking for the missing disk store. We recommend keeping all of the colocated data together." Given that the current statement in the documentation adds a non compatible change to previous versions and also that the given restriction prevents from the independent management of the disk used by the region and by the parallel gateway sender queues it is proposed to change the statement from an obligation to a recommendation giving the reasons for it or completely removing the obligation. was: As a result of GEODE-7997, it was documented that "the persisted data from a parallel gateway sender must go to the same disk store as used by the region, because parallel gateway sender queues must be colocated with their regions to operate correctly.". Even though it is true that "parallel gateway sender queues must be colocated with their regions to operate correctly", having different disk stores for the region and for the parallel gateway sender queues does not prevent them from being colocated and therefore to operate correctly. As stated in the Activity in the original ticket by Dan Smith, "The only issue with separating the data into two separate disk stores is that manually deleting the files for just one of the disk stores could cause a hang on startup looking for the missing disk store. We recommend keeping all of the colocated data together." Given that the current statement in the documentation adds a non compatible change to previous versions and also that the given restriction prevents from the independent management of the disk used by the region and by the parallel gateway sender queues it is proposed to change the statement from an obligation to a recommendation giving the reasons for it. > Remove from documentation obligation for parallel gateway sender to share > disk store with region > > > Key: GEODE-10002 > URL: https://issues.apache.org/jira/browse/GEODE-10002 > Project: Geode > Issue Type: Bug > Components: docs, wan >Reporter: Alberto Gomez >Assignee: Alberto Gomez >Priority: Major > Labels: needsTriage, pull-request-available > > As a result of GEODE-7997, it was documented that "the persisted data from a > parallel gateway sender must go to the same disk store as used by the region, > because parallel gateway sender queues must be colocated with their regions > to operate correctly.". > As stated in the Activity in the original ticket by Dan Smith, "The only > issue with separating the data into two separate disk stores is that manually > deleting the files for just one of the disk stores could cause a hang on > startup looking for the missing disk store. We recommend keeping all of the > colocated data together." > Given that the current statement in the documentation adds a non compatible > change to previous versions and also that the given restriction prevents from > the independent management of the disk used by the region and by the parallel > gateway sender queues it is proposed to change the statement from an > obligation to a recommendation giving the reasons for it or completely > removing the obligation. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (GEODE-10002) Remove from documentation obligation for parallel gateway sender to share disk store with region
[ https://issues.apache.org/jira/browse/GEODE-10002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alberto Gomez resolved GEODE-10002. --- Fix Version/s: 1.16.0 Resolution: Fixed > Remove from documentation obligation for parallel gateway sender to share > disk store with region > > > Key: GEODE-10002 > URL: https://issues.apache.org/jira/browse/GEODE-10002 > Project: Geode > Issue Type: Bug > Components: docs, wan >Reporter: Alberto Gomez >Assignee: Alberto Gomez >Priority: Major > Labels: needsTriage, pull-request-available > Fix For: 1.16.0 > > > As a result of GEODE-7997, it was documented that "the persisted data from a > parallel gateway sender must go to the same disk store as used by the region, > because parallel gateway sender queues must be colocated with their regions > to operate correctly.". > As stated in the Activity in the original ticket by Dan Smith, "The only > issue with separating the data into two separate disk stores is that manually > deleting the files for just one of the disk stores could cause a hang on > startup looking for the missing disk store. We recommend keeping all of the > colocated data together." > Given that the current statement in the documentation adds a non compatible > change to previous versions and also that the given restriction prevents from > the independent management of the disk used by the region and by the parallel > gateway sender queues it is proposed to change the statement from an > obligation to a recommendation giving the reasons for it or completely > removing the obligation. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (GEODE-10008) Avoid possible EntryDestroyedException error in wan-copy region command when entry destroyed in partitioned region
[ https://issues.apache.org/jira/browse/GEODE-10008?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alberto Gomez resolved GEODE-10008. --- Fix Version/s: 1.16.0 Resolution: Fixed > Avoid possible EntryDestroyedException error in wan-copy region command when > entry destroyed in partitioned region > -- > > Key: GEODE-10008 > URL: https://issues.apache.org/jira/browse/GEODE-10008 > Project: Geode > Issue Type: Bug > Components: gfsh, wan >Reporter: Alberto Gomez >Assignee: Alberto Gomez >Priority: Major > Labels: needsTriage, pull-request-available > Fix For: 1.16.0 > > > When the wan-copy region command is executed over a partitioned region, it is > possible that sometimes an EntryDestroyedException error is found if, while > reading the entries from the region, one of them is destroyed. > The error has been seen sometimes when running the following test: > WanCopyRegionCommandDUnitTest. > testSuccessfulExecutionWhileRunningOpsOnRegion(true, true). > > Log of the error: > Multiple Failures (2 failures) > org.opentest4j.AssertionFailedError: [ Member | > Status | Message > -- | -- | > --- > alberto-dell(421543):41010 | ERROR | Execution failed. Error: > org.apache.geode.cache.EntryDestroyedException: 26 > alberto-dell(421504):41009 | OK | Entries copied: 2,977 > alberto-dell(421598):41011 | OK | Entries copied: 3,042 > ] > expected: OK > but was: ERROR > java.lang.AssertionError: Suspicious strings were written to the log > during this run. > Fix the strings or use IgnoredException.addIgnoredException to ignore. > --- > Found suspect string in 'dunit_suspect-vm6.log' at line 1883 > [error 2022/02/01 08:58:59.046 CET tid=99] > Exception occurred attempting to wan-copy region > java.util.concurrent.ExecutionException: > org.apache.geode.cache.EntryDestroyedException: 26 > at java.util.concurrent.FutureTask.report(FutureTask.java:122) > at java.util.concurrent.FutureTask.get(FutureTask.java:192) > at > org.apache.geode.cache.wan.internal.WanCopyRegionFunctionService.execute(WanCopyRegionFunctionService.java:90) > at > org.apache.geode.management.internal.cli.functions.WanCopyRegionFunction.executeFunctionInService(WanCopyRegionFunction.java:163) > at > org.apache.geode.management.internal.cli.functions.WanCopyRegionFunction.executeFunction(WanCopyRegionFunction.java:157) > at > org.apache.geode.management.cli.CliFunction.execute(CliFunction.java:37) > at > org.apache.geode.internal.cache.MemberFunctionStreamingMessage.process(MemberFunctionStreamingMessage.java:201) > at > org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:382) > at > org.apache.geode.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:447) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > at > org.apache.geode.distributed.internal.ClusterOperationExecutors.runUntilShutdown(ClusterOperationExecutors.java:444) > at > org.apache.geode.distributed.internal.ClusterOperationExecutors.doFunctionExecutionThread(ClusterOperationExecutors.java:379) > at > org.apache.geode.logging.internal.executors.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:120) > at java.lang.Thread.run(Thread.java:748) > Caused by: org.apache.geode.cache.EntryDestroyedException: 26 > at > org.apache.geode.internal.cache.NonTXEntry.basicGetEntry(NonTXEntry.java:62) > at > org.apache.geode.internal.cache.NonTXEntry.getRegion(NonTXEntry.java:119) > at > org.apache.geode.internal.cache.NonTXEntry.hashCode(NonTXEntry.java:157) > at java.util.HashMap.hash(HashMap.java:340) > at java.util.HashMap.put(HashMap.java:613) > at java.util.HashSet.add(HashSet.java:220) > at java.util.stream.ReduceOps$3ReducingSink.accept(ReduceOps.java:169) > at java.util.Iterator.forEachRemaining(Iterator.java:116) > at > java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801) > at > java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:647) > at > java.util.stream.ReferencePipeline$7$1.accept(ReferencePipeline.java:272) > at java.util.HashMap$KeySpliterator.forEachRemaining(HashMap.java:1580) > at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:482) > at > java.util.stream.AbstractP
[jira] [Resolved] (GEODE-10000) Avoid gfsh stop gateway sender error when stopped a second time
[ https://issues.apache.org/jira/browse/GEODE-1?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alberto Gomez resolved GEODE-1. --- Fix Version/s: 1.16.0 Resolution: Fixed > Avoid gfsh stop gateway sender error when stopped a second time > --- > > Key: GEODE-1 > URL: https://issues.apache.org/jira/browse/GEODE-1 > Project: Geode > Issue Type: Bug > Components: gfsh, wan >Reporter: Alberto Gomez >Assignee: Alberto Gomez >Priority: Major > Labels: needsTriage, pull-request-available > Fix For: 1.16.0 > > > After changing the implementation of the "stop gateway sender" command to be > parallel, when it is invoked a second time it fails with the following error: > Error while processing command Reason : > Task java.util.concurrent.FutureTask@513d30f9 rejected from > java.util.concurrent.ThreadPoolExecutor@85189b9[Terminated, pool size = 0, > active threads = 0, queued tasks = 0, completed tasks = 2] -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (GEODE-10077) wan-copy region command does not prevent callbacks to be executed on the remote site
Alberto Gomez created GEODE-10077: - Summary: wan-copy region command does not prevent callbacks to be executed on the remote site Key: GEODE-10077 URL: https://issues.apache.org/jira/browse/GEODE-10077 Project: Geode Issue Type: Bug Components: gfsh, wan Reporter: Alberto Gomez The wan-copy region command does not always prevent that callbacks are executed at the remote site for the entries copied. For example, if the remote site has more than one server and the gateway receiver that gets the entries copied does not host the primary bucket of the entry received, it will send the put operation to the server than hosts the primary bucket and on this server, callbacks will be executed, provoking, for example, that if a gateway sender is configured for the region, the event will be sent by that gateway sender in the remote site. Also, if the remote site has more than one server and the region has at least one replica (either because it is a replicated region or because it is a partitioned region with number of replicas greater than 1) then servers in the remote site that receive an UpdateMessage from the server that received the copied entry via the gateway receiver, would execute the callbacks, provoking, like in the above case that if a gateway sender is configured for the region, the event will be sent by that gateway sender in the remote site. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (GEODE-10077) wan-copy region command does not prevent callbacks to be executed on the remote site
[ https://issues.apache.org/jira/browse/GEODE-10077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alberto Gomez reassigned GEODE-10077: - Assignee: Alberto Gomez > wan-copy region command does not prevent callbacks to be executed on the > remote site > > > Key: GEODE-10077 > URL: https://issues.apache.org/jira/browse/GEODE-10077 > Project: Geode > Issue Type: Bug > Components: gfsh, wan >Reporter: Alberto Gomez >Assignee: Alberto Gomez >Priority: Major > Labels: needsTriage > > The wan-copy region command does not always prevent that callbacks are > executed at the remote site for the entries copied. > For example, if the remote site has more than one server and the gateway > receiver that gets the entries copied does not host the primary bucket of the > entry received, it will send the put operation to the server than hosts the > primary bucket and on this server, callbacks will be executed, provoking, for > example, that if a gateway sender is configured for the region, the event > will be sent by that gateway sender in the remote site. > Also, if the remote site has more than one server and the region has at least > one replica (either because it is a replicated region or because it is a > partitioned region with number of replicas greater than 1) then servers in > the remote site that receive an UpdateMessage from the server that received > the copied entry via the gateway receiver, would execute the callbacks, > provoking, like in the above case that if a gateway sender is configured for > the region, the event will be sent by that gateway sender in the remote site. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (GEODE-10087) Enhance Off-heap memory fragmentation visibility
[
https://issues.apache.org/jira/browse/GEODE-10087?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alberto Gomez reassigned GEODE-10087:
-
Assignee: Alberto Gomez
> Enhance Off-heap memory fragmentation visibility
> -
>
> Key: GEODE-10087
> URL: https://issues.apache.org/jira/browse/GEODE-10087
> Project: Geode
> Issue Type: Improvement
> Components: offheap, statistics
>Reporter: Alberto Gomez
>Assignee: Alberto Gomez
>Priority: Major
>
> As pointed out in
> https://cwiki.apache.org/confluence/display/GEODE/Enhance+Off-heap+memory+fragmentation+visibility:
> "Even though Geode offers several stats related to the status of the off-heap
> memory area ({_}usedMemory{_}, {_}freeMemory{_}, {_}fragmentation{_},
> _largestFragment_ and {_}fragments{_}), the ones that provide information
> about the level of the fragmentation of the off-heap memory
> ({_}fragmentation{_}, _largestFragment_ and {_}fragments{_}) are only updated
> when defragmentation is executed."
> The visibility of the off-heap memory fragmentation status must be made more
> visible as proposed in the above RFC by means of:
> * Updating the largestFragment stat periodically.
> * Adding a new off-heap stat called "freedChunks" that will provide the
> number of elements in the tiny and huge lists. This stat will be periodically
> updated.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (GEODE-10087) Enhance Off-heap memory fragmentation visibility
Alberto Gomez created GEODE-10087:
-
Summary: Enhance Off-heap memory fragmentation visibility
Key: GEODE-10087
URL: https://issues.apache.org/jira/browse/GEODE-10087
Project: Geode
Issue Type: Improvement
Components: offheap, statistics
Reporter: Alberto Gomez
As pointed out in
https://cwiki.apache.org/confluence/display/GEODE/Enhance+Off-heap+memory+fragmentation+visibility:
"Even though Geode offers several stats related to the status of the off-heap
memory area ({_}usedMemory{_}, {_}freeMemory{_}, {_}fragmentation{_},
_largestFragment_ and {_}fragments{_}), the ones that provide information about
the level of the fragmentation of the off-heap memory ({_}fragmentation{_},
_largestFragment_ and {_}fragments{_}) are only updated when defragmentation is
executed."
The visibility of the off-heap memory fragmentation status must be made more
visible as proposed in the above RFC by means of:
* Updating the largestFragment stat periodically.
* Adding a new off-heap stat called "freedChunks" that will provide the number
of elements in the tiny and huge lists. This stat will be periodically updated.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Resolved] (GEODE-9984) Mass-Test-Run: WanCopyRegionCommandDUnitTest > testCommandDoesNotCopyEntriesUpdatedAfterCommandStarted FAILED
[ https://issues.apache.org/jira/browse/GEODE-9984?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alberto Gomez resolved GEODE-9984. -- Fix Version/s: 1.16.0 Resolution: Fixed > Mass-Test-Run: WanCopyRegionCommandDUnitTest > > testCommandDoesNotCopyEntriesUpdatedAfterCommandStarted FAILED > - > > Key: GEODE-9984 > URL: https://issues.apache.org/jira/browse/GEODE-9984 > Project: Geode > Issue Type: Bug >Affects Versions: 1.15.0 >Reporter: Kristen >Assignee: Alberto Gomez >Priority: Major > Labels: flaky-test, pull-request-available > Fix For: 1.16.0 > > > WanCopyRegionCommandDUnitTest > > testCommandDoesNotCopyEntriesUpdatedAfterCommandStarted(true, true) [0] FAILED > org.opentest4j.AssertionFailedError: > expected: 5 > but was: 50001 > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native > Method) > at > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at > org.apache.geode.cache.wan.internal.cli.commands.WanCopyRegionCommandDUnitTest.testCommandDoesNotCopyEntriesUpdatedAfterCommandStarted(WanCopyRegionCommandDUnitTest.java:884) > 948 tests completed, 1 failed, 59 skipped > Test report artifacts from this job are available at: > [*http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build.0806/test-artifacts/1642850654/distributedtestfiles-openjdk8-1.15.0-build.0806.tgz*] > > > > May be an issue similar or related to > https://issues.apache.org/jira/browse/GEODE-9859. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (GEODE-10067) WANCopyRegionFunctionDelegate needs to be optimized to handle large regions
[ https://issues.apache.org/jira/browse/GEODE-10067?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alberto Gomez reassigned GEODE-10067: - Assignee: Alberto Gomez > WANCopyRegionFunctionDelegate needs to be optimized to handle large regions > --- > > Key: GEODE-10067 > URL: https://issues.apache.org/jira/browse/GEODE-10067 > Project: Geode > Issue Type: Improvement > Components: wan >Affects Versions: 1.15.0, 1.16.0 >Reporter: Udo Kohlmeyer >Assignee: Alberto Gomez >Priority: Major > Labels: pull-request-available > > The current WanCopyRegionFunctionDelegate may cause significant memory issues > in with really large regions. > The > [getEntries|https://github.com/apache/geode/blob/develop/geode-wan/src/main/java/org/apache/geode/management/internal/cli/functions/WanCopyRegionFunctionDelegate.java#L102] > method returns both primary and redundant Region Entries for local server. > The invocation of getEntries from the PartitionedRegionDataStore will cause > all entries to be deserialized > https://github.com/apache/geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/PartitionedRegionDataStore.java#L2501-L2515 > The > [createBatch|https://github.com/apache/geode/blob/develop/geode-wan/src/main/java/org/apache/geode/management/internal/cli/functions/WanCopyRegionFunctionDelegate.java#L107-L108] > method creates a List equally that of the local Region > size. > Essentially ... In a system with VERY large regions this might cause > significant memory issues > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (GEODE-10071) Remove the dependency that WanCopyRegionFunction has on WanCopyRegionCommand
[ https://issues.apache.org/jira/browse/GEODE-10071?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alberto Gomez reassigned GEODE-10071: - Assignee: Alberto Gomez > Remove the dependency that WanCopyRegionFunction has on WanCopyRegionCommand > > > Key: GEODE-10071 > URL: https://issues.apache.org/jira/browse/GEODE-10071 > Project: Geode > Issue Type: Improvement > Components: wan >Affects Versions: 1.15.0, 1.16.0 >Reporter: Udo Kohlmeyer >Assignee: Alberto Gomez >Priority: Major > > There is a cyclical dependency between the Command and the implementing > function for the Wan copy feature. > Logically, the command needs to have a dependency on the function. > The error messages currently defined in the Command class need to be moved to > the function class where they are used. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (GEODE-10071) Remove the dependency that WanCopyRegionFunction has on WanCopyRegionCommand
[ https://issues.apache.org/jira/browse/GEODE-10071?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alberto Gomez resolved GEODE-10071. --- Fix Version/s: 1.16.0 Resolution: Fixed > Remove the dependency that WanCopyRegionFunction has on WanCopyRegionCommand > > > Key: GEODE-10071 > URL: https://issues.apache.org/jira/browse/GEODE-10071 > Project: Geode > Issue Type: Improvement > Components: wan >Affects Versions: 1.15.0, 1.16.0 >Reporter: Udo Kohlmeyer >Assignee: Alberto Gomez >Priority: Major > Labels: pull-request-available > Fix For: 1.16.0 > > > There is a cyclical dependency between the Command and the implementing > function for the Wan copy feature. > Logically, the command needs to have a dependency on the function. > The error messages currently defined in the Command class need to be moved to > the function class where they are used. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (GEODE-10067) WANCopyRegionFunctionDelegate needs to be optimized to handle large regions
[ https://issues.apache.org/jira/browse/GEODE-10067?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alberto Gomez resolved GEODE-10067. --- Fix Version/s: 1.15.0 Resolution: Fixed > WANCopyRegionFunctionDelegate needs to be optimized to handle large regions > --- > > Key: GEODE-10067 > URL: https://issues.apache.org/jira/browse/GEODE-10067 > Project: Geode > Issue Type: Improvement > Components: wan >Affects Versions: 1.15.0 >Reporter: Udo Kohlmeyer >Assignee: Alberto Gomez >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > The current WanCopyRegionFunctionDelegate may cause significant memory issues > in with really large regions. > The > [getEntries|https://github.com/apache/geode/blob/develop/geode-wan/src/main/java/org/apache/geode/management/internal/cli/functions/WanCopyRegionFunctionDelegate.java#L102] > method returns both primary and redundant Region Entries for local server. > The invocation of getEntries from the PartitionedRegionDataStore will cause > all entries to be deserialized > https://github.com/apache/geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/PartitionedRegionDataStore.java#L2501-L2515 > The > [createBatch|https://github.com/apache/geode/blob/develop/geode-wan/src/main/java/org/apache/geode/management/internal/cli/functions/WanCopyRegionFunctionDelegate.java#L107-L108] > method creates a List equally that of the local Region > size. > Essentially ... In a system with VERY large regions this might cause > significant memory issues > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (GEODE-10155) ServerConnection thread hangs when client function execution times-out
Alberto Gomez created GEODE-10155: - Summary: ServerConnection thread hangs when client function execution times-out Key: GEODE-10155 URL: https://issues.apache.org/jira/browse/GEODE-10155 Project: Geode Issue Type: Bug Components: core, functions Reporter: Alberto Gomez If a Geode client executes a server function with a timeout and the function is handled in the Geode server by a "Function Execution Processor" thread (for example by calling the function with onRegion() on a partitioned region without a filter) and the function times-out before the server has answered back with all the results then the ServerConnection thread that originally started to handle the function execution will be stuck forever. If this happens several times and the max-threads parameters is set to a value greater than 0, the server will eventually run out of ServerConnection threads and will not be able to process more client requests. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (GEODE-10155) ServerConnection thread hangs when client function execution times-out
[ https://issues.apache.org/jira/browse/GEODE-10155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alberto Gomez reassigned GEODE-10155: - Assignee: Alberto Gomez > ServerConnection thread hangs when client function execution times-out > -- > > Key: GEODE-10155 > URL: https://issues.apache.org/jira/browse/GEODE-10155 > Project: Geode > Issue Type: Bug > Components: core, functions >Reporter: Alberto Gomez >Assignee: Alberto Gomez >Priority: Major > Labels: needsTriage > > If a Geode client executes a server function with a timeout > and > the function is handled in the Geode server by a "Function Execution > Processor" thread (for example by calling the function with onRegion() on a > partitioned region without a filter) > and > the function times-out before the server has answered back with all the > results > then > the ServerConnection thread that originally started to handle the function > execution will be stuck forever. > > If this happens several times and the max-threads parameters is set to a > value greater than 0, the server will eventually run out of ServerConnection > threads and will not be able to process more client requests. > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (GEODE-10300) C++ Native client messages coming from the locator cannot be longer than 3000 bytes
Alberto Gomez created GEODE-10300: - Summary: C++ Native client messages coming from the locator cannot be longer than 3000 bytes Key: GEODE-10300 URL: https://issues.apache.org/jira/browse/GEODE-10300 Project: Geode Issue Type: Bug Components: native client Reporter: Alberto Gomez If a locator sends a response to the C++ native client that is longer than 3000 bytes the C++ native client library will only pass to the client the first 3000 bytes. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Assigned] (GEODE-10300) C++ Native client messages coming from the locator cannot be longer than 3000 bytes
[ https://issues.apache.org/jira/browse/GEODE-10300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alberto Gomez reassigned GEODE-10300: - Assignee: Alberto Gomez > C++ Native client messages coming from the locator cannot be longer than 3000 > bytes > --- > > Key: GEODE-10300 > URL: https://issues.apache.org/jira/browse/GEODE-10300 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Alberto Gomez >Assignee: Alberto Gomez >Priority: Major > Labels: needsTriage > > If a locator sends a response to the C++ native client that is longer than > 3000 bytes the C++ native client library will only pass to the client the > first 3000 bytes. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-10300) C++ Native client messages coming from the locator cannot be longer than 3000 bytes
[ https://issues.apache.org/jira/browse/GEODE-10300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alberto Gomez updated GEODE-10300: -- Description: If a locator sends a response to the C++ native client that is longer than 3000 bytes the C++ native client library will only read the first 3000 bytes. (was: If a locator sends a response to the C++ native client that is longer than 3000 bytes the C++ native client library will only pass to the client the first 3000 bytes.) > C++ Native client messages coming from the locator cannot be longer than 3000 > bytes > --- > > Key: GEODE-10300 > URL: https://issues.apache.org/jira/browse/GEODE-10300 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Alberto Gomez >Assignee: Alberto Gomez >Priority: Major > Labels: needsTriage > > If a locator sends a response to the C++ native client that is longer than > 3000 bytes the C++ native client library will only read the first 3000 bytes. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Created] (GEODE-7019) Idle connections are never closed by native C++ client library
Alberto Gomez created GEODE-7019: Summary: Idle connections are never closed by native C++ client library Key: GEODE-7019 URL: https://issues.apache.org/jira/browse/GEODE-7019 Project: Geode Issue Type: Bug Components: native client Reporter: Alberto Gomez The native client C++ library never closes idle connections even if idleTimeout is set to a low value. This has been observed on a C++ client that executes some operations on the Geode cluster (which provokes the creation of client to server connections), then stops to send any operation but all the previously opened the connections are never closed. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Assigned] (GEODE-7019) Idle connections are never closed by native C++ client library
[ https://issues.apache.org/jira/browse/GEODE-7019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alberto Gomez reassigned GEODE-7019: Assignee: Alberto Gomez > Idle connections are never closed by native C++ client library > -- > > Key: GEODE-7019 > URL: https://issues.apache.org/jira/browse/GEODE-7019 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Alberto Gomez >Assignee: Alberto Gomez >Priority: Major > > The native client C++ library never closes idle connections even if > idleTimeout is set to a low value. > This has been observed on a C++ client that executes some operations on the > Geode cluster (which provokes the creation of client to server connections), > then stops to send any operation but all the previously opened the > connections are never closed. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (GEODE-1730) Cleanup SmHelper, SharedLibrary, PureJavaMode classes
[ https://issues.apache.org/jira/browse/GEODE-1730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16896137#comment-16896137 ] Alberto Gomez commented on GEODE-1730: -- I have not seen the classes mentioned in the ticket in the Geode repo. Is this ticket still relevant? > Cleanup SmHelper, SharedLibrary, PureJavaMode classes > - > > Key: GEODE-1730 > URL: https://issues.apache.org/jira/browse/GEODE-1730 > Project: Geode > Issue Type: Improvement > Components: general >Reporter: Kirk Lund >Priority: Minor > Labels: starter > > These classes are for the GemFire native code which is not in Geode. There > are a couple of methods still used on these classes such as is64bit() which > could be moved to another class such as SystemUtils. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (GEODE-7019) Idle connections are never closed by native C++ client library
[ https://issues.apache.org/jira/browse/GEODE-7019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16897007#comment-16897007 ] Alberto Gomez commented on GEODE-7019: -- Hi Alexander! I have only observed this problem in versions 1.8 and 1.9 because those are the versions I have tested with. Can't tell you if the problem was also present in previous versions. Looking at the code, the bug has been there at least since the introduction of class ThinClientPoolDM. -Alberto > Idle connections are never closed by native C++ client library > -- > > Key: GEODE-7019 > URL: https://issues.apache.org/jira/browse/GEODE-7019 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Alberto Gomez >Assignee: Alberto Gomez >Priority: Major > Time Spent: 1h 40m > Remaining Estimate: 0h > > The native client C++ library never closes idle connections even if > idleTimeout is set to a low value. > This has been observed on a C++ client that executes some operations on the > Geode cluster (which provokes the creation of client to server connections), > then stops to send any operation but all the previously opened the > connections are never closed. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Assigned] (GEODE-7049) Add timeout parameter to Java native client Execution::execute() methods
[
https://issues.apache.org/jira/browse/GEODE-7049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alberto Gomez reassigned GEODE-7049:
Assignee: Alberto Gomez
> Add timeout parameter to Java native client Execution::execute() methods
> -
>
> Key: GEODE-7049
> URL: https://issues.apache.org/jira/browse/GEODE-7049
> Project: Geode
> Issue Type: Improvement
> Components: native client
>Reporter: Alberto Gomez
>Assignee: Alberto Gomez
>Priority: Major
>
> The Java native client only allows to set a timeout to functions by means of
> a system property (gemfire.CLIENT_FUNCTION_TIMEOUT) while the C++ and C#
> native client allow to pass a timeout parameter on a function invocation
> basis.
> It will be good to have the same functionality on the Java native client by
> means of having the following methods on the Execution interface:
>
> {code:java}
> ResultCollector execute(Function function, int timeoutMs) throws
> FunctionException;
> ResultCollector execute(String functionId, int timeoutMs) throws
> FunctionException;
> {code}
>
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Created] (GEODE-7049) Add timeout parameter to Java native client Execution::execute() methods
Alberto Gomez created GEODE-7049:
Summary: Add timeout parameter to Java native client
Execution::execute() methods
Key: GEODE-7049
URL: https://issues.apache.org/jira/browse/GEODE-7049
Project: Geode
Issue Type: Improvement
Components: native client
Reporter: Alberto Gomez
The Java native client only allows to set a timeout to functions by means of a
system property (gemfire.CLIENT_FUNCTION_TIMEOUT) while the C++ and C# native
client allow to pass a timeout parameter on a function invocation basis.
It will be good to have the same functionality on the Java native client by
means of having the following methods on the Execution interface:
{code:java}
ResultCollector execute(Function function, int timeoutMs) throws
FunctionException;
ResultCollector execute(String functionId, int timeoutMs) throws
FunctionException;
{code}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Updated] (GEODE-7049) Add timeout parameter to Java native client Execution::execute() methods
[
https://issues.apache.org/jira/browse/GEODE-7049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alberto Gomez updated GEODE-7049:
-
Description:
The Java native client only allows to set a timeout to functions by means of a
system property (gemfire.CLIENT_FUNCTION_TIMEOUT) while the C++ and C# native
clients allow to pass a timeout parameter on a function invocation basis.
It will be good to have the same functionality on the Java native client by
means of having the following methods on the Execution interface:
{code:java}
ResultCollector execute(Function function, int timeoutMs) throws
FunctionException;
ResultCollector execute(String functionId, int timeoutMs) throws
FunctionException;
{code}
was:
The Java native client only allows to set a timeout to functions by means of a
system property (gemfire.CLIENT_FUNCTION_TIMEOUT) while the C++ and C# native
client allow to pass a timeout parameter on a function invocation basis.
It will be good to have the same functionality on the Java native client by
means of having the following methods on the Execution interface:
{code:java}
ResultCollector execute(Function function, int timeoutMs) throws
FunctionException;
ResultCollector execute(String functionId, int timeoutMs) throws
FunctionException;
{code}
> Add timeout parameter to Java native client Execution::execute() methods
> -
>
> Key: GEODE-7049
> URL: https://issues.apache.org/jira/browse/GEODE-7049
> Project: Geode
> Issue Type: Improvement
> Components: native client
>Reporter: Alberto Gomez
>Assignee: Alberto Gomez
>Priority: Major
>
> The Java native client only allows to set a timeout to functions by means of
> a system property (gemfire.CLIENT_FUNCTION_TIMEOUT) while the C++ and C#
> native clients allow to pass a timeout parameter on a function invocation
> basis.
> It will be good to have the same functionality on the Java native client by
> means of having the following methods on the Execution interface:
>
> {code:java}
> ResultCollector execute(Function function, int timeoutMs) throws
> FunctionException;
> ResultCollector execute(String functionId, int timeoutMs) throws
> FunctionException;
> {code}
>
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Updated] (GEODE-7049) Add timeout parameter to Java native client Execution::execute() methods
[
https://issues.apache.org/jira/browse/GEODE-7049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alberto Gomez updated GEODE-7049:
-
Description:
The Java native client only allows to set a timeout to functions by means of a
system property (gemfire.CLIENT_FUNCTION_TIMEOUT) while the C++ and C# native
clients allow to pass a timeout parameter on a function execution basis.
It will be good to have the same functionality on the Java native client by
means of having the following methods on the Execution interface:
{code:java}
ResultCollector execute(Function function, int timeoutMs) throws
FunctionException;
ResultCollector execute(String functionId, int timeoutMs) throws
FunctionException;
{code}
was:
The Java native client only allows to set a timeout to functions by means of a
system property (gemfire.CLIENT_FUNCTION_TIMEOUT) while the C++ and C# native
clients allow to pass a timeout parameter on a function invocation basis.
It will be good to have the same functionality on the Java native client by
means of having the following methods on the Execution interface:
{code:java}
ResultCollector execute(Function function, int timeoutMs) throws
FunctionException;
ResultCollector execute(String functionId, int timeoutMs) throws
FunctionException;
{code}
> Add timeout parameter to Java native client Execution::execute() methods
> -
>
> Key: GEODE-7049
> URL: https://issues.apache.org/jira/browse/GEODE-7049
> Project: Geode
> Issue Type: Improvement
> Components: native client
>Reporter: Alberto Gomez
>Assignee: Alberto Gomez
>Priority: Major
>
> The Java native client only allows to set a timeout to functions by means of
> a system property (gemfire.CLIENT_FUNCTION_TIMEOUT) while the C++ and C#
> native clients allow to pass a timeout parameter on a function execution
> basis.
> It will be good to have the same functionality on the Java native client by
> means of having the following methods on the Execution interface:
>
> {code:java}
> ResultCollector execute(Function function, int timeoutMs) throws
> FunctionException;
> ResultCollector execute(String functionId, int timeoutMs) throws
> FunctionException;
> {code}
>
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Created] (GEODE-7061) Under heavy load and many threads the C++ Native client may open lots of connections
Alberto Gomez created GEODE-7061: Summary: Under heavy load and many threads the C++ Native client may open lots of connections Key: GEODE-7061 URL: https://issues.apache.org/jira/browse/GEODE-7061 Project: Geode Issue Type: Bug Components: native client Reporter: Alberto Gomez Under heavy load and many threads (>30) the C++ Native client tends to open a lot of connections which, if the idleTimeout is not relatively small, could provoke client port exhaustion. The reason for this uncontrolled creation of connections is the implementation of the thread managing connections (ThinClientPoolDM::cleanStaleConnections()) that, in order to determine which connections to close due to timeout or load conditioning, gets all the connections from the pool for some time. Threads requiring a connection when this operation is fired, will create new connections while the maximum is not reached. The proposed solution consists of changing the implementation of the cleanStaleConnections so that it does not get all the connections at some point but instead, takes one at a time in order to determine if it should close it. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Assigned] (GEODE-7061) Under heavy load and many threads the C++ Native client may open lots of connections
[ https://issues.apache.org/jira/browse/GEODE-7061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alberto Gomez reassigned GEODE-7061: Assignee: Alberto Gomez > Under heavy load and many threads the C++ Native client may open lots of > connections > > > Key: GEODE-7061 > URL: https://issues.apache.org/jira/browse/GEODE-7061 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Alberto Gomez >Assignee: Alberto Gomez >Priority: Major > > Under heavy load and many threads (>30) the C++ Native client tends to open a > lot of connections which, if the idleTimeout is not relatively small, could > provoke client port exhaustion. > The reason for this uncontrolled creation of connections is the > implementation of the thread managing connections > (ThinClientPoolDM::cleanStaleConnections()) that, in order to determine which > connections to close due to timeout or load conditioning, gets all the > connections from the pool for some time. Threads requiring a connection when > this operation is fired, will create new connections while the maximum is not > reached. > The proposed solution consists of changing the implementation of the > cleanStaleConnections so that it does not get all the connections at some > point but instead, takes one at a time in order to determine if it should > close it. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Updated] (GEODE-7061) Under heavy load and many threads the C++ Native client may open lots of connections
[ https://issues.apache.org/jira/browse/GEODE-7061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alberto Gomez updated GEODE-7061: - Description: Under heavy load and many threads (>30) the C++ Native client tends to open a lot of connections which, if the idleTimeout is not relatively small, could provoke client port exhaustion. The reason for this uncontrolled creation of connections is the implementation of the thread managing connections (ThinClientPoolDM::cleanStaleConnections()) that, in order to determine which connections to close due to timeout or load conditioning, gets all the connections from the pool for some time. Threads requiring a connection when this operation is fired, will create new connections while the maximum is not reached. The proposed solution consists of changing the implementation of the cleanStaleConnections so that it does not get all the connections from the pool at some point but instead, takes one at a time in order to determine if it should close it. was: Under heavy load and many threads (>30) the C++ Native client tends to open a lot of connections which, if the idleTimeout is not relatively small, could provoke client port exhaustion. The reason for this uncontrolled creation of connections is the implementation of the thread managing connections (ThinClientPoolDM::cleanStaleConnections()) that, in order to determine which connections to close due to timeout or load conditioning, gets all the connections from the pool for some time. Threads requiring a connection when this operation is fired, will create new connections while the maximum is not reached. The proposed solution consists of changing the implementation of the cleanStaleConnections so that it does not get all the connections at some point but instead, takes one at a time in order to determine if it should close it. > Under heavy load and many threads the C++ Native client may open lots of > connections > > > Key: GEODE-7061 > URL: https://issues.apache.org/jira/browse/GEODE-7061 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Alberto Gomez >Assignee: Alberto Gomez >Priority: Major > > Under heavy load and many threads (>30) the C++ Native client tends to open a > lot of connections which, if the idleTimeout is not relatively small, could > provoke client port exhaustion. > The reason for this uncontrolled creation of connections is the > implementation of the thread managing connections > (ThinClientPoolDM::cleanStaleConnections()) that, in order to determine which > connections to close due to timeout or load conditioning, gets all the > connections from the pool for some time. Threads requiring a connection when > this operation is fired, will create new connections while the maximum is not > reached. > The proposed solution consists of changing the implementation of the > cleanStaleConnections so that it does not get all the connections from the > pool at some point but instead, takes one at a time in order to determine if > it should close it. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Updated] (GEODE-7049) Add timeout parameter to Java client Execution::execute() methods
[
https://issues.apache.org/jira/browse/GEODE-7049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alberto Gomez updated GEODE-7049:
-
Description:
The Java client only allows to set a timeout to functions by means of a system
property (gemfire.CLIENT_FUNCTION_TIMEOUT) while the C++ and C# native clients
allow to pass a timeout parameter on a function execution basis.
It will be good to have the same functionality on the Java native client by
means of having the following methods on the Execution interface:
{code:java}
ResultCollector execute(Function function, int timeoutMs) throws
FunctionException;
ResultCollector execute(String functionId, int timeoutMs) throws
FunctionException;
{code}
was:
The Java native client only allows to set a timeout to functions by means of a
system property (gemfire.CLIENT_FUNCTION_TIMEOUT) while the C++ and C# native
clients allow to pass a timeout parameter on a function execution basis.
It will be good to have the same functionality on the Java native client by
means of having the following methods on the Execution interface:
{code:java}
ResultCollector execute(Function function, int timeoutMs) throws
FunctionException;
ResultCollector execute(String functionId, int timeoutMs) throws
FunctionException;
{code}
> Add timeout parameter to Java client Execution::execute() methods
> --
>
> Key: GEODE-7049
> URL: https://issues.apache.org/jira/browse/GEODE-7049
> Project: Geode
> Issue Type: Improvement
> Components: native client
>Reporter: Alberto Gomez
>Assignee: Alberto Gomez
>Priority: Major
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> The Java client only allows to set a timeout to functions by means of a
> system property (gemfire.CLIENT_FUNCTION_TIMEOUT) while the C++ and C# native
> clients allow to pass a timeout parameter on a function execution basis.
> It will be good to have the same functionality on the Java native client by
> means of having the following methods on the Execution interface:
>
> {code:java}
> ResultCollector execute(Function function, int timeoutMs) throws
> FunctionException;
> ResultCollector execute(String functionId, int timeoutMs) throws
> FunctionException;
> {code}
>
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Updated] (GEODE-7049) Add timeout parameter to Java client Execution::execute() methods
[
https://issues.apache.org/jira/browse/GEODE-7049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alberto Gomez updated GEODE-7049:
-
Summary: Add timeout parameter to Java client Execution::execute() methods
(was: Add timeout parameter to Java native client Execution::execute() methods
)
> Add timeout parameter to Java client Execution::execute() methods
> --
>
> Key: GEODE-7049
> URL: https://issues.apache.org/jira/browse/GEODE-7049
> Project: Geode
> Issue Type: Improvement
> Components: native client
>Reporter: Alberto Gomez
>Assignee: Alberto Gomez
>Priority: Major
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> The Java native client only allows to set a timeout to functions by means of
> a system property (gemfire.CLIENT_FUNCTION_TIMEOUT) while the C++ and C#
> native clients allow to pass a timeout parameter on a function execution
> basis.
> It will be good to have the same functionality on the Java native client by
> means of having the following methods on the Execution interface:
>
> {code:java}
> ResultCollector execute(Function function, int timeoutMs) throws
> FunctionException;
> ResultCollector execute(String functionId, int timeoutMs) throws
> FunctionException;
> {code}
>
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Created] (GEODE-7113) Rat error in geode-native CI due to missing header in ./packer/windows/install-doxygen.ps1 file
Alberto Gomez created GEODE-7113: Summary: 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 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.2#803003)
[jira] [Assigned] (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 ] Alberto Gomez reassigned GEODE-7113: Assignee: Alberto Gomez > 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 > 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.2#803003)
[jira] [Resolved] (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 ] Alberto Gomez resolved GEODE-7113. -- Resolution: Fixed > 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 > 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.2#803003)
[jira] [Resolved] (GEODE-7061) Under heavy load and many threads the C++ Native client may open lots of connections
[ https://issues.apache.org/jira/browse/GEODE-7061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alberto Gomez resolved GEODE-7061. -- Fix Version/s: 1.11.0 Resolution: Fixed > Under heavy load and many threads the C++ Native client may open lots of > connections > > > Key: GEODE-7061 > URL: https://issues.apache.org/jira/browse/GEODE-7061 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Alberto Gomez >Assignee: Alberto Gomez >Priority: Major > Fix For: 1.11.0 > > Time Spent: 50m > Remaining Estimate: 0h > > Under heavy load and many threads (>30) the C++ Native client tends to open a > lot of connections which, if the idleTimeout is not relatively small, could > provoke client port exhaustion. > The reason for this uncontrolled creation of connections is the > implementation of the thread managing connections > (ThinClientPoolDM::cleanStaleConnections()) that, in order to determine which > connections to close due to timeout or load conditioning, gets all the > connections from the pool for some time. Threads requiring a connection when > this operation is fired, will create new connections while the maximum is not > reached. > The proposed solution consists of changing the implementation of the > cleanStaleConnections so that it does not get all the connections from the > pool at some point but instead, takes one at a time in order to determine if > it should close it. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Updated] (GEODE-7049) Add timeout parameter to Java client Execution::execute() methods
[
https://issues.apache.org/jira/browse/GEODE-7049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alberto Gomez updated GEODE-7049:
-
Description:
The Java client only allows to set a timeout to functions by means of a system
property (gemfire.CLIENT_FUNCTION_TIMEOUT) while the C++ and C# native clients
allow to pass a timeout parameter on a function execution basis.
It will be good to have the same functionality on the Java client by means of
having the following methods on the Execution interface:
{code:java}
ResultCollector execute(Function function, int timeoutMs) throws
FunctionException;
ResultCollector execute(String functionId, int timeoutMs) throws
FunctionException;
{code}
was:
The Java client only allows to set a timeout to functions by means of a system
property (gemfire.CLIENT_FUNCTION_TIMEOUT) while the C++ and C# native clients
allow to pass a timeout parameter on a function execution basis.
It will be good to have the same functionality on the Java native client by
means of having the following methods on the Execution interface:
{code:java}
ResultCollector execute(Function function, int timeoutMs) throws
FunctionException;
ResultCollector execute(String functionId, int timeoutMs) throws
FunctionException;
{code}
> Add timeout parameter to Java client Execution::execute() methods
> --
>
> Key: GEODE-7049
> URL: https://issues.apache.org/jira/browse/GEODE-7049
> Project: Geode
> Issue Type: Improvement
> Components: native client
>Reporter: Alberto Gomez
>Assignee: Alberto Gomez
>Priority: Major
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> The Java client only allows to set a timeout to functions by means of a
> system property (gemfire.CLIENT_FUNCTION_TIMEOUT) while the C++ and C# native
> clients allow to pass a timeout parameter on a function execution basis.
> It will be good to have the same functionality on the Java client by means of
> having the following methods on the Execution interface:
>
> {code:java}
> ResultCollector execute(Function function, int timeoutMs) throws
> FunctionException;
> ResultCollector execute(String functionId, int timeoutMs) throws
> FunctionException;
> {code}
>
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (GEODE-7049) Add timeout parameter to Java client Execution::execute() methods
[
https://issues.apache.org/jira/browse/GEODE-7049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16935834#comment-16935834
]
Alberto Gomez commented on GEODE-7049:
--
The final scope of this ticket has been defined here:
https://cwiki.apache.org/confluence/display/GEODE/Improvements+on+client+Function+execution+API
> Add timeout parameter to Java client Execution::execute() methods
> --
>
> Key: GEODE-7049
> URL: https://issues.apache.org/jira/browse/GEODE-7049
> Project: Geode
> Issue Type: Improvement
> Components: native client
>Reporter: Alberto Gomez
>Assignee: Alberto Gomez
>Priority: Major
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> The Java client only allows to set a timeout to functions by means of a
> system property (gemfire.CLIENT_FUNCTION_TIMEOUT) while the C++ and C# native
> clients allow to pass a timeout parameter on a function execution basis.
> It will be good to have the same functionality on the Java client by means of
> having the following methods on the Execution interface:
>
> {code:java}
> ResultCollector execute(Function function, int timeoutMs) throws
> FunctionException;
> ResultCollector execute(String functionId, int timeoutMs) throws
> FunctionException;
> {code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (GEODE-7049) Add timeout parameter to Java client Execution::execute() methods
[
https://issues.apache.org/jira/browse/GEODE-7049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alberto Gomez resolved GEODE-7049.
--
Fix Version/s: 1.11.0
Resolution: Fixed
> Add timeout parameter to Java client Execution::execute() methods
> --
>
> Key: GEODE-7049
> URL: https://issues.apache.org/jira/browse/GEODE-7049
> Project: Geode
> Issue Type: Improvement
> Components: native client
>Reporter: Alberto Gomez
>Assignee: Alberto Gomez
>Priority: Major
> Fix For: 1.11.0
>
> Time Spent: 2h 50m
> Remaining Estimate: 0h
>
> The Java client only allows to set a timeout to functions by means of a
> system property (gemfire.CLIENT_FUNCTION_TIMEOUT) while the C++ and C# native
> clients allow to pass a timeout parameter on a function execution basis.
> It will be good to have the same functionality on the Java client by means of
> having the following methods on the Execution interface:
>
> {code:java}
> ResultCollector execute(Function function, int timeoutMs) throws
> FunctionException;
> ResultCollector execute(String functionId, int timeoutMs) throws
> FunctionException;
> {code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (GEODE-7049) Add timeout parameter to Java client Execution::execute() methods
[
https://issues.apache.org/jira/browse/GEODE-7049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alberto Gomez closed GEODE-7049.
> Add timeout parameter to Java client Execution::execute() methods
> --
>
> Key: GEODE-7049
> URL: https://issues.apache.org/jira/browse/GEODE-7049
> Project: Geode
> Issue Type: Improvement
> Components: native client
>Reporter: Alberto Gomez
>Assignee: Alberto Gomez
>Priority: Major
> Fix For: 1.11.0
>
> Time Spent: 2h 50m
> Remaining Estimate: 0h
>
> The Java client only allows to set a timeout to functions by means of a
> system property (gemfire.CLIENT_FUNCTION_TIMEOUT) while the C++ and C# native
> clients allow to pass a timeout parameter on a function execution basis.
> It will be good to have the same functionality on the Java client by means of
> having the following methods on the Execution interface:
>
> {code:java}
> ResultCollector execute(Function function, int timeoutMs) throws
> FunctionException;
> ResultCollector execute(String functionId, int timeoutMs) throws
> FunctionException;
> {code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-7049) Add timeout parameter to Java client Execution::execute() methods
[
https://issues.apache.org/jira/browse/GEODE-7049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alberto Gomez updated GEODE-7049:
-
Component/s: (was: native client)
functions
> Add timeout parameter to Java client Execution::execute() methods
> --
>
> Key: GEODE-7049
> URL: https://issues.apache.org/jira/browse/GEODE-7049
> Project: Geode
> Issue Type: Improvement
> Components: functions
>Reporter: Alberto Gomez
>Assignee: Alberto Gomez
>Priority: Major
> Fix For: 1.11.0
>
> Time Spent: 2h 50m
> Remaining Estimate: 0h
>
> The Java client only allows to set a timeout to functions by means of a
> system property (gemfire.CLIENT_FUNCTION_TIMEOUT) while the C++ and C# native
> clients allow to pass a timeout parameter on a function execution basis.
> It will be good to have the same functionality on the Java client by means of
> having the following methods on the Execution interface:
>
> {code:java}
> ResultCollector execute(Function function, int timeoutMs) throws
> FunctionException;
> ResultCollector execute(String functionId, int timeoutMs) throws
> FunctionException;
> {code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (GEODE-7249) GfshInitFileIntegrationTest needs to be rewritten
[ https://issues.apache.org/jira/browse/GEODE-7249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16941105#comment-16941105 ] Alberto Gomez edited comment on GEODE-7249 at 9/30/19 4:15 PM: --- Hi, Could you please give some more details about what is the problem? Is it only due to the fact that reflection is used? Thanks was (Author: alberto.gomez): Hi, Could you give some more details about what is the problem? Is it only due to the fact that reflection is used? Thanks > GfshInitFileIntegrationTest needs to be rewritten > - > > Key: GEODE-7249 > URL: https://issues.apache.org/jira/browse/GEODE-7249 > Project: Geode > Issue Type: Test > Components: gfsh, tests >Reporter: Kirk Lund >Priority: Major > Time Spent: 0.5h > Remaining Estimate: 0h > > GfshInitFileIntegrationTest fails intermittently and currently uses > reflection to alter values of static variables in Gfsh. > It needs to be disabled in CI until someone has the time and desire to > rewrite this test. > Please refactor Gfsh to be testable instead of using reflection or PowerMock. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7249) GfshInitFileIntegrationTest needs to be rewritten
[ https://issues.apache.org/jira/browse/GEODE-7249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16941105#comment-16941105 ] Alberto Gomez commented on GEODE-7249: -- Hi, Could you give some more details about what is the problem? Is it only due to the fact that reflection is used? Thanks > GfshInitFileIntegrationTest needs to be rewritten > - > > Key: GEODE-7249 > URL: https://issues.apache.org/jira/browse/GEODE-7249 > Project: Geode > Issue Type: Test > Components: gfsh, tests >Reporter: Kirk Lund >Priority: Major > Time Spent: 0.5h > Remaining Estimate: 0h > > GfshInitFileIntegrationTest fails intermittently and currently uses > reflection to alter values of static variables in Gfsh. > It needs to be disabled in CI until someone has the time and desire to > rewrite this test. > Please refactor Gfsh to be testable instead of using reflection or PowerMock. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-7287) Add test case for REST function invocation with a filter
Alberto Gomez created GEODE-7287: Summary: Add test case for REST function invocation with a filter Key: GEODE-7287 URL: https://issues.apache.org/jira/browse/GEODE-7287 Project: Geode Issue Type: Improvement Components: tests Reporter: Alberto Gomez Fix For: 1.11.0 There isn't an integration test for the REST function invocation in which a filter is passed. It would be nice to have one in the RestAccessControllerTest class. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-7287) Add test case for REST function invocation with a filter
[ https://issues.apache.org/jira/browse/GEODE-7287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alberto Gomez reassigned GEODE-7287: Assignee: Alberto Gomez > Add test case for REST function invocation with a filter > > > Key: GEODE-7287 > URL: https://issues.apache.org/jira/browse/GEODE-7287 > Project: Geode > Issue Type: Improvement > Components: tests >Reporter: Alberto Gomez >Assignee: Alberto Gomez >Priority: Major > Fix For: 1.11.0 > > > There isn't an integration test for the REST function invocation in which a > filter is passed. > It would be nice to have one in the RestAccessControllerTest class. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-7287) Add test case for REST function invocation with a filter
[ https://issues.apache.org/jira/browse/GEODE-7287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alberto Gomez resolved GEODE-7287. -- Resolution: Fixed > Add test case for REST function invocation with a filter > > > Key: GEODE-7287 > URL: https://issues.apache.org/jira/browse/GEODE-7287 > Project: Geode > Issue Type: Improvement > Components: tests >Reporter: Alberto Gomez >Assignee: Alberto Gomez >Priority: Major > Fix For: 1.11.0 > > Time Spent: 40m > Remaining Estimate: 0h > > There isn't an integration test for the REST function invocation in which a > filter is passed. > It would be nice to have one in the RestAccessControllerTest class. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-7157) SSLConfigurationFactory and SSLConfig are NOT Thread-safe!
[
https://issues.apache.org/jira/browse/GEODE-7157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alberto Gomez reassigned GEODE-7157:
Assignee: Alberto Gomez
> SSLConfigurationFactory and SSLConfig are NOT Thread-safe!
> --
>
> Key: GEODE-7157
> URL: https://issues.apache.org/jira/browse/GEODE-7157
> Project: Geode
> Issue Type: Bug
> Components: configuration, core, security
>Reporter: John Blum
>Assignee: Alberto Gomez
>Priority: Critical
> Labels: affects-spring
>
> {{SSLConfig}} is a "_shared_" object (if you carefully analyze the
> {{SSLConfigurationFactory}} class) and needs to be Thread-safe!!
> {{SSLConfigurationFactory}} does NOT properly guard all access points to the
> (once again) "_shared_" {{registeredSSLConfig}} {{Map}} instance.
> Furthermore, this class also uses an non-Thread-safe {{Map}} implementation
> for {{registeredSSLConfig}}, i.e. {{HashMap}}, to "cache" {{SSLConfig}}
> objects, which is "safe" iff "_all_" access to this "shared"
> {{registeredSSLConfig}} {{Map}} instance is "{{synchronized}}", which it
> isn't (!!) ... e.g. {{SSLConfigurationFactory.close()}}, which subsequently
> calls {{clearSSLConfigForAllComponents()}}, which "_clears_" the
> {{registeredSSLConfig}} {{Map}}. Because it is not properly protected, it is
> possible to see stale state, especially between tests!!!
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (GEODE-6971) Update CqAttributesFactory to be a fluid API
[
https://issues.apache.org/jira/browse/GEODE-6971?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alberto Gomez reassigned GEODE-6971:
Assignee: Alberto Gomez
> Update CqAttributesFactory to be a fluid API
>
>
> Key: GEODE-6971
> URL: https://issues.apache.org/jira/browse/GEODE-6971
> Project: Geode
> Issue Type: Improvement
> Components: core
>Reporter: Charlie Black
>Assignee: Alberto Gomez
>Priority: Major
>
> CQAttributes does not currently support fluid API (like ClientCacheFactory
> and ClientRegionFactory). In the ideal world, I'd like to do something like
> the following
> {{CqAttributes cqa = new CqAttributesFactory()}}{{ }}
> {{ .addCqListener(new SimpleCQListener())}}
> {{ .create();}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-6971) Update CqAttributesFactory to be a fluid API
[
https://issues.apache.org/jira/browse/GEODE-6971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16958863#comment-16958863
]
Alberto Gomez commented on GEODE-6971:
--
Unfortunately, changing the return type from void to CqAttributesFactory in the
addCqListener and initCqLIsteners methods breaks the backward compatibility of
Geode as it can be observed when running the following upgrade test:
org.apache.geode.security.ClientAuthorizationCQDUnitTest
The only way I can think of fixing this is creating new fluid versions of the
old methods with a different name. The old ones could be deprecated in the
future.
Is it worth it?
> Update CqAttributesFactory to be a fluid API
>
>
> Key: GEODE-6971
> URL: https://issues.apache.org/jira/browse/GEODE-6971
> Project: Geode
> Issue Type: Improvement
> Components: core
>Reporter: Charlie Black
>Assignee: Alberto Gomez
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> CQAttributes does not currently support fluid API (like ClientCacheFactory
> and ClientRegionFactory). In the ideal world, I'd like to do something like
> the following
> {{CqAttributes cqa = new CqAttributesFactory()}}{{ }}
> {{ .addCqListener(new SimpleCQListener())}}
> {{ .create();}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-7254) ServerOperationException While performing a remote put
[ https://issues.apache.org/jira/browse/GEODE-7254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16959515#comment-16959515 ] Alberto Gomez commented on GEODE-7254: -- Hi, According to the server logs the problem is that in one of your classes ( com.actuate.iserver.utils.cache.GeodeCacheClient), you are trying to connect to the distributed system by invoking ClientCacheFactory.create() but there already exists a connection to the distributed system, the one from the server. See [https://geode.apache.org/releases/latest/javadoc/org/apache/geode/distributed/DistributedSystem.html.|https://geode.apache.org/releases/latest/javadoc/org/apache/geode/distributed/DistributedSystem.html] What configuration are you using to connect to the distributed system? If the configuration used to connect to the distributed system you are using is very similar to the one of the server then you may not encounter the problem P.S. See below an excerpt from the server logs with the relevant information: "A connection to a distributed system already exists in this VM." [severe 2019/09/30 20:47:50.576 IST iHubCacheServerProcess_100.82.204.14 tid=0x53] Server connection from [identity(100.82.204.14(5296:loner):51773:b186be82,connection=1; port=51773] : Unexpected Error on server java.lang.ExceptionInInitializerError at com.actuate.iserver.utils.CachedUserProperties.(CachedUserProperties.java:33) ... Caused by: java.lang.IllegalStateException: A connection to a distributed system already exists in this VM. It has the following configuration: ack-severe-alert-threshold="0" ack-wait-threshold="15" ... at org.apache.geode.distributed.internal.InternalDistributedSystem.validateSameProperties(InternalDistributedSystem.java:2928) at org.apache.geode.distributed.DistributedSystem.connect(DistributedSystem.java:203) at org.apache.geode.cache.client.ClientCacheFactory.basicCreate(ClientCacheFactory.java:242) at org.apache.geode.cache.client.ClientCacheFactory.create(ClientCacheFactory.java:213) at com.actuate.iserver.server.GeodeCache.getCacheInstance(GeodeCache.java:93) at com.actuate.iserver.server.GeodeRegion.getRegionInstance(GeodeRegion.java:21) at com.actuate.iserver.utils.cache.GeodeCacheClient.(GeodeCacheClient.java:20) ... 56 more > ServerOperationException While performing a remote put > -- > > Key: GEODE-7254 > URL: https://issues.apache.org/jira/browse/GEODE-7254 > Project: Geode > Issue Type: Bug > Components: client/server, configuration, core >Affects Versions: 1.8.0 >Reporter: rajesh >Priority: Blocker > Attachments: iHubCacheLocatorProcess.log, iHubCacheServerProcess.log, > ihub.5296.RGOTETPF0T711Q.2019-09-30_20_44_40+0530.0.log, > meta-iHubCacheLocatorProcess-01.log, meta-iHubCacheServerProcess-02.log > > > Configuration: Locator and Server are running as different process using > peer to peer configuration. > while trying to insert a custom object in to a cache region using client > cache we are getting the following exception. > This occurs only when the Geode Locator/Server are started with log level set > to fine, finer, finest and all. > If the log level is set to severe, error, warning, info, config everything > works fine. > I am not sure if log level change has anything to do with put operation. I am > attaching the locator and server log files. > > Also we have recently upgraded the geode version from 1.1.0 to 1.8. we have > been using 1.1.0 for quite sometime without any major issues. upgraded to > 1.8 and no code changes were made but still getting this issue. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7157) SSLConfigurationFactory and SSLConfig are NOT Thread-safe!
[
https://issues.apache.org/jira/browse/GEODE-7157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16968159#comment-16968159
]
Alberto Gomez commented on GEODE-7157:
--
[~burcham] Thanks!
> SSLConfigurationFactory and SSLConfig are NOT Thread-safe!
> --
>
> Key: GEODE-7157
> URL: https://issues.apache.org/jira/browse/GEODE-7157
> Project: Geode
> Issue Type: Bug
> Components: configuration, core, security
>Reporter: John Blum
>Assignee: Alberto Gomez
>Priority: Critical
> Labels: affects-spring
> Time Spent: 3.5h
> Remaining Estimate: 0h
>
> {{SSLConfig}} is a "_shared_" object (if you carefully analyze the
> {{SSLConfigurationFactory}} class) and needs to be Thread-safe!!
> {{SSLConfigurationFactory}} does NOT properly guard all access points to the
> (once again) "_shared_" {{registeredSSLConfig}} {{Map}} instance.
> Furthermore, this class also uses an non-Thread-safe {{Map}} implementation
> for {{registeredSSLConfig}}, i.e. {{HashMap}}, to "cache" {{SSLConfig}}
> objects, which is "safe" iff "_all_" access to this "shared"
> {{registeredSSLConfig}} {{Map}} instance is "{{synchronized}}", which it
> isn't (!!) ... e.g. {{SSLConfigurationFactory.close()}}, which subsequently
> calls {{clearSSLConfigForAllComponents()}}, which "_clears_" the
> {{registeredSSLConfig}} {{Map}}. Because it is not properly protected, it is
> possible to see stale state, especially between tests!!!
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GEODE-7476) Memory leaks in C++ native client manifested when running integration tests
Alberto Gomez created GEODE-7476: Summary: Memory leaks in C++ native client manifested when running integration tests Key: GEODE-7476 URL: https://issues.apache.org/jira/browse/GEODE-7476 Project: Geode Issue Type: Bug Components: native client Reporter: Alberto Gomez When running the integration tests of the C++ native client under valgrind several memory leaks have been found. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-7476) Memory leaks in C++ native client manifested when running integration tests
[ https://issues.apache.org/jira/browse/GEODE-7476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alberto Gomez updated GEODE-7476: - Description: When running the integration tests of the C++ native client under valgrind several memory leaks have been found. See attached file with valgrind reports. was: When running the integration tests of the C++ native client under valgrind several memory leaks have been found. > Memory leaks in C++ native client manifested when running integration tests > --- > > Key: GEODE-7476 > URL: https://issues.apache.org/jira/browse/GEODE-7476 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Alberto Gomez >Priority: Major > Attachments: MemoryCheckerReports.tar.gz > > > When running the integration tests of the C++ native client under valgrind > several memory leaks have been found. > See attached file with valgrind reports. > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-7476) Memory leaks in C++ native client manifested when running integration tests
[ https://issues.apache.org/jira/browse/GEODE-7476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alberto Gomez updated GEODE-7476: - Attachment: MemoryCheckerReports.tar.gz > Memory leaks in C++ native client manifested when running integration tests > --- > > Key: GEODE-7476 > URL: https://issues.apache.org/jira/browse/GEODE-7476 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Alberto Gomez >Priority: Major > Attachments: MemoryCheckerReports.tar.gz > > > When running the integration tests of the C++ native client under valgrind > several memory leaks have been found. > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-7476) Memory leaks in C++ native client manifested when running integration tests
[ https://issues.apache.org/jira/browse/GEODE-7476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alberto Gomez reassigned GEODE-7476: Assignee: Alberto Gomez > Memory leaks in C++ native client manifested when running integration tests > --- > > Key: GEODE-7476 > URL: https://issues.apache.org/jira/browse/GEODE-7476 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Alberto Gomez >Assignee: Alberto Gomez >Priority: Major > Attachments: MemoryCheckerReports.tar.gz > > > When running the integration tests of the C++ native client under valgrind > several memory leaks have been found. > See attached file with valgrind reports. > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-7509) Memory leaks in C++ native client
Alberto Gomez created GEODE-7509: Summary: Memory leaks in C++ native client Key: GEODE-7509 URL: https://issues.apache.org/jira/browse/GEODE-7509 Project: Geode Issue Type: Bug Components: native client Reporter: Alberto Gomez There are some remaining memory leaks in the C++ client observed when running the integration tests under valgrind. This ticket tries to address the ones left by GEODE-7476. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-7534) Add to documentation how to access top level region data with bind parameters in the path expression (FROM)
Alberto Gomez created GEODE-7534: Summary: Add to documentation how to access top level region data with bind parameters in the path expression (FROM) Key: GEODE-7534 URL: https://issues.apache.org/jira/browse/GEODE-7534 Project: Geode Issue Type: Improvement Components: docs Reporter: Alberto Gomez When trying to create a query using bind parameters in the path expression (FROM) in order to select to level region data it is not obvious that in order for the expression to be correct, the bind parameter must be surrounded by parenthesis as in the following example: SELECT e.key FROM ($1).entrySet e WHERE e.value.name=$2" -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-7534) Add to documentation how to access top level region data with bind parameters in the path expression (FROM)
[ https://issues.apache.org/jira/browse/GEODE-7534?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alberto Gomez reassigned GEODE-7534: Assignee: Alberto Gomez > Add to documentation how to access top level region data with bind parameters > in the path expression (FROM) > --- > > Key: GEODE-7534 > URL: https://issues.apache.org/jira/browse/GEODE-7534 > Project: Geode > Issue Type: Improvement > Components: docs >Reporter: Alberto Gomez >Assignee: Alberto Gomez >Priority: Major > > When trying to create a query using bind parameters in the path expression > (FROM) in order to select to level region data it is not obvious that in > order for the expression to be correct, the bind parameter must be surrounded > by parenthesis as in the following example: > > SELECT e.key FROM ($1).entrySet e WHERE e.value.name=$2" -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-7476) Memory leaks in C++ native client manifested when running integration tests
[ https://issues.apache.org/jira/browse/GEODE-7476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alberto Gomez resolved GEODE-7476. -- Resolution: Fixed > Memory leaks in C++ native client manifested when running integration tests > --- > > Key: GEODE-7476 > URL: https://issues.apache.org/jira/browse/GEODE-7476 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Alberto Gomez >Assignee: Alberto Gomez >Priority: Major > Fix For: 1.12.0 > > Attachments: MemoryCheckerReports.tar.gz > > Time Spent: 4.5h > Remaining Estimate: 0h > > When running the integration tests of the C++ native client under valgrind > several memory leaks have been found. > See attached file with valgrind reports. > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-7476) Memory leaks in C++ native client manifested when running integration tests
[ https://issues.apache.org/jira/browse/GEODE-7476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alberto Gomez updated GEODE-7476: - Fix Version/s: 1.12.0 > Memory leaks in C++ native client manifested when running integration tests > --- > > Key: GEODE-7476 > URL: https://issues.apache.org/jira/browse/GEODE-7476 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Alberto Gomez >Assignee: Alberto Gomez >Priority: Major > Fix For: 1.12.0 > > Attachments: MemoryCheckerReports.tar.gz > > Time Spent: 4.5h > Remaining Estimate: 0h > > When running the integration tests of the C++ native client under valgrind > several memory leaks have been found. > See attached file with valgrind reports. > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-7534) Add to documentation how to access top level region data with bind parameters in the path expression (FROM)
[ https://issues.apache.org/jira/browse/GEODE-7534?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alberto Gomez updated GEODE-7534: - Fix Version/s: 1.12.0 > Add to documentation how to access top level region data with bind parameters > in the path expression (FROM) > --- > > Key: GEODE-7534 > URL: https://issues.apache.org/jira/browse/GEODE-7534 > Project: Geode > Issue Type: Improvement > Components: docs >Reporter: Alberto Gomez >Assignee: Alberto Gomez >Priority: Major > Fix For: 1.12.0 > > > When trying to create a query using bind parameters in the path expression > (FROM) in order to select to level region data it is not obvious that in > order for the expression to be correct, the bind parameter must be surrounded > by parenthesis as in the following example: > > SELECT e.key FROM ($1).entrySet e WHERE e.value.name=$2" -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-7509) Memory leaks in C++ native client
[ https://issues.apache.org/jira/browse/GEODE-7509?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alberto Gomez updated GEODE-7509: - Fix Version/s: 1.12.0 > Memory leaks in C++ native client > - > > Key: GEODE-7509 > URL: https://issues.apache.org/jira/browse/GEODE-7509 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Alberto Gomez >Assignee: Alberto Gomez >Priority: Major > Fix For: 1.12.0 > > Time Spent: 3h 20m > Remaining Estimate: 0h > > There are some remaining memory leaks in the C++ client observed when running > the integration tests under valgrind. > This ticket tries to address the ones left by GEODE-7476. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-7509) Memory leaks in C++ native client
[ https://issues.apache.org/jira/browse/GEODE-7509?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alberto Gomez resolved GEODE-7509. -- Resolution: Fixed > Memory leaks in C++ native client > - > > Key: GEODE-7509 > URL: https://issues.apache.org/jira/browse/GEODE-7509 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Alberto Gomez >Assignee: Alberto Gomez >Priority: Major > Fix For: 1.12.0 > > Time Spent: 3h 20m > Remaining Estimate: 0h > > There are some remaining memory leaks in the C++ client observed when running > the integration tests under valgrind. > This ticket tries to address the ones left by GEODE-7476. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7254) ServerOperationException While performing a remote put
[ https://issues.apache.org/jira/browse/GEODE-7254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16993274#comment-16993274 ] Alberto Gomez commented on GEODE-7254: -- Hi Rajesh, Can you try with a configuration to connect to the distributed system with ClientCacheFactory.create() with log level equal to fine,finer to be in line with the one of the server? It might be that difference between the server configuration and the one you are using to connect with ClientCacheFactory.create() the one provoking the error. BR, Alberto > ServerOperationException While performing a remote put > -- > > Key: GEODE-7254 > URL: https://issues.apache.org/jira/browse/GEODE-7254 > Project: Geode > Issue Type: Bug > Components: client/server, configuration, core >Affects Versions: 1.8.0 >Reporter: rajesh >Priority: Blocker > Attachments: iHubCacheLocatorProcess.log, iHubCacheServerProcess.log, > ihub.5296.RGOTETPF0T711Q.2019-09-30_20_44_40+0530.0.log, > meta-iHubCacheLocatorProcess-01.log, meta-iHubCacheServerProcess-02.log > > > Configuration: Locator and Server are running as different process using > peer to peer configuration. > while trying to insert a custom object in to a cache region using client > cache we are getting the following exception. > This occurs only when the Geode Locator/Server are started with log level set > to fine, finer, finest and all. > If the log level is set to severe, error, warning, info, config everything > works fine. > I am not sure if log level change has anything to do with put operation. I am > attaching the locator and server log files. > > Also we have recently upgraded the geode version from 1.1.0 to 1.8. we have > been using 1.1.0 for quite sometime without any major issues. upgraded to > 1.8 and no code changes were made but still getting this issue. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-7573) Issues with TrasactionIds managed by CacheTransactionManager in C++ native client
[ https://issues.apache.org/jira/browse/GEODE-7573?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alberto Gomez reassigned GEODE-7573: Assignee: Alberto Gomez > Issues with TrasactionIds managed by CacheTransactionManager in C++ native > client > - > > Key: GEODE-7573 > URL: https://issues.apache.org/jira/browse/GEODE-7573 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Alberto Gomez >Assignee: Alberto Gomez >Priority: Major > > There are several problems related to the TransactionIds managed by the > CacheTransactionManager class: > > On the one hand, according to the documentation, the > CacheTransactionManager::getTransactionId() returns null if no transaction is > associated to the thread but according to the signature of the method the > object returned is of type TransactionId&. Therefore, there is no possibility > to return true. The same applies to the > CacheTransactionManager::getTransactionId() method. > > If we go to the implementation classes, the following is observed: > If CacheTransactionManagerImpl::suspend() is invoked and there is no > transaction in progress a TransactionException is thrown. This must be > documented instead of the current information that states that a null pointer > is returned. > If CacheTransactionManagerImpl::getTransactionId() is invoked and there is no > transaction in progress what we get is a segmentation fault because the > TXState that should provide the TransactionId object is null. In my opinion > the code should be changed to throw an exception just as it is done when > suspend() is invoked and there is no transaction in progress. > > On the other hand, once a transaction has been commited, a valid > TransactionId reference returned previously by either suspend() or > getTransactionId() becomes invalid because the commit of the transaction > deletes the object (which is stored in the TXState that is destroyed at > commit). > Subsequent uses of the TransacionId once the transaction is commited like it > is done in the testThinClientTransactionsWithSticky integration test (for > example calling exists() or resume()) would access freed memory. > Unawareness of this may cause unexpected behavior in the client code and > should be avoided. Two alternatives are proposed: > * Document in the C++ API that TransactionId references returned by > CacheTransactionManager should not be used after the transaction is commited. > * Change the type of object returned/managed to a TransactionId shared > pointer. > The problem with the second approach is that it involves a change in the API > so the first alternative is the recommended one. > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-7573) Issues with TrasactionIds managed by CacheTransactionManager in C++ native client
Alberto Gomez created GEODE-7573: Summary: Issues with TrasactionIds managed by CacheTransactionManager in C++ native client Key: GEODE-7573 URL: https://issues.apache.org/jira/browse/GEODE-7573 Project: Geode Issue Type: Bug Components: native client Reporter: Alberto Gomez There are several problems related to the TransactionIds managed by the CacheTransactionManager class: On the one hand, according to the documentation, the CacheTransactionManager::getTransactionId() returns null if no transaction is associated to the thread but according to the signature of the method the object returned is of type TransactionId&. Therefore, there is no possibility to return true. The same applies to the CacheTransactionManager::getTransactionId() method. If we go to the implementation classes, the following is observed: If CacheTransactionManagerImpl::suspend() is invoked and there is no transaction in progress a TransactionException is thrown. This must be documented instead of the current information that states that a null pointer is returned. If CacheTransactionManagerImpl::getTransactionId() is invoked and there is no transaction in progress what we get is a segmentation fault because the TXState that should provide the TransactionId object is null. In my opinion the code should be changed to throw an exception just as it is done when suspend() is invoked and there is no transaction in progress. On the other hand, once a transaction has been commited, a valid TransactionId reference returned previously by either suspend() or getTransactionId() becomes invalid because the commit of the transaction deletes the object (which is stored in the TXState that is destroyed at commit). Subsequent uses of the TransacionId once the transaction is commited like it is done in the testThinClientTransactionsWithSticky integration test (for example calling exists() or resume()) would access freed memory. Unawareness of this may cause unexpected behavior in the client code and should be avoided. Two alternatives are proposed: * Document in the C++ API that TransactionId references returned by CacheTransactionManager should not be used after the transaction is commited. * Change the type of object returned/managed to a TransactionId shared pointer. The problem with the second approach is that it involves a change in the API so the first alternative is the recommended one. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-7573) Issues with TrasactionIds managed by CacheTransactionManager in C++ native client
[ https://issues.apache.org/jira/browse/GEODE-7573?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alberto Gomez updated GEODE-7573: - Description: There are several problems related to the TransactionIds managed by the CacheTransactionManager class: On the one hand, according to the documentation, the CacheTransactionManager::getTransactionId() returns null if no transaction is associated to the thread but according to the signature of the method the object returned is of type TransactionId&. Therefore, there is no possibility to return null. The same applies to the CacheTransactionManager::getTransactionId() method. If we go to the implementation classes, the following is observed: If CacheTransactionManagerImpl::suspend() is invoked and there is no transaction in progress a TransactionException is thrown. This must be documented instead of the current information that states that a null pointer is returned. If CacheTransactionManagerImpl::getTransactionId() is invoked and there is no transaction in progress what we get is a segmentation fault because the TXState that should provide the TransactionId object is null. In my opinion the code should be changed to throw an exception just as it is done when suspend() is invoked and there is no transaction in progress. On the other hand, once a transaction has been commited, a valid TransactionId reference returned previously by either suspend() or getTransactionId() becomes invalid because the commit of the transaction deletes the object (which is stored in the TXState that is destroyed at commit). Subsequent uses of the TransacionId once the transaction is commited like it is done in the testThinClientTransactionsWithSticky integration test (for example calling exists() or resume()) would access freed memory. Unawareness of this may cause unexpected behavior in the client code and should be avoided. Two alternatives are proposed: * Document in the C++ API that TransactionId references returned by CacheTransactionManager should not be used after the transaction is commited. * Change the type of object returned/managed to a TransactionId shared pointer. The problem with the second approach is that it involves a change in the API so the first alternative is the recommended one. was: There are several problems related to the TransactionIds managed by the CacheTransactionManager class: On the one hand, according to the documentation, the CacheTransactionManager::getTransactionId() returns null if no transaction is associated to the thread but according to the signature of the method the object returned is of type TransactionId&. Therefore, there is no possibility to return true. The same applies to the CacheTransactionManager::getTransactionId() method. If we go to the implementation classes, the following is observed: If CacheTransactionManagerImpl::suspend() is invoked and there is no transaction in progress a TransactionException is thrown. This must be documented instead of the current information that states that a null pointer is returned. If CacheTransactionManagerImpl::getTransactionId() is invoked and there is no transaction in progress what we get is a segmentation fault because the TXState that should provide the TransactionId object is null. In my opinion the code should be changed to throw an exception just as it is done when suspend() is invoked and there is no transaction in progress. On the other hand, once a transaction has been commited, a valid TransactionId reference returned previously by either suspend() or getTransactionId() becomes invalid because the commit of the transaction deletes the object (which is stored in the TXState that is destroyed at commit). Subsequent uses of the TransacionId once the transaction is commited like it is done in the testThinClientTransactionsWithSticky integration test (for example calling exists() or resume()) would access freed memory. Unawareness of this may cause unexpected behavior in the client code and should be avoided. Two alternatives are proposed: * Document in the C++ API that TransactionId references returned by CacheTransactionManager should not be used after the transaction is commited. * Change the type of object returned/managed to a TransactionId shared pointer. The problem with the second approach is that it involves a change in the API so the first alternative is the recommended one. > Issues with TrasactionIds managed by CacheTransactionManager in C++ native > client > - > > Key: GEODE-7573 > URL: https://issues.apache.org/jira/browse/GEODE-7573 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Alberto Gomez >Assignee: Alberto Gomez >
