[jira] [Resolved] (GEODE-7401) Use locator launcher to start a locator in a rule
[ https://issues.apache.org/jira/browse/GEODE-7401?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao resolved GEODE-7401. Fix Version/s: 1.11.0 Resolution: Fixed > Use locator launcher to start a locator in a rule > - > > Key: GEODE-7401 > URL: https://issues.apache.org/jira/browse/GEODE-7401 > Project: Geode > Issue Type: Improvement > Components: tests >Reporter: Jinmei Liao >Priority: Major > Fix For: 1.11.0 > > Time Spent: 1h > Remaining Estimate: 0h > > currently we have LocatorStartupRule that use internal api to create the > locator, sometimes the tests needs to get hold of the locatorLauncher to > verify certain state, would be nice to have a rule that would start the > locator using the locatorLauncher. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-7339) move "experimental" out of url
[ https://issues.apache.org/jira/browse/GEODE-7339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao resolved GEODE-7339. Fix Version/s: 1.11.0 Resolution: Fixed > move "experimental" out of url > -- > > Key: GEODE-7339 > URL: https://issues.apache.org/jira/browse/GEODE-7339 > Project: Geode > Issue Type: Improvement > Components: management, rest (admin) >Reporter: Gang Yan >Priority: Major > Fix For: 1.11.0 > > > # WHY > * reduce the migration cost of customers for future formal release > * encourage developer to use it > > # WHAT > * replace "experimental" with "v1" in the url > * update the documentation about url updates > * update the documentation to tag all the endpoint as experimental -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-7456) Extract DirectChannel out of GMSMembershipManager
[ https://issues.apache.org/jira/browse/GEODE-7456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Smith updated GEODE-7456: - Fix Version/s: 1.11.0 > Extract DirectChannel out of GMSMembershipManager > - > > Key: GEODE-7456 > URL: https://issues.apache.org/jira/browse/GEODE-7456 > Project: Geode > Issue Type: Sub-task > Components: membership >Reporter: Dan Smith >Assignee: Dan Smith >Priority: Major > Fix For: 1.11.0 > > Time Spent: 4h > Remaining Estimate: 0h > > The GMSMembershipManager class represents the core class of the membership > subsystem. However, it currently is also responsible for owning and > delagating `send` calls to the DirectChannel. > We should pull the DirectChannel related logic out of GMSMembershipManager > and move GMSMembershipManager back into the .gms package, indicating that is > part of the code to be moved to a future geode-membership module. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-7357) membership-timeout documentation is incorrect
[ https://issues.apache.org/jira/browse/GEODE-7357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Smith updated GEODE-7357: - Fix Version/s: 1.11.0 > membership-timeout documentation is incorrect > - > > Key: GEODE-7357 > URL: https://issues.apache.org/jira/browse/GEODE-7357 > Project: Geode > Issue Type: Bug > Components: docs, membership >Reporter: Dan Smith >Assignee: Dan Smith >Priority: Major > Fix For: 1.11.0 > > Time Spent: 20m > Remaining Estimate: 0h > > The description for membership-timeout on > https://geode.apache.org/docs/guide/110/reference/topics/gemfire_properties.html > is incorrect. > It describes the member-timeout behavior of an old version of the product, > before geode 1.0. > Based on this description, a user might assume that an unresponsive member > will be kicked out of the system only after 3*member-timeout milliseconds > have elapsed. That may have been true before geode 1.0, but the geode has a > different failure detection algorithm which will remove members after a > minimum of 2*member-timeout milliseconds -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-7177) Move membership's logging dependencies to its own module
[ https://issues.apache.org/jira/browse/GEODE-7177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Smith updated GEODE-7177: - Fix Version/s: 1.11.0 > Move membership's logging dependencies to its own module > > > Key: GEODE-7177 > URL: https://issues.apache.org/jira/browse/GEODE-7177 > Project: Geode > Issue Type: Improvement > Components: logging, membership >Reporter: Ryan McMahon >Assignee: Dan Smith >Priority: Major > Fix For: 1.11.0 > > Time Spent: 6.5h > Remaining Estimate: 0h > > As part of eliminating membership's dependency on geode-core, we want to move > LogService and some other supporting classes to its own module which > membership can depend on. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-7326) Add cache gets timers
[ https://issues.apache.org/jira/browse/GEODE-7326?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron Lindsey resolved GEODE-7326. -- Fix Version/s: 1.11.0 Resolution: Fixed > Add cache gets timers > - > > Key: GEODE-7326 > URL: https://issues.apache.org/jira/browse/GEODE-7326 > Project: Geode > Issue Type: Improvement >Reporter: Aaron Lindsey >Assignee: Aaron Lindsey >Priority: Major > Fix For: 1.11.0 > > Time Spent: 5h 10m > Remaining Estimate: 0h > > h3. Why > Users want to understand the performance of their operations within the > server. > h3. Acceptance Criteria > Type: timer > Name: geode.cache.gets > Tags: region, result=hit/miss > Lifecycle of meter: The hit/miss meter for each region is created when the > region is created. The meter(s) are removed when the region is > destroyed/closed. > Description for meter: The total time and count for GET requests from clients. > Thing to measure : A count and total time for GET operations that didn't > error, by this specific Server (1 or many cacheservers) in the geode cluster > from when the server receives the request to when it sends the response. > Business Rule for this measurement: This meter records any operation sent > through a CacheServer > h3. Scenarios > *Scenario: Java client hits* > Given a cluster with a Server1 and a Locator1 with time statistics enabled > When the oldest supported java client issues 5 get operations using the > region.get(key) command > Then a meter on Server1 exists such that: > - Meter Name = 'geode.cache.gets' > - Count = 5 > - Total Time = total time spent from received request to response to client > for these 5 requests > - Tag: region = region that the 'get' method was called against > - Tag: result=hit > *Scenario: Java client misses* > Given a cluster with a Server1 and a Locator1 with time statistics enabled > When the oldest supported java client issues 5 get operations where the user > is getting a key that doesn't exist in the region using the region.get(key) > command > Then a meter on Server1 exists such that: > - Meter Name = 'geode.cache.gets' > - Count = 5 > - Total Time = total time spent from received request to response to client > for these 5 requests > - Tag: region = region that the 'get' method was called against > - Tag: result=miss > *Scenario: Java client hits with time stats disabled* > Given a cluster with a Server1 and a Locator1 with time statistics disabled > When a java client issues a get operation using the region.get(key) command > where the key exists > Then a meter on Server1 exists such that: > - Meter Name = 'geode.cache.gets' > - Count = 1 > - Total Time = 0 > - Tag: region = region that the 'get' method was called against > - Tag: result=hit > *Scenario: Java client error response* > Given a cluster with a Server1 > And a RegionA exists with NO entry with a Key="1" > And the client is unauthorized for Key="1" > When the client issues a region.get(1) request > Then no meter on Server1 should exist like: > - Meter Name = 'geode.cache.gets' > - Tag: region = RegionA -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-7184) Add function execution timers
[ https://issues.apache.org/jira/browse/GEODE-7184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron Lindsey resolved GEODE-7184. -- Fix Version/s: 1.11.0 Resolution: Fixed > Add function execution timers > - > > Key: GEODE-7184 > URL: https://issues.apache.org/jira/browse/GEODE-7184 > Project: Geode > Issue Type: Improvement >Reporter: Aaron Lindsey >Assignee: Aaron Lindsey >Priority: Major > Fix For: 1.11.0 > > Time Spent: 5h 40m > Remaining Estimate: 0h > > Developers oftentimes deploy their own functions to the system to enable > decorator pattern for caching to add information to specific key/value pairs. > In doing so, they can introduce bottlenecks into the system where server-side > functions can cause issues or make things slower than intended. We want a way > that users can view functions that they create, and see what the average > execution time looks like. > * *Meter Type*: Timer > * *Name*: geode.function.executions > * *Description*: TBD > * *Tags*: , function (getId on function, if DNE present > getClass.getname of deployed function), succeeded (true/false) > h3. Acceptance Criteria > *Meter creation/deletion*: Create meter on function execution > *Measurement*: On an individual server, start the timer when a *USER* > function is invoked/executed, and stop the timer when the user function > completes OR errors. If it throws a Function Execution or another error then > the tag function.isSuccessful=false > Details on Functions and their execution: > [https://geode.apache.org/docs/guide/110/developing/function_exec/function_execution.html] > h3. Scenarios > *Scenario: The timers are created when the function is first executed* > Given a user executed a function with ID functionToTime on a cluster with 1 > locator/1 server > And functionToTime has not been executed previously > Then the server has the following timer: > - name: geode.function.executions > - tag: id = functionToTime > - tag: succeeded = true > - count > 1 > - totalTime >= 5,000,000,000ns > And the server has the following timer: > - name: geode.function.executions > - tag: id = functionToTime > - tag: succeeded = false > - count = 0 > - totalTime = 0 > *Scenario: Successful singular function execution (registered execution)* > Given a user registers a function with ID functionToTime (that waits for 5 > seconds) on a cluster with 1 locator/1 server > When functionToTime is triggered using gfsh command: "execute function > --id=functionToTime" > And the function completes without error > Then the server has the following timer: > - name: geode.function.executions > - tag: id = functionToTime > - tag: succeeded = true > - count = 1 > - totalTime >= 5,000,000,000ns > *Scenario: Successful singular function execution (unregistered execution)* > Given an unregistered function with ID functionToTime (that waits for 5 > seconds) exists > When triggered on a client using > "FunctionService.onServers(cache).execute(new FunctionToTime())" > And the function completes without error > Then the server has the following timer: > - name: geode.function.executions > - tag: id = functionToTime > - tag: succeeded = true > - count = 1 > - totalTime >= 5,000,000,000ns > *Scenario: Singular function execution with Any Exception* > Given an unregistered function with ID functionToTime (that waits for 5 > seconds) exists > When triggered on a client using > "FunctionService.onServers(cache).execute(new FunctionToTime())" > And the function exits with a Any exception error after running for 5 seconds > Then the server has the following timer: > - name: geode.function.executions > - tag: id = functionToTime > - tag: succeeded = false > - count = 1 > - totalTime >= 5,000,000,000ns > *Scenario: Function execution onRegion multi-server* > Given a cluster with 1 locator (named L1) as well as 2 servers (named S1,S2) > And a region called RR1 that is a replicate region > When a function execution is triggered against that replicate region using > "FunctionService.onRegion(regionRR1).execute(new FunctionToTime())" > Then one server has the following timer: > - name: geode.function.executions > - tag: id = functionToTime > - tag: succeeded = true > - count = 1 > - totalTime >= 5,000,000,000ns > And the other server has the following timer: > - name: geode.cache.function.executions > - tag: id = functionToTime > - tag: succeeded = true > - count = 0 > - totalTime = 0 > *Scenario: Function execution onRegion with partition region multiple times* > *Scenario: Function execution onRegion multi-server* > Given a cluster with 1 locator (named L1) as well as 2 servers (named S1,S2) > And a partition region called PR1 that only exists on S1 > When a function execution is triggered 10 times against that replicate region > using
[jira] [Updated] (GEODE-7164) IntelliJ IDEA 2019 error: the output path is not specified for modules
[ https://issues.apache.org/jira/browse/GEODE-7164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron Lindsey updated GEODE-7164: - Fix Version/s: 1.11.0 > IntelliJ IDEA 2019 error: the output path is not specified for modules > -- > > Key: GEODE-7164 > URL: https://issues.apache.org/jira/browse/GEODE-7164 > Project: Geode > Issue Type: Improvement >Reporter: Aaron Lindsey >Assignee: Aaron Lindsey >Priority: Major > Fix For: 1.11.0 > > Attachments: Screen Shot 2019-09-04 at 10.45.47 AM.png, Screen Shot > 2019-09-04 at 10.51.04 AM.png, image-2019-10-25-16-54-38-061.png > > Time Spent: 1h 20m > Remaining Estimate: 0h > > When delegating build/run actions to IntelliJ IDEA instead of Gradle, > IntelliJ IDEA 2019 fails to build geode with an error similar to the one > shown in the screenshot below: > !Screen Shot 2019-09-04 at 10.45.47 AM.png|width=370,height=298! > h4. Steps to Reproduce: > (Tested on IntelliJ IDEA CE versions 2019.1.4 and 2019.2.1) > # Make sure Gradle delegation is disabled for build/run > ** Instructions for 2019.1.4: > *** Go to Preferences | Build, Execution, Deployment | Build Tools | Gradle > | Runner > *** Make sure "Delegate build/run actions to Gradle" is unchecked > ** Instructions for 2019.2.1: > *** Go to Preferences | Build, Execution, Deployment | Build Tools | Gradle > *** Make sure "Build and Run using:" is set to "IntelliJ IDEA" > # Clone geode into an empty directory > # Follow the instructions > [here|https://github.com/apache/geode/blob/develop/BUILDING.md] to import and > build geode using IntelliJ IDEA > # Enable Gradle build/run delegation > ** Instructions for 2019.1.4: > *** Go to Preferences | Build, Execution, Deployment | Build Tools | Gradle > | Runner > *** Check "Delegate build/run actions to Gradle" > ** Instructions for 2019.2.1: > *** Go to Preferences | Build, Execution, Deployment | Build Tools | Gradle > *** Set "Build and Run using:" to "Gradle" > # Select "Build Project" from the Build menu to build geode > # After the build succeeds, revert the change from step 4 to switch back to > the IntelliJ build runner > # Repeat step 5 to build the project again > # The popup error message shown in the screenshot should show and IntelliJ > will not initiate the build -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-7375) Metrics acceptance tests fail due to use of default/hard-coded ports
[ https://issues.apache.org/jira/browse/GEODE-7375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dale Emery updated GEODE-7375: -- Fix Version/s: 1.11.0 > Metrics acceptance tests fail due to use of default/hard-coded ports > > > Key: GEODE-7375 > URL: https://issues.apache.org/jira/browse/GEODE-7375 > Project: Geode > Issue Type: Bug > Components: tests >Reporter: Dale Emery >Assignee: Dale Emery >Priority: Major > Fix For: 1.11.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Several metrics acceptance test classes fail consistently on Windows: > * RegionEntriesGaugeTest > * MemberTypeCommonTagsTest > These tests either use hard-coded ports or default ports for various > purposes. On Windows, the ports sometimes class between tests, causing bind > failures. > Other metrics acceptance test classes are vulnerable to similar failures. > Example CI failure: > [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/WindowsAcceptanceTestOpenJDK11/builds/974] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-5971) Refactor gfsh commands to extend SingleGfshCommand and return ResultModel
[ https://issues.apache.org/jira/browse/GEODE-5971?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Deppe updated GEODE-5971: -- Fix Version/s: 1.10.0 > Refactor gfsh commands to extend SingleGfshCommand and return ResultModel > - > > Key: GEODE-5971 > URL: https://issues.apache.org/jira/browse/GEODE-5971 > Project: Geode > Issue Type: Improvement > Components: gfsh >Reporter: Jens Deppe >Assignee: Jens Deppe >Priority: Major > Labels: pull-request-available > Fix For: 1.10.0 > > Time Spent: 41.5h > Remaining Estimate: 0h > > This list will eventually include the following commands: > - AlterAsyncEventQueueCommand > - AlterOfflineDiskStoreCommand > - AlterRegionCommand > - AlterRuntimeConfigCommand > - BackupDiskStoreCommand > - ChangeLogLevelCommand > - ClearDefinedIndexesCommand > - CloseDurableCQsCommand > - CloseDurableClientCommand > - CompactDiskStoreCommand > - CompactOfflineDiskStoreCommand > - ConnectCommand > - CountDurableCQEventsCommand > - CreateGatewaySenderCommand > - CreateRegionCommand > - DebugCommand > - DefineIndexCommand > - DeployCommand > - DescribeClientCommand > - DescribeConfigCommand > - DescribeConnectionCommand > - DescribeDiskStoreCommand > - DescribeJndiBindingCommand > - DescribeMemberCommand > - DescribeOfflineDiskStoreCommand > - DescribeRegionCommand > - DestroyAsyncEventQueueCommand > - DestroyFunctionCommand > - DestroyGatewaySenderCommand > - DestroyRegionCommand > - DisconnectCommand > - EchoCommand > - ExecuteFunctionCommand > - ExecuteScriptCommand > - ExitCommand > - ExportClusterConfigurationCommand > - ExportConfigCommand > - ExportDataCommand > - ExportLogsCommand > - ExportOfflineDiskStoreCommand > - ExportStackTraceCommand > - GCCommand > - GetCommand > - GfshHelpCommand > - GfshHintCommand > - HistoryCommand > - ImportClusterConfigurationCommand > - ImportDataCommand > - ListAsyncEventQueuesCommand > - ListClientCommand > - ListDeployedCommand > - ListDiskStoresCommand > - ListDurableClientCQsCommand > - ListFunctionCommand > - ListGatewayCommand > - ListIndexCommand > - ListJndiBindingCommand > - ListMembersCommand > - ListRegionCommand > - LoadBalanceGatewaySenderCommand > - LocateEntryCommand > - NetstatCommand > - PDXRenameCommand > - PauseGatewaySenderCommand > - PutCommand > - QueryCommand > - RebalanceCommand > - RemoveCommand > - ResumeGatewaySenderCommand > - RevokeMissingDiskStoreCommand > - SetVariableCommand > - ShCommand > - ShowDeadlockCommand > - ShowLogCommand > - ShowMetricsCommand > - ShowMissingDiskStoreCommand > - ShutdownCommand > - SleepCommand > - StartGatewayReceiverCommand > - StartGatewaySenderCommand > - StartLocatorCommand > - StartServerCommand > - StatusClusterConfigServiceCommand > - StatusGatewayReceiverCommand > - StatusGatewaySenderCommand > - StopGatewayReceiverCommand > - StopGatewaySenderCommand > - UndeployCommand > - UpgradeOfflineDiskStoreCommand > - ValidateDiskStoreCommand > - VersionCommand > - StartJConsoleCommand > - StartJVisualVMCommand > - StartPulseCommand > - StartVsdCommand > - StatusLocatorCommand > - StatusServerCommand > - StopLocatorCommand > - StopServerCommand > - LuceneIndexCommands -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-5971) Refactor gfsh commands to extend SingleGfshCommand and return ResultModel
[ https://issues.apache.org/jira/browse/GEODE-5971?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Deppe resolved GEODE-5971. --- Resolution: Fixed > Refactor gfsh commands to extend SingleGfshCommand and return ResultModel > - > > Key: GEODE-5971 > URL: https://issues.apache.org/jira/browse/GEODE-5971 > Project: Geode > Issue Type: Improvement > Components: gfsh >Reporter: Jens Deppe >Assignee: Jens Deppe >Priority: Major > Labels: pull-request-available > Fix For: 1.10.0 > > Time Spent: 41.5h > Remaining Estimate: 0h > > This list will eventually include the following commands: > - AlterAsyncEventQueueCommand > - AlterOfflineDiskStoreCommand > - AlterRegionCommand > - AlterRuntimeConfigCommand > - BackupDiskStoreCommand > - ChangeLogLevelCommand > - ClearDefinedIndexesCommand > - CloseDurableCQsCommand > - CloseDurableClientCommand > - CompactDiskStoreCommand > - CompactOfflineDiskStoreCommand > - ConnectCommand > - CountDurableCQEventsCommand > - CreateGatewaySenderCommand > - CreateRegionCommand > - DebugCommand > - DefineIndexCommand > - DeployCommand > - DescribeClientCommand > - DescribeConfigCommand > - DescribeConnectionCommand > - DescribeDiskStoreCommand > - DescribeJndiBindingCommand > - DescribeMemberCommand > - DescribeOfflineDiskStoreCommand > - DescribeRegionCommand > - DestroyAsyncEventQueueCommand > - DestroyFunctionCommand > - DestroyGatewaySenderCommand > - DestroyRegionCommand > - DisconnectCommand > - EchoCommand > - ExecuteFunctionCommand > - ExecuteScriptCommand > - ExitCommand > - ExportClusterConfigurationCommand > - ExportConfigCommand > - ExportDataCommand > - ExportLogsCommand > - ExportOfflineDiskStoreCommand > - ExportStackTraceCommand > - GCCommand > - GetCommand > - GfshHelpCommand > - GfshHintCommand > - HistoryCommand > - ImportClusterConfigurationCommand > - ImportDataCommand > - ListAsyncEventQueuesCommand > - ListClientCommand > - ListDeployedCommand > - ListDiskStoresCommand > - ListDurableClientCQsCommand > - ListFunctionCommand > - ListGatewayCommand > - ListIndexCommand > - ListJndiBindingCommand > - ListMembersCommand > - ListRegionCommand > - LoadBalanceGatewaySenderCommand > - LocateEntryCommand > - NetstatCommand > - PDXRenameCommand > - PauseGatewaySenderCommand > - PutCommand > - QueryCommand > - RebalanceCommand > - RemoveCommand > - ResumeGatewaySenderCommand > - RevokeMissingDiskStoreCommand > - SetVariableCommand > - ShCommand > - ShowDeadlockCommand > - ShowLogCommand > - ShowMetricsCommand > - ShowMissingDiskStoreCommand > - ShutdownCommand > - SleepCommand > - StartGatewayReceiverCommand > - StartGatewaySenderCommand > - StartLocatorCommand > - StartServerCommand > - StatusClusterConfigServiceCommand > - StatusGatewayReceiverCommand > - StatusGatewaySenderCommand > - StopGatewayReceiverCommand > - StopGatewaySenderCommand > - UndeployCommand > - UpgradeOfflineDiskStoreCommand > - ValidateDiskStoreCommand > - VersionCommand > - StartJConsoleCommand > - StartJVisualVMCommand > - StartPulseCommand > - StartVsdCommand > - StatusLocatorCommand > - StatusServerCommand > - StopLocatorCommand > - StopServerCommand > - LuceneIndexCommands -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (GEODE-5971) Refactor gfsh commands to extend SingleGfshCommand and return ResultModel
[ https://issues.apache.org/jira/browse/GEODE-5971?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Deppe closed GEODE-5971. - > Refactor gfsh commands to extend SingleGfshCommand and return ResultModel > - > > Key: GEODE-5971 > URL: https://issues.apache.org/jira/browse/GEODE-5971 > Project: Geode > Issue Type: Improvement > Components: gfsh >Reporter: Jens Deppe >Assignee: Jens Deppe >Priority: Major > Labels: pull-request-available > Fix For: 1.10.0 > > Time Spent: 41.5h > Remaining Estimate: 0h > > This list will eventually include the following commands: > - AlterAsyncEventQueueCommand > - AlterOfflineDiskStoreCommand > - AlterRegionCommand > - AlterRuntimeConfigCommand > - BackupDiskStoreCommand > - ChangeLogLevelCommand > - ClearDefinedIndexesCommand > - CloseDurableCQsCommand > - CloseDurableClientCommand > - CompactDiskStoreCommand > - CompactOfflineDiskStoreCommand > - ConnectCommand > - CountDurableCQEventsCommand > - CreateGatewaySenderCommand > - CreateRegionCommand > - DebugCommand > - DefineIndexCommand > - DeployCommand > - DescribeClientCommand > - DescribeConfigCommand > - DescribeConnectionCommand > - DescribeDiskStoreCommand > - DescribeJndiBindingCommand > - DescribeMemberCommand > - DescribeOfflineDiskStoreCommand > - DescribeRegionCommand > - DestroyAsyncEventQueueCommand > - DestroyFunctionCommand > - DestroyGatewaySenderCommand > - DestroyRegionCommand > - DisconnectCommand > - EchoCommand > - ExecuteFunctionCommand > - ExecuteScriptCommand > - ExitCommand > - ExportClusterConfigurationCommand > - ExportConfigCommand > - ExportDataCommand > - ExportLogsCommand > - ExportOfflineDiskStoreCommand > - ExportStackTraceCommand > - GCCommand > - GetCommand > - GfshHelpCommand > - GfshHintCommand > - HistoryCommand > - ImportClusterConfigurationCommand > - ImportDataCommand > - ListAsyncEventQueuesCommand > - ListClientCommand > - ListDeployedCommand > - ListDiskStoresCommand > - ListDurableClientCQsCommand > - ListFunctionCommand > - ListGatewayCommand > - ListIndexCommand > - ListJndiBindingCommand > - ListMembersCommand > - ListRegionCommand > - LoadBalanceGatewaySenderCommand > - LocateEntryCommand > - NetstatCommand > - PDXRenameCommand > - PauseGatewaySenderCommand > - PutCommand > - QueryCommand > - RebalanceCommand > - RemoveCommand > - ResumeGatewaySenderCommand > - RevokeMissingDiskStoreCommand > - SetVariableCommand > - ShCommand > - ShowDeadlockCommand > - ShowLogCommand > - ShowMetricsCommand > - ShowMissingDiskStoreCommand > - ShutdownCommand > - SleepCommand > - StartGatewayReceiverCommand > - StartGatewaySenderCommand > - StartLocatorCommand > - StartServerCommand > - StatusClusterConfigServiceCommand > - StatusGatewayReceiverCommand > - StatusGatewaySenderCommand > - StopGatewayReceiverCommand > - StopGatewaySenderCommand > - UndeployCommand > - UpgradeOfflineDiskStoreCommand > - ValidateDiskStoreCommand > - VersionCommand > - StartJConsoleCommand > - StartJVisualVMCommand > - StartPulseCommand > - StartVsdCommand > - StatusLocatorCommand > - StatusServerCommand > - StopLocatorCommand > - StopServerCommand > - LuceneIndexCommands -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-7363) Add member type the tags for meterics
[ https://issues.apache.org/jira/browse/GEODE-7363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dale Emery resolved GEODE-7363. --- Fix Version/s: 1.11.0 Resolution: Fixed > Add member type the tags for meterics > - > > Key: GEODE-7363 > URL: https://issues.apache.org/jira/browse/GEODE-7363 > Project: Geode > Issue Type: New Feature > Components: statistics >Reporter: Mark Hanson >Priority: Major > Fix For: 1.11.0 > > Time Spent: 20m > Remaining Estimate: 0h > > This would be good to tell the type of member that is providing the > information such as server, locator, embedded cache, or a server with an > embedded locator. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-7265) Avoid creating default locator VM when ClusterStartupRule is used
[ https://issues.apache.org/jira/browse/GEODE-7265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Deppe resolved GEODE-7265. --- Fix Version/s: 1.11.0 Resolution: Fixed > Avoid creating default locator VM when ClusterStartupRule is used > - > > Key: GEODE-7265 > URL: https://issues.apache.org/jira/browse/GEODE-7265 > Project: Geode > Issue Type: Improvement > Components: tests >Reporter: Jens Deppe >Assignee: Jens Deppe >Priority: Major > Fix For: 1.11.0 > > Time Spent: 10m > Remaining Estimate: 0h > > It's not needed, so why create it. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-7395) Add Micrometer to documentation
[ https://issues.apache.org/jira/browse/GEODE-7395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dick Cavender updated GEODE-7395: - Fix Version/s: 1.11.0 > Add Micrometer to documentation > --- > > Key: GEODE-7395 > URL: https://issues.apache.org/jira/browse/GEODE-7395 > Project: Geode > Issue Type: Improvement > Components: docs, statistics >Reporter: Nick Vallely >Assignee: Nick Vallely >Priority: Major > Labels: observability > Fix For: 1.11.0 > > Time Spent: 3h > Remaining Estimate: 0h > > As of 1.9 we added Micrometer as a way to publish metrics to external > monitoring systems. As of 1.10/1.11 we added metrics that would be emitted > out of a Meter Registry and documented everything in the Apache Geode wiki. > We need to formalize some of this functionality a little more with a section > on Micrometer in our docx. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-7304) Make publish-war and publish-java build scripts more consistent
[ https://issues.apache.org/jira/browse/GEODE-7304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Deppe resolved GEODE-7304. --- Resolution: Won't Fix > Make publish-war and publish-java build scripts more consistent > --- > > Key: GEODE-7304 > URL: https://issues.apache.org/jira/browse/GEODE-7304 > Project: Geode > Issue Type: Improvement > Components: build >Reporter: Jens Deppe >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-7393) Parameterize concourse team variable
[ https://issues.apache.org/jira/browse/GEODE-7393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Houghton resolved GEODE-7393. Fix Version/s: 1.12.0 Resolution: Fixed > Parameterize concourse team variable > > > Key: GEODE-7393 > URL: https://issues.apache.org/jira/browse/GEODE-7393 > Project: Geode > Issue Type: Improvement > Components: ci >Reporter: Bala Tripura Sundari Kaza Venkata >Priority: Trivial > Fix For: 1.12.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Geode needs 'CONCOURSE_TEAM' in meta.properties > This would allow us to override the pipeline groupings. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-7392) Add tag indicating the commit under test to heavy lifters
[ https://issues.apache.org/jira/browse/GEODE-7392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dick Cavender updated GEODE-7392: - Fix Version/s: 1.11.0 > Add tag indicating the commit under test to heavy lifters > - > > Key: GEODE-7392 > URL: https://issues.apache.org/jira/browse/GEODE-7392 > Project: Geode > Issue Type: Improvement > Components: ci >Reporter: Sean Goller >Assignee: Sean Goller >Priority: Major > Fix For: 1.11.0 > > Time Spent: 50m > Remaining Estimate: 0h > > Currently heavy lifter instances are tagged with information about the build > in concourse it was launched by. In order to facilitate forensics from > metrics, tag the instance with the commit under test. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-7185) Use proper Gradle configuration for new serialization module
[ https://issues.apache.org/jira/browse/GEODE-7185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Houghton resolved GEODE-7185. Fix Version/s: 1.11.0 Resolution: Fixed > Use proper Gradle configuration for new serialization module > > > Key: GEODE-7185 > URL: https://issues.apache.org/jira/browse/GEODE-7185 > Project: Geode > Issue Type: Improvement > Components: build >Reporter: Robert Houghton >Priority: Major > Fix For: 1.11.0 > > Time Spent: 10m > Remaining Estimate: 0h > > The geode-serialization module split from geode-core contains classes only > within the internal package. So the configuration of the dependency should be > implementation, not api. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-7171) Encapsulate metrics session responsibilities
[ https://issues.apache.org/jira/browse/GEODE-7171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dale Emery updated GEODE-7171: -- Fix Version/s: 1.11.0 > Encapsulate metrics session responsibilities > > > Key: GEODE-7171 > URL: https://issues.apache.org/jira/browse/GEODE-7171 > Project: Geode > Issue Type: Improvement > Components: statistics >Reporter: Dale Emery >Assignee: Dale Emery >Priority: Major > Fix For: 1.11.0 > > Time Spent: 3.5h > Remaining Estimate: 0h > > Too many parts of Geode are starting to know too much about the details of a > metrics session. We should encapsulate metrics session details and provide > appropriate methods to interact with the session. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-7367) Specify memory usage for Cargo test containers
[ https://issues.apache.org/jira/browse/GEODE-7367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dick Cavender updated GEODE-7367: - Fix Version/s: 1.11.0 > Specify memory usage for Cargo test containers > -- > > Key: GEODE-7367 > URL: https://issues.apache.org/jira/browse/GEODE-7367 > Project: Geode > Issue Type: Improvement > Components: tests >Reporter: Benjamin P Ross >Assignee: Benjamin P Ross >Priority: Major > Fix For: 1.11.0 > > Time Spent: 1h 50m > Remaining Estimate: 0h > > Currently the server container class used by cargo tests has no specification > for max and initial heap causing them to default to amounts much larger than > what our tests need. This has caused the Tomcat Cargo tests to use > significantly more memory than they need to and put additional stress on the > CI process. > We can fix this by specifying an appropriate amount of memory in the server > container's configuration object. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-7365) DistributedTest, AcceptanceTest timing out a lot
[ https://issues.apache.org/jira/browse/GEODE-7365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dick Cavender resolved GEODE-7365. -- Resolution: Abandoned > DistributedTest, AcceptanceTest timing out a lot > > > Key: GEODE-7365 > URL: https://issues.apache.org/jira/browse/GEODE-7365 > Project: Geode > Issue Type: Bug > Components: ci >Reporter: Owen Nichols >Assignee: Owen Nichols >Priority: Major > Time Spent: 1h 20m > Remaining Estimate: 0h > > examples: > [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/1231] > https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/AcceptanceTestOpenJDK11/builds/1214 > > no tests appear to be hung. probably just need to increase the timeout on > these jobs -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-7319) BucketRegionTest > invokeDestroyCallbacksDoesNotInvokeCallbacksIfPartitionedRegionIsNotInitialized FAILED
[ https://issues.apache.org/jira/browse/GEODE-7319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dick Cavender updated GEODE-7319: - Fix Version/s: 1.11.0 > BucketRegionTest > > invokeDestroyCallbacksDoesNotInvokeCallbacksIfPartitionedRegionIsNotInitialized > FAILED > - > > Key: GEODE-7319 > URL: https://issues.apache.org/jira/browse/GEODE-7319 > Project: Geode > Issue Type: Bug > Components: ci >Reporter: Mario Ivanac >Assignee: Mario Ivanac >Priority: Major > Labels: flaky, needs-review, pull-request-available > Fix For: 1.11.0 > > Time Spent: 2h > Remaining Estimate: 0h > > > > org.apache.geode.internal.cache.BucketRegionTest > > invokeDestroyCallbacksDoesNotInvokeCallbacksIfPartitionedRegionIsNotInitialized > FAILED > > java.lang.NullPointerException > > at > org.apache.geode.internal.cache.EntryEventImpl.(EntryEventImpl.java:343) > > at > org.apache.geode.internal.cache.EntryEventImpl.(EntryEventImpl.java:314) > > at > org.apache.geode.internal.cache.BucketRegion.createEventForPR(BucketRegion.java:1613) > > at > org.apache.geode.internal.cache.BucketRegion.invokeDestroyCallbacks(BucketRegion.java:1706) > > at > org.apache.geode.internal.cache.BucketRegionTest.invokeDestroyCallbacksDoesNotInvokeCallbacksIfPartitionedRegionIsNotInitialized(BucketRegionTest.java:459) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-7308) Upgrade Jetty from 9.4.12.v20180830 to 9.4.21.v20190926
[ https://issues.apache.org/jira/browse/GEODE-7308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dick Cavender updated GEODE-7308: - Fix Version/s: 1.11.0 > Upgrade Jetty from 9.4.12.v20180830 to 9.4.21.v20190926 > > > Key: GEODE-7308 > URL: https://issues.apache.org/jira/browse/GEODE-7308 > Project: Geode > Issue Type: Sub-task >Reporter: Mario Kevo >Assignee: Mario Kevo >Priority: Major > Fix For: 1.11.0 > > Time Spent: 50m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-7248) PersistentPartitionedRegionWithRedundancyDUnitTest > testGetDataDelayDueToRecoveryAfterServerShutdown failed
[ https://issues.apache.org/jira/browse/GEODE-7248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dick Cavender updated GEODE-7248: - Fix Version/s: 1.11.0 > PersistentPartitionedRegionWithRedundancyDUnitTest > > testGetDataDelayDueToRecoveryAfterServerShutdown failed > - > > Key: GEODE-7248 > URL: https://issues.apache.org/jira/browse/GEODE-7248 > Project: Geode > Issue Type: Bug > Components: tests >Reporter: Mark Hanson >Assignee: Mario Ivanac >Priority: Major > Labels: pull-request-available > Fix For: 1.11.0 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > org.apache.geode.internal.cache.partitioned.PersistentPartitionedRegionWithRedundancyDUnitTest > > testGetDataDelayDueToRecoveryAfterServerShutdown FAILED > org.apache.geode.test.dunit.RMIException: While invoking > org.apache.geode.internal.cache.partitioned.PersistentPartitionedRegionWithRedundancyDUnitTest$$Lambda$39/1370067059.run > in VM 0 running on Host c1e0b1808326 with 4 VMs > at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:579) > at org.apache.geode.test.dunit.VM.invoke(VM.java:406) > at > org.apache.geode.internal.cache.partitioned.PersistentPartitionedRegionWithRedundancyDUnitTest.testGetDataDelayDueToRecoveryAfterServerShutdown(PersistentPartitionedRegionWithRedundancyDUnitTest.java:165) > Caused by: > java.lang.AssertionError: Delayed get 236, for key: 7831 > at org.junit.Assert.fail(Assert.java:88) > at > org.apache.geode.internal.cache.partitioned.PersistentPartitionedRegionWithRedundancyDUnitTest.lambda$testGetDataDelayDueToRecoveryAfterServerShutdown$6441c1c0$2(PersistentPartitionedRegionWithRedundancyDUnitTest.java:176) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-7216) The ExportStackTraceCommand should include a timestamp similar to jstack
[
https://issues.apache.org/jira/browse/GEODE-7216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Barrett Oglesby updated GEODE-7216:
---
Fix Version/s: 1.11.0
> The ExportStackTraceCommand should include a timestamp similar to jstack
>
>
> Key: GEODE-7216
> URL: https://issues.apache.org/jira/browse/GEODE-7216
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Reporter: Barrett Oglesby
>Assignee: Mario Kevo
>Priority: Major
> Fix For: 1.11.0
>
> Time Spent: 4h
> Remaining Estimate: 0h
>
> Currently the ExportStackTraceCommand dumps stack traces with a head for each
> member like:
> {noformat}
> *** Stack-trace for member server3 ***
> {noformat}
> It would be nice for support purposes if it included a timestamp like:
> {noformat}
> *** Stack-trace for member server3 at 2019-09-16 10:39:57 ***
> {noformat}
> That'll help correlate stack traces with logs and stats.
> Something like:
> {noformat}
> ps.append(STACK_TRACE_FOR_MEMBER).append(entry.getKey()).append(" at ")
> .append(new SimpleDateFormat("-MM-dd HH:mm:ss").format(new
> Date())).append(" ***")
> .append(System.lineSeparator());
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (GEODE-7159) PoolManager.close(keepAlive) naively assumes all "registered" Pool objects are o.a.g.cache.client.internal.PoolImpl implementations!
[ https://issues.apache.org/jira/browse/GEODE-7159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Udo Kohlmeyer resolved GEODE-7159. -- Resolution: Fixed > PoolManager.close(keepAlive) naively assumes all "registered" Pool objects > are o.a.g.cache.client.internal.PoolImpl implementations! > > > Key: GEODE-7159 > URL: https://issues.apache.org/jira/browse/GEODE-7159 > Project: Geode > Issue Type: Bug > Components: client/server >Reporter: John Blum >Assignee: Udo Kohlmeyer >Priority: Major > Labels: affects-spring > Fix For: 1.11.0 > > Time Spent: 20m > Remaining Estimate: 0h > > This certainly does not work in a proper "Unit" Test with "mocked" > collaborators! -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-7531) PoolManagerImpl.unregister(:Pool) naively assumes all Pool object instances are PoolImpls
[
https://issues.apache.org/jira/browse/GEODE-7531?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Udo Kohlmeyer updated GEODE-7531:
-
Fix Version/s: 1.11.0
> PoolManagerImpl.unregister(:Pool) naively assumes all Pool object instances
> are PoolImpls
> -
>
> Key: GEODE-7531
> URL: https://issues.apache.org/jira/browse/GEODE-7531
> Project: Geode
> Issue Type: Bug
> Components: client/server
>Affects Versions: 1.10.0
> Environment: Apache Geode based applications on the JVM.
>Reporter: John Blum
>Assignee: Udo Kohlmeyer
>Priority: Blocker
> Fix For: 1.11.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> A recent
> [change|https://github.com/apache/geode/blob/rel/v1.10.0/geode-core/src/main/java/org/apache/geode/internal/cache/PoolManagerImpl.java#L169-L174]
> to the {{o.a.g.internal.cache.PoolManagerImpl}} class expects all
> {{o.a.g.cache.client.Pools}} registered with the
> {{o.a.g.cache.client.PoolManager}} to be
> {{o.a.g.cache.client.internal.PoolImp}} objects.
> This is certainly not going to be the case for Unit Tests that properly
> "mock" 1 or more {{Pool}} instances and additionally needs to register the
> mock {{Pool}} instances with the {{PoolManager}}. While the later may not be
> as common for application code, it is more certainly common, and in some
> cases necessary, for framework or tooling code.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (GEODE-7531) PoolManagerImpl.unregister(:Pool) naively assumes all Pool object instances are PoolImpls
[
https://issues.apache.org/jira/browse/GEODE-7531?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Udo Kohlmeyer resolved GEODE-7531.
--
Resolution: Fixed
> PoolManagerImpl.unregister(:Pool) naively assumes all Pool object instances
> are PoolImpls
> -
>
> Key: GEODE-7531
> URL: https://issues.apache.org/jira/browse/GEODE-7531
> Project: Geode
> Issue Type: Bug
> Components: client/server
>Affects Versions: 1.10.0
> Environment: Apache Geode based applications on the JVM.
>Reporter: John Blum
>Assignee: Udo Kohlmeyer
>Priority: Blocker
> Fix For: 1.11.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> A recent
> [change|https://github.com/apache/geode/blob/rel/v1.10.0/geode-core/src/main/java/org/apache/geode/internal/cache/PoolManagerImpl.java#L169-L174]
> to the {{o.a.g.internal.cache.PoolManagerImpl}} class expects all
> {{o.a.g.cache.client.Pools}} registered with the
> {{o.a.g.cache.client.PoolManager}} to be
> {{o.a.g.cache.client.internal.PoolImp}} objects.
> This is certainly not going to be the case for Unit Tests that properly
> "mock" 1 or more {{Pool}} instances and additionally needs to register the
> mock {{Pool}} instances with the {{PoolManager}}. While the later may not be
> as common for application code, it is more certainly common, and in some
> cases necessary, for framework or tooling code.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (GEODE-7233) add default Jq selector to the various management rest endpoint for client tool readability
[ https://issues.apache.org/jira/browse/GEODE-7233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao resolved GEODE-7233. Fix Version/s: 1.11.0 Resolution: Fixed > add default Jq selector to the various management rest endpoint for client > tool readability > --- > > Key: GEODE-7233 > URL: https://issues.apache.org/jira/browse/GEODE-7233 > Project: Geode > Issue Type: Improvement > Components: management >Reporter: Jinmei Liao >Assignee: Jinmei Liao >Priority: Major > Fix For: 1.11.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > each management v2 end point should provide a default jq selector to allow > client rest tools to display the result in a more readable format. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-7159) PoolManager.close(keepAlive) naively assumes all "registered" Pool objects are o.a.g.cache.client.internal.PoolImpl implementations!
[ https://issues.apache.org/jira/browse/GEODE-7159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Udo Kohlmeyer updated GEODE-7159: - Fix Version/s: 1.11.0 > PoolManager.close(keepAlive) naively assumes all "registered" Pool objects > are o.a.g.cache.client.internal.PoolImpl implementations! > > > Key: GEODE-7159 > URL: https://issues.apache.org/jira/browse/GEODE-7159 > Project: Geode > Issue Type: Bug > Components: client/server >Reporter: John Blum >Assignee: Udo Kohlmeyer >Priority: Major > Labels: affects-spring > Fix For: 1.11.0 > > Time Spent: 20m > Remaining Estimate: 0h > > This certainly does not work in a proper "Unit" Test with "mocked" > collaborators! -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7583) "status locator --name/--dir" is not working properly when locator ssl is enabled
[
https://issues.apache.org/jira/browse/GEODE-7583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17000474#comment-17000474
]
ASF subversion and git services commented on GEODE-7583:
Commit dac5b1cb0dc372bee3800a5eec7f56ea04565802 in geode's branch
refs/heads/develop from Jinmei Liao
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=dac5b1c ]
GEODE-7583: rule improvement for ssl support (#4499)
> "status locator --name/--dir" is not working properly when locator ssl is
> enabled
> -
>
> Key: GEODE-7583
> URL: https://issues.apache.org/jira/browse/GEODE-7583
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Affects Versions: 1.8.0, 1.9.0, 1.10.0, 1.11.0
>Reporter: Jinmei Liao
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> in 1.8:
> 1. start a locator with ssl enabled
> 2. "status locator --dir" or "status locator --name" would trigger such error
> messages in the locator log:
> {quote}[info 2019/12/16 08:57:39.958 PST locator
> tid=0x23] Exception in processing request from 10.118.20.75
> javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection?
> at
> sun.security.ssl.InputRecord.handleUnknownRecord(InputRecord.java:710)
> at sun.security.ssl.InputRecord.read(InputRecord.java:527)
> at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:975)
> at
> sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1367)
> at
> sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1395)
> at
> sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1379)
> at
> org.apache.geode.internal.net.SocketCreator.handshakeIfSocketIsSSL(SocketCreator.java:981)
> at
> org.apache.geode.distributed.internal.tcpserver.TcpServer.lambda$processRequest$0(TcpServer.java:346)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> {quote}
> In develop branch: the gfsh output would be a strange ClassCastException.
> It's definitely broken on develop
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-7108) GCMetricsBinders Leak memory
[ https://issues.apache.org/jira/browse/GEODE-7108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dale Emery updated GEODE-7108: -- Fix Version/s: 1.11.0 > GCMetricsBinders Leak memory > > > Key: GEODE-7108 > URL: https://issues.apache.org/jira/browse/GEODE-7108 > Project: Geode > Issue Type: Bug > Components: statistics >Reporter: Mark Hanson >Assignee: Dale Emery >Priority: Major > Fix For: 1.11.0 > > Time Spent: 4h 20m > Remaining Estimate: 0h > > The GCMetricsBinders are not being closed for metrics and are thus leaking > memory. > Adding a fix to ensure that the close happens. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-7186) Move HttpService implementation into its own module
[ https://issues.apache.org/jira/browse/GEODE-7186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Deppe resolved GEODE-7186. --- Fix Version/s: 1.11.0 Resolution: Fixed > Move HttpService implementation into its own module > --- > > Key: GEODE-7186 > URL: https://issues.apache.org/jira/browse/GEODE-7186 > Project: Geode > Issue Type: Improvement > Components: management, rest (admin), rest (dev) >Reporter: Jens Deppe >Assignee: Jens Deppe >Priority: Major > Fix For: 1.11.0 > > Time Spent: 1h 40m > Remaining Estimate: 0h > > This will provide a clearer separation for this service. When Geode is used > in a Spring Boot context, the presence of various transitive http-related > libraries may cause unwanted components to be started. > This should also pave the way for Geode to leverage the Spring Boot provided > containers instead of having to start and manage its own http service. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-7172) Add ArchUnit test to break TCPServer dependencies on geode-core
[ https://issues.apache.org/jira/browse/GEODE-7172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ernest Burghardt updated GEODE-7172: Fix Version/s: 1.11.0 > Add ArchUnit test to break TCPServer dependencies on geode-core > --- > > Key: GEODE-7172 > URL: https://issues.apache.org/jira/browse/GEODE-7172 > Project: Geode > Issue Type: Test > Components: membership, tests >Reporter: Ryan McMahon >Assignee: Ernest Burghardt >Priority: Major > Fix For: 1.11.0 > > Time Spent: 40m > Remaining Estimate: 0h > > We would like to shift responsibilities of running the TCPServer which > handles PeerRequestMessages from the Locator to the membership module. This > is a step towards being able to run membership tests in isolation from the > rest of geode-core. > A first step is to write an ArchUnit test which will highlight dependencies > from the tcpserver package to the rest of geode-core. After the test is > written, we can work through breaking all of the undesired dependencies. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7544) Break dependency on ClassPathLoader
[ https://issues.apache.org/jira/browse/GEODE-7544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17000463#comment-17000463 ] ASF subversion and git services commented on GEODE-7544: Commit a1f219de76178b314c5d7a0273b079ce9a88e6ce in geode's branch refs/heads/feature/GEODE-7544 from Bruce Schuchardt [ https://gitbox.apache.org/repos/asf?p=geode.git;h=a1f219d ] GEODE-7544 Break dependency on ClassPathLoader Look for the jgroups configuration file using regular class loaders instead of geode-core's ClassPathLoader. > Break dependency on ClassPathLoader > > > Key: GEODE-7544 > URL: https://issues.apache.org/jira/browse/GEODE-7544 > Project: Geode > Issue Type: Sub-task > Components: membership >Reporter: Ernest Burghardt >Assignee: Bruce J Schuchardt >Priority: Major > > JGroupsMessenger usage -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-7102) Convert tests that use fixed key/trust stores to use CertificateBuilder
[
https://issues.apache.org/jira/browse/GEODE-7102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jens Deppe resolved GEODE-7102.
---
Fix Version/s: 1.11.0
Resolution: Fixed
> Convert tests that use fixed key/trust stores to use CertificateBuilder
> ---
>
> Key: GEODE-7102
> URL: https://issues.apache.org/jira/browse/GEODE-7102
> Project: Geode
> Issue Type: Test
> Components: tests
>Reporter: Jens Deppe
>Assignee: Jens Deppe
>Priority: Major
> Fix For: 1.11.0
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> We now have the ability to create CAs and signed certificates in tests with a
> simple java api. Convert all tests that reference key and truststore files to
> use this java api - {{CertificateBuilder}} and {{CertStores}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (GEODE-7131) add bi-direction linkage to Region and index in REST API V2
[ https://issues.apache.org/jira/browse/GEODE-7131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao resolved GEODE-7131. Fix Version/s: 1.11.0 Resolution: Fixed > add bi-direction linkage to Region and index in REST API V2 > --- > > Key: GEODE-7131 > URL: https://issues.apache.org/jira/browse/GEODE-7131 > Project: Geode > Issue Type: Improvement > Components: management >Reporter: Gang Yan >Priority: Major > Fix For: 1.11.0 > > Time Spent: 7h > Remaining Estimate: 0h > > for region and index, they are related. > currently, in the output of json, the customers can not find the relation > between region and index. > > ### WHAT > # add the link of index to region , if the region has index > # add the link of region to index > for region: > in "config" part, add a link of "indexes: > /management/experimental/regionname/indexes" > for index: > in "config" part, add a link of "region: > /management/experimental/regionname" -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-7134) Reduce overhead of PartitionedRegion.executeOnBucketSet
[
https://issues.apache.org/jira/browse/GEODE-7134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dick Cavender updated GEODE-7134:
-
Fix Version/s: 1.11.0
> Reduce overhead of PartitionedRegion.executeOnBucketSet
> ---
>
> Key: GEODE-7134
> URL: https://issues.apache.org/jira/browse/GEODE-7134
> Project: Geode
> Issue Type: Improvement
> Components: functions, regions
>Reporter: Jacob Barrett
>Assignee: Mario Ivanac
>Priority: Major
> Labels: needs-review, performance, pull-request-available
> Fix For: 1.11.0
>
> Time Spent: 4h 10m
> Remaining Estimate: 0h
>
> {{PartitionedRegion.executeOnBucketSet}} spends 56% of function executions
> CPU time comparing and pruning bucket sets. It also accounts for 89% of the
> transient object allocation during function execution.
> Given that bucket sets are sets of integers let's look for a more suitable
> implementation of set operations on integers. Consider {{int[]}} as set of
> integers too reduce CPU and transient object allocations.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (GEODE-7544) Break dependency on ClassPathLoader
[ https://issues.apache.org/jira/browse/GEODE-7544?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bruce J Schuchardt reassigned GEODE-7544: - Assignee: Bruce J Schuchardt > Break dependency on ClassPathLoader > > > Key: GEODE-7544 > URL: https://issues.apache.org/jira/browse/GEODE-7544 > Project: Geode > Issue Type: Sub-task > Components: membership >Reporter: Ernest Burghardt >Assignee: Bruce J Schuchardt >Priority: Major > > JGroupsMessenger usage -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7606) Break dependency on InternalDataSerializer
[ https://issues.apache.org/jira/browse/GEODE-7606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17000440#comment-17000440 ] ASF subversion and git services commented on GEODE-7606: Commit 23e7106cdd56fa0ebf1d756a51a769981ba8e715 in geode's branch refs/heads/feature/GEODE-7606 from Bruce Schuchardt [ https://gitbox.apache.org/repos/asf?p=geode.git;h=23e7106 ] GEODE-7606 Break dependency on InternalDataSerializer Inject a serializer and deserializer into GMSLocator for use in reading and writing its persistent membership view. > Break dependency on InternalDataSerializer > -- > > Key: GEODE-7606 > URL: https://issues.apache.org/jira/browse/GEODE-7606 > Project: Geode > Issue Type: Improvement > Components: membership >Reporter: Bruce J Schuchardt >Assignee: Bruce J Schuchardt >Priority: Major > > Membership classes should use DSFIDSerializer to serialize/deserialize > objects. Currently GMSLocator and one of the GMSMember tests use > InternalDataSerializer for this purpose. The test can manufacture a > DSFIDSerializer and GMSLocator can use the serializer provided by its > TcpClient. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-7606) Break dependency on InternalDataSerializer
[ https://issues.apache.org/jira/browse/GEODE-7606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bruce J Schuchardt reassigned GEODE-7606: - Assignee: Bruce J Schuchardt > Break dependency on InternalDataSerializer > -- > > Key: GEODE-7606 > URL: https://issues.apache.org/jira/browse/GEODE-7606 > Project: Geode > Issue Type: Improvement > Components: membership >Reporter: Bruce J Schuchardt >Assignee: Bruce J Schuchardt >Priority: Major > > Membership classes should use DSFIDSerializer to serialize/deserialize > objects. Currently GMSLocator and one of the GMSMember tests use > InternalDataSerializer for this purpose. The test can manufacture a > DSFIDSerializer and GMSLocator can use the serializer provided by its > TcpClient. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-7606) Break dependency on InternalDataSerializer
Bruce J Schuchardt created GEODE-7606: - Summary: Break dependency on InternalDataSerializer Key: GEODE-7606 URL: https://issues.apache.org/jira/browse/GEODE-7606 Project: Geode Issue Type: Improvement Components: membership Reporter: Bruce J Schuchardt Membership classes should use DSFIDSerializer to serialize/deserialize objects. Currently GMSLocator and one of the GMSMember tests use InternalDataSerializer for this purpose. The test can manufacture a DSFIDSerializer and GMSLocator can use the serializer provided by its TcpClient. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-7551) Remove membership API dependency on ClusterDistributionManager
[ https://issues.apache.org/jira/browse/GEODE-7551?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bruce J Schuchardt resolved GEODE-7551. --- Fix Version/s: 1.12.0 Resolution: Fixed > Remove membership API dependency on ClusterDistributionManager > -- > > Key: GEODE-7551 > URL: https://issues.apache.org/jira/browse/GEODE-7551 > Project: Geode > Issue Type: Sub-task > Components: membership >Reporter: Bruce J Schuchardt >Assignee: Bruce J Schuchardt >Priority: Major > Fix For: 1.12.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > The membership API can't refer to ClusterDistributionManager if we're going > to create a membership module. It's used very little in the API and > implementation classes. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7589) Provide ability to have batch dispatch be time based instead of size based
[ https://issues.apache.org/jira/browse/GEODE-7589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17000399#comment-17000399 ] Jason Huynh commented on GEODE-7589: The problem with setting a large batch size is that we allocate that size for each batch, even if the expected number of events is low per time period. > Provide ability to have batch dispatch be time based instead of size based > -- > > Key: GEODE-7589 > URL: https://issues.apache.org/jira/browse/GEODE-7589 > Project: Geode > Issue Type: Improvement > Components: wan >Reporter: Jason Huynh >Assignee: Jason Huynh >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > It would be nice to be able to configure wan to dispatch batches at intervals > of time (time triggered) instead of batch size triggered. > Currently we have batchIntervalTime and batchSize. The wan will dispatch > when the size of batch matches batchSize OR when the time interval is hit. > We can provide the user the ability to set the batchSize to say -1 and only > trigger dispatch based on time and no longer on batch size. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-7556) Remove membership dependency on geode-core exception classes
[ https://issues.apache.org/jira/browse/GEODE-7556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bruce J Schuchardt resolved GEODE-7556. --- Fix Version/s: 1.12.0 Resolution: Fixed > Remove membership dependency on geode-core exception classes > > > Key: GEODE-7556 > URL: https://issues.apache.org/jira/browse/GEODE-7556 > Project: Geode > Issue Type: Improvement > Components: membership >Reporter: Bruce J Schuchardt >Assignee: Bruce J Schuchardt >Priority: Major > Fix For: 1.12.0 > > Time Spent: 10m > Remaining Estimate: 0h > > MembershipDependencyJUnitTest lists two dependency exceptions for geode-core > Throwable classes: GemFireException and InternalGemFireError. These should > be removed so that membership can be moved to a separate sub-project. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7556) Remove membership dependency on geode-core exception classes
[ https://issues.apache.org/jira/browse/GEODE-7556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17000358#comment-17000358 ] ASF subversion and git services commented on GEODE-7556: Commit a357e6d0d1e6eb6658e0e36900e3e1aaede77884 in geode's branch refs/heads/develop from Bruce Schuchardt [ https://gitbox.apache.org/repos/asf?p=geode.git;h=a357e6d ] GEODE-7556: remove membership dependencies on geode-core exeptions (#4502) * GEODE-7556: remove membership dependencies on geode-core exeptions Removed use of geode-core exceptions from membership. DistributionImpl now converts membership exceptions into geode-core exceptions where necessary. Except for MembershipClosedException the new membership exceptions are all checked exceptions. This let me isolate where the exceptions are used and ensure that they're changed into appropriate geode-core exceptions. MemberShunnedException is now in the membership module instead of the TcpConduit module. It, too, is a checked exception. CancelCriterion is also removed from use in the membership module. The Stopper in Services.java doesn't need to be a CancelCriterion to function properly. Several tests had to be modified to handle our stress-test environement. * use checkCancelled method > Remove membership dependency on geode-core exception classes > > > Key: GEODE-7556 > URL: https://issues.apache.org/jira/browse/GEODE-7556 > Project: Geode > Issue Type: Improvement > Components: membership >Reporter: Bruce J Schuchardt >Assignee: Bruce J Schuchardt >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > MembershipDependencyJUnitTest lists two dependency exceptions for geode-core > Throwable classes: GemFireException and InternalGemFireError. These should > be removed so that membership can be moved to a separate sub-project. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7556) Remove membership dependency on geode-core exception classes
[ https://issues.apache.org/jira/browse/GEODE-7556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17000359#comment-17000359 ] ASF subversion and git services commented on GEODE-7556: Commit a357e6d0d1e6eb6658e0e36900e3e1aaede77884 in geode's branch refs/heads/develop from Bruce Schuchardt [ https://gitbox.apache.org/repos/asf?p=geode.git;h=a357e6d ] GEODE-7556: remove membership dependencies on geode-core exeptions (#4502) * GEODE-7556: remove membership dependencies on geode-core exeptions Removed use of geode-core exceptions from membership. DistributionImpl now converts membership exceptions into geode-core exceptions where necessary. Except for MembershipClosedException the new membership exceptions are all checked exceptions. This let me isolate where the exceptions are used and ensure that they're changed into appropriate geode-core exceptions. MemberShunnedException is now in the membership module instead of the TcpConduit module. It, too, is a checked exception. CancelCriterion is also removed from use in the membership module. The Stopper in Services.java doesn't need to be a CancelCriterion to function properly. Several tests had to be modified to handle our stress-test environement. * use checkCancelled method > Remove membership dependency on geode-core exception classes > > > Key: GEODE-7556 > URL: https://issues.apache.org/jira/browse/GEODE-7556 > Project: Geode > Issue Type: Improvement > Components: membership >Reporter: Bruce J Schuchardt >Assignee: Bruce J Schuchardt >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > MembershipDependencyJUnitTest lists two dependency exceptions for geode-core > Throwable classes: GemFireException and InternalGemFireError. These should > be removed so that membership can be moved to a separate sub-project. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7593) Indexing pdx strings with eviction does not provide eviction benefits
[ https://issues.apache.org/jira/browse/GEODE-7593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17000357#comment-17000357 ] ASF subversion and git services commented on GEODE-7593: Commit a36eadca6c08078e089cb4942225498ac64cb947 in geode's branch refs/heads/release/1.11.0 from Jason Huynh [ https://gitbox.apache.org/repos/asf?p=geode.git;h=a36eadc ] GEODE-7593: Force index to use Strings instead of PdxStrings when eviction is enabled on region (#4500) (cherry picked from commit 1beec9e3930a071031b960f045874fb337e72e7c) > Indexing pdx strings with eviction does not provide eviction benefits > - > > Key: GEODE-7593 > URL: https://issues.apache.org/jira/browse/GEODE-7593 > Project: Geode > Issue Type: Bug > Components: querying >Reporter: Jason Huynh >Assignee: Jason Huynh >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > PdxStrings hold references to the values bytes. When the indexed key is a > pdx string, the index holds references in memory. Eviction will properly > evict the region entry's value but the index holds the values byte in memory > still. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-7074) improve Cluster Management Rest api Swagger documentation
[
https://issues.apache.org/jira/browse/GEODE-7074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Darrel Schneider resolved GEODE-7074.
-
Fix Version/s: 1.11.0
Resolution: Fixed
> improve Cluster Management Rest api Swagger documentation
> -
>
> Key: GEODE-7074
> URL: https://issues.apache.org/jira/browse/GEODE-7074
> Project: Geode
> Issue Type: Improvement
> Components: management
>Reporter: Jack Weissburg
>Priority: Major
> Fix For: 1.11.0
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> # the api operation names
> # the json request/response wording changes.
> # If you do a POST on the "pdx" endpoint and give it a bad json input it
> returns 400 Error: Bad Request but this in not documented in swagger (swagger
> only mentions: 200, 201, 401, 403, 404, and 500).
> The 400 returns the following json output:
> {
> "statusCode": "ILLEGAL_ARGUMENT",
> "statusMessage": "JSON parse error: Unexpected end-of-input: expected close
> marker for Object (start marker at [Source: (PushbackInputStream); line: 1,
> column: 1]); nested exception is
> com.fasterxml.jackson.core.io.JsonEOFException: Unexpected end-of-input:
> expected close marker for Object (start marker at [Source:
> (PushbackInputStream); line: 1, column: 1])\n at [Source:
> (PushbackInputStream); line: 6, column: 103]."
> }
> # Swagger will show example json docs and it always shows "statusCode" to be
> "ILLEGAL_ARGUMENT".
> I think this is because it is the first enum value. If we changed "OK" to be
> the first the swagger examples would be better.
> # hide "group, groups, " for config pdx from Swagger docs.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (GEODE-7422) ReplicatedGetBenchmark with SSL is failing intermittently
[ https://issues.apache.org/jira/browse/GEODE-7422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Helena Bales reassigned GEODE-7422: --- Assignee: Helena Bales > ReplicatedGetBenchmark with SSL is failing intermittently > - > > Key: GEODE-7422 > URL: https://issues.apache.org/jira/browse/GEODE-7422 > Project: Geode > Issue Type: Bug > Components: benchmarks >Reporter: Jacob Barrett >Assignee: Helena Bales >Priority: Major > > org.apache.geode.benchmark.tests.ReplicatedGetBenchmark fails intermittently > with SSL enabled. The put and get benchmarks show consistently lower > performance with SSL enabled between high-water mark and HEAD of develop. > Current high-water: 42a0d0d54d5e307837d0b12d87bb288ac7c2493e > Current HEAD: cf1aef105853df4455fc19301aa233a99443071d > > > [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/Benchmark/builds/671#L5dbce136:1874] > [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/Benchmark/builds/643#L5d980631:1872] > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-7099) Clean up MeterSubregistryReconnectDistributedTest
[ https://issues.apache.org/jira/browse/GEODE-7099?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dale Emery updated GEODE-7099: -- Fix Version/s: 1.11.0 > Clean up MeterSubregistryReconnectDistributedTest > - > > Key: GEODE-7099 > URL: https://issues.apache.org/jira/browse/GEODE-7099 > Project: Geode > Issue Type: Test > Components: statistics >Reporter: Dale Emery >Assignee: Dale Emery >Priority: Major > Fix For: 1.11.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Improve readability of the test. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-7089) Possible memory leak due to failure to clean up client's registration queue
[ https://issues.apache.org/jira/browse/GEODE-7089?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dick Cavender updated GEODE-7089: - Fix Version/s: 1.11.0 > Possible memory leak due to failure to clean up client's registration queue > --- > > Key: GEODE-7089 > URL: https://issues.apache.org/jira/browse/GEODE-7089 > Project: Geode > Issue Type: Bug > Components: client queues >Reporter: Ryan McMahon >Assignee: Ryan McMahon >Priority: Major > Fix For: 1.10.0, 1.11.0 > > Time Spent: 1h 40m > Remaining Estimate: 0h > > It is possible for a client's queue to leak and never be removed from the > ClientRegistrationEventQueueManager's collection, which will result in it > collecting events indefinitely and ultimately cause an OOM exception. This > can happen if the registration fails for any reason (GII failed due to a peer > crashing, unforseen serialization issues while copying the queue, etc). If > the client does not retry on the same server after failure, the queue will > leak. This is because we currently only remove the queue once a successful > registration is performed, but its possible the client will just go to a > different server on its next attempt. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-7088) Possible ConcurrentModificationException while client queue image is copied
[ https://issues.apache.org/jira/browse/GEODE-7088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dick Cavender updated GEODE-7088: - Fix Version/s: 1.11.0 > Possible ConcurrentModificationException while client queue image is copied > --- > > Key: GEODE-7088 > URL: https://issues.apache.org/jira/browse/GEODE-7088 > Project: Geode > Issue Type: Bug > Components: client queues >Reporter: Ryan McMahon >Assignee: Ryan McMahon >Priority: Major > Fix For: 1.10.0, 1.11.0 > > Time Spent: 1h 50m > Remaining Estimate: 0h > > The following corner case scenario will result in a > ConcurrentModificationException which causes the queue image transfer to fail > and subsequently client registration to fail: > # Client 1 is currently opening a subscription endpoint with server 1 and > events are being staged in the client's temporary registration queue > # One or more of those events also match interest for Client 2 who is > already fully registered, so the event is put into Client 2's queue (in > addition to Client 1's temp queue) > # Client 2 asks server 2 to open a secondary subscription endpoint. Server > 2 attempts to copy Client 2's queue from server 1. This results in > serializing all of the events in Client 2's queue. > # While the image is being transferred, Client 1 finishes registration and > begins to drain its temporary registration queue. The filter info for each > event is recalculated which ends up mutating the shared event in Client 2's > queue. > # The event has some metadata stored as a non-concurrent set. Recalculating > the filter info for Client 1 will mutate that set, but the image transfer for > Client 2 is trying to copy that set simultaneously. This can result in a > ConcurrentModificationException because the set is not thread safe. Note > that there no danger in recalculating the filter from Client 2's perspective, > because it is already in Client 2's queue. As such, Client 2's queue > transfer should be tolerant of such modifications since they have no > consequence to it. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-7063) Add AssertJ assertions for Micrometer meters
[ https://issues.apache.org/jira/browse/GEODE-7063?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dale Emery updated GEODE-7063: -- Fix Version/s: 1.11.0 > Add AssertJ assertions for Micrometer meters > > > Key: GEODE-7063 > URL: https://issues.apache.org/jira/browse/GEODE-7063 > Project: Geode > Issue Type: New Feature >Reporter: Dale Emery >Assignee: Dale Emery >Priority: Major > Fix For: 1.11.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Add basic AssertJ assertions for currently used Micrometer meter types and > features. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-7071) Add CA capability to CertStores
[ https://issues.apache.org/jira/browse/GEODE-7071?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Deppe resolved GEODE-7071. --- Fix Version/s: 1.11.0 Resolution: Fixed > Add CA capability to CertStores > --- > > Key: GEODE-7071 > URL: https://issues.apache.org/jira/browse/GEODE-7071 > Project: Geode > Issue Type: Test > Components: tests >Reporter: Jens Deppe >Assignee: Jens Deppe >Priority: Major > Fix For: 1.11.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Most (all?) SSL tests end up using self-signed certificates. We should add an > actual root CA so that certificates can actually be signed correctly. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-7054) Add some SSL benchmarks to CI
[ https://issues.apache.org/jira/browse/GEODE-7054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Helena Bales resolved GEODE-7054. - Fix Version/s: 1.11.0 Resolution: Fixed > Add some SSL benchmarks to CI > - > > Key: GEODE-7054 > URL: https://issues.apache.org/jira/browse/GEODE-7054 > Project: Geode > Issue Type: Improvement >Reporter: Murtuza Boxwala >Assignee: Murtuza Boxwala >Priority: Major > Fix For: 1.11.0 > > Time Spent: 1.5h > Remaining Estimate: 0h > > Add task for running some benchmarks with SSL enabled. This task should run > in parallel with the current benchmark task. Should run targeted benchmarks. > Benchmarks: > * *GetBenchmark > * *PutBenchmark > Args: > -PwithSsl > Accpetance: > Benchmarks are stable between runs and don't cause numerous false failures. > May require adding story for adding parameter analyzer to specify alternative > threshold (default is 5%). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Reopened] (GEODE-6807) changing advisors to cache advice can improve performance
[ https://issues.apache.org/jira/browse/GEODE-6807?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Huynh reopened GEODE-6807: Reverted as this was causing a test to become flakey and some other data inconsistency issues. > changing advisors to cache advice can improve performance > - > > Key: GEODE-6807 > URL: https://issues.apache.org/jira/browse/GEODE-6807 > Project: Geode > Issue Type: Improvement > Components: core >Reporter: Darrel Schneider >Assignee: Mario Ivanac >Priority: Major > Labels: performance > Time Spent: 6h 40m > Remaining Estimate: 0h > > Cluster messaging uses advisors to know what member of the cluster should be > sent a message. > Currently, every time and advisor is asked for advice to iterates over its > profiles building up the advice in a HashSet that is returned. > I found on a partitioned region client/server put benchmark (32 client > threads, 2 servers with redundancy 1) that if I changed the method > adviseAllEventsOrCached to remember what it computed, that it caused the put > throughput to increase by 8%. [Update I reran and did not see an improvement > so the original 8% difference may have been caused by something else]. > Advisors know when a profile is added, removed, or modified. When that > happens any advice it has cached can be dropped. Also, the requestors of > advice need to expect the Set they get back to be unmodifiable. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-7050) Log4jAgent should avoid casting non-log4j loggers
[
https://issues.apache.org/jira/browse/GEODE-7050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dick Cavender updated GEODE-7050:
-
Fix Version/s: 1.11.0
> Log4jAgent should avoid casting non-log4j loggers
> -
>
> Key: GEODE-7050
> URL: https://issues.apache.org/jira/browse/GEODE-7050
> Project: Geode
> Issue Type: Bug
> Components: logging
>Affects Versions: 1.9.0, 1.10.0
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
> Fix For: 1.9.1, 1.10.0, 1.11.0
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Users should be able to use SLF4J API with Geode even when log4j-core is in
> the class path and the Geode log4j appenders are being used.
> Log4jAgent assumes that all Loggers are Log4J loggers. This can result in a
> ClassCastException when encountering an instance of SLF4JLogger.
> {noformat}
> Caused by: java.lang.ClassCastException: org.apache.logging.slf4j.SLF4JLogger
> cannot be cast to org.apache.logging.log4j.core.Logger
> at
> org.apache.geode.internal.logging.log4j.Log4jAgent.getRootLoggerContext(Log4jAgent.java:91)
> at
> org.apache.geode.internal.logging.log4j.Log4jAgent.getConfiguration(Log4jAgent.java:95)
> at
> org.apache.geode.internal.logging.log4j.Log4jAgent.isUsingGemFireDefaultConfig(Log4jAgent.java:80)
> at
> org.apache.geode.internal.logging.log4j.Log4jAgent.shouldUpdateLogLevels(Log4jAgent.java:129)
> at
> org.apache.geode.internal.logging.log4j.Log4jAgent.configure(Log4jAgent.java:107)
> at
> org.apache.geode.internal.logging.Configuration.configChanged(Configuration.java:152)
> at
> org.apache.geode.internal.logging.Configuration.initialize(Configuration.java:141)
> at
> org.apache.geode.internal.logging.LoggingSession.createSession(LoggingSession.java:65)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.initialize(InternalDistributedSystem.java:762)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.newInstance(InternalDistributedSystem.java:446)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.newInstance(InternalDistributedSystem.java:432)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.connectInternal(InternalDistributedSystem.java:257)
> at
> org.apache.geode.distributed.DistributedSystem.connect(DistributedSystem.java:164)
> at
> org.apache.geode.cache.client.ClientCacheFactory.basicCreate(ClientCacheFactory.java:243)
> at
> org.apache.geode.cache.client.ClientCacheFactory.create(ClientCacheFactory.java:214)
> at
> org.springframework.data.gemfire.client.ClientCacheFactoryBean.createCache(ClientCacheFactoryBean.java:391)
> at
> org.springframework.data.gemfire.CacheFactoryBean.resolveCache(CacheFactoryBean.java:325)
> at
> org.springframework.data.gemfire.CacheFactoryBean.init(CacheFactoryBean.java:269)
> ... 107 more
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-7589) Provide ability to have batch dispatch be time based instead of size based
[ https://issues.apache.org/jira/browse/GEODE-7589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17000304#comment-17000304 ] Anilkumar Gingade commented on GEODE-7589: -- Currently application can achieve this by setting large number batch-size. If that suffice the requirement do we need this. in terms of ease of use (setting multiple properties); with this change too user will need to set/configure multiple properties, right? > Provide ability to have batch dispatch be time based instead of size based > -- > > Key: GEODE-7589 > URL: https://issues.apache.org/jira/browse/GEODE-7589 > Project: Geode > Issue Type: Improvement > Components: wan >Reporter: Jason Huynh >Assignee: Jason Huynh >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > It would be nice to be able to configure wan to dispatch batches at intervals > of time (time triggered) instead of batch size triggered. > Currently we have batchIntervalTime and batchSize. The wan will dispatch > when the size of batch matches batchSize OR when the time interval is hit. > We can provide the user the ability to set the batchSize to say -1 and only > trigger dispatch based on time and no longer on batch size. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-7038) After auto-reconnect a server's multicat communications aren't working correctly
[ https://issues.apache.org/jira/browse/GEODE-7038?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bruce J Schuchardt updated GEODE-7038: -- Fix Version/s: 1.11.0 > After auto-reconnect a server's multicat communications aren't working > correctly > > > Key: GEODE-7038 > URL: https://issues.apache.org/jira/browse/GEODE-7038 > Project: Geode > Issue Type: Bug > Components: membership, messaging >Reporter: Bruce J Schuchardt >Assignee: Bruce J Schuchardt >Priority: Major > Fix For: 1.11.0 > > Time Spent: 50m > Remaining Estimate: 0h > > This was observed in an server having multicast enabled on a Region. The > server went into a GC pause and was kicked out of the cluster. After > auto-reconnecting all of the servers were requested to shut down and they all > hung on destroy-region message responses. Statistics showed constant > multicast retransmission requests but no retransmissions being sent. > When a Region is configured to use multicast all of its cache operation > messages are multicast, including a destroy-region message. > Some time ago we decided to stop sending Join Request Responses during > discovery. These messages were responsible for carrying the JGroups > multicast message digest so that a joining member could install this digest > into its multicast protocol. Today these messages are only sent if a UDP > Diffie-Hellman algorithm has been specified. We need to also ensure that we > send these messages if multicast is enabled. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-7031) Attempts to send messages to alert listeners delays network partition detection
[
https://issues.apache.org/jira/browse/GEODE-7031?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruce J Schuchardt updated GEODE-7031:
--
Fix Version/s: 1.11.0
> Attempts to send messages to alert listeners delays network partition
> detection
> ---
>
> Key: GEODE-7031
> URL: https://issues.apache.org/jira/browse/GEODE-7031
> Project: Geode
> Issue Type: Improvement
> Components: membership
>Reporter: Bruce J Schuchardt
>Assignee: Bruce J Schuchardt
>Priority: Major
> Fix For: 1.11.0
>
> Time Spent: 2h 50m
> Remaining Estimate: 0h
>
> In a number of recent regression test runs in AWS we have seen network
> partition detection tests fail to detect the partition in a reasonable amount
> of time. Logs show membership services attempting to send alerts to other
> processes that are no longer reachable. Each attempt takes 6 * the
> member-timeout setting - that's 30 seconds for each attempt. It would be
> nice to have a different connection-formation timeout for something like this
> since alert notification is built into the logging system that membership
> services have to use. Since the alert system is also dependent on membership
> services functioning properly this creates a circular dependency that has
> historically caused hangs and delays such as the one described here.
> {noformat}
> [debug 2019/07/29 14:35:03.824 PDT
> tid=0xc3] Sending (Alert "Unable to send message to
> 10.32.108.136(gemfire3_host2_12249:12249):41003" level WARNING) to 1
> peers ([10.32.108.136(gemfire4_host2_12220:12220:locator):41001]) via
> tcp/ip
> [debug 2019/07/29 14:35:03.825 PDT
> tid=0xc3] created PendingConnection
> org.apache.geode.internal.tcp.ConnectionTable$PendingConnection@4f4c8630
> created by Geode Failure Detection thread 5
> [info 2019/07/29 14:35:33.847 PDT
> tid=0xc3] Connection: shared=true ordered=true failed to connect to peer
> 10.32.108.136(gemfire4_host2_12220:12220:locator):41001 because:
> java.net.SocketTimeoutException
> [debug 2019/07/29 14:35:33.852 PDT
> tid=0xc3] Giving up connecting to alert listener
> 10.32.108.136(gemfire4_host2_12220:12220:locator):41001{noformat}
>
>
>
>
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-7571) Lucene query may use the wrong version to determine if reindexing is enabled
[ https://issues.apache.org/jira/browse/GEODE-7571?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17000282#comment-17000282 ] ASF subversion and git services commented on GEODE-7571: Commit b1b7e133a66dd7effd226b3f2e22283c7070d8df in geode's branch refs/heads/develop from Jason Huynh [ https://gitbox.apache.org/repos/asf?p=geode.git;h=b1b7e13 ] GEODE-7571: Fix logic determining when query will wait for a repo (#4466) > Lucene query may use the wrong version to determine if reindexing is enabled > > > Key: GEODE-7571 > URL: https://issues.apache.org/jira/browse/GEODE-7571 > Project: Geode > Issue Type: Bug > Components: lucene >Reporter: Jason Huynh >Assignee: Jason Huynh >Priority: Major > Labels: GeodeCommons > Time Spent: 0.5h > Remaining Estimate: 0h > > There are snippets of code that expected reindexing lucene features to be > enabled by a certain version. Specifically in the LuceneQueryFunction. The > logic should be updated to wait for repo creation depending on whether the > flag is set OR a specific version criteria is met. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-6661) NioSslEngine has some problems in its ByteBuffer management
[ https://issues.apache.org/jira/browse/GEODE-6661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bruce J Schuchardt updated GEODE-6661: -- Fix Version/s: (was: 1.12.0) 1.11.0 > NioSslEngine has some problems in its ByteBuffer management > --- > > Key: GEODE-6661 > URL: https://issues.apache.org/jira/browse/GEODE-6661 > Project: Geode > Issue Type: Bug > Components: messaging >Reporter: Darrel Schneider >Assignee: Bruce J Schuchardt >Priority: Major > Labels: performance > Fix For: 1.11.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > the NioSslEngine appears to have some problems with how it manages ByteBuffer > instances, > # It has a "handshakeBuffer" instance variable and code that will > conditionally create it but higher level code always passes in a non-null > inputBuffer. It should just be changed to require an outside buffer. Also no > need for an instance variable since "handshakeBuffer" is only used by a > single method. It can just be passed in to it. > # The "myNetData" and "peerAppData" are both created as heap ByteBuffer > instances in the constructor. But if they ever need to be resized it does it > by calling Buffers.expandWriteBufferIfNeeded which will return the original > heap ByteBuffer to the queue of buffers that should always be direct byte > buffers. And now the one used by NioSslEngine will be direct instead of heap. > This will also cause the stats that Buffers has to be wrong because we return > a buffer to it that we did not allocate from it. > # From a performance standpoint, we want to also have the buffer that we > directly write to a socket channel, or fill by reading from a socket channel, > be a direct byte buffer. Other byte buffers should not be direct. So normally > the ByteBuffer we serialize an outgoing message into is a direct ByteBuffer > because it will be handed to the socket channel for the message write. But in > the case of the NioSslEngine we would want that first buffer to be a > non-direct, heap ByteBuffer. It ends up being passed to NioSslEngine.wrap > which copies it into "myNetData". The encrypted data in "myNetData" in turn > is written to the socket channel so it is the one that should be a direct > ByteBuffer. For reading it is just the opposite. We read encrypted data from > the socket channel into what should be direct byte buffer (and it currently > is because it is allocated with Buffers). But then it is passed to > NioSslEngine.unwrap which will copy (and decrypt) what is in it into the > "peerAppData". So "peerAppData" should be kept a heap ByteBuffer. You can > always get away with using either type of ByteBuffer. It is simply a > performance issue. What happens at a lower level in the jdk with a heap > ByteBuffer being used with a socket channel is that it eventually just copies > it into a direct ByteBuffer and then uses it. That extra copy can hurt > performance and in the past we had trouble with the jdk caching of direct > ByteBuffers not reusing as well as ours and running out of direct memory. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-6070) CI Failure: ShutdownCommandOverHttpDUnitTest > testShutdownAll
[
https://issues.apache.org/jira/browse/GEODE-6070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17000275#comment-17000275
]
Mark Hanson commented on GEODE-6070:
testShutdownAll is failing in ShutdownCommandDUnitTest and
ShutdownCommandOverHttpDUnitTest
org.apache.geode.management.internal.cli.commands.ShutdownCommandDUnitTest: 1
failures (99.667% success rate)
testShutdownAll
[https://concourse.apachegeode-ci.info/teams/main/pipelines/mhansonp-mhanson-mass-test-ru-main/jobs/DistributedTestOpenJDK8/builds/2100]
{noformat}
09:30:23org.apache.geode.management.internal.cli.commands.ShutdownCommandDUnitTest
> testShutdownAll FAILED
09:30:23java.lang.AssertionError: Suspicious strings were written to the
log during this run.
09:30:23Fix the strings or use IgnoredException.addIgnoredException to
ignore.
09:30:23
---
09:30:23Found suspect string in log4j at line 293
09:30:23
09:30:23
org.apache.geode.distributed.DistributedSystemDisconnectedException:
Distribution manager on 172.17.0.17(server-2:120):41002 started at Mon Dec
16 17:30:08 GMT 2019: Message distribution has terminated
09:30:23at
org.apache.geode.distributed.internal.ClusterDistributionManager$Stopper.generateCancelledException(ClusterDistributionManager.java:2784)
09:30:23at
org.apache.geode.CancelCriterion.checkCancelInProgress(CancelCriterion.java:83)
09:30:23at
org.apache.geode.distributed.internal.ClusterDistributionManager.sendMessage(ClusterDistributionManager.java:2005)
09:30:23at
org.apache.geode.distributed.internal.ClusterDistributionManager.putOutgoing(ClusterDistributionManager.java:1070)
09:30:23at
org.apache.geode.internal.cache.FunctionStreamingReplyMessage.send(FunctionStreamingReplyMessage.java:65)
09:30:23at
org.apache.geode.internal.cache.MemberFunctionStreamingMessage.sendReply(MemberFunctionStreamingMessage.java:368)
09:30:23at
org.apache.geode.internal.cache.MemberFunctionStreamingMessage.sendReplyForOneResult(MemberFunctionStreamingMessage.java:353)
09:30:23at
org.apache.geode.internal.cache.execute.MemberFunctionResultSender.lastResult(MemberFunctionResultSender.java:101)
09:30:23at
org.apache.geode.management.internal.cli.functions.ShutDownFunction.execute(ShutDownFunction.java:55)
09:30:23at
org.apache.geode.internal.cache.MemberFunctionStreamingMessage.process(MemberFunctionStreamingMessage.java:201)
09:30:23at
org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:394)
09:30:23at
org.apache.geode.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:458)
09:30:23at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
09:30:23at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
09:30:23at
org.apache.geode.distributed.internal.ClusterOperationExecutors.runUntilShutdown(ClusterOperationExecutors.java:475)
09:30:23at
org.apache.geode.distributed.internal.ClusterOperationExecutors.doFunctionExecutionThread(ClusterOperationExecutors.java:393)
09:30:23at
org.apache.geode.logging.internal.executors.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:119)
09:30:23at java.lang.Thread.run(Thread.java:748)
09:42:03
09:42:03352 tests completed, 1 failed, 5 skipped {noformat}
org.apache.geode.management.internal.cli.commands.ShutdownCommandOverHttpDUnitTest:
1 failures (99.667% success rate)
testShutdownAll
[https://concourse.apachegeode-ci.info/teams/main/pipelines/mhansonp-mhanson-mass-test-ru-main/jobs/DistributedTestOpenJDK8/builds/2075]
{noformat}
22:10:45org.apache.geode.management.internal.cli.commands.ShutdownCommandOverHttpDUnitTest
> testShutdownAll FAILED
22:10:45java.lang.AssertionError: Suspicious strings were written to the
log during this run.
22:10:45Fix the strings or use IgnoredException.addIgnoredException to
ignore.
22:10:45
---
22:10:45Found suspect string in log4j at line 264
22:10:45
22:10:45
org.apache.geode.distributed.DistributedSystemDisconnectedException:
Distribution manager on 172.17.0.19(server-1:112):41001 started at Mon Dec
16 06:10:19 GMT 2019: Message distribution has terminated
22:10:45at
org.apache.geode.distributed.internal.ClusterDistributionManager$Stopper.generateCancelledException(ClusterDistributionManager.java:2784)
22:10:45at
org.apache.geode.CancelCriterion.checkCancelInProgress(CancelCriterion.java:83)
22:10:45at
org.apache.geode.distributed.internal.ClusterDistributionManager.sendMessage(ClusterDistributionManager.java:2005)
22:10:45at
[jira] [Created] (GEODE-7605) PersistentRecoveryOrderDUnitTest and PersistentRecoveryOrderOldConfigDUnitTest fail in testGIIDuringDestroy
Mark Hanson created GEODE-7605:
--
Summary: PersistentRecoveryOrderDUnitTest and
PersistentRecoveryOrderOldConfigDUnitTest fail in testGIIDuringDestroy
Key: GEODE-7605
URL: https://issues.apache.org/jira/browse/GEODE-7605
Project: Geode
Issue Type: Bug
Components: tests
Reporter: Mark Hanson
org.apache.geode.internal.cache.persistence.PersistentRecoveryOrderDUnitTest: 1
failures (99.667% success rate)
testGIIDuringDestroy
[https://concourse.apachegeode-ci.info/teams/main/pipelines/mhansonp-mhanson-mass-test-ru-main/jobs/DistributedTestOpenJDK8/builds/2251]
{noformat}
01:38:05org.apache.geode.internal.cache.persistence.PersistentRecoveryOrderDUnitTest
> testGIIDuringDestroy FAILED
01:38:05org.apache.geode.test.dunit.RMIException: While invoking
org.apache.geode.internal.cache.persistence.PersistentRecoveryOrderDUnitTest$$Lambda$196/1137975618.run
in VM 1 running on Host c27ac1dbf5cd with 4 VMs
01:38:05at
org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:610)
01:38:05at org.apache.geode.test.dunit.VM.invoke(VM.java:437)
01:38:05at
org.apache.geode.internal.cache.persistence.PersistentRecoveryOrderDUnitTest.testGIIDuringDestroy(PersistentRecoveryOrderDUnitTest.java:1004)
01:38:05
01:38:05Caused by:
01:38:05org.apache.geode.cache.RegionDestroyedException:
org.apache.geode.internal.cache.DistributedRegion[path='/PersistentRecoveryOrderDUnitTest_testGIIDuringDestroyRegion';scope=DISTRIBUTED_ACK';dataPolicy=PERSISTENT_REPLICATE;
concurrencyChecksEnabled]
01:38:05at
org.apache.geode.internal.cache.LocalRegion.checkRegionDestroyed(LocalRegion.java:7296)
01:38:05at
org.apache.geode.internal.cache.LocalRegion.checkReadiness(LocalRegion.java:2750)
01:38:05at
org.apache.geode.internal.cache.LocalRegion.size(LocalRegion.java:8256)
01:38:05at java.util.TreeMap.putAll(TreeMap.java:313)
01:38:05at java.util.TreeMap.(TreeMap.java:185)
01:38:05at
org.assertj.core.presentation.StandardRepresentation.toSortedMapIfPossible(StandardRepresentation.java:339)
01:38:05at
org.assertj.core.presentation.StandardRepresentation.toStringOf(StandardRepresentation.java:319)
01:38:05at
org.assertj.core.presentation.StandardRepresentation.toStringOf(StandardRepresentation.java:178)
01:38:05at
org.assertj.core.error.ShouldBeEqual.actualAndExpectedHaveSameStringRepresentation(ShouldBeEqual.java:137)
01:38:05at
org.assertj.core.error.ShouldBeEqual.smartErrorMessage(ShouldBeEqual.java:151)
01:38:05at
org.assertj.core.error.ShouldBeEqual.newAssertionError(ShouldBeEqual.java:116)
01:38:05at
org.assertj.core.internal.Failures.failure(Failures.java:100)
01:38:05at
org.assertj.core.internal.Objects.assertNull(Objects.java:364)
01:38:05at
org.assertj.core.api.AbstractAssert.isNull(AbstractAssert.java:272)
01:38:05at
org.apache.geode.internal.cache.persistence.PersistentRecoveryOrderDUnitTest.lambda$null$16(PersistentRecoveryOrderDUnitTest.java:1007)
01:38:05
01:38:05java.lang.AssertionError: Suspicious strings were written to the
log during this run.
01:38:05Fix the strings or use IgnoredException.addIgnoredException to
ignore.
01:38:05
---
01:38:05Found suspect string in log4j at line 1923
01:38:05
01:38:05[error 2019/12/19 09:38:03.305 GMT tid=32]
org.apache.geode.distributed.DistributedSystemDisconnectedException: This
connection to a distributed system has been disconnected.
02:22:02 {noformat}
org.apache.geode.internal.cache.persistence.PersistentRecoveryOrderOldConfigDUnitTest:
1 failures (99.667% success rate)
testGIIDuringDestroy
[https://concourse.apachegeode-ci.info/teams/main/pipelines/mhansonp-mhanson-mass-test-ru-main/jobs/DistributedTestOpenJDK8/builds/2212]
{noformat}
org.apache.geode.internal.cache.persistence.PersistentRecoveryOrderOldConfigDUnitTest
> testGIIDuringDestroy FAILED
09:18:39org.apache.geode.test.dunit.RMIException: While invoking
org.apache.geode.internal.cache.persistence.PersistentRecoveryOrderDUnitTest$$Lambda$196/873195048.run
in VM 1 running on Host 8112b4e87eac with 4 VMs
09:18:39
09:18:39Caused by:
09:18:39org.apache.geode.cache.RegionDestroyedException:
org.apache.geode.internal.cache.DistributedRegion[path='/PersistentRecoveryOrderOldConfigDUnitTest_testGIIDuringDestroyRegion';scope=DISTRIBUTED_ACK';dataPolicy=PERSISTENT_REPLICATE;
concurrencyChecksEnabled]
09:18:39
09:18:39java.lang.AssertionError: Suspicious strings were written to the
log during this run.
09:18:39Fix the strings or use IgnoredException.addIgnoredException to
ignore.
09:18:39
[jira] [Updated] (GEODE-7605) PersistentRecoveryOrderDUnitTest and PersistentRecoveryOrderOldConfigDUnitTest fail in testGIIDuringDestroy
[
https://issues.apache.org/jira/browse/GEODE-7605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Hanson updated GEODE-7605:
---
Labels: flaky (was: )
> PersistentRecoveryOrderDUnitTest and
> PersistentRecoveryOrderOldConfigDUnitTest fail in testGIIDuringDestroy
> ---
>
> Key: GEODE-7605
> URL: https://issues.apache.org/jira/browse/GEODE-7605
> Project: Geode
> Issue Type: Bug
> Components: tests
>Reporter: Mark Hanson
>Priority: Major
> Labels: flaky
>
> org.apache.geode.internal.cache.persistence.PersistentRecoveryOrderDUnitTest:
> 1 failures (99.667% success rate)
> testGIIDuringDestroy
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/mhansonp-mhanson-mass-test-ru-main/jobs/DistributedTestOpenJDK8/builds/2251]
> {noformat}
> 01:38:05org.apache.geode.internal.cache.persistence.PersistentRecoveryOrderDUnitTest
> > testGIIDuringDestroy FAILED
> 01:38:05org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.persistence.PersistentRecoveryOrderDUnitTest$$Lambda$196/1137975618.run
> in VM 1 running on Host c27ac1dbf5cd with 4 VMs
> 01:38:05at
> org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:610)
> 01:38:05at org.apache.geode.test.dunit.VM.invoke(VM.java:437)
> 01:38:05at
> org.apache.geode.internal.cache.persistence.PersistentRecoveryOrderDUnitTest.testGIIDuringDestroy(PersistentRecoveryOrderDUnitTest.java:1004)
> 01:38:05
> 01:38:05Caused by:
> 01:38:05org.apache.geode.cache.RegionDestroyedException:
> org.apache.geode.internal.cache.DistributedRegion[path='/PersistentRecoveryOrderDUnitTest_testGIIDuringDestroyRegion';scope=DISTRIBUTED_ACK';dataPolicy=PERSISTENT_REPLICATE;
> concurrencyChecksEnabled]
> 01:38:05at
> org.apache.geode.internal.cache.LocalRegion.checkRegionDestroyed(LocalRegion.java:7296)
> 01:38:05at
> org.apache.geode.internal.cache.LocalRegion.checkReadiness(LocalRegion.java:2750)
> 01:38:05at
> org.apache.geode.internal.cache.LocalRegion.size(LocalRegion.java:8256)
> 01:38:05at java.util.TreeMap.putAll(TreeMap.java:313)
> 01:38:05at java.util.TreeMap.(TreeMap.java:185)
> 01:38:05at
> org.assertj.core.presentation.StandardRepresentation.toSortedMapIfPossible(StandardRepresentation.java:339)
> 01:38:05at
> org.assertj.core.presentation.StandardRepresentation.toStringOf(StandardRepresentation.java:319)
> 01:38:05at
> org.assertj.core.presentation.StandardRepresentation.toStringOf(StandardRepresentation.java:178)
> 01:38:05at
> org.assertj.core.error.ShouldBeEqual.actualAndExpectedHaveSameStringRepresentation(ShouldBeEqual.java:137)
> 01:38:05at
> org.assertj.core.error.ShouldBeEqual.smartErrorMessage(ShouldBeEqual.java:151)
> 01:38:05at
> org.assertj.core.error.ShouldBeEqual.newAssertionError(ShouldBeEqual.java:116)
> 01:38:05at
> org.assertj.core.internal.Failures.failure(Failures.java:100)
> 01:38:05at
> org.assertj.core.internal.Objects.assertNull(Objects.java:364)
> 01:38:05at
> org.assertj.core.api.AbstractAssert.isNull(AbstractAssert.java:272)
> 01:38:05at
> org.apache.geode.internal.cache.persistence.PersistentRecoveryOrderDUnitTest.lambda$null$16(PersistentRecoveryOrderDUnitTest.java:1007)
> 01:38:05
> 01:38:05java.lang.AssertionError: Suspicious strings were written to the
> log during this run.
> 01:38:05Fix the strings or use IgnoredException.addIgnoredException to
> ignore.
> 01:38:05
> ---
> 01:38:05Found suspect string in log4j at line 1923
> 01:38:05
> 01:38:05[error 2019/12/19 09:38:03.305 GMT Connection(1)-172.17.0.3> tid=32]
> org.apache.geode.distributed.DistributedSystemDisconnectedException: This
> connection to a distributed system has been disconnected.
> 02:22:02 {noformat}
> org.apache.geode.internal.cache.persistence.PersistentRecoveryOrderOldConfigDUnitTest:
> 1 failures (99.667% success rate)
> testGIIDuringDestroy
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/mhansonp-mhanson-mass-test-ru-main/jobs/DistributedTestOpenJDK8/builds/2212]
>
> {noformat}
> org.apache.geode.internal.cache.persistence.PersistentRecoveryOrderOldConfigDUnitTest
> > testGIIDuringDestroy FAILED
> 09:18:39org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.persistence.PersistentRecoveryOrderDUnitTest$$Lambda$196/873195048.run
> in VM 1 running on Host 8112b4e87eac with 4 VMs
> 09:18:39
> 09:18:39Caused by:
> 09:18:39
[jira] [Commented] (GEODE-6489) CI Failures with testDistributedDeadlock
[
https://issues.apache.org/jira/browse/GEODE-6489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17000269#comment-17000269
]
Mark Hanson commented on GEODE-6489:
More mass test run failures.
testNoDeadlock
*
https://concourse.apachegeode-ci.info/teams/main/pipelines/mhansonp-mhanson-mass-test-ru-main/jobs/DistributedTestOpenJDK8/builds/2087
testDistributedDeadlockWithFunction
*
https://concourse.apachegeode-ci.info/teams/main/pipelines/mhansonp-mhanson-mass-test-ru-main/jobs/DistributedTestOpenJDK8/builds/2087
> CI Failures with testDistributedDeadlock
>
>
> Key: GEODE-6489
> URL: https://issues.apache.org/jira/browse/GEODE-6489
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Affects Versions: 1.10.0
>Reporter: Lynn Hughes-Godfrey
>Assignee: Kirk Lund
>Priority: Major
>
> In an single CI run, we see 3 failures all related to testDistributedDeadlock:
> {noformat}
> org.apache.geode.management.internal.cli.commands.ShowDeadlockOverHttpDUnitTest
> > testDistributedDeadlockWithFunction FAILED
> org.apache.geode.management.internal.cli.commands.ShowDeadlockOverHttpDUnitTest
> > testNoDeadlock FAILED
> org.apache.geode.distributed.internal.deadlock.GemFireDeadlockDetectorDUnitTest
> > testDistributedDeadlockWithDLock FAILED
> {noformat}
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/469
> {noformat}
> org.apache.geode.management.internal.cli.commands.ShowDeadlockOverHttpDUnitTest
> > testDistributedDeadlockWithFunction FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.management.internal.cli.commands.ShowDeadlockDistributedTestBase$$Lambda$68/829260532.run
> in VM 1 running on Host ceb4d948b5be with 4 VMs
> Caused by:
> org.awaitility.core.ConditionTimeoutException: Condition with
> org.apache.geode.management.internal.cli.commands.ShowDeadlockDistributedTestBase
> was not fulfilled within 300 seconds.
> org.apache.geode.management.internal.cli.commands.ShowDeadlockOverHttpDUnitTest
> > testNoDeadlock FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.management.internal.cli.commands.ShowDeadlockDistributedTestBase$$Lambda$68/829260532.run
> in VM 1 running on Host ceb4d948b5be with 4 VMs
> Caused by:
> org.awaitility.core.ConditionTimeoutException: Condition with
> org.apache.geode.management.internal.cli.commands.ShowDeadlockDistributedTestBase
> was not fulfilled within 300 seconds.
> 137 tests completed, 2 failed
> > Task :geode-web:distributedTest FAILED
> > Task :geode-core:distributedTest
> org.apache.geode.distributed.internal.deadlock.GemFireDeadlockDetectorDUnitTest
> > testDistributedDeadlockWithDLock FAILED
> java.lang.AssertionError
> at org.junit.Assert.fail(Assert.java:86)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at org.junit.Assert.assertTrue(Assert.java:52)
> at
> org.apache.geode.distributed.internal.deadlock.GemFireDeadlockDetectorDUnitTest.testDistributedDeadlockWithDLock(GemFireDeadlockDetectorDUnitTest.java:201)
> {noformat}
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.10.0-SNAPSHOT.0019/test-results/distributedTest/1551833386/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.10.0-SNAPSHOT.0019/test-artifacts/1551833386/distributedtestfiles-OpenJDK8-1.10.0-SNAPSHOT.0019.tgz
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-6489) CI Failures with testDistributedDeadlock
[
https://issues.apache.org/jira/browse/GEODE-6489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Hanson updated GEODE-6489:
---
Labels: flaky (was: )
> CI Failures with testDistributedDeadlock
>
>
> Key: GEODE-6489
> URL: https://issues.apache.org/jira/browse/GEODE-6489
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Affects Versions: 1.10.0
>Reporter: Lynn Hughes-Godfrey
>Assignee: Kirk Lund
>Priority: Major
> Labels: flaky
>
> In an single CI run, we see 3 failures all related to testDistributedDeadlock:
> {noformat}
> org.apache.geode.management.internal.cli.commands.ShowDeadlockOverHttpDUnitTest
> > testDistributedDeadlockWithFunction FAILED
> org.apache.geode.management.internal.cli.commands.ShowDeadlockOverHttpDUnitTest
> > testNoDeadlock FAILED
> org.apache.geode.distributed.internal.deadlock.GemFireDeadlockDetectorDUnitTest
> > testDistributedDeadlockWithDLock FAILED
> {noformat}
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/469
> {noformat}
> org.apache.geode.management.internal.cli.commands.ShowDeadlockOverHttpDUnitTest
> > testDistributedDeadlockWithFunction FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.management.internal.cli.commands.ShowDeadlockDistributedTestBase$$Lambda$68/829260532.run
> in VM 1 running on Host ceb4d948b5be with 4 VMs
> Caused by:
> org.awaitility.core.ConditionTimeoutException: Condition with
> org.apache.geode.management.internal.cli.commands.ShowDeadlockDistributedTestBase
> was not fulfilled within 300 seconds.
> org.apache.geode.management.internal.cli.commands.ShowDeadlockOverHttpDUnitTest
> > testNoDeadlock FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.management.internal.cli.commands.ShowDeadlockDistributedTestBase$$Lambda$68/829260532.run
> in VM 1 running on Host ceb4d948b5be with 4 VMs
> Caused by:
> org.awaitility.core.ConditionTimeoutException: Condition with
> org.apache.geode.management.internal.cli.commands.ShowDeadlockDistributedTestBase
> was not fulfilled within 300 seconds.
> 137 tests completed, 2 failed
> > Task :geode-web:distributedTest FAILED
> > Task :geode-core:distributedTest
> org.apache.geode.distributed.internal.deadlock.GemFireDeadlockDetectorDUnitTest
> > testDistributedDeadlockWithDLock FAILED
> java.lang.AssertionError
> at org.junit.Assert.fail(Assert.java:86)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at org.junit.Assert.assertTrue(Assert.java:52)
> at
> org.apache.geode.distributed.internal.deadlock.GemFireDeadlockDetectorDUnitTest.testDistributedDeadlockWithDLock(GemFireDeadlockDetectorDUnitTest.java:201)
> {noformat}
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.10.0-SNAPSHOT.0019/test-results/distributedTest/1551833386/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.10.0-SNAPSHOT.0019/test-artifacts/1551833386/distributedtestfiles-OpenJDK8-1.10.0-SNAPSHOT.0019.tgz
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-6819) CI failure: PartitionedRegionSingleHopDUnitTest. testMetadataIsSameOnAllServersAndClients
[
https://issues.apache.org/jira/browse/GEODE-6819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17000267#comment-17000267
]
Mark Hanson commented on GEODE-6819:
More failures from mass test runs
testMetadataFetchOnlyThroughFunctions
*
https://concourse.apachegeode-ci.info/teams/main/pipelines/mhansonp-mhanson-mass-test-ru-main/jobs/DistributedTestOpenJDK8/builds/2171
testMetadataIsSameOnAllServersAndClients
*
https://concourse.apachegeode-ci.info/teams/main/pipelines/mhansonp-mhanson-mass-test-ru-main/jobs/DistributedTestOpenJDK8/builds/2173
test_MetadataServiceCallAccuracy_FromGetOp
*
https://concourse.apachegeode-ci.info/teams/main/pipelines/mhansonp-mhanson-mass-test-ru-main/jobs/DistributedTestOpenJDK8/builds/2239
https://concourse.apachegeode-ci.info/teams/main/pipelines/mhansonp-mhanson-mass-test-ru-main/jobs/DistributedTestOpenJDK8/builds/2228
https://concourse.apachegeode-ci.info/teams/main/pipelines/mhansonp-mhanson-mass-test-ru-main/jobs/DistributedTestOpenJDK8/builds/2156
> CI failure: PartitionedRegionSingleHopDUnitTest.
> testMetadataIsSameOnAllServersAndClients
> -
>
> Key: GEODE-6819
> URL: https://issues.apache.org/jira/browse/GEODE-6819
> Project: Geode
> Issue Type: Bug
> Components: client/server
>Reporter: Bruce J Schuchardt
>Priority: Major
>
> {noformat}
> org.apache.geode.internal.cache.PartitionedRegionSingleHopDUnitTest >
> testMetadataIsSameOnAllServersAndClients FAILED
> org.awaitility.core.ConditionTimeoutException: Assertion condition
> defined in public void
> org.apache.geode.internal.cache.PartitionedRegionSingleHopDUnitTest.testMetadataIsSameOnAllServersAndClients()
> bucket copies are not created within 300 seconds.
> at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:145)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:122)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:32)
> at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:902)
> at
> org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:723)
> at
> org.apache.geode.internal.cache.PartitionedRegionSingleHopDUnitTest.testMetadataIsSameOnAllServersAndClients(PartitionedRegionSingleHopDUnitTest.java:849)
> Caused by:
> java.lang.AssertionError: bucket copies are not created{noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-6819) CI failure: PartitionedRegionSingleHopDUnitTest. testMetadataIsSameOnAllServersAndClients
[
https://issues.apache.org/jira/browse/GEODE-6819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Hanson updated GEODE-6819:
---
Labels: flaky (was: )
> CI failure: PartitionedRegionSingleHopDUnitTest.
> testMetadataIsSameOnAllServersAndClients
> -
>
> Key: GEODE-6819
> URL: https://issues.apache.org/jira/browse/GEODE-6819
> Project: Geode
> Issue Type: Bug
> Components: client/server
>Reporter: Bruce J Schuchardt
>Priority: Major
> Labels: flaky
>
> {noformat}
> org.apache.geode.internal.cache.PartitionedRegionSingleHopDUnitTest >
> testMetadataIsSameOnAllServersAndClients FAILED
> org.awaitility.core.ConditionTimeoutException: Assertion condition
> defined in public void
> org.apache.geode.internal.cache.PartitionedRegionSingleHopDUnitTest.testMetadataIsSameOnAllServersAndClients()
> bucket copies are not created within 300 seconds.
> at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:145)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:122)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:32)
> at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:902)
> at
> org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:723)
> at
> org.apache.geode.internal.cache.PartitionedRegionSingleHopDUnitTest.testMetadataIsSameOnAllServersAndClients(PartitionedRegionSingleHopDUnitTest.java:849)
> Caused by:
> java.lang.AssertionError: bucket copies are not created{noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (GEODE-7576) BootstrappingFunction should be executed after cache is fully created
[ https://issues.apache.org/jira/browse/GEODE-7576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Shu resolved GEODE-7576. - Resolution: Fixed > BootstrappingFunction should be executed after cache is fully created > - > > Key: GEODE-7576 > URL: https://issues.apache.org/jira/browse/GEODE-7576 > Project: Geode > Issue Type: Bug > Components: functions >Affects Versions: 1.12.0 >Reporter: Eric Shu >Assignee: Eric Shu >Priority: Major > Labels: GeodeCommons > Fix For: 1.12.0 > > Time Spent: 20m > Remaining Estimate: 0h > > The tomcat client server session module test failed: > [warn 2019/12/12 20:57:59.795 PST tid=0x10] Thread <39> > (0x27) that was executed at <12 Dec 2019 20:55:00 PST> has been stuck for > <178.813 seconds> and number of thread monitor iteration <2> > Thread Name state > Waiting on > > Owned By with ID <1> > Executor Group > Monitored metric > Thread Stack: > sun.misc.Unsafe.park(Native Method) > java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) > java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836) > java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997) > java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304) > java.util.concurrent.locks.ReentrantReadWriteLock$ReadLock.lockInterruptibly(ReentrantReadWriteLock.java:772) > org.apache.geode.management.internal.beans.ManagementListener.handleEvent(ManagementListener.java:116) > org.apache.geode.distributed.internal.InternalDistributedSystem.notifyResourceEventListeners(InternalDistributedSystem.java:2065) > org.apache.geode.distributed.internal.InternalDistributedSystem.handleResourceEvent(InternalDistributedSystem.java:606) > org.apache.geode.distributed.internal.locks.DLockService.init(DLockService.java:1915) > org.apache.geode.distributed.internal.locks.DLockService.basicCreate(DLockService.java:1892) > org.apache.geode.distributed.internal.locks.DLockService.create(DLockService.java:2710) > org.apache.geode.internal.cache.GemFireCacheImpl.getPartitionedRegionLockService(GemFireCacheImpl.java:1938) > org.apache.geode.internal.cache.DistributedRegion.(DistributedRegion.java:245) > org.apache.geode.internal.cache.GemFireCacheImpl.createVMRegion(GemFireCacheImpl.java:3009) > org.apache.geode.modules.util.CreateRegionFunction.createRegionConfigurationMetadataRegion(CreateRegionFunction.java:273) > org.apache.geode.modules.util.CreateRegionFunction.(CreateRegionFunction.java:63) > org.apache.geode.modules.util.BootstrappingFunction.registerFunctions(BootstrappingFunction.java:124) > org.apache.geode.modules.util.BootstrappingFunction.execute(BootstrappingFunction.java:67) > org.apache.geode.internal.cache.MemberFunctionStreamingMessage.process(MemberFunctionStreamingMessage.java:193) > org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:365) > org.apache.geode.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:429) > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > org.apache.geode.distributed.internal.ClusterDistributionManager.runUntilShutdown(ClusterDistributionManager.java:961) > org.apache.geode.distributed.internal.ClusterDistributionManager.doFunctionExecutionThread(ClusterDistributionManager.java:815) > org.apache.geode.distributed.internal.ClusterDistributionManager$$Lambda$52/1112527632.invoke(Unknown > Source) > org.apache.geode.internal.logging.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:121) > org.apache.geode.internal.logging.LoggingThreadFactory$$Lambda$42/973936431.run(Unknown > Source) > java.lang.Thread.run(Thread.java:748) > Was able to get a thread dump: > "Function Execution Processor3": > at sun.misc.Unsafe.park(Native Method) > - parking to wait for <0x0005c0732318> (a > java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync) > at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304) > at >
[jira] [Updated] (GEODE-6094) Fix string format statements.(extra arguments)
[
https://issues.apache.org/jira/browse/GEODE-6094?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dick Cavender updated GEODE-6094:
-
Fix Version/s: 1.11.0
> Fix string format statements.(extra arguments)
> --
>
> Key: GEODE-6094
> URL: https://issues.apache.org/jira/browse/GEODE-6094
> Project: Geode
> Issue Type: Bug
>Reporter: Nabarun Nag
>Assignee: Nabarun Nag
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.11.0
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> /ServerLauncher.java]1 alert
>
> |⇅|1-800|
> |801|}|
> |802| |
> |803|[debug|https://lgtm.com/projects/g/apache/geode/snapshot/dba71cfcffe43e1e956571c604c82d153bb5eddb/files/geode-core/src/main/java/org/apache/geode/distributed/AbstractLauncher.java#xd49f14da1f246ffa:1]("Running
> Server on (%1$s) in (%2$s) as (%2$s)...",
> [getId|https://lgtm.com/projects/g/apache/geode/snapshot/dba71cfcffe43e1e956571c604c82d153bb5eddb/files/geode-core/src/main/java/org/apache/geode/distributed/ServerLauncher.java#x502c219765570b55:1](),
>
> [getWorkingDirectory|https://lgtm.com/projects/g/apache/geode/snapshot/dba71cfcffe43e1e956571c604c82d153bb5eddb/files/geode-core/src/main/java/org/apache/geode/distributed/ServerLauncher.java#x98cbefa66f4c0447:1](),|
> |804|[getMember|https://lgtm.com/projects/g/apache/geode/snapshot/dba71cfcffe43e1e956571c604c82d153bb5eddb/files/geode-core/src/main/java/org/apache/geode/distributed/AbstractLauncher.java#xa3c9c4ed6541f433:1]());|
> | | This format call refers to 2 argument(s) but supplies 3 argument(s).
> |
> |805|this.[running|https://lgtm.com/projects/g/apache/geode/snapshot/dba71cfcffe43e1e956571c604c82d153bb5eddb/files/geode-core/src/main/java/org/apache/geode/distributed/AbstractLauncher.java#x4a0d86f43eabb521:1].set(true);|
> |806| |
> |⇅|807-2723|
> LocatorLauncher.java]1 alert
>
> |⇅|1-667|
> |668|}|
> |669| |
> |670|[debug|https://lgtm.com/projects/g/apache/geode/snapshot/dba71cfcffe43e1e956571c604c82d153bb5eddb/files/geode-core/src/main/java/org/apache/geode/distributed/AbstractLauncher.java#xd49f14da1f246ffa:1]("Running
> Locator on (%1$s) in (%2$s) as (%2$s)...",
> [getId|https://lgtm.com/projects/g/apache/geode/snapshot/dba71cfcffe43e1e956571c604c82d153bb5eddb/files/geode-core/src/main/java/org/apache/geode/distributed/LocatorLauncher.java#x682bfb00656578dd:1](),
>
> [getWorkingDirectory|https://lgtm.com/projects/g/apache/geode/snapshot/dba71cfcffe43e1e956571c604c82d153bb5eddb/files/geode-core/src/main/java/org/apache/geode/distributed/LocatorLauncher.java#xa97f084f7d5e1c09:1](),|
> |671|[getMember|https://lgtm.com/projects/g/apache/geode/snapshot/dba71cfcffe43e1e956571c604c82d153bb5eddb/files/geode-core/src/main/java/org/apache/geode/distributed/AbstractLauncher.java#xa3c9c4ed6541f433:1]());|
> | | This format call refers to 2 argument(s) but supplies 3 argument(s).
> |
> |672|[running|https://lgtm.com/projects/g/apache/geode/snapshot/dba71cfcffe43e1e956571c604c82d153bb5eddb/files/geode-core/src/main/java/org/apache/geode/distributed/AbstractLauncher.java#x4a0d86f43eabb521:1].set(true);|
> |673| |
> |⇅|674-2129|
> AbstractBaseController.java]1 alert
>
> |⇅|1-404|
> |405|(String.format("Query store does not exist!",
> This format call refers to 0 argument(s) but supplies 1 argument(s). \|
> \|408\| }|
> |409| |
> |⇅|410-951|
> /PartitionedRegionLoadModel.java]1 alert
>
> |⇅|1-818|
> |819|}|
> |820| |
> |821|[result|https://lgtm.com/projects/g/apache/geode/snapshot/dba71cfcffe43e1e956571c604c82d153bb5eddb/files/geode-core/src/main/java/org/apache/geode/internal/cache/partitioned/rebalance/model/PartitionedRegionLoadModel.java#x7ef966c81e25f79f:1].append(String.format("\n%"
> +
> [longestMemberId|https://lgtm.com/projects/g/apache/geode/snapshot/dba71cfcffe43e1e956571c604c82d153bb5eddb/files/geode-core/src/main/java/org/apache/geode/internal/cache/partitioned/rebalance/model/PartitionedRegionLoadModel.java#x213915db1cfe3133:1]
> + "s ",|
> |822|"#offline", 0, 0, 0));|
> | | This format call refers to 1 argument(s) but supplies 4 argument(s).
> |
> |823|for
> ([Bucket|https://lgtm.com/projects/g/apache/geode/snapshot/dba71cfcffe43e1e956571c604c82d153bb5eddb/files/geode-core/src/main/java/org/apache/geode/internal/cache/partitioned/rebalance/model/Bucket.java#x46307f8d530e3f82:1]
> bucket :
> [allBucketIds|https://lgtm.com/projects/g/apache/geode/snapshot/dba71cfcffe43e1e956571c604c82d153bb5eddb/files/geode-core/src/main/java/org/apache/geode/internal/cache/partitioned/rebalance/model/PartitionedRegionLoadModel.java#x6b9723dd22bf83a1:1])
> {|
>
[jira] [Resolved] (GEODE-853) PartitionedRegionSingleHopDUnitTest.testServerLocationRemovalThroughPing
[
https://issues.apache.org/jira/browse/GEODE-853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Hanson resolved GEODE-853.
---
> PartitionedRegionSingleHopDUnitTest.testServerLocationRemovalThroughPing
>
>
> Key: GEODE-853
> URL: https://issues.apache.org/jira/browse/GEODE-853
> Project: Geode
> Issue Type: Bug
> Components: functions
>Reporter: Xiaojian Zhou
>Priority: Major
> Labels: CI, Flaky, swat
> Attachments: Test results - Class
> org.apache.geode.internal.cache.PartitionedRegionSingleHopDUnitTest.htm
>
>
> Revision: df274cc0fe8323f307e718a688e96bd7ff14288b
> failed at DistributedTests 1370
> {noformat}
> junit.framework.AssertionFailedError: expected:<4> but was:<3>
> at junit.framework.Assert.fail(Assert.java:57)
> at junit.framework.Assert.failNotEquals(Assert.java:329)
> at junit.framework.Assert.assertEquals(Assert.java:78)
> at junit.framework.Assert.assertEquals(Assert.java:234)
> at junit.framework.Assert.assertEquals(Assert.java:241)
> at junit.framework.TestCase.assertEquals(TestCase.java:409)
> at
> com.gemstone.gemfire.internal.cache.PartitionedRegionSingleHopDUnitTest.testServerLocationRemovalThroughPing(PartitionedRegionSingleHopDUnitTest.java:787)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at junit.framework.TestCase.runBare(TestCase.java:141)
> at junit.framework.TestResult$1.protect(TestResult.java:122)
> at junit.framework.TestResult.runProtected(TestResult.java:142)
> at junit.framework.TestResult.run(TestResult.java:125)
> at junit.framework.TestCase.run(TestCase.java:129)
> at junit.framework.TestSuite.runTest(TestSuite.java:252)
> at junit.framework.TestSuite.run(TestSuite.java:247)
> at
> org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:86)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:105)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:56)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:64)
> at
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:50)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
> at
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
> at
> org.gradle.messaging.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
> at
> org.gradle.messaging.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
> at com.sun.proxy.$Proxy2.processTestClass(Unknown Source)
> at
> org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:106)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
> at
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
> at
> org.gradle.messaging.remote.internal.hub.MessageHub$Handler.run(MessageHub.java:360)
> at
> org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:54)
> at
> org.gradle.internal.concurrent.StoppableExecutorImpl$1.run(StoppableExecutorImpl.java:40)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
--
This message was sent by Atlassian Jira
[jira] [Updated] (GEODE-7576) BootstrappingFunction should be executed after cache is fully created
[ https://issues.apache.org/jira/browse/GEODE-7576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Shu updated GEODE-7576: Fix Version/s: 1.12.0 > BootstrappingFunction should be executed after cache is fully created > - > > Key: GEODE-7576 > URL: https://issues.apache.org/jira/browse/GEODE-7576 > Project: Geode > Issue Type: Bug > Components: functions >Affects Versions: 1.12.0 >Reporter: Eric Shu >Assignee: Eric Shu >Priority: Major > Labels: GeodeCommons > Fix For: 1.12.0 > > Time Spent: 20m > Remaining Estimate: 0h > > The tomcat client server session module test failed: > [warn 2019/12/12 20:57:59.795 PST tid=0x10] Thread <39> > (0x27) that was executed at <12 Dec 2019 20:55:00 PST> has been stuck for > <178.813 seconds> and number of thread monitor iteration <2> > Thread Name state > Waiting on > > Owned By with ID <1> > Executor Group > Monitored metric > Thread Stack: > sun.misc.Unsafe.park(Native Method) > java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) > java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836) > java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997) > java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304) > java.util.concurrent.locks.ReentrantReadWriteLock$ReadLock.lockInterruptibly(ReentrantReadWriteLock.java:772) > org.apache.geode.management.internal.beans.ManagementListener.handleEvent(ManagementListener.java:116) > org.apache.geode.distributed.internal.InternalDistributedSystem.notifyResourceEventListeners(InternalDistributedSystem.java:2065) > org.apache.geode.distributed.internal.InternalDistributedSystem.handleResourceEvent(InternalDistributedSystem.java:606) > org.apache.geode.distributed.internal.locks.DLockService.init(DLockService.java:1915) > org.apache.geode.distributed.internal.locks.DLockService.basicCreate(DLockService.java:1892) > org.apache.geode.distributed.internal.locks.DLockService.create(DLockService.java:2710) > org.apache.geode.internal.cache.GemFireCacheImpl.getPartitionedRegionLockService(GemFireCacheImpl.java:1938) > org.apache.geode.internal.cache.DistributedRegion.(DistributedRegion.java:245) > org.apache.geode.internal.cache.GemFireCacheImpl.createVMRegion(GemFireCacheImpl.java:3009) > org.apache.geode.modules.util.CreateRegionFunction.createRegionConfigurationMetadataRegion(CreateRegionFunction.java:273) > org.apache.geode.modules.util.CreateRegionFunction.(CreateRegionFunction.java:63) > org.apache.geode.modules.util.BootstrappingFunction.registerFunctions(BootstrappingFunction.java:124) > org.apache.geode.modules.util.BootstrappingFunction.execute(BootstrappingFunction.java:67) > org.apache.geode.internal.cache.MemberFunctionStreamingMessage.process(MemberFunctionStreamingMessage.java:193) > org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:365) > org.apache.geode.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:429) > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > org.apache.geode.distributed.internal.ClusterDistributionManager.runUntilShutdown(ClusterDistributionManager.java:961) > org.apache.geode.distributed.internal.ClusterDistributionManager.doFunctionExecutionThread(ClusterDistributionManager.java:815) > org.apache.geode.distributed.internal.ClusterDistributionManager$$Lambda$52/1112527632.invoke(Unknown > Source) > org.apache.geode.internal.logging.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:121) > org.apache.geode.internal.logging.LoggingThreadFactory$$Lambda$42/973936431.run(Unknown > Source) > java.lang.Thread.run(Thread.java:748) > Was able to get a thread dump: > "Function Execution Processor3": > at sun.misc.Unsafe.park(Native Method) > - parking to wait for <0x0005c0732318> (a > java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync) > at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304) > at >
[jira] [Updated] (GEODE-7116) CI Failure: PartitionedRegionSingleHopDUnitTest > testServerLocationRemovalThroughPing
[ https://issues.apache.org/jira/browse/GEODE-7116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Hanson updated GEODE-7116: --- Labels: flaky (was: ) > CI Failure: PartitionedRegionSingleHopDUnitTest > > testServerLocationRemovalThroughPing > -- > > Key: GEODE-7116 > URL: https://issues.apache.org/jira/browse/GEODE-7116 > Project: Geode > Issue Type: Bug >Reporter: Donal Evans >Priority: Major > Labels: flaky > > https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK11/builds/1008 > org.apache.geode.internal.cache.PartitionedRegionSingleHopDUnitTest > > testServerLocationRemovalThroughPing FAILED > java.lang.AssertionError: expected:<4> but was:<0> > at org.junit.Assert.fail(Assert.java:88) > at org.junit.Assert.failNotEquals(Assert.java:834) > at org.junit.Assert.assertEquals(Assert.java:645) > at org.junit.Assert.assertEquals(Assert.java:631) > at > org.apache.geode.internal.cache.PartitionedRegionSingleHopDUnitTest.testServerLocationRemovalThroughPing(PartitionedRegionSingleHopDUnitTest.java:679) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7576) BootstrappingFunction should be executed after cache is fully created
[ https://issues.apache.org/jira/browse/GEODE-7576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17000263#comment-17000263 ] Eric Shu commented on GEODE-7576: - This issue no longer valid for now as removing synchronization lock form CacheFactory.getAnyInstance() via CacheFactoryStatics is backed out. More effort is need to investigate whether removing synchronization is a valid option. > BootstrappingFunction should be executed after cache is fully created > - > > Key: GEODE-7576 > URL: https://issues.apache.org/jira/browse/GEODE-7576 > Project: Geode > Issue Type: Bug > Components: functions >Affects Versions: 1.11.0 >Reporter: Eric Shu >Assignee: Eric Shu >Priority: Major > Labels: GeodeCommons > Time Spent: 20m > Remaining Estimate: 0h > > The tomcat client server session module test failed: > [warn 2019/12/12 20:57:59.795 PST tid=0x10] Thread <39> > (0x27) that was executed at <12 Dec 2019 20:55:00 PST> has been stuck for > <178.813 seconds> and number of thread monitor iteration <2> > Thread Name state > Waiting on > > Owned By with ID <1> > Executor Group > Monitored metric > Thread Stack: > sun.misc.Unsafe.park(Native Method) > java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) > java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836) > java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997) > java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304) > java.util.concurrent.locks.ReentrantReadWriteLock$ReadLock.lockInterruptibly(ReentrantReadWriteLock.java:772) > org.apache.geode.management.internal.beans.ManagementListener.handleEvent(ManagementListener.java:116) > org.apache.geode.distributed.internal.InternalDistributedSystem.notifyResourceEventListeners(InternalDistributedSystem.java:2065) > org.apache.geode.distributed.internal.InternalDistributedSystem.handleResourceEvent(InternalDistributedSystem.java:606) > org.apache.geode.distributed.internal.locks.DLockService.init(DLockService.java:1915) > org.apache.geode.distributed.internal.locks.DLockService.basicCreate(DLockService.java:1892) > org.apache.geode.distributed.internal.locks.DLockService.create(DLockService.java:2710) > org.apache.geode.internal.cache.GemFireCacheImpl.getPartitionedRegionLockService(GemFireCacheImpl.java:1938) > org.apache.geode.internal.cache.DistributedRegion.(DistributedRegion.java:245) > org.apache.geode.internal.cache.GemFireCacheImpl.createVMRegion(GemFireCacheImpl.java:3009) > org.apache.geode.modules.util.CreateRegionFunction.createRegionConfigurationMetadataRegion(CreateRegionFunction.java:273) > org.apache.geode.modules.util.CreateRegionFunction.(CreateRegionFunction.java:63) > org.apache.geode.modules.util.BootstrappingFunction.registerFunctions(BootstrappingFunction.java:124) > org.apache.geode.modules.util.BootstrappingFunction.execute(BootstrappingFunction.java:67) > org.apache.geode.internal.cache.MemberFunctionStreamingMessage.process(MemberFunctionStreamingMessage.java:193) > org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:365) > org.apache.geode.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:429) > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > org.apache.geode.distributed.internal.ClusterDistributionManager.runUntilShutdown(ClusterDistributionManager.java:961) > org.apache.geode.distributed.internal.ClusterDistributionManager.doFunctionExecutionThread(ClusterDistributionManager.java:815) > org.apache.geode.distributed.internal.ClusterDistributionManager$$Lambda$52/1112527632.invoke(Unknown > Source) > org.apache.geode.internal.logging.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:121) > org.apache.geode.internal.logging.LoggingThreadFactory$$Lambda$42/973936431.run(Unknown > Source) > java.lang.Thread.run(Thread.java:748) > Was able to get a thread dump: > "Function Execution Processor3": > at sun.misc.Unsafe.park(Native Method) > - parking to wait for <0x0005c0732318> (a > java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync) > at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997) > at >
[jira] [Updated] (GEODE-7576) BootstrappingFunction should be executed after cache is fully created
[ https://issues.apache.org/jira/browse/GEODE-7576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Shu updated GEODE-7576: Affects Version/s: (was: 1.11.0) 1.12.0 > BootstrappingFunction should be executed after cache is fully created > - > > Key: GEODE-7576 > URL: https://issues.apache.org/jira/browse/GEODE-7576 > Project: Geode > Issue Type: Bug > Components: functions >Affects Versions: 1.12.0 >Reporter: Eric Shu >Assignee: Eric Shu >Priority: Major > Labels: GeodeCommons > Time Spent: 20m > Remaining Estimate: 0h > > The tomcat client server session module test failed: > [warn 2019/12/12 20:57:59.795 PST tid=0x10] Thread <39> > (0x27) that was executed at <12 Dec 2019 20:55:00 PST> has been stuck for > <178.813 seconds> and number of thread monitor iteration <2> > Thread Name state > Waiting on > > Owned By with ID <1> > Executor Group > Monitored metric > Thread Stack: > sun.misc.Unsafe.park(Native Method) > java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) > java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836) > java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997) > java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304) > java.util.concurrent.locks.ReentrantReadWriteLock$ReadLock.lockInterruptibly(ReentrantReadWriteLock.java:772) > org.apache.geode.management.internal.beans.ManagementListener.handleEvent(ManagementListener.java:116) > org.apache.geode.distributed.internal.InternalDistributedSystem.notifyResourceEventListeners(InternalDistributedSystem.java:2065) > org.apache.geode.distributed.internal.InternalDistributedSystem.handleResourceEvent(InternalDistributedSystem.java:606) > org.apache.geode.distributed.internal.locks.DLockService.init(DLockService.java:1915) > org.apache.geode.distributed.internal.locks.DLockService.basicCreate(DLockService.java:1892) > org.apache.geode.distributed.internal.locks.DLockService.create(DLockService.java:2710) > org.apache.geode.internal.cache.GemFireCacheImpl.getPartitionedRegionLockService(GemFireCacheImpl.java:1938) > org.apache.geode.internal.cache.DistributedRegion.(DistributedRegion.java:245) > org.apache.geode.internal.cache.GemFireCacheImpl.createVMRegion(GemFireCacheImpl.java:3009) > org.apache.geode.modules.util.CreateRegionFunction.createRegionConfigurationMetadataRegion(CreateRegionFunction.java:273) > org.apache.geode.modules.util.CreateRegionFunction.(CreateRegionFunction.java:63) > org.apache.geode.modules.util.BootstrappingFunction.registerFunctions(BootstrappingFunction.java:124) > org.apache.geode.modules.util.BootstrappingFunction.execute(BootstrappingFunction.java:67) > org.apache.geode.internal.cache.MemberFunctionStreamingMessage.process(MemberFunctionStreamingMessage.java:193) > org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:365) > org.apache.geode.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:429) > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > org.apache.geode.distributed.internal.ClusterDistributionManager.runUntilShutdown(ClusterDistributionManager.java:961) > org.apache.geode.distributed.internal.ClusterDistributionManager.doFunctionExecutionThread(ClusterDistributionManager.java:815) > org.apache.geode.distributed.internal.ClusterDistributionManager$$Lambda$52/1112527632.invoke(Unknown > Source) > org.apache.geode.internal.logging.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:121) > org.apache.geode.internal.logging.LoggingThreadFactory$$Lambda$42/973936431.run(Unknown > Source) > java.lang.Thread.run(Thread.java:748) > Was able to get a thread dump: > "Function Execution Processor3": > at sun.misc.Unsafe.park(Native Method) > - parking to wait for <0x0005c0732318> (a > java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync) > at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304) > at >
[jira] [Updated] (GEODE-7098) Tomcat8SessionsClientServerDUnitTest fails with ConnectException
[ https://issues.apache.org/jira/browse/GEODE-7098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Hanson updated GEODE-7098: --- Labels: flaky (was: ) > Tomcat8SessionsClientServerDUnitTest fails with ConnectException > > > Key: GEODE-7098 > URL: https://issues.apache.org/jira/browse/GEODE-7098 > Project: Geode > Issue Type: Bug >Reporter: Benjamin P Ross >Priority: Major > Labels: flaky > > We've seen Tomcat8SessionsClientServerDUnitTest.testExtraSessionsNotCreated > fail with > a ConnectException > org.apache.geode.modules.session.Tomcat8SessionsClientServerDUnitTest > > testExtraSessionsNotCreated FAILED > java.net.ConnectException: Connection refused (Connection refused) > Caused by: > java.net.ConnectException: Connection refused (Connection refused) > This could be an environmental error, but if a pattern develops it could be > due to a flaky test. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-6014) Remove unnecessary null checks in the code.
[ https://issues.apache.org/jira/browse/GEODE-6014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dick Cavender updated GEODE-6014: - Fix Version/s: 1.11.0 > Remove unnecessary null checks in the code. > --- > > Key: GEODE-6014 > URL: https://issues.apache.org/jira/browse/GEODE-6014 > Project: Geode > Issue Type: Bug >Reporter: Nabarun Nag >Priority: Major > Labels: pull-request-available > Fix For: 1.11.0 > > Time Spent: 3h > Remaining Estimate: 0h > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7098) Tomcat8SessionsClientServerDUnitTest fails with ConnectException
[
https://issues.apache.org/jira/browse/GEODE-7098?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17000258#comment-17000258
]
Mark Hanson commented on GEODE-7098:
testInvalidate
[https://concourse.apachegeode-ci.info/teams/main/pipelines/mhansonp-mhanson-mass-test-ru-main/jobs/DistributedTestOpenJDK8/builds/2199]
{noformat}
03:17:38org.apache.geode.modules.session.Tomcat8SessionsClientServerDUnitTest >
testInvalidate FAILED
03:17:38java.net.ConnectException: Connection refused (Connection refused)
03:17:38
03:17:38Caused by:
03:17:38java.net.ConnectException: Connection refused (Connection
refused)
03:18:23
03:18:2330 tests completed, 1 failed {noformat}
testCallback
[https://concourse.apachegeode-ci.info/teams/main/pipelines/mhansonp-mhanson-mass-test-ru-main/jobs/DistributedTestOpenJDK8/builds/2166]
{noformat}
org.apache.geode.modules.session.Tomcat8SessionsClientServerDUnitTest >
testCallback FAILED
12:34:53java.net.ConnectException: Connection refused (Connection refused)
12:34:53
12:34:53Caused by:
12:34:53java.net.ConnectException: Connection refused (Connection
refused)
12:38:05 {noformat}
> Tomcat8SessionsClientServerDUnitTest fails with ConnectException
>
>
> Key: GEODE-7098
> URL: https://issues.apache.org/jira/browse/GEODE-7098
> Project: Geode
> Issue Type: Bug
>Reporter: Benjamin P Ross
>Priority: Major
>
> We've seen Tomcat8SessionsClientServerDUnitTest.testExtraSessionsNotCreated
> fail with
> a ConnectException
> org.apache.geode.modules.session.Tomcat8SessionsClientServerDUnitTest >
> testExtraSessionsNotCreated FAILED
> java.net.ConnectException: Connection refused (Connection refused)
> Caused by:
> java.net.ConnectException: Connection refused (Connection refused)
> This could be an environmental error, but if a pattern develops it could be
> due to a flaky test.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-7604) QueryConfigurationServiceConstraintsDistributedTest
[
https://issues.apache.org/jira/browse/GEODE-7604?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Hanson updated GEODE-7604:
---
Labels: flaky (was: )
> QueryConfigurationServiceConstraintsDistributedTest
> ---
>
> Key: GEODE-7604
> URL: https://issues.apache.org/jira/browse/GEODE-7604
> Project: Geode
> Issue Type: Bug
> Components: tests
>Reporter: Mark Hanson
>Priority: Major
> Labels: flaky
>
> QueryConfigurationServiceConstraintsDistributedTest had two failures in the
> mass test run...
> [2]
> https://concourse.apachegeode-ci.info/teams/main/pipelines/mhansonp-mhanson-mass-test-ru-main/jobs/DistributedTestOpenJDK8/builds/2252
> [6]
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/mhansonp-mhanson-mass-test-ru-main/jobs/DistributedTestOpenJDK8/builds/2211]
>
> {noformat}
> 01:28:56org.apache.geode.cache.query.internal.QueryConfigurationServiceConstraintsDistributedTest
> > [2]
> cqsShouldSucceedDuringEventProcessingAfterRegionOperationWhenMethodAuthorizerIsChangedAndQueryContainsMethodsAllowedByTheNewAuthorizer(RegionType:REPLICATE;Operation:CREATE,ExecuteWithInitialResults:true)
> FAILED
> 01:28:56org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.cache.query.internal.QueryConfigurationServiceConstraintsDistributedTest$$Lambda$57/2082907347.run
> in VM 2 running on Host 8cbcba2ac2b2 with 4 VMs
> 01:28:56at
> org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:610)
> 01:28:56at org.apache.geode.test.dunit.VM.invoke(VM.java:437)
> 01:28:56at
> org.apache.geode.test.junit.rules.VMProvider.invoke(VMProvider.java:94)
> 01:28:56at
> org.apache.geode.cache.query.internal.QueryConfigurationServiceConstraintsDistributedTest.cqsShouldSucceedDuringEventProcessingAfterRegionOperationWhenMethodAuthorizerIsChangedAndQueryContainsMethodsAllowedByTheNewAuthorizer(QueryConfigurationServiceConstraintsDistributedTest.java:260)
> 01:28:56
> 01:28:56Caused by:
> 01:28:56org.awaitility.core.ConditionTimeoutException: Assertion
> condition defined as a
> org.apache.geode.cache.query.internal.QueryConfigurationServiceConstraintsDistributedTest
> expected:<[7]> but was:<[4]> within 300 seconds.
> 01:28:56at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:145)
> 01:28:56at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:122)
> 01:28:56at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:32)
> 01:28:56at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:902)
> 01:28:56at
> org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:723)
> 01:28:56at
> org.apache.geode.cache.query.internal.QueryConfigurationServiceConstraintsDistributedTest.lambda$cqsShouldSucceedDuringEventProcessingAfterRegionOperationWhenMethodAuthorizerIsChangedAndQueryContainsMethodsAllowedByTheNewAuthorizer$868d1d80$1(QueryConfigurationServiceConstraintsDistributedTest.java:264)
> 01:28:56
> 01:28:56Caused by:
> 01:28:56org.junit.ComparisonFailure: expected:<[7]> but was:<[4]>
> 01:28:56at
> sun.reflect.GeneratedConstructorAccessor207.newInstance(Unknown Source)
> 01:28:56at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> 01:28:56at
> org.apache.geode.cache.query.internal.QueryConfigurationServiceConstraintsDistributedTest.lambda$null$13(QueryConfigurationServiceConstraintsDistributedTest.java:266)
> 02:03:51
> 02:03:51679 tests completed, 1 failed, 39 skipped {noformat}
>
>
> {noformat}
> 07:59:46org.apache.geode.cache.query.internal.QueryConfigurationServiceConstraintsDistributedTest
> > [6]
> cqsShouldFailDuringEventProcessingAfterRegionOperationWhenMethodAuthorizerIsChangedAndQueryContainsMethodsNotAllowedByTheNewAuthorizer(RegionType:REPLICATE;Operation:DESTROY,ExecuteWithInitialResults:true)
> FAILED
> 07:59:46org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.cache.query.internal.QueryConfigurationServiceConstraintsDistributedTest$$Lambda$33/1244479648.run
> in VM 2 running on Host 4f921f4602aa with 4 VMs
> 07:59:46at
> org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:610)
> 07:59:46at org.apache.geode.test.dunit.VM.invoke(VM.java:437)
> 07:59:46at
> org.apache.geode.test.junit.rules.VMProvider.invoke(VMProvider.java:94)
> 07:59:46at
>
[jira] [Created] (GEODE-7604) QueryConfigurationServiceConstraintsDistributedTest
Mark Hanson created GEODE-7604:
--
Summary: QueryConfigurationServiceConstraintsDistributedTest
Key: GEODE-7604
URL: https://issues.apache.org/jira/browse/GEODE-7604
Project: Geode
Issue Type: Bug
Components: tests
Reporter: Mark Hanson
QueryConfigurationServiceConstraintsDistributedTest had two failures in the
mass test run...
[2]
https://concourse.apachegeode-ci.info/teams/main/pipelines/mhansonp-mhanson-mass-test-ru-main/jobs/DistributedTestOpenJDK8/builds/2252
[6]
[https://concourse.apachegeode-ci.info/teams/main/pipelines/mhansonp-mhanson-mass-test-ru-main/jobs/DistributedTestOpenJDK8/builds/2211]
{noformat}
01:28:56org.apache.geode.cache.query.internal.QueryConfigurationServiceConstraintsDistributedTest
> [2]
cqsShouldSucceedDuringEventProcessingAfterRegionOperationWhenMethodAuthorizerIsChangedAndQueryContainsMethodsAllowedByTheNewAuthorizer(RegionType:REPLICATE;Operation:CREATE,ExecuteWithInitialResults:true)
FAILED
01:28:56org.apache.geode.test.dunit.RMIException: While invoking
org.apache.geode.cache.query.internal.QueryConfigurationServiceConstraintsDistributedTest$$Lambda$57/2082907347.run
in VM 2 running on Host 8cbcba2ac2b2 with 4 VMs
01:28:56at
org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:610)
01:28:56at org.apache.geode.test.dunit.VM.invoke(VM.java:437)
01:28:56at
org.apache.geode.test.junit.rules.VMProvider.invoke(VMProvider.java:94)
01:28:56at
org.apache.geode.cache.query.internal.QueryConfigurationServiceConstraintsDistributedTest.cqsShouldSucceedDuringEventProcessingAfterRegionOperationWhenMethodAuthorizerIsChangedAndQueryContainsMethodsAllowedByTheNewAuthorizer(QueryConfigurationServiceConstraintsDistributedTest.java:260)
01:28:56
01:28:56Caused by:
01:28:56org.awaitility.core.ConditionTimeoutException: Assertion
condition defined as a
org.apache.geode.cache.query.internal.QueryConfigurationServiceConstraintsDistributedTest
expected:<[7]> but was:<[4]> within 300 seconds.
01:28:56at
org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:145)
01:28:56at
org.awaitility.core.AssertionCondition.await(AssertionCondition.java:122)
01:28:56at
org.awaitility.core.AssertionCondition.await(AssertionCondition.java:32)
01:28:56at
org.awaitility.core.ConditionFactory.until(ConditionFactory.java:902)
01:28:56at
org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:723)
01:28:56at
org.apache.geode.cache.query.internal.QueryConfigurationServiceConstraintsDistributedTest.lambda$cqsShouldSucceedDuringEventProcessingAfterRegionOperationWhenMethodAuthorizerIsChangedAndQueryContainsMethodsAllowedByTheNewAuthorizer$868d1d80$1(QueryConfigurationServiceConstraintsDistributedTest.java:264)
01:28:56
01:28:56Caused by:
01:28:56org.junit.ComparisonFailure: expected:<[7]> but was:<[4]>
01:28:56at
sun.reflect.GeneratedConstructorAccessor207.newInstance(Unknown Source)
01:28:56at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
01:28:56at
org.apache.geode.cache.query.internal.QueryConfigurationServiceConstraintsDistributedTest.lambda$null$13(QueryConfigurationServiceConstraintsDistributedTest.java:266)
02:03:51
02:03:51679 tests completed, 1 failed, 39 skipped {noformat}
{noformat}
07:59:46org.apache.geode.cache.query.internal.QueryConfigurationServiceConstraintsDistributedTest
> [6]
cqsShouldFailDuringEventProcessingAfterRegionOperationWhenMethodAuthorizerIsChangedAndQueryContainsMethodsNotAllowedByTheNewAuthorizer(RegionType:REPLICATE;Operation:DESTROY,ExecuteWithInitialResults:true)
FAILED
07:59:46org.apache.geode.test.dunit.RMIException: While invoking
org.apache.geode.cache.query.internal.QueryConfigurationServiceConstraintsDistributedTest$$Lambda$33/1244479648.run
in VM 2 running on Host 4f921f4602aa with 4 VMs
07:59:46at
org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:610)
07:59:46at org.apache.geode.test.dunit.VM.invoke(VM.java:437)
07:59:46at
org.apache.geode.test.junit.rules.VMProvider.invoke(VMProvider.java:94)
07:59:46at
org.apache.geode.cache.query.internal.QueryConfigurationServiceConstraintsDistributedTest.cqsShouldFailDuringEventProcessingAfterRegionOperationWhenMethodAuthorizerIsChangedAndQueryContainsMethodsNotAllowedByTheNewAuthorizer(QueryConfigurationServiceConstraintsDistributedTest.java:304)
07:59:46
07:59:46Caused by:
07:59:46org.awaitility.core.ConditionTimeoutException: Assertion
condition defined as a
org.apache.geode.cache.query.internal.QueryConfigurationServiceConstraintsDistributedTest
expected:<[7]> but was:<[6]> within 300 seconds.
07:59:46at
[jira] [Updated] (GEODE-7603) RepeatedRebalanceDUnitTest.testSecondRebalanceIsNotNecessaryWithAddedAndRestartedMembers
[
https://issues.apache.org/jira/browse/GEODE-7603?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Hanson updated GEODE-7603:
---
Labels: flaky (was: )
> RepeatedRebalanceDUnitTest.testSecondRebalanceIsNotNecessaryWithAddedAndRestartedMembers
>
>
> Key: GEODE-7603
> URL: https://issues.apache.org/jira/browse/GEODE-7603
> Project: Geode
> Issue Type: Bug
> Components: tests
>Reporter: Mark Hanson
>Priority: Major
> Labels: flaky
>
> RepeatedRebalanceDUnitTest.testSecondRebalanceIsNotNecessaryWithAddedAndRestartedMembers
> failed twice as a part of the mass test run.
> https://concourse.apachegeode-ci.info/teams/main/pipelines/mhansonp-mhanson-mass-test-ru-main/jobs/DistributedTestOpenJDK8/builds/2160
> https://concourse.apachegeode-ci.info/teams/main/pipelines/mhansonp-mhanson-mass-test-ru-main/jobs/DistributedTestOpenJDK8/builds/2130
>
> {noformat}
> 10:56:44org.apache.geode.management.internal.cli.commands.RepeatedRebalanceDUnitTest
> > testSecondRebalanceIsNotNecessaryWithAddedAndRestartedMembers FAILED
> 10:56:44java.lang.AssertionError: [List check last element]
> 10:56:44Expecting:
> 10:56:44 <"0">
> 10:56:44not to be equal to:
> 10:56:44 <"0">
> 10:56:44at
> org.apache.geode.management.internal.cli.commands.RepeatedRebalanceDUnitTest.assertPrimariesTransfered(RepeatedRebalanceDUnitTest.java:204)
> 10:56:44at
> org.apache.geode.management.internal.cli.commands.RepeatedRebalanceDUnitTest.testSecondRebalanceIsNotNecessaryWithAddedAndRestartedMembers(RepeatedRebalanceDUnitTest.java:124)
> 11:06:20
> 11:06:20352 tests completed, 1 failed, 5 skipped
> 11:06:22
> 11:06:22> Task :geode-gfsh:distributedTest FAILED
> 11:54:40
> 11:54:40> Task :geode-core:distributedTest
> 11:54:40
> 11:54:40org.apache.geode.management.JMXMBeanReconnectDUnitTest >
> testRemoteBeanKnowledge_MaintainServerAndCrashLocator FAILED
> 11:54:40org.awaitility.core.ConditionTimeoutException: Condition with
> alias 'Locators must agree on the state of the system' didn't complete within
> 300 seconds because assertion condition defined as a lambda expression in
> org.apache.geode.management.JMXMBeanReconnectDUnitTest
> 11:54:40Expecting:
> 11:54:40 <[GemFire:service=Region,name="/test-region-1",type=Distributed,
> 11:54:40
> GemFire:service=LockService,name=__CLUSTER_CONFIG_LS,type=Distributed,
> 11:54:40GemFire:service=AccessControl,type=Distributed,
> 11:54:40GemFire:service=FileUploader,type=Distributed,
> 11:54:40GemFire:service=System,type=Distributed,
> 11:54:40
> GemFire:service=LockService,name=__CLUSTER_CONFIG_LS,type=Member,member=locator-0,
> 11:54:40
> GemFire:service=DiskStore,name=cluster_config,type=Member,member=locator-0,
> 11:54:40GemFire:service=Locator,type=Member,member=locator-0,
> 11:54:40GemFire:type=Member,member=locator-0,
> 11:54:40
> GemFire:service=LockService,name=__CLUSTER_CONFIG_LS,type=Member,member=locator-1,
> 11:54:40
> GemFire:service=DiskStore,name=cluster_config,type=Member,member=locator-1,
> 11:54:40GemFire:service=Locator,type=Member,member=locator-1,
> 11:54:40GemFire:type=Member,member=locator-1,
> 11:54:40
> GemFire:service=Region,name="/test-region-1",type=Member,member=server-2,
> 11:54:40
> GemFire:service=CacheServer,port=45477,type=Member,member=server-2,
> 11:54:40GemFire:type=Member,member=server-2,
> 11:54:40
> GemFire:service=Region,name="/test-region-1",type=Member,member=server-3,
> 11:54:40
> GemFire:service=CacheServer,port=34171,type=Member,member=server-3,
> 11:54:40GemFire:type=Member,member=server-3]>
> 11:54:40to contain exactly (and in same order):
> 11:54:40 <[GemFire:service=Region,name="/test-region-1",type=Distributed,
> 11:54:40
> GemFire:service=LockService,name=__CLUSTER_CONFIG_LS,type=Distributed,
> 11:54:40GemFire:service=AccessControl,type=Distributed,
> 11:54:40GemFire:service=FileUploader,type=Distributed,
> 11:54:40GemFire:service=System,type=Distributed,
> 11:54:40GemFire:service=Locator,type=Member,member=locator-0,
> 11:54:40GemFire:type=Member,member=locator-0,
> 11:54:40
> GemFire:service=LockService,name=__CLUSTER_CONFIG_LS,type=Member,member=locator-1,
> 11:54:40
> GemFire:service=DiskStore,name=cluster_config,type=Member,member=locator-1,
> 11:54:40GemFire:service=Locator,type=Member,member=locator-1,
> 11:54:40GemFire:type=Member,member=locator-1,
> 11:54:40
> GemFire:service=Region,name="/test-region-1",type=Member,member=server-2,
> 11:54:40
>
[jira] [Created] (GEODE-7603) RepeatedRebalanceDUnitTest.testSecondRebalanceIsNotNecessaryWithAddedAndRestartedMembers
Mark Hanson created GEODE-7603:
--
Summary:
RepeatedRebalanceDUnitTest.testSecondRebalanceIsNotNecessaryWithAddedAndRestartedMembers
Key: GEODE-7603
URL: https://issues.apache.org/jira/browse/GEODE-7603
Project: Geode
Issue Type: Bug
Components: tests
Reporter: Mark Hanson
RepeatedRebalanceDUnitTest.testSecondRebalanceIsNotNecessaryWithAddedAndRestartedMembers
failed twice as a part of the mass test run.
https://concourse.apachegeode-ci.info/teams/main/pipelines/mhansonp-mhanson-mass-test-ru-main/jobs/DistributedTestOpenJDK8/builds/2160
https://concourse.apachegeode-ci.info/teams/main/pipelines/mhansonp-mhanson-mass-test-ru-main/jobs/DistributedTestOpenJDK8/builds/2130
{noformat}
10:56:44org.apache.geode.management.internal.cli.commands.RepeatedRebalanceDUnitTest
> testSecondRebalanceIsNotNecessaryWithAddedAndRestartedMembers FAILED
10:56:44java.lang.AssertionError: [List check last element]
10:56:44Expecting:
10:56:44 <"0">
10:56:44not to be equal to:
10:56:44 <"0">
10:56:44at
org.apache.geode.management.internal.cli.commands.RepeatedRebalanceDUnitTest.assertPrimariesTransfered(RepeatedRebalanceDUnitTest.java:204)
10:56:44at
org.apache.geode.management.internal.cli.commands.RepeatedRebalanceDUnitTest.testSecondRebalanceIsNotNecessaryWithAddedAndRestartedMembers(RepeatedRebalanceDUnitTest.java:124)
11:06:20
11:06:20352 tests completed, 1 failed, 5 skipped
11:06:22
11:06:22> Task :geode-gfsh:distributedTest FAILED
11:54:40
11:54:40> Task :geode-core:distributedTest
11:54:40
11:54:40org.apache.geode.management.JMXMBeanReconnectDUnitTest >
testRemoteBeanKnowledge_MaintainServerAndCrashLocator FAILED
11:54:40org.awaitility.core.ConditionTimeoutException: Condition with alias
'Locators must agree on the state of the system' didn't complete within 300
seconds because assertion condition defined as a lambda expression in
org.apache.geode.management.JMXMBeanReconnectDUnitTest
11:54:40Expecting:
11:54:40 <[GemFire:service=Region,name="/test-region-1",type=Distributed,
11:54:40
GemFire:service=LockService,name=__CLUSTER_CONFIG_LS,type=Distributed,
11:54:40GemFire:service=AccessControl,type=Distributed,
11:54:40GemFire:service=FileUploader,type=Distributed,
11:54:40GemFire:service=System,type=Distributed,
11:54:40
GemFire:service=LockService,name=__CLUSTER_CONFIG_LS,type=Member,member=locator-0,
11:54:40
GemFire:service=DiskStore,name=cluster_config,type=Member,member=locator-0,
11:54:40GemFire:service=Locator,type=Member,member=locator-0,
11:54:40GemFire:type=Member,member=locator-0,
11:54:40
GemFire:service=LockService,name=__CLUSTER_CONFIG_LS,type=Member,member=locator-1,
11:54:40
GemFire:service=DiskStore,name=cluster_config,type=Member,member=locator-1,
11:54:40GemFire:service=Locator,type=Member,member=locator-1,
11:54:40GemFire:type=Member,member=locator-1,
11:54:40
GemFire:service=Region,name="/test-region-1",type=Member,member=server-2,
11:54:40
GemFire:service=CacheServer,port=45477,type=Member,member=server-2,
11:54:40GemFire:type=Member,member=server-2,
11:54:40
GemFire:service=Region,name="/test-region-1",type=Member,member=server-3,
11:54:40
GemFire:service=CacheServer,port=34171,type=Member,member=server-3,
11:54:40GemFire:type=Member,member=server-3]>
11:54:40to contain exactly (and in same order):
11:54:40 <[GemFire:service=Region,name="/test-region-1",type=Distributed,
11:54:40
GemFire:service=LockService,name=__CLUSTER_CONFIG_LS,type=Distributed,
11:54:40GemFire:service=AccessControl,type=Distributed,
11:54:40GemFire:service=FileUploader,type=Distributed,
11:54:40GemFire:service=System,type=Distributed,
11:54:40GemFire:service=Locator,type=Member,member=locator-0,
11:54:40GemFire:type=Member,member=locator-0,
11:54:40
GemFire:service=LockService,name=__CLUSTER_CONFIG_LS,type=Member,member=locator-1,
11:54:40
GemFire:service=DiskStore,name=cluster_config,type=Member,member=locator-1,
11:54:40GemFire:service=Locator,type=Member,member=locator-1,
11:54:40GemFire:type=Member,member=locator-1,
11:54:40
GemFire:service=Region,name="/test-region-1",type=Member,member=server-2,
11:54:40
GemFire:service=CacheServer,port=45477,type=Member,member=server-2,
11:54:40GemFire:type=Member,member=server-2,
11:54:40
GemFire:service=Region,name="/test-region-1",type=Member,member=server-3,
11:54:40
GemFire:service=CacheServer,port=34171,type=Member,member=server-3,
11:54:40GemFire:type=Member,member=server-3]>
11:54:40but some elements were not expected:
11:54:40
[jira] [Updated] (GEODE-7537) hang in gii/rebalance of AEQ in recycled server (with persistence)
[ https://issues.apache.org/jira/browse/GEODE-7537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Shu updated GEODE-7537: Fix Version/s: (was: 1.12.0) 1.11.0 > hang in gii/rebalance of AEQ in recycled server (with persistence) > -- > > Key: GEODE-7537 > URL: https://issues.apache.org/jira/browse/GEODE-7537 > Project: Geode > Issue Type: Bug > Components: lucene >Affects Versions: 1.9.0 >Reporter: Mark Hanson >Assignee: Eric Shu >Priority: Major > Labels: GeodeCommons > Fix For: 1.11.0 > > Time Spent: 1h > Remaining Estimate: 0h > > Actively being investigated... -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7135) Tomcat8SessionsDUnitTest > testSessionExpiration1 FAILED
[
https://issues.apache.org/jira/browse/GEODE-7135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17000237#comment-17000237
]
Owen Nichols commented on GEODE-7135:
-
Seen again in
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/1414
> Tomcat8SessionsDUnitTest > testSessionExpiration1 FAILED
>
>
> Key: GEODE-7135
> URL: https://issues.apache.org/jira/browse/GEODE-7135
> Project: Geode
> Issue Type: Bug
>Reporter: Murtuza Boxwala
>Priority: Major
> Labels: flaky
>
> {code:java}
> org.apache.geode.modules.session.Tomcat8SessionsDUnitTest >
> testSessionExpiration1 FAILED
> java.net.ConnectException: Connection refused (Connection refused)
> Caused by:
> java.net.ConnectException: Connection refused (Connection refused)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-7599) Use GCI Concourse resource to track compute image versions
[ https://issues.apache.org/jira/browse/GEODE-7599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17000239#comment-17000239 ] ASF subversion and git services commented on GEODE-7599: Commit 5113f5275494057750e82019c1b274c6b7e5b683 in geode's branch refs/heads/develop from Robert Houghton [ https://gitbox.apache.org/repos/asf?p=geode.git;h=5113f52 ] GEODE-7599 - Use Google Compute Image resource in Concourse. (#4504) * Parameterize gcp image-family-name. * Change geode-build template to set image-family-name. * Remove reduntant 'do' in pipeline definition. * Add image-family-name for pr and examples pipelines. * Remove intermediatary files when deploying meta pipeline. * Test jobs track when new compute image is used. * Use gci-resource correctly per platform image family Authored-by: Robert Houghton > Use GCI Concourse resource to track compute image versions > -- > > Key: GEODE-7599 > URL: https://issues.apache.org/jira/browse/GEODE-7599 > Project: Geode > Issue Type: Improvement > Components: ci >Reporter: Robert Houghton >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Use the Google Compute Image resource in concourse as an input to jobs that > use the heavy-lifter pattern. This will make it easier to track job failures > due to an image rebuild. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7593) Indexing pdx strings with eviction does not provide eviction benefits
[ https://issues.apache.org/jira/browse/GEODE-7593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17000232#comment-17000232 ] ASF subversion and git services commented on GEODE-7593: Commit 1beec9e3930a071031b960f045874fb337e72e7c in geode's branch refs/heads/develop from Jason Huynh [ https://gitbox.apache.org/repos/asf?p=geode.git;h=1beec9e ] GEODE-7593: Force index to use Strings instead of PdxStrings when eviction is enabled on region (#4500) > Indexing pdx strings with eviction does not provide eviction benefits > - > > Key: GEODE-7593 > URL: https://issues.apache.org/jira/browse/GEODE-7593 > Project: Geode > Issue Type: Bug > Components: querying >Reporter: Jason Huynh >Assignee: Jason Huynh >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > PdxStrings hold references to the values bytes. When the indexed key is a > pdx string, the index holds references in memory. Eviction will properly > evict the region entry's value but the index holds the values byte in memory > still. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-7601) Memory leaks in C++ native client found when running old integration-tests
[ https://issues.apache.org/jira/browse/GEODE-7601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alberto Gomez updated GEODE-7601: - Summary: Memory leaks in C++ native client found when running old integration-tests (was: Memory leaks in C++ native client) > Memory leaks in C++ native client found when running old integration-tests > -- > > Key: GEODE-7601 > URL: https://issues.apache.org/jira/browse/GEODE-7601 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Alberto Gomez >Assignee: Alberto Gomez >Priority: Major > Fix For: 1.12.0 > > > Some memory leaks, invalid reads and mismatched free / delete delete[] errors > are reported by valgrind when running the old integration tests > (integration-test). > Lots of memory issues are also found in the testing framework which makes it > hard to identify the errors in the native client. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-7601) Memory leaks in C++ native client
Alberto Gomez created GEODE-7601: Summary: Memory leaks in C++ native client Key: GEODE-7601 URL: https://issues.apache.org/jira/browse/GEODE-7601 Project: Geode Issue Type: Bug Components: native client Reporter: Alberto Gomez Fix For: 1.12.0 Some memory leaks, invalid reads and mismatched free / delete delete[] errors are reported by valgrind when running the old integration tests (integration-test). Lots of memory issues are also found in the testing framework which makes it hard to identify the errors in the native client. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-7601) Memory leaks in C++ native client
[ https://issues.apache.org/jira/browse/GEODE-7601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alberto Gomez reassigned GEODE-7601: Assignee: Alberto Gomez > Memory leaks in C++ native client > - > > Key: GEODE-7601 > URL: https://issues.apache.org/jira/browse/GEODE-7601 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Alberto Gomez >Assignee: Alberto Gomez >Priority: Major > Fix For: 1.12.0 > > > Some memory leaks, invalid reads and mismatched free / delete delete[] errors > are reported by valgrind when running the old integration tests > (integration-test). > Lots of memory issues are also found in the testing framework which makes it > hard to identify the errors in the native client. -- This message was sent by Atlassian Jira (v8.3.4#803005)
