[jira] [Commented] (GEODE-7064) Increase timeout from 10 to 20 minutes on UnitTestX execute_test task in Concourse
[ https://issues.apache.org/jira/browse/GEODE-7064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16911852#comment-16911852 ] ASF subversion and git services commented on GEODE-7064: Commit e8372917a1c9037279b2d647fa621e94c10ebb64 in geode's branch refs/heads/release/1.9.1 from Ryan McMahon [ https://gitbox.apache.org/repos/asf?p=geode.git;h=e837291 ] GEODE-7064: Increase timeout to 30m for UnitTest Execute Tests task (#3900) * GEODE-7064: Increase timeout to 30m for UnitTest Execute Tests task (cherry picked from commit c2940cb3e2dd770995221ce432837c5fa840054a) (cherry picked from commit 6a5904fe8219b743c86fd911797dd41cc8158263) > Increase timeout from 10 to 20 minutes on UnitTestX execute_test task in > Concourse > -- > > Key: GEODE-7064 > URL: https://issues.apache.org/jira/browse/GEODE-7064 > Project: Geode > Issue Type: Improvement > Components: ci >Reporter: Ryan McMahon >Assignee: Ryan McMahon >Priority: Major > Time Spent: 40m > Remaining Estimate: 0h > > We have seen several timeouts in the execute_test task in UnitTestX jobs in > the CI which were found to be resolved by experimenting with increasing the > timeout. The community agreed we should increase the timeout from 10 to 20 > minutes to handle intermittent degradation of the performance of this task, > due to infrastructure issues or otherwise. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (GEODE-7064) Increase timeout from 10 to 20 minutes on UnitTestX execute_test task in Concourse
[ https://issues.apache.org/jira/browse/GEODE-7064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16911853#comment-16911853 ] ASF subversion and git services commented on GEODE-7064: Commit e8372917a1c9037279b2d647fa621e94c10ebb64 in geode's branch refs/heads/release/1.9.1 from Ryan McMahon [ https://gitbox.apache.org/repos/asf?p=geode.git;h=e837291 ] GEODE-7064: Increase timeout to 30m for UnitTest Execute Tests task (#3900) * GEODE-7064: Increase timeout to 30m for UnitTest Execute Tests task (cherry picked from commit c2940cb3e2dd770995221ce432837c5fa840054a) (cherry picked from commit 6a5904fe8219b743c86fd911797dd41cc8158263) > Increase timeout from 10 to 20 minutes on UnitTestX execute_test task in > Concourse > -- > > Key: GEODE-7064 > URL: https://issues.apache.org/jira/browse/GEODE-7064 > Project: Geode > Issue Type: Improvement > Components: ci >Reporter: Ryan McMahon >Assignee: Ryan McMahon >Priority: Major > Time Spent: 40m > Remaining Estimate: 0h > > We have seen several timeouts in the execute_test task in UnitTestX jobs in > the CI which were found to be resolved by experimenting with increasing the > timeout. The community agreed we should increase the timeout from 10 to 20 > minutes to handle intermittent degradation of the performance of this task, > due to infrastructure issues or otherwise. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (GEODE-7099) Clean up MeterSubregistryReconnectDistributedTest
[ https://issues.apache.org/jira/browse/GEODE-7099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16911835#comment-16911835 ] ASF subversion and git services commented on GEODE-7099: Commit 5a6c1f8ae14f661d8788c7e5e1a78d39385c2061 in geode's branch refs/heads/develop from Dale Emery [ https://gitbox.apache.org/repos/asf?p=geode.git;h=5a6c1f8 ] GEODE-7099: Clean up MeterSubregistryReconnectDistributedTest (#3942) Co-authored-by: Dale Emery Co-authored-by: Kirk Lund > 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 > Time Spent: 20m > Remaining Estimate: 0h > > Improve readability of the test. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (GEODE-3689) Unable to specify custom log4j configuration file from gfsh
[
https://issues.apache.org/jira/browse/GEODE-3689?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16911821#comment-16911821
]
Aaron Lindsey commented on GEODE-3689:
--
[~klund] does the work around splitting out log4j-core into a submodule fix
this issue?
> Unable to specify custom log4j configuration file from gfsh
> ---
>
> Key: GEODE-3689
> URL: https://issues.apache.org/jira/browse/GEODE-3689
> Project: Geode
> Issue Type: Bug
> Components: gfsh, logging
>Reporter: Jens Deppe
>Assignee: Kirk Lund
>Priority: Major
>
> When starting a server with gfsh, it does not honor a log4j configuration
> location by specifying {{--J=-Dlog4j.configurationFile=/path/to/log4j2.xml}}.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Updated] (GEODE-3689) Unable to specify custom log4j configuration file from gfsh
[
https://issues.apache.org/jira/browse/GEODE-3689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aaron Lindsey updated GEODE-3689:
-
Labels: observability (was: )
> Unable to specify custom log4j configuration file from gfsh
> ---
>
> Key: GEODE-3689
> URL: https://issues.apache.org/jira/browse/GEODE-3689
> Project: Geode
> Issue Type: Bug
> Components: gfsh, logging
>Reporter: Jens Deppe
>Assignee: Kirk Lund
>Priority: Major
> Labels: observability
>
> When starting a server with gfsh, it does not honor a log4j configuration
> location by specifying {{--J=-Dlog4j.configurationFile=/path/to/log4j2.xml}}.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Updated] (GEODE-2946) Extend pulse data browser to support lucene queries
[ https://issues.apache.org/jira/browse/GEODE-2946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron Lindsey updated GEODE-2946: - Labels: observability (was: ) > Extend pulse data browser to support lucene queries > --- > > Key: GEODE-2946 > URL: https://issues.apache.org/jira/browse/GEODE-2946 > Project: Geode > Issue Type: New Feature > Components: lucene, pulse >Reporter: Shelley Lynn Hughes-Godfrey >Priority: Major > Labels: observability > > It would be nice to allow lucene queries through the pulse data browser -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Updated] (GEODE-2650) Need an integration test to scan logs for clear-text passwords
[ https://issues.apache.org/jira/browse/GEODE-2650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron Lindsey updated GEODE-2650: - Labels: observability (was: ) > Need an integration test to scan logs for clear-text passwords > -- > > Key: GEODE-2650 > URL: https://issues.apache.org/jira/browse/GEODE-2650 > Project: Geode > Issue Type: Improvement > Components: gfsh, logging >Reporter: Kevin Duling >Priority: Major > Labels: observability > > This issue keeps creeping up, so it would be good to have a test that scans > log files for any password in the clear. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (GEODE-2299) Integrate Geode with Grafana for historical and real-time metrics analysis
[ https://issues.apache.org/jira/browse/GEODE-2299?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16911817#comment-16911817 ] Aaron Lindsey commented on GEODE-2299: -- With the addition of Micrometer, you can now integrate with different time-series databases which can be read by Grafana or other visualization tools. > Integrate Geode with Grafana for historical and real-time metrics analysis > -- > > Key: GEODE-2299 > URL: https://issues.apache.org/jira/browse/GEODE-2299 > Project: Geode > Issue Type: Improvement > Components: docs, jmx, management, pulse, statistics >Reporter: Christian Tzolov >Priority: Major > > Use Grafana dashboards for querying, visualizing and analysing Apache Geode > statistics archives and JMX real-time metrics. > Solution should provide unified technical stack for visualizing and analysing > both real-time (e.g JMX metrics) and historical (archive files) cluster > statistics. > Initial work: https://github.com/tzolov/geode-dashboard -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Assigned] (GEODE-2299) Integrate Geode with Grafana for historical and real-time metrics analysis
[ https://issues.apache.org/jira/browse/GEODE-2299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron Lindsey reassigned GEODE-2299: Assignee: Nick Vallely (was: Aaron Lindsey) > Integrate Geode with Grafana for historical and real-time metrics analysis > -- > > Key: GEODE-2299 > URL: https://issues.apache.org/jira/browse/GEODE-2299 > Project: Geode > Issue Type: Improvement > Components: docs, jmx, management, pulse, statistics >Reporter: Christian Tzolov >Assignee: Nick Vallely >Priority: Major > > Use Grafana dashboards for querying, visualizing and analysing Apache Geode > statistics archives and JMX real-time metrics. > Solution should provide unified technical stack for visualizing and analysing > both real-time (e.g JMX metrics) and historical (archive files) cluster > statistics. > Initial work: https://github.com/tzolov/geode-dashboard -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Assigned] (GEODE-2299) Integrate Geode with Grafana for historical and real-time metrics analysis
[ https://issues.apache.org/jira/browse/GEODE-2299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron Lindsey reassigned GEODE-2299: Assignee: Aaron Lindsey > Integrate Geode with Grafana for historical and real-time metrics analysis > -- > > Key: GEODE-2299 > URL: https://issues.apache.org/jira/browse/GEODE-2299 > Project: Geode > Issue Type: Improvement > Components: docs, jmx, management, pulse, statistics >Reporter: Christian Tzolov >Assignee: Aaron Lindsey >Priority: Major > > Use Grafana dashboards for querying, visualizing and analysing Apache Geode > statistics archives and JMX real-time metrics. > Solution should provide unified technical stack for visualizing and analysing > both real-time (e.g JMX metrics) and historical (archive files) cluster > statistics. > Initial work: https://github.com/tzolov/geode-dashboard -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Updated] (GEODE-1444) Need a gfsh command/tool to analyze customer basic health
[ https://issues.apache.org/jira/browse/GEODE-1444?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron Lindsey updated GEODE-1444: - Component/s: (was: statistics) > Need a gfsh command/tool to analyze customer basic health > - > > Key: GEODE-1444 > URL: https://issues.apache.org/jira/browse/GEODE-1444 > Project: Geode > Issue Type: New Feature > Components: gfsh >Reporter: David Wisler >Priority: Major > > Customers have been increasingly asking for a nice gfsh command that will > assess the basic health of their systems to help stave off at the earliest > time any issues that might soon impact their clusters. > Such a command would greatly increase customer confidence that the system is > indeed operating within healthy parameters. In addition, it could be used by > the Global Support Team to greatly decrease the time spent attempting to > assess such health issues as we generally take the first 30 minutes > attempting to establish such basic health criteria prior to drilling down to > some specific issue. > It is my understanding the most recent Hack Day produced a small prototype of > such a command, created by the Lynn's and others. > Please take this and prioritize this work now that it has some footing. I > believe the benefits of this command would be very evident both externally, > becoming a part of customer runbooks, and internally for our teams trying to > discover Root Cause of many issues. > If you need some emails from customers for this one, let me know and I will > drive that forward. > Such a tool/command could be customized based upon what the customer wants to > monitor via use of the command. This could be configured using properties > and/or xml ultimately, or simply use a basic set of 5-10 statistics which can > be very effective an early indicators of issues impacting the system. > Can we take this prototype and drive it forward? I believe the benefit of > such a command would increase customer confidence greatly. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Assigned] (GEODE-1383) LogBanner is missing from rolled log files
[ https://issues.apache.org/jira/browse/GEODE-1383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron Lindsey reassigned GEODE-1383: Assignee: (was: Kirk Lund) > LogBanner is missing from rolled log files > -- > > Key: GEODE-1383 > URL: https://issues.apache.org/jira/browse/GEODE-1383 > Project: Geode > Issue Type: Bug > Components: logging >Reporter: Jens Deppe >Priority: Major > Labels: LogBanner, observability, starter > > Please add gemfire,heap, xml configuration information to start of every log > file > We often have situations where we have difficulty establishing the > configuration or JVM startup arguments, or XML configuration without multiple > interactions with the customer, even when they've provided logs. When the > customer has rolled over enough, and we overwrite the "parent" first log, we > then lose all of that detail from startup that often proves very helpful. > If it would be easy to incorporate this startup configuration information > into the beginning of each log file as we rollover, we would always have it > and be able to be more productive debugging prod issues and ultimately have > happier users. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Updated] (GEODE-1383) LogBanner is missing from rolled log files
[ https://issues.apache.org/jira/browse/GEODE-1383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron Lindsey updated GEODE-1383: - Labels: LogBanner observability starter (was: LogBanner starter) > LogBanner is missing from rolled log files > -- > > Key: GEODE-1383 > URL: https://issues.apache.org/jira/browse/GEODE-1383 > Project: Geode > Issue Type: Bug > Components: logging >Reporter: Jens Deppe >Assignee: Kirk Lund >Priority: Major > Labels: LogBanner, observability, starter > > Please add gemfire,heap, xml configuration information to start of every log > file > We often have situations where we have difficulty establishing the > configuration or JVM startup arguments, or XML configuration without multiple > interactions with the customer, even when they've provided logs. When the > customer has rolled over enough, and we overwrite the "parent" first log, we > then lose all of that detail from startup that often proves very helpful. > If it would be easy to incorporate this startup configuration information > into the beginning of each log file as we rollover, we would always have it > and be able to be more productive debugging prod issues and ultimately have > happier users. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Assigned] (GEODE-1210) MemberMBeanBridge DiskDirectoryStats are not monitored for PartitionedRegions
[
https://issues.apache.org/jira/browse/GEODE-1210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aaron Lindsey reassigned GEODE-1210:
Assignee: Barry Oglesby
Is this still an issue? If so, what is the expected behavior for a partitioned
region DiskDirectoryStats?
> MemberMBeanBridge DiskDirectoryStats are not monitored for PartitionedRegions
> -
>
> Key: GEODE-1210
> URL: https://issues.apache.org/jira/browse/GEODE-1210
> Project: Geode
> Issue Type: Bug
> Components: jmx
>Reporter: Barry Oglesby
>Assignee: Barry Oglesby
>Priority: Major
> Labels: observability
>
> This means that {{TotalDiskUsage}} is 0 for {{PartitionedRegions}}.
> The member's {{TotalDiskUsage}} JMX attribute comes from
> {{MemberMBeanBridge.getTotalDiskUsage}} which does:
> {noformat}
> public long getTotalDiskUsage() {
> long diskSpaceUsage = regionMonitor.getDiskSpace();
> return diskSpaceUsage;
> }
> {noformat}
> The {{regionMonitor}} gets the {{diskSpace}} by monitoring the
> {{DiskDirectoryStats}} of all its persistent {{Regions}}.
> For each region, {{MemberMBeanBridge.addRegion}} adds the
> {{DiskDirectoryStats}} of that region to its {{regionMonitor}}.
> If the region is a {{PartitionedRegion}}, then its {{DiskRegion}} is null
> since the {{DiskRegions}} are on the {{BucketRegions}} so no
> {{DiskDirectoryStats}} are monitored.
> This code in {{MemberMBeanBridge.addRegion}} falls through for
> {{PartitionedRegions}} since {{dr}} is null:
> {noformat}
> DiskRegion dr = l.getDiskRegion();
> if(dr != null){
> for(DirectoryHolder dh:dr.getDirectories()){
> addDirectoryStats(dh.getDiskDirectoryStats());
> }
> }
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Updated] (GEODE-1080) Move JettyHelper and related classes to a subproject
[ https://issues.apache.org/jira/browse/GEODE-1080?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron Lindsey updated GEODE-1080: - Labels: commons (was: ) > Move JettyHelper and related classes to a subproject > > > Key: GEODE-1080 > URL: https://issues.apache.org/jira/browse/GEODE-1080 > Project: Geode > Issue Type: Sub-task > Components: pulse, rest (admin), rest (dev) >Reporter: Dan Smith >Priority: Major > Labels: commons > > geode-core pulls in jetty because there is some code that bootstraps a > webserver for the REST, admin REST, and pulse web applications. > Those web applications shouldn't be required for all geode-core users, > especially geode clients. This bootstrap code should be moved to a separate > subproject called geode-web-launcher or something like that. The jetty > dependencies should be moved to that project. > The launcher code can implement CacheService and use the service loader > mechanism to be launched when the cache is created. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Assigned] (GEODE-751) RegionMXBean shouldn't rely on Eviction Algorithm for getEntrySize
[
https://issues.apache.org/jira/browse/GEODE-751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aaron Lindsey reassigned GEODE-751:
---
Assignee: Jens Deppe
We intent to de-couple the need for eviction information to exist in order to
get a measurement on the amount of bytes in a replicate region when we get to
this measurement in Micrometer. Can we create a new Jira ticket for fixing this
in Micrometer?
> RegionMXBean shouldn't rely on Eviction Algorithm for getEntrySize
> --
>
> Key: GEODE-751
> URL: https://issues.apache.org/jira/browse/GEODE-751
> Project: Geode
> Issue Type: Improvement
> Components: jmx, statistics
>Affects Versions: 1.0.0-incubating
>Reporter: Jens Deppe
>Assignee: Jens Deppe
>Priority: Major
>
> We have the following in the javadoc for method {{getEntrySize}} on interface
> {{RegionMXBean}}:
> {quote}
> Returns the aggregate entry size (in bytes) of all entries. This will provide
> a correct value only if the eviction algorithm has been set to
> {{EvictionAlgorithm.LRU_MEMORY}}. For all partition regions it will show
> entry size in bytes. It will also include size of all the secondary entries
> in the data store. So while referring to size one should take redundancy into
> account.
> {quote}
> The region memory consumption and the eviction algorithm are two separate
> concepts, we should not obligate customers to use a custom eviction algorithm
> to report the correct memory consumption for a region.
> We rely on this attribute to show information on PULSE, so neither the member
> memory usage nor cluster memory usage are accurate if the eviction algorithm
> is not configured as {{EvictionAlgorithm.LRU_MEMORY}}.
> To reproduce, start up a cluster with a simple replicated region and insert
> some data. You can check afterwards (from JConsole) that the attribute
> "EntrySize" for the replicated region is set as "-1".
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Closed] (GEODE-536) Remove i18n code
[ https://issues.apache.org/jira/browse/GEODE-536?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron Lindsey closed GEODE-536. --- > Remove i18n code > > > Key: GEODE-536 > URL: https://issues.apache.org/jira/browse/GEODE-536 > Project: Geode > Issue Type: Task > Components: logging >Reporter: Roman Shtykh >Priority: Minor > > i18n is not needed. No plans to support it so far. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Resolved] (GEODE-536) Remove i18n code
[ https://issues.apache.org/jira/browse/GEODE-536?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron Lindsey resolved GEODE-536. - Resolution: Not A Problem > Remove i18n code > > > Key: GEODE-536 > URL: https://issues.apache.org/jira/browse/GEODE-536 > Project: Geode > Issue Type: Task > Components: logging >Reporter: Roman Shtykh >Priority: Minor > > i18n is not needed. No plans to support it so far. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (GEODE-750) Expose evictionStartEvents and heapCriticalEvents as attributes on MemberMXBean
[ https://issues.apache.org/jira/browse/GEODE-750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16911799#comment-16911799 ] Aaron Lindsey commented on GEODE-750: - [~jens.deppe] assigned to you. We're evaluating observability related tickets, and this doesn't seem in-line with our path of exposing metrics via Micrometer. Would you have any issues with us closing it, or would you push for us exposing this through Micrometer? > Expose evictionStartEvents and heapCriticalEvents as attributes on > MemberMXBean > --- > > Key: GEODE-750 > URL: https://issues.apache.org/jira/browse/GEODE-750 > Project: Geode > Issue Type: Improvement > Components: jmx, statistics >Reporter: Jens Deppe >Assignee: Jens Deppe >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Assigned] (GEODE-750) Expose evictionStartEvents and heapCriticalEvents as attributes on MemberMXBean
[ https://issues.apache.org/jira/browse/GEODE-750?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron Lindsey reassigned GEODE-750: --- Assignee: Jens Deppe > Expose evictionStartEvents and heapCriticalEvents as attributes on > MemberMXBean > --- > > Key: GEODE-750 > URL: https://issues.apache.org/jira/browse/GEODE-750 > Project: Geode > Issue Type: Improvement > Components: jmx, statistics >Reporter: Jens Deppe >Assignee: Jens Deppe >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Updated] (GEODE-6928) peer-to-peer SSL stream corruption with conserve-sockets=false
[ https://issues.apache.org/jira/browse/GEODE-6928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols updated GEODE-6928: Fix Version/s: 1.9.1 > peer-to-peer SSL stream corruption with conserve-sockets=false > -- > > Key: GEODE-6928 > URL: https://issues.apache.org/jira/browse/GEODE-6928 > Project: Geode > Issue Type: Bug > Components: messaging >Reporter: Bruce Schuchardt >Priority: Major > Fix For: 1.9.1, 1.10.0 > > Time Spent: 1h 40m > Remaining Estimate: 0h > > In a system configured to use SSL in the cluster I observed many "Attempting > TCP/IP reconnect" messages and failures to return "direct replies". > I modified the ClusterCommunicationsDUnitTest to perform multiple updates in > a thread and found the same behavior. The DistributionStats > reconnectAttempts statistic showed new connections being formed when old ones > were deemed corrupt. The retry logic in our communications caused the test > to pass. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Resolved] (GEODE-7087) IllegalMonitorStateException: attempt to unlock read lock, not locked by current thread is shown in debug logging
[ https://issues.apache.org/jira/browse/GEODE-7087?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Shu resolved GEODE-7087. - Fix Version/s: 1.11.0 Resolution: Fixed > IllegalMonitorStateException: attempt to unlock read lock, not locked by > current thread is shown in debug logging > - > > Key: GEODE-7087 > URL: https://issues.apache.org/jira/browse/GEODE-7087 > Project: Geode > Issue Type: Bug > Components: transactions >Reporter: Eric Shu >Assignee: Eric Shu >Priority: Major > Labels: GeodeCommons > Fix For: 1.11.0 > > Time Spent: 40m > Remaining Estimate: 0h > > GotBucketLocks flag is never being reset after lock is released cause the > following debug logging. However. it does not affect the correctness of the > transaction layer. > [vm3] [debug 2019/08/14 05:14:37.163 PDT Thread 13> tid=0x5464] Exception while unlocking bucket region > /_PR/_BClientServerTransactionFailoverDistributedTestmultipleClientLongTransactionsCanFailoverWithoutLosingOperations_region_0 > this is probably because the bucket was destroyed and never locked initially. > [vm3] java.lang.IllegalMonitorStateException: attempt to unlock read lock, > not locked by current thread > [vm3] at > java.util.concurrent.locks.ReentrantReadWriteLock$Sync.unmatchedUnlockException(ReentrantReadWriteLock.java:444) > [vm3] at > java.util.concurrent.locks.ReentrantReadWriteLock$Sync.tryReleaseShared(ReentrantReadWriteLock.java:428) > [vm3] at > java.util.concurrent.locks.AbstractQueuedSynchronizer.releaseShared(AbstractQueuedSynchronizer.java:1341) > [vm3] at > java.util.concurrent.locks.ReentrantReadWriteLock$ReadLock.unlock(ReentrantReadWriteLock.java:881) > [vm3] at > org.apache.geode.internal.cache.BucketRegion.doUnlockForPrimary(BucketRegion.java:862) > [vm3] at org.apache.geode.internal.cache.TXState.doCleanup(TXState.java:913) > [vm3] at org.apache.geode.internal.cache.TXState.cleanup(TXState.java:880) > [vm3] at > org.apache.geode.internal.cache.TXManagerImpl.cleanupTransactionIfNoLongerHost(TXManagerImpl.java:1069) > [vm3] at > org.apache.geode.internal.cache.TXManagerImpl.unmasquerade(TXManagerImpl.java:1055) > [vm3] at > org.apache.geode.internal.cache.tier.sockets.BaseCommand.execute(BaseCommand.java:180) > [vm3] at > org.apache.geode.internal.cache.tier.sockets.ServerConnection.doNormalMessage(ServerConnection.java:848) > [vm3] at > org.apache.geode.internal.cache.tier.sockets.OriginalServerConnection.doOneMessage(OriginalServerConnection.java:72) > [vm3] at > org.apache.geode.internal.cache.tier.sockets.ServerConnection.run(ServerConnection.java:1212) > [vm3] at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > [vm3] at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > [vm3] at > org.apache.geode.internal.cache.tier.sockets.AcceptorImpl.lambda$initializeServerConnectionThreadPool$3(AcceptorImpl.java:673) > [vm3] at > org.apache.geode.internal.logging.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:121) > [vm3] at java.lang.Thread.run(Thread.java:748) -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Updated] (GEODE-7058) Log4j-core dependency should be optional in geode-core
[ https://issues.apache.org/jira/browse/GEODE-7058?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols updated GEODE-7058: Fix Version/s: 1.9.1 > Log4j-core dependency should be optional in geode-core > -- > > Key: GEODE-7058 > URL: https://issues.apache.org/jira/browse/GEODE-7058 > Project: Geode > Issue Type: Wish > 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 > > > This change depends on all commits for GEODE-2644 and GEODE-6122. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Updated] (GEODE-6959) NPE if AlertAppender is not defined
[
https://issues.apache.org/jira/browse/GEODE-6959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Owen Nichols updated GEODE-6959:
Fix Version/s: 1.9.1
> NPE if AlertAppender is not defined
> ---
>
> Key: GEODE-6959
> URL: https://issues.apache.org/jira/browse/GEODE-6959
> Project: Geode
> Issue Type: Bug
> Components: logging
>Affects Versions: 1.9.0, 1.10.0
>Reporter: Vadim Lotarev
>Assignee: Kirk Lund
>Priority: Major
> Fix For: 1.9.1, 1.10.0
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> NullPointer exception is produced if custom Log4j2.xml is used and
> AlertAppender is not defined.
>
> {code:java}
> 01:43:12.760 WARN [] JGRP39: 192.168.100.109:10100: failed to
> deliver OOB message [dst: 192.168.100.109:10100, src:
> 192.168.100.109:41000 (2 headers), size=208 bytes,
> flags=OOB|DONT_BUNDLE|NO_FC|SKIP_BARRIER]: java.lang.NullPointerException
> java.lang.NullPointerException
> at
> org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManager.forceDisconnect(GMSMembershipManager.java:2558)
> ~[geode-core-1.9.0.jar:?]
> at
> org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave.forceDisconnect(GMSJoinLeave.java:1093)
> ~[geode-core-1.9.0.jar:?]
> at
> org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave.processRemoveRequest(GMSJoinLeave.java:674)
> ~[geode-core-1.9.0.jar:?]
> at
> org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave.processMessage(GMSJoinLeave.java:1897)
> ~[geode-core-1.9.0.jar:?]
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger$JGroupsReceiver.receive(JGroupsMessenger.java:1328)
> ~[geode-core-1.9.0.jar:?]
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger$JGroupsReceiver.receive(JGroupsMessenger.java:1266)
> ~[geode-core-1.9.0.jar:?]
> at org.jgroups.JChannel.invokeCallback(JChannel.java:816)
> ~[jgroups-3.6.14.Final.jar:3.6.14.Final]
> at org.jgroups.JChannel.up(JChannel.java:741)
> ~[jgroups-3.6.14.Final.jar:3.6.14.Final]
> at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1030)
> ~[jgroups-3.6.14.Final.jar:3.6.14.Final]
> {code}
> I would propose to make AlertAppender optional.
>
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[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
]
Owen Nichols updated GEODE-7050:
Fix Version/s: 1.9.1
> 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
>
> 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.2#803003)
[jira] [Commented] (GEODE-7087) IllegalMonitorStateException: attempt to unlock read lock, not locked by current thread is shown in debug logging
[ https://issues.apache.org/jira/browse/GEODE-7087?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16911792#comment-16911792 ] ASF subversion and git services commented on GEODE-7087: Commit b5c0395218822eb6fc2881634f7d9cd80560a4d7 in geode's branch refs/heads/develop from Eric Shu [ https://gitbox.apache.org/repos/asf?p=geode.git;h=b5c0395 ] GEODE-7087: Reset flag after unlock bucket primary lock. (#3926) > IllegalMonitorStateException: attempt to unlock read lock, not locked by > current thread is shown in debug logging > - > > Key: GEODE-7087 > URL: https://issues.apache.org/jira/browse/GEODE-7087 > Project: Geode > Issue Type: Bug > Components: transactions >Reporter: Eric Shu >Assignee: Eric Shu >Priority: Major > Labels: GeodeCommons > Time Spent: 40m > Remaining Estimate: 0h > > GotBucketLocks flag is never being reset after lock is released cause the > following debug logging. However. it does not affect the correctness of the > transaction layer. > [vm3] [debug 2019/08/14 05:14:37.163 PDT Thread 13> tid=0x5464] Exception while unlocking bucket region > /_PR/_BClientServerTransactionFailoverDistributedTestmultipleClientLongTransactionsCanFailoverWithoutLosingOperations_region_0 > this is probably because the bucket was destroyed and never locked initially. > [vm3] java.lang.IllegalMonitorStateException: attempt to unlock read lock, > not locked by current thread > [vm3] at > java.util.concurrent.locks.ReentrantReadWriteLock$Sync.unmatchedUnlockException(ReentrantReadWriteLock.java:444) > [vm3] at > java.util.concurrent.locks.ReentrantReadWriteLock$Sync.tryReleaseShared(ReentrantReadWriteLock.java:428) > [vm3] at > java.util.concurrent.locks.AbstractQueuedSynchronizer.releaseShared(AbstractQueuedSynchronizer.java:1341) > [vm3] at > java.util.concurrent.locks.ReentrantReadWriteLock$ReadLock.unlock(ReentrantReadWriteLock.java:881) > [vm3] at > org.apache.geode.internal.cache.BucketRegion.doUnlockForPrimary(BucketRegion.java:862) > [vm3] at org.apache.geode.internal.cache.TXState.doCleanup(TXState.java:913) > [vm3] at org.apache.geode.internal.cache.TXState.cleanup(TXState.java:880) > [vm3] at > org.apache.geode.internal.cache.TXManagerImpl.cleanupTransactionIfNoLongerHost(TXManagerImpl.java:1069) > [vm3] at > org.apache.geode.internal.cache.TXManagerImpl.unmasquerade(TXManagerImpl.java:1055) > [vm3] at > org.apache.geode.internal.cache.tier.sockets.BaseCommand.execute(BaseCommand.java:180) > [vm3] at > org.apache.geode.internal.cache.tier.sockets.ServerConnection.doNormalMessage(ServerConnection.java:848) > [vm3] at > org.apache.geode.internal.cache.tier.sockets.OriginalServerConnection.doOneMessage(OriginalServerConnection.java:72) > [vm3] at > org.apache.geode.internal.cache.tier.sockets.ServerConnection.run(ServerConnection.java:1212) > [vm3] at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > [vm3] at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > [vm3] at > org.apache.geode.internal.cache.tier.sockets.AcceptorImpl.lambda$initializeServerConnectionThreadPool$3(AcceptorImpl.java:673) > [vm3] at > org.apache.geode.internal.logging.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:121) > [vm3] at java.lang.Thread.run(Thread.java:748) -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (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:comment-tabpanel=16911790#comment-16911790 ] ASF subversion and git services commented on GEODE-7089: Commit 5d0153ad4adb1612a1083673f98b1982819a6589 in geode's branch refs/heads/develop from Ryan McMahon [ https://gitbox.apache.org/repos/asf?p=geode.git;h=5d0153a ] GEODE-7089: Each client registration thread uses its own queue Co-authored-by: Ryan McMahon Co-authored-by: Donal Evans > 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 > Time Spent: 1h 10m > 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.2#803003)
[jira] [Commented] (GEODE-6734) Create Image pipeline red due to bad Java url in script
[ https://issues.apache.org/jira/browse/GEODE-6734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16911773#comment-16911773 ] ASF subversion and git services commented on GEODE-6734: Commit 5a746977829171bcb841582ede755de9865a9f83 in geode's branch refs/heads/release/1.9.1 from Robert Houghton [ https://gitbox.apache.org/repos/asf?p=geode.git;h=5a74697 ] GEODE-6734: Change packer image resources and scripts to Bionic Authored-by: Robert Houghton > Create Image pipeline red due to bad Java url in script > --- > > Key: GEODE-6734 > URL: https://issues.apache.org/jira/browse/GEODE-6734 > Project: Geode > Issue Type: Bug > Components: ci >Reporter: Robert Houghton >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > build-google-geode-builder job is broken. Update the Docker/Packer to fix -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (GEODE-7027) build-google-windows-geode-builder frequently fails to build because of rsync location instability
[ https://issues.apache.org/jira/browse/GEODE-7027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16911772#comment-16911772 ] ASF subversion and git services commented on GEODE-7027: Commit be95b69938e1b479c9cd788eb939b0dcd8347efd in geode's branch refs/heads/release/1.9.1 from Sean Goller [ https://gitbox.apache.org/repos/asf?p=geode.git;h=be95b69 ] [GEODE-7027] Use cygwin to get rsync instead of chocolatey directly. (#3863) Authored-by: Sean Goller (cherry picked from commit a37a43a98ddac2bdda3090682c8f74bd400c37f8) > build-google-windows-geode-builder frequently fails to build because of rsync > location instability > -- > > Key: GEODE-7027 > URL: https://issues.apache.org/jira/browse/GEODE-7027 > Project: Geode > Issue Type: Bug > Components: ci >Reporter: Sean Goller >Assignee: Sean Goller >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > The build-google-windows-geode-builder job frequently fails because of > instability surrounding fetching rsync via chocolatey. Get rsync a different > way to resolve this. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (GEODE-6945) geode-managment should create its own set of configuration objects for IndexConfiguration
[ https://issues.apache.org/jira/browse/GEODE-6945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16911723#comment-16911723 ] ASF subversion and git services commented on GEODE-6945: Commit 7d6e08a1597b4d93dc2984fce0d399d530491741 in geode's branch refs/heads/develop from Jinmei Liao [ https://gitbox.apache.org/repos/asf?p=geode.git;h=7d6e08a ] GEODE-6945: expand the type to related xml attributes (#3936) > geode-managment should create its own set of configuration objects for > IndexConfiguration > - > > Key: GEODE-6945 > URL: https://issues.apache.org/jira/browse/GEODE-6945 > Project: Geode > Issue Type: Sub-task > Components: management >Reporter: Jinmei Liao >Priority: Major > Fix For: 1.11.0 > > Time Spent: 2h 40m > Remaining Estimate: 0h > > IndexConfiguration > only add the supported attributes > modify the implementation of ConfigurationManager to do the bridging between > the configuration objects and xml domain objects -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (GEODE-7085) Cannot recover from disk store if region version is greater than Integer.MAX_VALUE
[ https://issues.apache.org/jira/browse/GEODE-7085?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16911720#comment-16911720 ] ASF subversion and git services commented on GEODE-7085: Commit f17931bf541fc0255112f713931388d9ee0bbc30 in geode's branch refs/heads/develop from Dan Smith [ https://gitbox.apache.org/repos/asf?p=geode.git;h=f17931b ] GEODE-7085: Ensure bitset is flushed in all code paths In recordVersion, there was a code path where we would not call flushBitSetDuringRecording before calling setVersionInBitSet. Moving the flush to the top of the method to ensure that the bit set is always flushed, and we never end up with a case where we try to set too large of a bit. By code inspection, we determined that initializeFrom was what got us into the state that triggered this code path - it could leave bitSetVersion at a small number while setting version to a large number. Fixing initializeFrom so that it correctly sets bitSetVersion. Co-Authored-By: Ernest Burghardt > Cannot recover from disk store if region version is greater than > Integer.MAX_VALUE > -- > > Key: GEODE-7085 > URL: https://issues.apache.org/jira/browse/GEODE-7085 > Project: Geode > Issue Type: Bug > Components: membership, persistence >Reporter: Dan Smith >Assignee: Dan Smith >Priority: Major > Fix For: 1.11.0 > > Time Spent: 4h 20m > Remaining Estimate: 0h > > We hit an issue where a member failed to recover due to a > IndexOutOfBoundsException while recording a version during recovery. > Looking closer, it looks like the issue is due to the fact that a > RegionVersionHolder cannot record a version greater than Integer.MAX_VALUE if > it just just constructed. > When we are recovering from disk, the first thing we read from is the .drf > files. The first thing in those drf files is RVV information. We read the RVV > records and call recordRecoveredGCVersion. > When that call gets down inside RegionVersionHolder.recordVersion, there is > some logic that is supposed to flush out the bitSet and advance the > bitSetVersion. Unfortunately it looks like flushBitSetDuringRecording is not > actually doing that. So if version we read from disk is greater than > Integer.MAX_VALUE, we wrap around and try to set a negative index in the > bitset. > I can reproduce this with a unit test of RegionVersionVector that records a > version greater than Integer.MAX_VALUE. I’m looking into how to fix the > flushBitSetDuringRecording method. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (GEODE-6734) Create Image pipeline red due to bad Java url in script
[ https://issues.apache.org/jira/browse/GEODE-6734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16911710#comment-16911710 ] ASF subversion and git services commented on GEODE-6734: Commit 1ac6f38c0b12bbe7bed71d1ccd41de35835e8494 in geode's branch refs/heads/release/1.9.1 from Robert Houghton [ https://gitbox.apache.org/repos/asf?p=geode.git;h=1ac6f38 ] GEODE-6734: Change packer image resources and scripts to Bionic Authored-by: Robert Houghton > Create Image pipeline red due to bad Java url in script > --- > > Key: GEODE-6734 > URL: https://issues.apache.org/jira/browse/GEODE-6734 > Project: Geode > Issue Type: Bug > Components: ci >Reporter: Robert Houghton >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > build-google-geode-builder job is broken. Update the Docker/Packer to fix -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (GEODE-7027) build-google-windows-geode-builder frequently fails to build because of rsync location instability
[ https://issues.apache.org/jira/browse/GEODE-7027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16911704#comment-16911704 ] ASF subversion and git services commented on GEODE-7027: Commit 8355f5d62b498dcfa2ac707d3fae39e2774a5f12 in geode's branch refs/heads/release/1.9.1 from Sean Goller [ https://gitbox.apache.org/repos/asf?p=geode.git;h=8355f5d ] [GEODE-7027] Use cygwin to get rsync instead of chocolatey directly. (#3863) Authored-by: Sean Goller (cherry picked from commit a37a43a98ddac2bdda3090682c8f74bd400c37f8) > build-google-windows-geode-builder frequently fails to build because of rsync > location instability > -- > > Key: GEODE-7027 > URL: https://issues.apache.org/jira/browse/GEODE-7027 > Project: Geode > Issue Type: Bug > Components: ci >Reporter: Sean Goller >Assignee: Sean Goller >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > The build-google-windows-geode-builder job frequently fails because of > instability surrounding fetching rsync via chocolatey. Get rsync a different > way to resolve this. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (GEODE-6122) Log4j core should be optional
[
https://issues.apache.org/jira/browse/GEODE-6122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16911671#comment-16911671
]
ASF subversion and git services commented on GEODE-6122:
Commit 63034887c70e7bb7ec5e086b5154b626049a84c0 in geode's branch
refs/heads/release/1.9.1 from Kirk Lund
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=6303488 ]
GEODE-7058: Mark log4j-core optional in geode-core
Note: this change requires all commits from GEODE-2644 and GEODE-6122.
(cherry picked from commit 413800bc16d05df689a2af5c30797f180aad6088)
> Log4j core should be optional
> -
>
> Key: GEODE-6122
> URL: https://issues.apache.org/jira/browse/GEODE-6122
> Project: Geode
> Issue Type: Bug
> Components: logging
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.9.0
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> A simple test of Geode without log4j core on the classpath results in the
> following log statement and stack trace:
> {noformat}
> ERROR StatusLogger Log4j2 could not find a logging implementation. Please add
> log4j-core to the classpath. Using SimpleLogger to log to the console...
> {noformat}
> {noformat}
> java.lang.NoClassDefFoundError: org/apache/logging/log4j/core/Logger
> at
> org.apache.geode.internal.logging.log4j.Log4jAgent.getRootLoggerContext(Log4jAgent.java:89)
> at
> org.apache.geode.internal.logging.log4j.Log4jAgent.getConfiguration(Log4jAgent.java:93)
> at
> org.apache.geode.internal.logging.log4j.Log4jAgent.isUsingGemFireDefaultConfig(Log4jAgent.java:78)
> at
> org.apache.geode.internal.logging.log4j.Log4jAgent.shouldUpdateLogLevels(Log4jAgent.java:127)
> at
> org.apache.geode.internal.logging.log4j.Log4jAgent.configure(Log4jAgent.java:105)
> at
> org.apache.geode.internal.logging.Configuration.configChanged(Configuration.java:175)
> at
> org.apache.geode.internal.logging.Configuration.initialize(Configuration.java:164)
> at
> org.apache.geode.internal.logging.LoggingSession.createSession(LoggingSession.java:66)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.initialize(InternalDistributedSystem.java:663)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.newInstance(InternalDistributedSystem.java:369)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.newInstance(InternalDistributedSystem.java:357)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.newInstance(InternalDistributedSystem.java:349)
> at
> org.apache.geode.distributed.DistributedSystem.connect(DistributedSystem.java:215)
> at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:218)
> at
> io.github.kirklund.geode.GeodeApplicationIntegrationTest.setUp(GeodeApplicationIntegrationTest.java:34)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:24)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
> at
> com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:47)
> at
>
[jira] [Commented] (GEODE-6389) CI Failure: ConcurrentWANPropagation_1_DUnitTest.testReplicatedSerialPropagation_withoutRemoteSite failed as entries failed to be propagated to remote site
[
https://issues.apache.org/jira/browse/GEODE-6389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16911665#comment-16911665
]
ASF subversion and git services commented on GEODE-6389:
Commit 4aed345d4ee592b573b11db67fe0ceb75188d310 in geode's branch
refs/heads/release/1.9.1 from Bruce Schuchardt
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=4aed345 ]
Revert "GEODE-6389 CI Failure:
ConcurrentWANPropagation_1_DUnitTest.testReplicatedSerialPropagation_withoutRemoteSite"
This reverts commit 71dacf6a6f8de535c07be4584ee3d054a41b10e3.
> CI Failure:
> ConcurrentWANPropagation_1_DUnitTest.testReplicatedSerialPropagation_withoutRemoteSite
> failed as entries failed to be propagated to remote site
>
>
> Key: GEODE-6389
> URL: https://issues.apache.org/jira/browse/GEODE-6389
> Project: Geode
> Issue Type: Bug
> Components: serialization
>Reporter: Eric Shu
>Assignee: Bruce Schuchardt
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.9.0
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> at
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK11/builds/388
> {noformat}
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.wan.concurrent.ConcurrentWANPropagation_1_DUnitTest$$Lambda$300/0x0008402ccc40.run
> in VM 2 running on Host 6d85d52e859b with 8 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:557)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:384)
> at
> org.apache.geode.internal.cache.wan.concurrent.ConcurrentWANPropagation_1_DUnitTest.testReplicatedSerialPropagation_withoutRemoteSite(ConcurrentWANPropagation_1_DUnitTest.java:94)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:566)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.runTestClass(JUnitTestClassExecutor.java:110)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:58)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:38)
> at
> org.gradle.api.internal.tasks.testing.junit.AbstractJUnitTestClassProcessor.processTestClass(AbstractJUnitTestClassProcessor.java:66)
> at
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:566)
> at
>
[jira] [Commented] (GEODE-2644) Provide ability to configure Geode appenders in log4j2.xml
[ https://issues.apache.org/jira/browse/GEODE-2644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16911670#comment-16911670 ] ASF subversion and git services commented on GEODE-2644: Commit 63034887c70e7bb7ec5e086b5154b626049a84c0 in geode's branch refs/heads/release/1.9.1 from Kirk Lund [ https://gitbox.apache.org/repos/asf?p=geode.git;h=6303488 ] GEODE-7058: Mark log4j-core optional in geode-core Note: this change requires all commits from GEODE-2644 and GEODE-6122. (cherry picked from commit 413800bc16d05df689a2af5c30797f180aad6088) > Provide ability to configure Geode appenders in log4j2.xml > -- > > Key: GEODE-2644 > URL: https://issues.apache.org/jira/browse/GEODE-2644 > Project: Geode > Issue Type: Improvement > Components: configuration, logging >Reporter: Kirk Lund >Assignee: Kirk Lund >Priority: Major > Labels: AlertAppender, Log4j2, LogWriterAppender, log4j2.xml, > pull-request-available > Fix For: 1.9.0 > > Time Spent: 8h 10m > Remaining Estimate: 0h > > Presently Geode dynamically creates, adds and removes AlertAppender and > LogWriterAppender by manipulating log4j2 core API. We should move the bulk of > the Appender functionality to internal classes and just leave the Appenders > registered with log4j2 during the life of the JVM. > This allows us to enable and configure our Appenders via log4j2.xml and > control the Cache-controlled lifecycle internally without having to add and > remove custom Appender instances. > The code would then become simpler, we could avoid invoking log4j2 core APIs, > and users would have control over configuring our use of log4j2 completely > within the .xml file. Presently, a user cannot configure our AlertAppender or > LogWriterAppender in log4j2.xml. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (GEODE-7050) Log4jAgent should avoid casting non-log4j loggers
[
https://issues.apache.org/jira/browse/GEODE-7050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16911674#comment-16911674
]
ASF subversion and git services commented on GEODE-7050:
Commit 50b31715355f65b61fd5a6f14dcad942f46afcfe in geode's branch
refs/heads/release/1.9.1 from Kirk Lund
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=50b3171 ]
GEODE-7050: Use Log4jAgent only if Log4j is using Log4jProvider (#3892)
* GEODE-7050: Use Log4jAgent only if Log4j is using Log4jProvider
This change prevents Geode from using Log4jAgent if Log4j Core is
present but not using Log4jProvider.
For example, Log4j Core uses SLF4JProvider when log4j-to-slf4j is in
the classpath.
By disabling Log4jAgent when other Log4j Providers are in use, this
prevents problems such as ClassCastExceptions when attemping to cast
loggers from org.apache.logging.slf4j.SLF4JLogger to
org.apache.logging.log4j.core.Logger to get the LoggerConfig or
LoggerContext.
* Update
geode-core/src/test/java/org/apache/geode/internal/logging/DefaultProviderCheckerTest.java
Co-Authored-By: Aaron Lindsey
(cherry picked from commit e5c9c420f462149fd062847904e3435fbe99afb4)
> 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.10.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.2#803003)
[jira] [Commented] (GEODE-2113) Implement SSL over NIO
[ https://issues.apache.org/jira/browse/GEODE-2113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16911668#comment-16911668 ] ASF subversion and git services commented on GEODE-2113: Commit 4a11e4d39652eedca8eaa36ed6466e2d825718fb in geode's branch refs/heads/release/1.9.1 from Bruce Schuchardt [ https://gitbox.apache.org/repos/asf?p=geode.git;h=4a11e4d ] Revert "GEODE-2113 Implement SSL over NIO" This reverts commit 33077b3dab41260c70cece5b4f7ff1c42501b01c. > Implement SSL over NIO > -- > > Key: GEODE-2113 > URL: https://issues.apache.org/jira/browse/GEODE-2113 > Project: Geode > Issue Type: Improvement > Components: docs >Reporter: Addison >Assignee: Joey McAllister >Priority: Major > Labels: SmallFeature, pull-request-available > Fix For: 1.9.0 > > Time Spent: 5.5h > Remaining Estimate: 0h > > Java now has a nifty javax.net.ssl.SSLSocketFactory that can produce an > SSLSocket from an existing Socket. This will let us create an SSLSocket that > has an NIO SocketChannel and get rid of all of the "Old IO" code. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (GEODE-2113) Implement SSL over NIO
[ https://issues.apache.org/jira/browse/GEODE-2113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16911667#comment-16911667 ] ASF subversion and git services commented on GEODE-2113: Commit 6d1851081d445302fa40cf9c73f2c62656d80502 in geode's branch refs/heads/release/1.9.1 from Bruce Schuchardt [ https://gitbox.apache.org/repos/asf?p=geode.git;h=6d18510 ] Revert "GEODE-2113 implement SSL over NIO" This reverts commit 588af8522a48b1fcaf045bb9ce028e4e8422dcba. > Implement SSL over NIO > -- > > Key: GEODE-2113 > URL: https://issues.apache.org/jira/browse/GEODE-2113 > Project: Geode > Issue Type: Improvement > Components: docs >Reporter: Addison >Assignee: Joey McAllister >Priority: Major > Labels: SmallFeature, pull-request-available > Fix For: 1.9.0 > > Time Spent: 5.5h > Remaining Estimate: 0h > > Java now has a nifty javax.net.ssl.SSLSocketFactory that can produce an > SSLSocket from an existing Socket. This will let us create an SSLSocket that > has an NIO SocketChannel and get rid of all of the "Old IO" code. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (GEODE-7050) Log4jAgent should avoid casting non-log4j loggers
[
https://issues.apache.org/jira/browse/GEODE-7050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16911673#comment-16911673
]
ASF subversion and git services commented on GEODE-7050:
Commit 50b31715355f65b61fd5a6f14dcad942f46afcfe in geode's branch
refs/heads/release/1.9.1 from Kirk Lund
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=50b3171 ]
GEODE-7050: Use Log4jAgent only if Log4j is using Log4jProvider (#3892)
* GEODE-7050: Use Log4jAgent only if Log4j is using Log4jProvider
This change prevents Geode from using Log4jAgent if Log4j Core is
present but not using Log4jProvider.
For example, Log4j Core uses SLF4JProvider when log4j-to-slf4j is in
the classpath.
By disabling Log4jAgent when other Log4j Providers are in use, this
prevents problems such as ClassCastExceptions when attemping to cast
loggers from org.apache.logging.slf4j.SLF4JLogger to
org.apache.logging.log4j.core.Logger to get the LoggerConfig or
LoggerContext.
* Update
geode-core/src/test/java/org/apache/geode/internal/logging/DefaultProviderCheckerTest.java
Co-Authored-By: Aaron Lindsey
(cherry picked from commit e5c9c420f462149fd062847904e3435fbe99afb4)
> 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.10.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.2#803003)
[jira] [Commented] (GEODE-7058) Log4j-core dependency should be optional in geode-core
[ https://issues.apache.org/jira/browse/GEODE-7058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16911669#comment-16911669 ] ASF subversion and git services commented on GEODE-7058: Commit 63034887c70e7bb7ec5e086b5154b626049a84c0 in geode's branch refs/heads/release/1.9.1 from Kirk Lund [ https://gitbox.apache.org/repos/asf?p=geode.git;h=6303488 ] GEODE-7058: Mark log4j-core optional in geode-core Note: this change requires all commits from GEODE-2644 and GEODE-6122. (cherry picked from commit 413800bc16d05df689a2af5c30797f180aad6088) > Log4j-core dependency should be optional in geode-core > -- > > Key: GEODE-7058 > URL: https://issues.apache.org/jira/browse/GEODE-7058 > Project: Geode > Issue Type: Wish > Components: logging >Affects Versions: 1.9.0, 1.10.0 >Reporter: Kirk Lund >Assignee: Kirk Lund >Priority: Major > Fix For: 1.10.0 > > > This change depends on all commits for GEODE-2644 and GEODE-6122. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (GEODE-6468) [CI Failure] ClusterCommunicationsDUnitTest fails on createEntryAndVerifyUpdate[UNSHARED_CONNECTIONS_WITH_SSL]
[
https://issues.apache.org/jira/browse/GEODE-6468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16911664#comment-16911664
]
ASF subversion and git services commented on GEODE-6468:
Commit e768c8c1dcdce2a6109330759b2a1bb4d5802d8d in geode's branch
refs/heads/release/1.9.1 from Bruce Schuchardt
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=e768c8c ]
Revert "GEODE-6468 [CI Failure] ClusterCommunicationsDUnitTest fails on
createEntryAndVerifyUpdate"
This reverts commit 6d1d82a15a5c548b2aafeff8bf023d12044581e7.
> [CI Failure] ClusterCommunicationsDUnitTest fails on
> createEntryAndVerifyUpdate[UNSHARED_CONNECTIONS_WITH_SSL]
> --
>
> Key: GEODE-6468
> URL: https://issues.apache.org/jira/browse/GEODE-6468
> Project: Geode
> Issue Type: Test
>Reporter: Jens Deppe
>Assignee: Bruce Schuchardt
>Priority: Major
> Labels: ci
> Fix For: 1.9.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> We see the following CI Failure:
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/447]
>
> The failing test has the following stack trace
>
> {code}
> org.apache.geode.ClusterCommunicationsDUnitTest >
> createEntryAndVerifyUpdate[UNSHARED_CONNECTIONS_WITH_SSL] FAILED
> java.lang.AssertionError: Suspicious strings were written to the log
> during this run.
> Fix the strings or use IgnoredException.addIgnoredException to ignore.
> ---
> Found suspect string in log4j at line 1606
> [fatal 2019/02/27 20:50:39.584 UTC
> tid=32] ack read exception
> java.lang.IllegalStateException: unexpected byte: HASH_TABLE while
> reading dsfid
> at
> org.apache.geode.internal.InternalDataSerializer.readDSFID(InternalDataSerializer.java:2657)
> at
> org.apache.geode.internal.InternalDataSerializer.readDSFID(InternalDataSerializer.java:2663)
> at
> org.apache.geode.internal.tcp.MsgReader.readMessage(MsgReader.java:103)
> at
> org.apache.geode.internal.tcp.Connection.readAck(Connection.java:2848)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.readAcks(DirectChannel.java:476)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToMany(DirectChannel.java:420)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToOne(DirectChannel.java:241)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.send(DirectChannel.java:595)
> at
> org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManager.directChannelSend(GMSMembershipManager.java:1710)
> at
> org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManager.send(GMSMembershipManager.java:1891)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendViaMembershipManager(ClusterDistributionManager.java:2878)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendOutgoing(ClusterDistributionManager.java:2798)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendMessage(ClusterDistributionManager.java:2837)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.putOutgoing(ClusterDistributionManager.java:1531)
> at
> org.apache.geode.internal.cache.DistributedCacheOperation._distribute(DistributedCacheOperation.java:562)
> at
> org.apache.geode.internal.cache.DistributedCacheOperation.startOperation(DistributedCacheOperation.java:270)
> at
> org.apache.geode.internal.cache.DistributedCacheOperation.distribute(DistributedCacheOperation.java:311)
> at
> org.apache.geode.internal.cache.DistributedRegion.distributeUpdate(DistributedRegion.java:502)
> at
> org.apache.geode.internal.cache.DistributedRegion.basicPutPart3(DistributedRegion.java:480)
> at
> org.apache.geode.internal.cache.map.RegionMapPut.doAfterCompletionActions(RegionMapPut.java:293)
> at
> org.apache.geode.internal.cache.map.AbstractRegionMapPut.doPut(AbstractRegionMapPut.java:185)
> at
> org.apache.geode.internal.cache.map.AbstractRegionMapPut.runWhileLockedForCacheModification(AbstractRegionMapPut.java:119)
> at
> org.apache.geode.internal.cache.map.RegionMapPut.runWhileLockedForCacheModification(RegionMapPut.java:150)
> at
> org.apache.geode.internal.cache.map.AbstractRegionMapPut.put(AbstractRegionMapPut.java:169)
> at
> org.apache.geode.internal.cache.AbstractRegionMap.basicPut(AbstractRegionMap.java:2103)
> at
> org.apache.geode.internal.cache.LocalRegion.virtualPut(LocalRegion.java:5708)
>
[jira] [Commented] (GEODE-6959) NPE if AlertAppender is not defined
[
https://issues.apache.org/jira/browse/GEODE-6959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16911672#comment-16911672
]
ASF subversion and git services commented on GEODE-6959:
Commit 353834199bc99f458f54b5e0d6e58756fff53a3d in geode's branch
refs/heads/release/1.9.1 from Kirk Lund
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=3538341 ]
GEODE-6959: Prevent NPE in GMSMembershipManager for null AlertAppender (#3899)
If a custom log4j2.xml is used without specifying the Geode AlertAppender,
GMSMembershipManager may throw a NullPointerException when invoking
AlertAppender.getInstance().stopSession() during a forceDisconnect. This
change prevents the NullPointerException allowing forceDisconnect to finish.
Users using Spring Boot with Logback are more likely to hit this bug.
Co-authored-by: Mark Hanson mhan...@pivotal.io
(cherry picked from commit dd15fec1f2ecbc3bc0cdfc42072252c379e0bb89)
> NPE if AlertAppender is not defined
> ---
>
> Key: GEODE-6959
> URL: https://issues.apache.org/jira/browse/GEODE-6959
> Project: Geode
> Issue Type: Bug
> Components: logging
>Affects Versions: 1.9.0, 1.10.0
>Reporter: Vadim Lotarev
>Assignee: Kirk Lund
>Priority: Major
> Fix For: 1.10.0
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> NullPointer exception is produced if custom Log4j2.xml is used and
> AlertAppender is not defined.
>
> {code:java}
> 01:43:12.760 WARN [] JGRP39: 192.168.100.109:10100: failed to
> deliver OOB message [dst: 192.168.100.109:10100, src:
> 192.168.100.109:41000 (2 headers), size=208 bytes,
> flags=OOB|DONT_BUNDLE|NO_FC|SKIP_BARRIER]: java.lang.NullPointerException
> java.lang.NullPointerException
> at
> org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManager.forceDisconnect(GMSMembershipManager.java:2558)
> ~[geode-core-1.9.0.jar:?]
> at
> org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave.forceDisconnect(GMSJoinLeave.java:1093)
> ~[geode-core-1.9.0.jar:?]
> at
> org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave.processRemoveRequest(GMSJoinLeave.java:674)
> ~[geode-core-1.9.0.jar:?]
> at
> org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave.processMessage(GMSJoinLeave.java:1897)
> ~[geode-core-1.9.0.jar:?]
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger$JGroupsReceiver.receive(JGroupsMessenger.java:1328)
> ~[geode-core-1.9.0.jar:?]
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger$JGroupsReceiver.receive(JGroupsMessenger.java:1266)
> ~[geode-core-1.9.0.jar:?]
> at org.jgroups.JChannel.invokeCallback(JChannel.java:816)
> ~[jgroups-3.6.14.Final.jar:3.6.14.Final]
> at org.jgroups.JChannel.up(JChannel.java:741)
> ~[jgroups-3.6.14.Final.jar:3.6.14.Final]
> at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1030)
> ~[jgroups-3.6.14.Final.jar:3.6.14.Final]
> {code}
> I would propose to make AlertAppender optional.
>
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (GEODE-7105) Function excution doc improvement.
[ https://issues.apache.org/jira/browse/GEODE-7105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16911587#comment-16911587 ] ASF subversion and git services commented on GEODE-7105: Commit c5121fb5d1a2f88035202a88e39598309629643e in geode's branch refs/heads/develop from Naburun Nag [ https://gitbox.apache.org/repos/asf?p=geode.git;h=c5121fb ] GEODE-7105: Changed Function execution HA docs * Before : the default for retries was -1 and function execution was retried infinitely. * After : the default behavior is now that the function will be retried on every server only once and if it fails on every one of them, then an exception will be returned to the user. > Function excution doc improvement. > -- > > Key: GEODE-7105 > URL: https://issues.apache.org/jira/browse/GEODE-7105 > Project: Geode > Issue Type: Bug > Components: docs >Reporter: nabarun >Priority: Major > Time Spent: 1h > Remaining Estimate: 0h > > After GEODE-6677 was checked into develop, function execution when HA is true > and default timeout is set has some behavior changes. > * Before : the default for retries was -1 and it function execution was > retried infinitely. > * After : the default behavior is now that the function will be retried on > every server only once and if it fails on every one of them, then an > exception will be returned to the user. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (GEODE-7105) Function excution doc improvement.
[ https://issues.apache.org/jira/browse/GEODE-7105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16911588#comment-16911588 ] ASF subversion and git services commented on GEODE-7105: Commit 222bbe6229dc3409f98af8ba35f06e3df97f4fdb in geode's branch refs/heads/develop from Joey McAllister [ https://gitbox.apache.org/repos/asf?p=geode.git;h=222bbe6 ] Merge pull request #3950 from nabarunnag/feature/GEODE-7105 GEODE-7105: Changed Function execution HA docs > Function excution doc improvement. > -- > > Key: GEODE-7105 > URL: https://issues.apache.org/jira/browse/GEODE-7105 > Project: Geode > Issue Type: Bug > Components: docs >Reporter: nabarun >Priority: Major > Time Spent: 1h > Remaining Estimate: 0h > > After GEODE-6677 was checked into develop, function execution when HA is true > and default timeout is set has some behavior changes. > * Before : the default for retries was -1 and it function execution was > retried infinitely. > * After : the default behavior is now that the function will be retried on > every server only once and if it fails on every one of them, then an > exception will be returned to the user. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (GEODE-7105) Function excution doc improvement.
[ https://issues.apache.org/jira/browse/GEODE-7105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16911589#comment-16911589 ] ASF subversion and git services commented on GEODE-7105: Commit 222bbe6229dc3409f98af8ba35f06e3df97f4fdb in geode's branch refs/heads/develop from Joey McAllister [ https://gitbox.apache.org/repos/asf?p=geode.git;h=222bbe6 ] Merge pull request #3950 from nabarunnag/feature/GEODE-7105 GEODE-7105: Changed Function execution HA docs > Function excution doc improvement. > -- > > Key: GEODE-7105 > URL: https://issues.apache.org/jira/browse/GEODE-7105 > Project: Geode > Issue Type: Bug > Components: docs >Reporter: nabarun >Priority: Major > Time Spent: 1h > Remaining Estimate: 0h > > After GEODE-6677 was checked into develop, function execution when HA is true > and default timeout is set has some behavior changes. > * Before : the default for retries was -1 and it function execution was > retried infinitely. > * After : the default behavior is now that the function will be retried on > every server only once and if it fails on every one of them, then an > exception will be returned to the user. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Resolved] (GEODE-6873) Add Tomcat session state module example to geode-examples
[ https://issues.apache.org/jira/browse/GEODE-6873?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] xiaojian zhou resolved GEODE-6873. -- Fix Version/s: 1.10.0 Resolution: Fixed > Add Tomcat session state module example to geode-examples > - > > Key: GEODE-6873 > URL: https://issues.apache.org/jira/browse/GEODE-6873 > Project: Geode > Issue Type: Improvement > Components: examples, http session >Reporter: Ryan McMahon >Assignee: Benjamin P Ross >Priority: Major > Labels: GeodeCommons > Fix For: 1.10.0 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > We don't have any fully working examples of our Tomcat session state module > in the context of a simple sample web application. It would be helpful for > new users to pull down some code to reference when setting up their > applications to use the module. > According to > [this|[https://docs.spring.io/spring-boot/docs/current/reference/html/howto-embedded-web-servers.html]], > you can use Tomcat as an embedded web server for Spring Boot, so maybe a > simple Spring Boot application would suffice. Whether geode-examples is the > right repository is another thing to consider, since our other examples just > exercise plain Geode features. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Assigned] (GEODE-6873) Add Tomcat session state module example to geode-examples
[ https://issues.apache.org/jira/browse/GEODE-6873?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] xiaojian zhou reassigned GEODE-6873: Assignee: Benjamin P Ross > Add Tomcat session state module example to geode-examples > - > > Key: GEODE-6873 > URL: https://issues.apache.org/jira/browse/GEODE-6873 > Project: Geode > Issue Type: Improvement > Components: examples, http session >Reporter: Ryan McMahon >Assignee: Benjamin P Ross >Priority: Major > Labels: GeodeCommons > Time Spent: 1h 10m > Remaining Estimate: 0h > > We don't have any fully working examples of our Tomcat session state module > in the context of a simple sample web application. It would be helpful for > new users to pull down some code to reference when setting up their > applications to use the module. > According to > [this|[https://docs.spring.io/spring-boot/docs/current/reference/html/howto-embedded-web-servers.html]], > you can use Tomcat as an embedded web server for Spring Boot, so maybe a > simple Spring Boot application would suffice. Whether geode-examples is the > right repository is another thing to consider, since our other examples just > exercise plain Geode features. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (GEODE-6873) Add Tomcat session state module example to geode-examples
[ https://issues.apache.org/jira/browse/GEODE-6873?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16911549#comment-16911549 ] ASF subversion and git services commented on GEODE-6873: Commit e4e3c953313408d587e7e928488d9dd48aebe88e in geode-examples's branch refs/heads/develop from Xiaojian Zhou [ https://gitbox.apache.org/repos/asf?p=geode-examples.git;h=e4e3c95 ] Merge pull request #84 from BenjaminPerryRoss/AddSessionStateDemo GEODE-6873: Add Tomcat session state module example to geode-examples Co-authored-by: Benjamin Ross > Add Tomcat session state module example to geode-examples > - > > Key: GEODE-6873 > URL: https://issues.apache.org/jira/browse/GEODE-6873 > Project: Geode > Issue Type: Improvement > Components: examples, http session >Reporter: Ryan McMahon >Priority: Major > Labels: GeodeCommons > Time Spent: 1h 10m > Remaining Estimate: 0h > > We don't have any fully working examples of our Tomcat session state module > in the context of a simple sample web application. It would be helpful for > new users to pull down some code to reference when setting up their > applications to use the module. > According to > [this|[https://docs.spring.io/spring-boot/docs/current/reference/html/howto-embedded-web-servers.html]], > you can use Tomcat as an embedded web server for Spring Boot, so maybe a > simple Spring Boot application would suffice. Whether geode-examples is the > right repository is another thing to consider, since our other examples just > exercise plain Geode features. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Assigned] (GEODE-6499) PersistentColocatedPartitionedRegionDUnitTest: Timed out waiting 60000 milliseconds for AsyncInvocation to complete.
[
https://issues.apache.org/jira/browse/GEODE-6499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kenneth Howe reassigned GEODE-6499:
---
Assignee: (was: Kenneth Howe)
> PersistentColocatedPartitionedRegionDUnitTest: Timed out waiting 6
> milliseconds for AsyncInvocation to complete.
>
>
> Key: GEODE-6499
> URL: https://issues.apache.org/jira/browse/GEODE-6499
> Project: Geode
> Issue Type: Bug
> Components: tests
>Reporter: Mark Hanson
>Priority: Major
> Attachments: PersistentColocatedPartitionedRegionDUnitTest.tgz
>
>
> {noformat}
>
> Task :geode-core:distributedTest
>
> org.apache.geode.internal.cache.partitioned.PersistentColocatedPartitionedRegionDUnitTest
> > testHierarchyOfColocatedChildPRsMissingGrandchild FAILED
> java.util.concurrent.TimeoutException: Timed out waiting 6 milliseconds
> for AsyncInvocation to complete.
> at
> org.apache.geode.test.dunit.AsyncInvocation.timeoutIfAlive(AsyncInvocation.java:462)
> at org.apache.geode.test.dunit.AsyncInvocation.get(AsyncInvocation.java:412)
> at
> org.apache.geode.internal.cache.partitioned.PersistentColocatedPartitionedRegionDUnitTest.testHierarchyOfColocatedChildPRsMissingGrandchild(PersistentColocatedPartitionedRegionDUnitTest.java:979)
>
>
> org.apache.geode.internal.cache.partitioned.PersistentColocatedPartitionedRegionDUnitTest
> > testMultipleColocatedChildPRsMissingWithSequencedStart FAILED
> java.util.concurrent.TimeoutException: Timed out waiting 6 milliseconds
> for AsyncInvocation to complete.
> at
> org.apache.geode.test.dunit.AsyncInvocation.timeoutIfAlive(AsyncInvocation.java:462)
> at org.apache.geode.test.dunit.AsyncInvocation.get(AsyncInvocation.java:412)
> at
> org.apache.geode.internal.cache.partitioned.PersistentColocatedPartitionedRegionDUnitTest.testMultipleColocatedChildPRsMissingWithSequencedStart(PersistentColocatedPartitionedRegionDUnitTest.java:865)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Updated] (GEODE-3780) suspected member is never watched again after passing final check
[ https://issues.apache.org/jira/browse/GEODE-3780?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bruce Schuchardt updated GEODE-3780: Fix Version/s: (was: 1.11.0) 1.10.0 > suspected member is never watched again after passing final check > - > > Key: GEODE-3780 > URL: https://issues.apache.org/jira/browse/GEODE-3780 > Project: Geode > Issue Type: Bug > Components: membership >Reporter: Bruce Schuchardt >Assignee: Bruce Schuchardt >Priority: Major > Labels: pull-request-available > Fix For: 1.10.0 > > Time Spent: 2.5h > Remaining Estimate: 0h > > In a network-down test we saw a node on the losing side of the network > partition perform final checks on members on the winning side. One of the > final checks mysteriously succeeded > [info 2017/09/17 12:24:45.552 PDT > gemfire1_rs-FullRegression-2017-09-15-21-00-35-client-10_8941 Detection thread 4> tid=0x128] Final check failed but detected recent message > traffic for suspect member > 10.32.109.252(gemfire3_rs-FullRegression-2017-09-15-21-00-35-client-16_6135:6135):1026 > [info 2017/09/17 12:24:45.552 PDT > gemfire1_rs-FullRegression-2017-09-15-21-00-35-client-10_8941 Detection thread 4> tid=0x128] Final check passed for suspect member > 10.32.109.252(gemfire3_rs-FullRegression-2017-09-15-21-00-35-client-16_6135:6135):1026 > After this the suspected member was never checked again and the losing side > failed to shut down. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (GEODE-6499) PersistentColocatedPartitionedRegionDUnitTest: Timed out waiting 60000 milliseconds for AsyncInvocation to complete.
[
https://issues.apache.org/jira/browse/GEODE-6499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16911461#comment-16911461
]
Bruce Schuchardt commented on GEODE-6499:
-
happened again in this run:
[https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/1002]
SHA 5c800d51d372692c6faa8a9a4f3c78a9cb182c43
{noformat}
org.apache.geode.internal.cache.partitioned.PersistentColocatedPartitionedRegionDUnitTest
> testFullTreeOfColocatedChildPRsWithMissingRegions FAILED
java.util.concurrent.TimeoutException: Timed out waiting 6 milliseconds
for AsyncInvocation to complete.
at
org.apache.geode.test.dunit.AsyncInvocation.timeoutIfAlive(AsyncInvocation.java:464)
at
org.apache.geode.test.dunit.AsyncInvocation.get(AsyncInvocation.java:414)
at
org.apache.geode.internal.cache.partitioned.PersistentColocatedPartitionedRegionDUnitTest.testFullTreeOfColocatedChildPRsWithMissingRegions(PersistentColocatedPartitionedRegionDUnitTest.java:1152)
org.apache.geode.internal.cache.partitioned.PersistentColocatedPartitionedRegionDUnitTest
> testMissingColocatedChildPRDueToDelayedStart FAILED
java.util.concurrent.TimeoutException: Timed out waiting 6 milliseconds
for AsyncInvocation to complete.
at
org.apache.geode.test.dunit.AsyncInvocation.timeoutIfAlive(AsyncInvocation.java:464)
at
org.apache.geode.test.dunit.AsyncInvocation.get(AsyncInvocation.java:414)
at
org.apache.geode.internal.cache.partitioned.PersistentColocatedPartitionedRegionDUnitTest.testMissingColocatedChildPRDueToDelayedStart(PersistentColocatedPartitionedRegionDUnitTest.java:709)
org.apache.geode.internal.cache.partitioned.PersistentColocatedPartitionedRegionDUnitTest
> testHierarchyOfColocatedChildPRsMissing FAILED
java.util.concurrent.TimeoutException: Timed out waiting 6 milliseconds
for AsyncInvocation to complete.
at
org.apache.geode.test.dunit.AsyncInvocation.timeoutIfAlive(AsyncInvocation.java:464)
at
org.apache.geode.test.dunit.AsyncInvocation.get(AsyncInvocation.java:414)
at
org.apache.geode.internal.cache.partitioned.PersistentColocatedPartitionedRegionDUnitTest.testHierarchyOfColocatedChildPRsMissing(PersistentColocatedPartitionedRegionDUnitTest.java:920)
org.apache.geode.internal.cache.partitioned.PersistentColocatedPartitionedRegionDUnitTest
> testMissingColocatedChildPR FAILED
java.util.concurrent.TimeoutException: Timed out waiting 6 milliseconds
for AsyncInvocation to complete.
at
org.apache.geode.test.dunit.AsyncInvocation.timeoutIfAlive(AsyncInvocation.java:464)
at
org.apache.geode.test.dunit.AsyncInvocation.get(AsyncInvocation.java:414)
at
org.apache.geode.internal.cache.partitioned.PersistentColocatedPartitionedRegionDUnitTest.testMissingColocatedChildPR(PersistentColocatedPartitionedRegionDUnitTest.java:754)
org.apache.geode.internal.cache.partitioned.PersistentColocatedPartitionedRegionDUnitTest
> testHierarchyOfColocatedChildPRsMissingGrandchild FAILED
java.util.concurrent.TimeoutException: Timed out waiting 6 milliseconds
for AsyncInvocation to complete.
at
org.apache.geode.test.dunit.AsyncInvocation.timeoutIfAlive(AsyncInvocation.java:464)
at
org.apache.geode.test.dunit.AsyncInvocation.get(AsyncInvocation.java:414)
at
org.apache.geode.internal.cache.partitioned.PersistentColocatedPartitionedRegionDUnitTest.testHierarchyOfColocatedChildPRsMissingGrandchild(PersistentColocatedPartitionedRegionDUnitTest.java:979)
{noformat}
> PersistentColocatedPartitionedRegionDUnitTest: Timed out waiting 6
> milliseconds for AsyncInvocation to complete.
>
>
> Key: GEODE-6499
> URL: https://issues.apache.org/jira/browse/GEODE-6499
> Project: Geode
> Issue Type: Bug
> Components: tests
>Reporter: Mark Hanson
>Assignee: Kenneth Howe
>Priority: Major
> Attachments: PersistentColocatedPartitionedRegionDUnitTest.tgz
>
>
> {noformat}
>
> Task :geode-core:distributedTest
>
> org.apache.geode.internal.cache.partitioned.PersistentColocatedPartitionedRegionDUnitTest
> > testHierarchyOfColocatedChildPRsMissingGrandchild FAILED
> java.util.concurrent.TimeoutException: Timed out waiting 6 milliseconds
> for AsyncInvocation to complete.
> at
> org.apache.geode.test.dunit.AsyncInvocation.timeoutIfAlive(AsyncInvocation.java:462)
> at org.apache.geode.test.dunit.AsyncInvocation.get(AsyncInvocation.java:412)
> at
> org.apache.geode.internal.cache.partitioned.PersistentColocatedPartitionedRegionDUnitTest.testHierarchyOfColocatedChildPRsMissingGrandchild(PersistentColocatedPartitionedRegionDUnitTest.java:979)
>
>
>
[jira] [Commented] (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:comment-tabpanel=16911295#comment-16911295
]
ASF subversion and git services commented on GEODE-7102:
Commit 0e19dcdad4bccd0f756ed81605f5ae608ebec746 in geode's branch
refs/heads/develop from Jens Deppe
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=0e19dcd ]
GEODE-7102: Convert tests to use CertificateBuilder (#3946)
Authored-by: Jens Deppe
> 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
> Time Spent: 20m
> 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.2#803003)
[jira] [Assigned] (GEODE-6915) Improve CompiledGroupBySelect Integration Test
[
https://issues.apache.org/jira/browse/GEODE-6915?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Juan José Ramos Cassella reassigned GEODE-6915:
---
Assignee: Juan José Ramos Cassella
> Improve CompiledGroupBySelect Integration Test
> --
>
> Key: GEODE-6915
> URL: https://issues.apache.org/jira/browse/GEODE-6915
> Project: Geode
> Issue Type: Improvement
> Components: tests
>Reporter: Juan José Ramos Cassella
>Assignee: Juan José Ramos Cassella
>Priority: Major
> Labels: GeodeCommons
>
> The name for {{CompiledGroupBySelectJUnitTest}} implies that the test is a
> *unit test* but it's not, it's actually an *integration test*: rename the
> class to {{CompiledGroupBySelectIntegrationTest}} instead. Also, the test
> only verifies the query compilation for some variations only ({{count}},
> {{group by}} and {{max}}), add tests for the remaining aggregate functions.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
