[jira] [Closed] (GEODE-10418) Uplift Jetty to a newer version
[ https://issues.apache.org/jira/browse/GEODE-10418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Kevo closed GEODE-10418. -- > Uplift Jetty to a newer version > --- > > Key: GEODE-10418 > URL: https://issues.apache.org/jira/browse/GEODE-10418 > Project: Geode > Issue Type: Bug >Reporter: Mario Kevo >Priority: Major > Labels: needsTriage > > The uplift of Eclipse Jetty to version 9.4.47 is needed due to high > vulnerability (CVE-2022-2048). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (GEODE-10418) Uplift Jetty to a newer version
[ https://issues.apache.org/jira/browse/GEODE-10418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Kevo resolved GEODE-10418. Resolution: Duplicate > Uplift Jetty to a newer version > --- > > Key: GEODE-10418 > URL: https://issues.apache.org/jira/browse/GEODE-10418 > Project: Geode > Issue Type: Bug >Reporter: Mario Kevo >Priority: Major > Labels: needsTriage > > The uplift of Eclipse Jetty to version 9.4.47 is needed due to high > vulnerability (CVE-2022-2048). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (GEODE-10418) Uplift Jetty to a newer version
[ https://issues.apache.org/jira/browse/GEODE-10418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17601374#comment-17601374 ] Mario Kevo commented on GEODE-10418: Yes, didn't see it. Thanks! > Uplift Jetty to a newer version > --- > > Key: GEODE-10418 > URL: https://issues.apache.org/jira/browse/GEODE-10418 > Project: Geode > Issue Type: Bug >Reporter: Mario Kevo >Priority: Major > Labels: needsTriage > > The uplift of Eclipse Jetty to version 9.4.47 is needed due to high > vulnerability (CVE-2022-2048). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (GEODE-10418) Uplift Jetty to a newer version
[ https://issues.apache.org/jira/browse/GEODE-10418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17601324#comment-17601324 ] Dick Cavender commented on GEODE-10418: --- I think this is same-as [GEODE-10415|https://issues.apache.org/jira/browse/GEODE-10415] > Uplift Jetty to a newer version > --- > > Key: GEODE-10418 > URL: https://issues.apache.org/jira/browse/GEODE-10418 > Project: Geode > Issue Type: Bug >Reporter: Mario Kevo >Priority: Major > Labels: needsTriage > > The uplift of Eclipse Jetty to version 9.4.47 is needed due to high > vulnerability (CVE-2022-2048). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (GEODE-10337) SocketCreatorFactory does not null out instance static
[
https://issues.apache.org/jira/browse/GEODE-10337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mario Ivanac resolved GEODE-10337.
--
Fix Version/s: 1.16.0
Resolution: Fixed
> SocketCreatorFactory does not null out instance static
> --
>
> Key: GEODE-10337
> URL: https://issues.apache.org/jira/browse/GEODE-10337
> Project: Geode
> Issue Type: Bug
> Components: membership
>Reporter: Darrel Schneider
>Assignee: Mario Ivanac
>Priority: Major
> Labels: blocks-1.16.0, pull-request-available
> Fix For: 1.16.0
>
>
> The SocketCreatorFactory has a static "instance" field that keeps the
> singleton factory. The factory has a reference in "distributionConfig" that
> ends up keeping the InternalDistributedSystem alive after disconnect.
> It also has a static close method but the product never calls it.
> To fix this leak do the following:
> On InternalDistributedSystem.disconnect add to the end of it:
> {code:java}
> if (!attemptingToReconnect) {
> SocketCreatorFactory.close();
> }
> {code}
> Also I think it would be good to change SocketCreatorFactory.getInstance to
> null out the static when close it called like so:
> {code:java}
> private static synchronized SocketCreatorFactory getInstance(boolean
> closing) {
> SocketCreatorFactory result = instance;
> if (result == null && !closing) {
> result = new SocketCreatorFactory();
> instance = result;
> } else if (result != null && closing) {
> instance = null;
> }
> return result;
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GEODE-10337) SocketCreatorFactory does not null out instance static
[
https://issues.apache.org/jira/browse/GEODE-10337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17601304#comment-17601304
]
ASF subversion and git services commented on GEODE-10337:
-
Commit 596a601d199ed810caf06cbc0bfc58ae3581f691 in geode's branch
refs/heads/develop from Mario Ivanac
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=596a601d19 ]
GEODE-10337: add use of SocketCreatorFactory.close() (#7842)
* GEODE-10337: add use of SocketCreatorFactory.close()
* GEODE-10337: added UT
> SocketCreatorFactory does not null out instance static
> --
>
> Key: GEODE-10337
> URL: https://issues.apache.org/jira/browse/GEODE-10337
> Project: Geode
> Issue Type: Bug
> Components: membership
>Reporter: Darrel Schneider
>Assignee: Mario Ivanac
>Priority: Major
> Labels: blocks-1.16.0, pull-request-available
>
> The SocketCreatorFactory has a static "instance" field that keeps the
> singleton factory. The factory has a reference in "distributionConfig" that
> ends up keeping the InternalDistributedSystem alive after disconnect.
> It also has a static close method but the product never calls it.
> To fix this leak do the following:
> On InternalDistributedSystem.disconnect add to the end of it:
> {code:java}
> if (!attemptingToReconnect) {
> SocketCreatorFactory.close();
> }
> {code}
> Also I think it would be good to change SocketCreatorFactory.getInstance to
> null out the static when close it called like so:
> {code:java}
> private static synchronized SocketCreatorFactory getInstance(boolean
> closing) {
> SocketCreatorFactory result = instance;
> if (result == null && !closing) {
> result = new SocketCreatorFactory();
> instance = result;
> } else if (result != null && closing) {
> instance = null;
> }
> return result;
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (GEODE-10418) Uplift Jetty to a newer version
[ https://issues.apache.org/jira/browse/GEODE-10418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann updated GEODE-10418: -- Labels: needsTriage (was: ) > Uplift Jetty to a newer version > --- > > Key: GEODE-10418 > URL: https://issues.apache.org/jira/browse/GEODE-10418 > Project: Geode > Issue Type: Bug >Reporter: Mario Kevo >Priority: Major > Labels: needsTriage > > The uplift of Eclipse Jetty to version 9.4.47 is needed due to high > vulnerability (CVE-2022-2048). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (GEODE-10418) Uplift Jetty to a newer version
Mario Kevo created GEODE-10418: -- Summary: Uplift Jetty to a newer version Key: GEODE-10418 URL: https://issues.apache.org/jira/browse/GEODE-10418 Project: Geode Issue Type: Bug Reporter: Mario Kevo The uplift of Eclipse Jetty to version 9.4.47 is needed due to high vulnerability (CVE-2022-2048). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (GEODE-9918) Distributed transaction is not a supported feature in geode
[ https://issues.apache.org/jira/browse/GEODE-9918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jakov Varenina reassigned GEODE-9918: - Assignee: Jakov Varenina > Distributed transaction is not a supported feature in geode > --- > > Key: GEODE-9918 > URL: https://issues.apache.org/jira/browse/GEODE-9918 > Project: Geode > Issue Type: Bug > Components: transactions >Reporter: Eric Shu >Assignee: Jakov Varenina >Priority: Major > Labels: GeodeOperationAPI > > Geode should throw UnsupportedOperationException when > CacheTransactionManager.setDistributed(true) is invoked. As the feature is > currently not supported. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (GEODE-10417) Fix NullPointerException when getting events from the gw sender queue to complete transactions
[ https://issues.apache.org/jira/browse/GEODE-10417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alberto Gomez resolved GEODE-10417. --- Fix Version/s: 1.16.0 Resolution: Fixed > Fix NullPointerException when getting events from the gw sender queue to > complete transactions > -- > > Key: GEODE-10417 > URL: https://issues.apache.org/jira/browse/GEODE-10417 > Project: Geode > Issue Type: Bug > Components: wan >Affects Versions: 1.13.8, 1.14.4, 1.15.0 >Reporter: Alberto Gomez >Assignee: Alberto Gomez >Priority: Major > Labels: needsTriage, pull-request-available > Fix For: 1.16.0 > > > When the WAN group-transaction-events feature is enabled in a parallel > gateway sender, it is possible to get a NullPointerException when retrieving > events from the queue to complete a transaction if the event in the queue is > null. > If this situation is reached then the gateway sender dispatcher will not > dispatch queue events anymore and therefore the WAN replication will not > progress. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (GEODE-10417) Fix NullPointerException when getting events from the gw sender queue to complete transactions
[ https://issues.apache.org/jira/browse/GEODE-10417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17601261#comment-17601261 ] ASF subversion and git services commented on GEODE-10417: - Commit dd485b2d118f12adf7e1629748de1439fa3d2e0d in geode's branch refs/heads/develop from Alberto Gomez [ https://gitbox.apache.org/repos/asf?p=geode.git;h=dd485b2d11 ] GEODE-10417: Fix NullPointerException in WAN replication (#7845) * GEODE-10417: Fix NullPointerException in WAN replication When the WAN group-transa$ction-events feature is enabled in a parallel gateway sender, it is possible to get a NullPointerException when retrieving events from the queue to complete a transaction if the event in the queue is null. If this situation is reached then the gateway sender dispatcher will not dispatch queue events anymore and therefore the WAN replication will not progress. This happens because the predicates that check if elements in the queue contain a transactionId are not protected against the event being null. A null check has been added before the predicates are invoked so that in case of a null event, the predicate is not invoked and the event is skipped from the checking. * GEODE-10417: Change assertEquals to assertThat > Fix NullPointerException when getting events from the gw sender queue to > complete transactions > -- > > Key: GEODE-10417 > URL: https://issues.apache.org/jira/browse/GEODE-10417 > Project: Geode > Issue Type: Bug > Components: wan >Affects Versions: 1.13.8, 1.14.4, 1.15.0 >Reporter: Alberto Gomez >Assignee: Alberto Gomez >Priority: Major > Labels: needsTriage, pull-request-available > > When the WAN group-transaction-events feature is enabled in a parallel > gateway sender, it is possible to get a NullPointerException when retrieving > events from the queue to complete a transaction if the event in the queue is > null. > If this situation is reached then the gateway sender dispatcher will not > dispatch queue events anymore and therefore the WAN replication will not > progress. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (GEODE-10038) Trying to access the QueryService results in NPE on server restart from deployed Jar
[
https://issues.apache.org/jira/browse/GEODE-10038?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jakov Varenina reassigned GEODE-10038:
--
Assignee: Jakov Varenina
> Trying to access the QueryService results in NPE on server restart from
> deployed Jar
>
>
> Key: GEODE-10038
> URL: https://issues.apache.org/jira/browse/GEODE-10038
> Project: Geode
> Issue Type: Bug
> Components: functions
>Affects Versions: 1.12.8, 1.13.7, 1.14.3, 1.15.0
>Reporter: Udo Kohlmeyer
>Assignee: Jakov Varenina
>Priority: Major
>
> After deploying a jar which contains a Function, restarting the server causes
> an NPE.
> Using the Function definition of:
> {code:java}
> public class CustomFunction implements Function {
> private GemFireCache cache;
> private QueryService queryService;
> public CustomFunction() {
> this.cache = CacheFactory.getAnyInstance();
> this.queryService = cache.getQueryService();
> }
> {code}
> Due to the startup flow
> https://github.com/apache/geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/GemFireCacheImpl.java#L1404
> the registration of Functions are initialized from cluster configuration
> [here|https://github.com/apache/geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/GemFireCacheImpl.java#L1419].
> There is a dependency on the `QueryService` to be available at Function
> construction time, but given that the services are only initialized
> [here|https://github.com/apache/geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/GemFireCacheImpl.java#L1435],
> the call to the `cache.getQueryService` fails with an NPE
> [here|https://github.com/apache/geode/blob/develop/geode-core/src/main/java/org/apache/geode/cache/query/internal/DefaultQueryService.java#L116-L117]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (GEODE-7201) Useless and unhelpful Exception inappropriately logged at ERROR
[
https://issues.apache.org/jira/browse/GEODE-7201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jakov Varenina reassigned GEODE-7201:
-
Assignee: (was: Jakov Varenina)
> Useless and unhelpful Exception inappropriately logged at ERROR
> ---
>
> Key: GEODE-7201
> URL: https://issues.apache.org/jira/browse/GEODE-7201
> Project: Geode
> Issue Type: Bug
>Reporter: John Blum
>Priority: Major
> Labels: affects-spring
>
> For testing, it is valid that I might register interests on a client Region
> where the server-side Region is a PARTITION Region, yet I am not using either
> mcast-port or Locators since I only need a single server for my tests!
> Therefore this Exception is not helpful in anyway and only adds confusion to
> the user...
> {code}
> 08:59:51 Caused by: java.lang.IllegalStateException: Should not register
> interest for a partitioned region when mcast-port is 0 and no locator is
> present
> 08:59:51 at
> org.apache.geode.internal.cache.tier.sockets.command.RegisterInterest61.cmdExecute(RegisterInterest61.java:257)
> 08:59:51 at
> org.apache.geode.internal.cache.tier.sockets.BaseCommand.execute(BaseCommand.java:183)
> 08:59:51 at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.doNormalMessage(ServerConnection.java:848)
> 08:59:51 at
> org.apache.geode.internal.cache.tier.sockets.OriginalServerConnection.doOneMessage(OriginalServerConnection.java:72)
> 08:59:51 at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.run(ServerConnection.java:1212)
> 08:59:51 at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> 08:59:51 at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> 08:59:51 at
> org.apache.geode.internal.cache.tier.sockets.AcceptorImpl.lambda$initializeServerConnectionThreadPool$3(AcceptorImpl.java:676)
> 08:59:51 at
> org.apache.geode.logging.internal.executors.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:119)
> 08:59:51 ... 1 more
> {code}
> So, I "should" not...
> > "_Should not register interest for a partitioned region when mcast-port is
> > 0 and no locator is present_"
> Why not?
> And, why does this message need to be logged at ERROR? WARN would suffice,
> especially since "_should_" implies a "_recommendation_" and not a strict,
> hard rule or requirement, which would rather be appropriately stated as
> "_Must not register interest..._".
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (GEODE-7201) Useless and unhelpful Exception inappropriately logged at ERROR
[
https://issues.apache.org/jira/browse/GEODE-7201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jakov Varenina reassigned GEODE-7201:
-
Assignee: Jakov Varenina
> Useless and unhelpful Exception inappropriately logged at ERROR
> ---
>
> Key: GEODE-7201
> URL: https://issues.apache.org/jira/browse/GEODE-7201
> Project: Geode
> Issue Type: Bug
>Reporter: John Blum
>Assignee: Jakov Varenina
>Priority: Major
> Labels: affects-spring
>
> For testing, it is valid that I might register interests on a client Region
> where the server-side Region is a PARTITION Region, yet I am not using either
> mcast-port or Locators since I only need a single server for my tests!
> Therefore this Exception is not helpful in anyway and only adds confusion to
> the user...
> {code}
> 08:59:51 Caused by: java.lang.IllegalStateException: Should not register
> interest for a partitioned region when mcast-port is 0 and no locator is
> present
> 08:59:51 at
> org.apache.geode.internal.cache.tier.sockets.command.RegisterInterest61.cmdExecute(RegisterInterest61.java:257)
> 08:59:51 at
> org.apache.geode.internal.cache.tier.sockets.BaseCommand.execute(BaseCommand.java:183)
> 08:59:51 at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.doNormalMessage(ServerConnection.java:848)
> 08:59:51 at
> org.apache.geode.internal.cache.tier.sockets.OriginalServerConnection.doOneMessage(OriginalServerConnection.java:72)
> 08:59:51 at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.run(ServerConnection.java:1212)
> 08:59:51 at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> 08:59:51 at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> 08:59:51 at
> org.apache.geode.internal.cache.tier.sockets.AcceptorImpl.lambda$initializeServerConnectionThreadPool$3(AcceptorImpl.java:676)
> 08:59:51 at
> org.apache.geode.logging.internal.executors.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:119)
> 08:59:51 ... 1 more
> {code}
> So, I "should" not...
> > "_Should not register interest for a partitioned region when mcast-port is
> > 0 and no locator is present_"
> Why not?
> And, why does this message need to be logged at ERROR? WARN would suffice,
> especially since "_should_" implies a "_recommendation_" and not a strict,
> hard rule or requirement, which would rather be appropriately stated as
> "_Must not register interest..._".
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (GEODE-10395) TXLockIdImpl memory leak after CommitConflictException from another node
[
https://issues.apache.org/jira/browse/GEODE-10395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-10395:
---
Labels: pull-request-available (was: )
> TXLockIdImpl memory leak after CommitConflictException from another node
>
>
> Key: GEODE-10395
> URL: https://issues.apache.org/jira/browse/GEODE-10395
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.14.0, 1.15.0
>Reporter: Eugene Nedzvetsky
>Assignee: Mario Kevo
>Priority: Major
> Labels: pull-request-available
>
> org.apache.geode.internal.cache.locks.TXLockServiceImpl#txLock:120 adds
> TXLockIdImpl objects to TXLockServiceImpl#txLockIdList.
> {code:java}
> synchronized (txLockIdList) {
> txLockId = new TXLockIdImpl(dlock.getDistributionManager().getId());
> txLockIdList.add(txLockId);
> }
> {code}
> These objects will not be removed from this list if dlock.acquireTryLocks
> returned false.
> {code:java}
> gotLocks = dlock.acquireTryLocks(batch, TIMEOUT_MILLIS, LEASE_MILLIS,
> keyIfFail);
> if (gotLocks) { // ...otherwise race can occur between tryLocks and
> readLock
> acquireRecoveryReadLock();
> } else if (keyIfFail[0] != null) {
> throw new CommitConflictException(
> String.format("Concurrent transaction commit detected %s",
> keyIfFail[0]));
> } else {
> throw new CommitConflictException(
> String.format("Failed to request try locks from grantor: %s",
> dlock.getLockGrantorId()));
> }
> {code}
> It throws CommitConflictException and after that system doesn't have a
> txLockId reference and this txLockId will be never removed from this list.
> It produces critical performance degradation. txLockIdList has a few hundred
> thousand txLocks after a few weeks and TXLockServiceImpl#release iterates
> this list 2 times on every tx commit and the same time "synchronized
> (txLockIdList)" locks other threads.
> TXLockIdImpl#equals works really slow because it checks bunch of variables in
> memberId.equals(that.memberId).
> {code:java}
> public void release(TXLockId txLockId) {
> synchronized (txLockIdList) {
> if (!txLockIdList.contains(txLockId)) {
> // TXLockService.destroyServices can be invoked in cache.close().
> // Other P2P threads could process message such as TXCommitMessage
> afterwards,
> // and invoke TXLockService.createDTLS(). It could create a new
> TXLockService
> // which will have a new empty list (txLockIdList) and it will not
> // contain the originally added txLockId
> throw new IllegalArgumentException(
> String.format("Invalid txLockId not found: %s",
> txLockId));
> }
> dlock.releaseTryLocks(txLockId, () -> {
> return recovering;
> });
> txLockIdList.remove(txLockId);
> releaseRecoveryReadLock();
> }
> }
> {code}
> I think TXLockServiceImpl#txLock should remove this txLockId from
> TXLockServiceImpl#txLockIdList in case of CommitConflictException:
> {code:java}
> if (gotLocks) { // ...otherwise race can occur between tryLocks and readLock
> acquireRecoveryReadLock();
> } else if (keyIfFail[0] != null) {
> synchronized (this.txLockIdList) {
> this.txLockIdList.remove(txLockId);
> }
> throw new CommitConflictException(
> String.format("Concurrent transaction commit detected
> %s",
> keyIfFail[0]));
> } else {
> synchronized (this.txLockIdList) {
> this.txLockIdList.remove(txLockId);
> }
> throw new CommitConflictException(
> String.format("Failed to request try locks from
> grantor: %s",
> this.dlock.getLockGrantorId()));
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (GEODE-10338) LogWriterAppender keeps a InternalDistributedSystem alive after disconnect
[
https://issues.apache.org/jira/browse/GEODE-10338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jakov Varenina resolved GEODE-10338.
Fix Version/s: 1.16.0
Resolution: Fixed
> LogWriterAppender keeps a InternalDistributedSystem alive after disconnect
> --
>
> Key: GEODE-10338
> URL: https://issues.apache.org/jira/browse/GEODE-10338
> Project: Geode
> Issue Type: Bug
> Components: logging
>Reporter: Darrel Schneider
>Assignee: Jakov Varenina
>Priority: Major
> Labels: blocks-1.16.0, pull-request-available
> Fix For: 1.16.0
>
>
> The LogWriterAppender has a "logWriter" field that can be a ManagerLogWriter.
> When stopSession is called on the appender, it closes the ManagerLogWriter's
> files but does not release its reference to it and the LogWriterAppender
> instance is kept around after disconnect. So this ends up keeping the
> InternalDistributedSystem alive.
> To fix this change LogWriterAppender.stopSession like so:
> {code:java}
> public synchronized void stopSession() {
> LOGGER.info("Stopping session in {}.", this);
> if (logWriter == null) {
> // we are probably already paused but make sure we are
> pause();
> return;
> }
> logWriter.shuttingDown();
> pause();
> logWriter.closingLogFile();
> logWriter = null;
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GEODE-10338) LogWriterAppender keeps a InternalDistributedSystem alive after disconnect
[
https://issues.apache.org/jira/browse/GEODE-10338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17601166#comment-17601166
]
ASF subversion and git services commented on GEODE-10338:
-
Commit 754e5c3b9cdd0cd6eeebe9a28443ff1f1cad23e0 in geode's branch
refs/heads/develop from Jakov Varenina
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=754e5c3b9c ]
GEODE-10338: Fix LogWriterAppender shutdown (#7725)
* GEODE-10338: Fix LogWriterAppender shutdown
When a stop session is called on the LogWriterAppender, it closes the
ManagerLogWriter's files. Still, it does not release
ManagerLogWriter's reference, so the LogWriterAppender instance is
kept around after disconnect. This situation ends up keeping the
InternalDistributedSystem alive.
The fix is to clear the LogWriterAppender's reference to the
ManagerLogWriter when the appender session is stopped.
* Update after review
* Fix integration test
* Add nullptr check in stopSession()
> LogWriterAppender keeps a InternalDistributedSystem alive after disconnect
> --
>
> Key: GEODE-10338
> URL: https://issues.apache.org/jira/browse/GEODE-10338
> Project: Geode
> Issue Type: Bug
> Components: logging
>Reporter: Darrel Schneider
>Assignee: Jakov Varenina
>Priority: Major
> Labels: blocks-1.16.0, pull-request-available
>
> The LogWriterAppender has a "logWriter" field that can be a ManagerLogWriter.
> When stopSession is called on the appender, it closes the ManagerLogWriter's
> files but does not release its reference to it and the LogWriterAppender
> instance is kept around after disconnect. So this ends up keeping the
> InternalDistributedSystem alive.
> To fix this change LogWriterAppender.stopSession like so:
> {code:java}
> public synchronized void stopSession() {
> LOGGER.info("Stopping session in {}.", this);
> if (logWriter == null) {
> // we are probably already paused but make sure we are
> pause();
> return;
> }
> logWriter.shuttingDown();
> pause();
> logWriter.closingLogFile();
> logWriter = null;
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
