[jira] [Created] (GEODE-3557) Classes that have access to a DM should be changed to ask it for the InternalCache instead of calling GemFIreCacheImpl.getInstance
Darrel Schneider created GEODE-3557: --- Summary: Classes that have access to a DM should be changed to ask it for the InternalCache instead of calling GemFIreCacheImpl.getInstance Key: GEODE-3557 URL: https://issues.apache.org/jira/browse/GEODE-3557 Project: Geode Issue Type: Improvement Components: core Reporter: Darrel Schneider A large number of classes call GemFireCacheImpl.getInstance that have access to a DM instance. The DM should be changed to remember the InternalCache associated with it and these classes can then ask it for the cache instead. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (GEODE-3557) Classes that have access to a DM should be changed to ask it for the InternalCache instead of calling GemFIreCacheImpl.getInstance
[ https://issues.apache.org/jira/browse/GEODE-3557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darrel Schneider reassigned GEODE-3557: --- Assignee: Darrel Schneider > Classes that have access to a DM should be changed to ask it for the > InternalCache instead of calling GemFIreCacheImpl.getInstance > -- > > Key: GEODE-3557 > URL: https://issues.apache.org/jira/browse/GEODE-3557 > Project: Geode > Issue Type: Improvement > Components: core >Reporter: Darrel Schneider >Assignee: Darrel Schneider > > A large number of classes call GemFireCacheImpl.getInstance that have access > to a DM instance. > The DM should be changed to remember the InternalCache associated with it and > these classes can then ask it for the cache instead. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (GEODE-3077) Client connection counts should be accurate
[
https://issues.apache.org/jira/browse/GEODE-3077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Galen O'Sullivan resolved GEODE-3077.
-
Resolution: Duplicate
Fix Version/s: 1.3.0
> Client connection counts should be accurate
> ---
>
> Key: GEODE-3077
> URL: https://issues.apache.org/jira/browse/GEODE-3077
> Project: Geode
> Issue Type: Sub-task
> Components: client/server
>Reporter: Galen O'Sullivan
> Fix For: 1.3.0
>
>
> As a dev user of Geode, I want to be able to look at connection counts and
> know they are reliable (no matter if I'm using the new client/server protocol
> or the old). Revisit connection-counting-related methods and ensure the
> counting mechanism is accurate.
> Specifically:
> Have a look at where and how the following three functions are used:
> {code}
> public void incClientServerCnxCount() {
> this.clientServerCnxCount.incrementAndGet();
> }
> public void decClientServerCnxCount() {
> this.clientServerCnxCount.decrementAndGet();
> }
> public int getClientServerCnxCount() {
> return this.clientServerCnxCount.get();
> }
> {code}
> These are tracking client-server connections. Extract these into common code
> in {{ServerConnection}} that both {{NewClientServerConnection}} and
> {{LegacyServerConnection}} can use, and make sure that counts are correct in
> both creation and cleanup situations. Write some tests to verify.
> Note: client counts look to be tracked separately from connection counts; the
> old protocol can have multiple connections per client. We're interested with
> the connection count in this ticket.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (GEODE-3556) Update gradle docker plugin
[ https://issues.apache.org/jira/browse/GEODE-3556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16151147#comment-16151147 ] ASF subversion and git services commented on GEODE-3556: Commit 6d32e28727136ce72ecff0017f7f6079757b819f in geode's branch refs/heads/feature/GEODE-3556 from [~jens.deppe] [ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=6d32e28 ] GEODE-3556: Update gradle docker plugin to 0.5.4 - Note that this feature only works on Linux > Update gradle docker plugin > --- > > Key: GEODE-3556 > URL: https://issues.apache.org/jira/browse/GEODE-3556 > Project: Geode > Issue Type: Improvement > Components: build >Reporter: Jens Deppe > > Since gradle has been updated to 3.5.1, the docker gradle plugin does not > work any more. We need to update the plugin to 0.5.4 and fix the associated > configuration. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (GEODE-3556) Update gradle docker plugin
Jens Deppe created GEODE-3556: - Summary: Update gradle docker plugin Key: GEODE-3556 URL: https://issues.apache.org/jira/browse/GEODE-3556 Project: Geode Issue Type: Improvement Components: build Reporter: Jens Deppe Since gradle has been updated to 3.5.1, the docker gradle plugin does not work any more. We need to update the plugin to 0.5.4 and fix the associated configuration. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (GEODE-3555) Protobuf clients are rejected with an old-client-specific message.
[
https://issues.apache.org/jira/browse/GEODE-3555?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Galen O'Sullivan updated GEODE-3555:
Description:
If the number of client connections is above the configured maximum, new client
connections will be rejected with a message that is meant for old clients and,
to them, is unintelligible.
This can be seen with the following test added to
{{RoundTripCacheConnectionJUnitTest}}:
{code}
@Test
public void testNewProtocolRespectsMaxConnectionLimit()
throws IOException, InterruptedException {
cache.close();
CacheFactory cacheFactory = new CacheFactory();
Cache cache = cacheFactory.create();
CacheServer cacheServer = cache.addCacheServer();
final int cacheServerPort = AvailablePortHelper.getRandomAvailableTCPPort();
cacheServer.setPort(cacheServerPort);
cacheServer.setMaxConnections(16);
cacheServer.setMaxThreads(16);
cacheServer.start();
AcceptorImpl acceptor = ((CacheServerImpl) cacheServer).getAcceptor();
Socket[] sockets = new Socket[16];
for (int i = 0; i < 16; i++) {
Socket socket = new Socket("localhost", cacheServerPort);
sockets[i] = socket;
Awaitility.await().atMost(5, TimeUnit.SECONDS).until(socket::isConnected);
socket.getOutputStream().write(CommunicationMode.ProtobufClientServerProtocol.getModeNumber());
}
try (Socket socket = new Socket("localhost", cacheServerPort)) {
Awaitility.await().atMost(5,
TimeUnit.SECONDS).until(socket::isConnected);
OutputStream outputStream = socket.getOutputStream();
outputStream
.write(CommunicationMode.ProtobufClientServerProtocol.getModeNumber());
assertEquals(-1, socket.getInputStream().read());
}
{code}
This can be traced to a call to
{{ServerHandShakeProcessor.refuse(socket.getOutputStream(), ...}} .
was:
If the number of client connections is above the configured maximum, new client
connections will be rejected with a message that is meant for old clients and,
to them, is unintelligible.
This can be seen with the following test added to
{{RoundTripCacheConnectionJUnitTest}}:
{code}
@Test
public void testNewProtocolRespectsMaxConnectionLimit()
throws IOException, InterruptedException {
cache.close();
CacheFactory cacheFactory = new CacheFactory();
Cache cache = cacheFactory.create();
CacheServer cacheServer = cache.addCacheServer();
final int cacheServerPort = AvailablePortHelper.getRandomAvailableTCPPort();
cacheServer.setPort(cacheServerPort);
cacheServer.setMaxConnections(16);
cacheServer.setMaxThreads(16);
cacheServer.start();
AcceptorImpl acceptor = ((CacheServerImpl) cacheServer).getAcceptor();
Socket[] sockets = new Socket[16];
for (int i = 0; i < 16; i++) {
Socket socket = new Socket("localhost", cacheServerPort);
sockets[i] = socket;
Awaitility.await().atMost(5, TimeUnit.SECONDS).until(socket::isConnected);
socket.getOutputStream().write(CommunicationMode.ProtobufClientServerProtocol.getModeNumber());
}
try (Socket socket = new Socket("localhost", cacheServerPort)) {
Awaitility.await().atMost(5,
TimeUnit.SECONDS).until(socket::isConnected);
OutputStream outputStream = socket.getOutputStream();
outputStream
.write(CommunicationMode.ProtobufClientServerProtocol.getModeNumber());
assertEquals(-1, socket.getInputStream().read());
}
{code}
This can be traced to a call to {{
ServerHandShakeProcessor.refuse(socket.getOutputStream(), ...}}
.
> Protobuf clients are rejected with an old-client-specific message.
> --
>
> Key: GEODE-3555
> URL: https://issues.apache.org/jira/browse/GEODE-3555
> Project: Geode
> Issue Type: Bug
> Components: messaging
>Reporter: Galen O'Sullivan
> Fix For: 1.3.0
>
>
> If the number of client connections is above the configured maximum, new
> client connections will be rejected with a message that is meant for old
> clients and, to them, is unintelligible.
> This can be seen with the following test added to
> {{RoundTripCacheConnectionJUnitTest}}:
> {code}
> @Test
> public void testNewProtocolRespectsMaxConnectionLimit()
> throws IOException, InterruptedException {
> cache.close();
> CacheFactory cacheFactory = new CacheFactory();
> Cache cache = cacheFactory.create();
> CacheServer cacheServer = cache.addCacheServer();
> final int cacheServerPort =
> AvailablePortHelper.getRandomAvailableTCPPort();
> cacheServer.setPort(cacheServerPort);
> cacheServer.setMaxConnections(16);
> cacheServer.setMaxThreads(16);
> cacheServer.start();
> AcceptorImpl acceptor = ((CacheServerImpl) cacheServer).getAcceptor();
>
[jira] [Updated] (GEODE-3555) Protobuf clients are rejected with an old-client-specific message.
[
https://issues.apache.org/jira/browse/GEODE-3555?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Galen O'Sullivan updated GEODE-3555:
Description:
If the number of client connections is above the configured maximum, new client
connections will be rejected with a message that is meant for old clients and,
to them, is unintelligible.
This can be seen with the following test added to
{{RoundTripCacheConnectionJUnitTest}}:
{code}
@Test
public void testNewProtocolRespectsMaxConnectionLimit()
throws IOException, InterruptedException {
cache.close();
CacheFactory cacheFactory = new CacheFactory();
Cache cache = cacheFactory.create();
CacheServer cacheServer = cache.addCacheServer();
final int cacheServerPort = AvailablePortHelper.getRandomAvailableTCPPort();
cacheServer.setPort(cacheServerPort);
cacheServer.setMaxConnections(16);
cacheServer.setMaxThreads(16);
cacheServer.start();
AcceptorImpl acceptor = ((CacheServerImpl) cacheServer).getAcceptor();
Socket[] sockets = new Socket[16];
for (int i = 0; i < 16; i++) {
Socket socket = new Socket("localhost", cacheServerPort);
sockets[i] = socket;
Awaitility.await().atMost(5, TimeUnit.SECONDS).until(socket::isConnected);
socket.getOutputStream().write(CommunicationMode.ProtobufClientServerProtocol.getModeNumber());
}
try (Socket socket = new Socket("localhost", cacheServerPort)) {
Awaitility.await().atMost(5,
TimeUnit.SECONDS).until(socket::isConnected);
OutputStream outputStream = socket.getOutputStream();
outputStream
.write(CommunicationMode.ProtobufClientServerProtocol.getModeNumber());
assertEquals(-1, socket.getInputStream().read());
}
{code}
This can be traced to a call to {{
ServerHandShakeProcessor.refuse(socket.getOutputStream(), ...}}
.
was:
If the number of client connections is above the configured maximum, new client
connections will be rejected with a message that is meant for old clients and,
to them, is unintelligible.
This can be seen with the following test added to
{{RoundTripCacheConnectionJUnitTest}}:
{code}
@Test
public void testNewProtocolRespectsMaxConnectionLimit()
throws IOException, InterruptedException {
cache.close();
CacheFactory cacheFactory = new CacheFactory();
Cache cache = cacheFactory.create();
CacheServer cacheServer = cache.addCacheServer();
final int cacheServerPort = AvailablePortHelper.getRandomAvailableTCPPort();
cacheServer.setPort(cacheServerPort);
cacheServer.setMaxConnections(16);
cacheServer.setMaxThreads(16);
cacheServer.start();
AcceptorImpl acceptor = ((CacheServerImpl) cacheServer).getAcceptor();
Socket[] sockets = new Socket[16];
for (int i = 0; i < 16; i++) {
Socket socket = new Socket("localhost", cacheServerPort);
sockets[i] = socket;
Awaitility.await().atMost(5, TimeUnit.SECONDS).until(socket::isConnected);
socket.getOutputStream().write(CommunicationMode.ProtobufClientServerProtocol.getModeNumber());
}
try (Socket socket = new Socket("localhost", cacheServerPort)) {
Awaitility.await().atMost(5,
TimeUnit.SECONDS).until(socket::isConnected);
OutputStream outputStream = socket.getOutputStream();
outputStream
.write(CommunicationMode.ProtobufClientServerProtocol.getModeNumber());
assertEquals(-1, socket.getInputStream().read());
}
{code}
This can be traced to a call to {{
ServerHandShakeProcessor.refuse(socket.getOutputStream(), ...}}.
> Protobuf clients are rejected with an old-client-specific message.
> --
>
> Key: GEODE-3555
> URL: https://issues.apache.org/jira/browse/GEODE-3555
> Project: Geode
> Issue Type: Bug
> Components: messaging
>Reporter: Galen O'Sullivan
> Fix For: 1.3.0
>
>
> If the number of client connections is above the configured maximum, new
> client connections will be rejected with a message that is meant for old
> clients and, to them, is unintelligible.
> This can be seen with the following test added to
> {{RoundTripCacheConnectionJUnitTest}}:
> {code}
> @Test
> public void testNewProtocolRespectsMaxConnectionLimit()
> throws IOException, InterruptedException {
> cache.close();
> CacheFactory cacheFactory = new CacheFactory();
> Cache cache = cacheFactory.create();
> CacheServer cacheServer = cache.addCacheServer();
> final int cacheServerPort =
> AvailablePortHelper.getRandomAvailableTCPPort();
> cacheServer.setPort(cacheServerPort);
> cacheServer.setMaxConnections(16);
> cacheServer.setMaxThreads(16);
> cacheServer.start();
> AcceptorImpl acceptor = ((CacheServerImpl) cacheServer).getAcceptor();
>
[jira] [Created] (GEODE-3555) Protobuf clients are rejected with an old-client-specific message.
Galen O'Sullivan created GEODE-3555:
---
Summary: Protobuf clients are rejected with an old-client-specific
message.
Key: GEODE-3555
URL: https://issues.apache.org/jira/browse/GEODE-3555
Project: Geode
Issue Type: Bug
Components: messaging
Reporter: Galen O'Sullivan
Fix For: 1.3.0
If the number of client connections is above the configured maximum, new client
connections will be rejected with a message that is meant for old clients and,
to them, is unintelligible.
This can be seen with the following test added to
{{RoundTripCacheConnectionJUnitTest}}:
{code}
@Test
public void testNewProtocolRespectsMaxConnectionLimit()
throws IOException, InterruptedException {
cache.close();
CacheFactory cacheFactory = new CacheFactory();
Cache cache = cacheFactory.create();
CacheServer cacheServer = cache.addCacheServer();
final int cacheServerPort = AvailablePortHelper.getRandomAvailableTCPPort();
cacheServer.setPort(cacheServerPort);
cacheServer.setMaxConnections(16);
cacheServer.setMaxThreads(16);
cacheServer.start();
AcceptorImpl acceptor = ((CacheServerImpl) cacheServer).getAcceptor();
Socket[] sockets = new Socket[16];
for (int i = 0; i < 16; i++) {
Socket socket = new Socket("localhost", cacheServerPort);
sockets[i] = socket;
Awaitility.await().atMost(5, TimeUnit.SECONDS).until(socket::isConnected);
socket.getOutputStream().write(CommunicationMode.ProtobufClientServerProtocol.getModeNumber());
}
try (Socket socket = new Socket("localhost", cacheServerPort)) {
Awaitility.await().atMost(5,
TimeUnit.SECONDS).until(socket::isConnected);
OutputStream outputStream = socket.getOutputStream();
outputStream
.write(CommunicationMode.ProtobufClientServerProtocol.getModeNumber());
assertEquals(-1, socket.getInputStream().read());
}
{code}
This can be traced to a call to {{
ServerHandShakeProcessor.refuse(socket.getOutputStream(), ...}}.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (GEODE-3550) Improve snapshot filter test
[ https://issues.apache.org/jira/browse/GEODE-3550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nick Reich resolved GEODE-3550. --- Resolution: Fixed Fix Version/s: 1.3.0 > Improve snapshot filter test > > > Key: GEODE-3550 > URL: https://issues.apache.org/jira/browse/GEODE-3550 > Project: Geode > Issue Type: Improvement > Components: snapshot >Reporter: Nick Reich >Assignee: Nick Reich > Fix For: 1.3.0 > > > The current test does not explicitly check that data matching a filter is > kept, only that no data is retained when run through two non-overlapping > filters. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (GEODE-3550) Improve snapshot filter test
[ https://issues.apache.org/jira/browse/GEODE-3550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16151115#comment-16151115 ] ASF subversion and git services commented on GEODE-3550: Commit d98a70108d7b008946d41b1ac5df5d52ee77236e in geode's branch refs/heads/develop from [~nreich] [ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=d98a701 ] GEODE-3550: Improve snapshot filter testing This closes #754 > Improve snapshot filter test > > > Key: GEODE-3550 > URL: https://issues.apache.org/jira/browse/GEODE-3550 > Project: Geode > Issue Type: Improvement > Components: snapshot >Reporter: Nick Reich >Assignee: Nick Reich > > The current test does not explicitly check that data matching a filter is > kept, only that no data is retained when run through two non-overlapping > filters. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (GEODE-3554) Fix startup freeze at callback to CacheFactory.getAnyInstance()
Fred Krone created GEODE-3554: - Summary: Fix startup freeze at callback to CacheFactory.getAnyInstance() Key: GEODE-3554 URL: https://issues.apache.org/jira/browse/GEODE-3554 Project: Geode Issue Type: Improvement Components: core Reporter: Fred Krone As long as the product continues to invoke user plug-in callbacks during startup (and with the main thread), we probably need to document a warning not to use CacheFactory.getAnyInstance() as the API call is common in plug-ins and this will freeze startup. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (GEODE-3553) CustomEntryConcurrentHashMap @since tag has the wrong value
[ https://issues.apache.org/jira/browse/GEODE-3553?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirk Lund reassigned GEODE-3553: Assignee: Kirk Lund > CustomEntryConcurrentHashMap @since tag has the wrong value > --- > > Key: GEODE-3553 > URL: https://issues.apache.org/jira/browse/GEODE-3553 > Project: Geode > Issue Type: Bug > Components: core >Reporter: Kirk Lund >Assignee: Kirk Lund > > The `@since` tag on CustomEntryConcurrentHashMap says GemFire 1.5 but this is > actually a class that was originally copied from the JSR 166 backport and > altered. The original `@since` tag was and should be Java 1.5. > All other attribution on this class, including the original license, is > accurate and complete. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (GEODE-3553) CustomEntryConcurrentHashMap @since tag has the wrong value
[ https://issues.apache.org/jira/browse/GEODE-3553?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirk Lund updated GEODE-3553: - Description: The `@since` tag on CustomEntryConcurrentHashMap says GemFire 1.5 but this is actually a class that was originally copied from the JSR 166 backport and altered. The original `@since` tag was and should be Java 1.5. All other attribution on this class, including the original license, is accurate and complete. was:The `@since` tag on CustomEntryConcurrentHashMap says GemFire 1.5 but this is actually a class that was originally copied from the JSR 166 backport and altered. The original `@since` tag was and should be Java 1.5. > CustomEntryConcurrentHashMap @since tag has the wrong value > --- > > Key: GEODE-3553 > URL: https://issues.apache.org/jira/browse/GEODE-3553 > Project: Geode > Issue Type: Bug > Components: core >Reporter: Kirk Lund > > The `@since` tag on CustomEntryConcurrentHashMap says GemFire 1.5 but this is > actually a class that was originally copied from the JSR 166 backport and > altered. The original `@since` tag was and should be Java 1.5. > All other attribution on this class, including the original license, is > accurate and complete. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (GEODE-3553) CustomEntryConcurrentHashMap @since tag has the wrong value
[
https://issues.apache.org/jira/browse/GEODE-3553?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirk Lund updated GEODE-3553:
-
Description: The `@since` tag on CustomEntryConcurrentHashMap says GemFire
1.5 but this is actually a class that was copied from JDK and altered. The
original `@since` tag was and should be Java 1.5. (was: The {code}@since{code}
tag on CustomEntryConcurrentHashMap says GemFire 1.5 but this is actually a
class that was copied from JDK and altered. The original {code}@since{code} tag
was and should be Java 1.5.)
> CustomEntryConcurrentHashMap @since tag has the wrong value
> ---
>
> Key: GEODE-3553
> URL: https://issues.apache.org/jira/browse/GEODE-3553
> Project: Geode
> Issue Type: Bug
> Components: core
>Reporter: Kirk Lund
>
> The `@since` tag on CustomEntryConcurrentHashMap says GemFire 1.5 but this is
> actually a class that was copied from JDK and altered. The original `@since`
> tag was and should be Java 1.5.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (GEODE-3553) CustomEntryConcurrentHashMap @since tag has the wrong value
Kirk Lund created GEODE-3553:
Summary: CustomEntryConcurrentHashMap @since tag has the wrong
value
Key: GEODE-3553
URL: https://issues.apache.org/jira/browse/GEODE-3553
Project: Geode
Issue Type: Bug
Components: core
Reporter: Kirk Lund
The {code}@since{code} tag on CustomEntryConcurrentHashMap says GemFire 1.5 but
this is actually a class that was copied from JDK and altered. The original
{code}@since{code} tag was and should be Java 1.5.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Assigned] (GEODE-3552) Cleanup org.apache.geode.management tests
[ https://issues.apache.org/jira/browse/GEODE-3552?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirk Lund reassigned GEODE-3552: Assignee: Kirk Lund > Cleanup org.apache.geode.management tests > - > > Key: GEODE-3552 > URL: https://issues.apache.org/jira/browse/GEODE-3552 > Project: Geode > Issue Type: Wish > Components: tests >Reporter: Kirk Lund >Assignee: Kirk Lund > > The tests under geode-core/src/test/java/org/apache/geode/management are > misnamed and combine a weird mix of unit/integration/distributed tests. Some > are missing assertions and are just a mess. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (GEODE-3552) Cleanup org.apache.geode.management tests
Kirk Lund created GEODE-3552: Summary: Cleanup org.apache.geode.management tests Key: GEODE-3552 URL: https://issues.apache.org/jira/browse/GEODE-3552 Project: Geode Issue Type: Wish Components: tests Reporter: Kirk Lund The tests under geode-core/src/test/java/org/apache/geode/management are misnamed and combine a weird mix of unit/integration/distributed tests. Some are missing assertions and are just a mess. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (GEODE-3059) LoadMonitor.connectionClosed incrementing statistics only for client-server connection
[
https://issues.apache.org/jira/browse/GEODE-3059?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruce Schuchardt resolved GEODE-3059.
-
Resolution: Fixed
Fix Version/s: 1.3.0
> LoadMonitor.connectionClosed incrementing statistics only for client-server
> connection
> --
>
> Key: GEODE-3059
> URL: https://issues.apache.org/jira/browse/GEODE-3059
> Project: Geode
> Issue Type: Bug
> Components: client/server
>Reporter: Galen O'Sullivan
> Fix For: 1.3.0
>
>
> The logic in {{LoadMonitor.connectionClosed}} looks wrong, or at least is
> quite counterintuitive. The connection count is decremented only if this is a
> client-server connection, which looks wrong, and the client count should be
> only if it's a client-to-server connection.
> We need to look at Gateway connections as well, and for the new client-server
> protocol.
> {code}
> public void connectionClosed(boolean lastConnection, byte
> communicationMode) {
> if (communicationMode == Acceptor.CLIENT_TO_SERVER) {
> metrics.decConnectionCount();
> }
> if (lastConnection) {
> metrics.decClientCount();
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (GEODE-3059) LoadMonitor.connectionClosed incrementing statistics only for client-server connection
[
https://issues.apache.org/jira/browse/GEODE-3059?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16151036#comment-16151036
]
ASF subversion and git services commented on GEODE-3059:
Commit fecec42fb57630a669b653ccb54a97b42948d219 in geode's branch
refs/heads/develop from [~bschuchardt]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=fecec42 ]
GEODE-3059: LoadMonitor.connectionClosed incrementing statistics only for
client-server connection
The stat should only be incremented/decremented for certain kinds of
connections. I've modified it to include protobuf connections. All
of the constant byte identifiers in Acceptor.java have been moved to
an enum in CommunicationMode.java. In that class I've added some
"isa" checks to replace the many big "if" checks for different kinds
of connection modes.
A new connection modes will henceforth need to be added to
CommunicationMode.java where the appropriate "isa" methods can be
updated to include the new mode.
> LoadMonitor.connectionClosed incrementing statistics only for client-server
> connection
> --
>
> Key: GEODE-3059
> URL: https://issues.apache.org/jira/browse/GEODE-3059
> Project: Geode
> Issue Type: Bug
> Components: client/server
>Reporter: Galen O'Sullivan
>
> The logic in {{LoadMonitor.connectionClosed}} looks wrong, or at least is
> quite counterintuitive. The connection count is decremented only if this is a
> client-server connection, which looks wrong, and the client count should be
> only if it's a client-to-server connection.
> We need to look at Gateway connections as well, and for the new client-server
> protocol.
> {code}
> public void connectionClosed(boolean lastConnection, byte
> communicationMode) {
> if (communicationMode == Acceptor.CLIENT_TO_SERVER) {
> metrics.decConnectionCount();
> }
> if (lastConnection) {
> metrics.decClientCount();
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (GEODE-3283) Add gfsh option on export/import to parallelize a snapshot for PRs
[
https://issues.apache.org/jira/browse/GEODE-3283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16151025#comment-16151025
]
ASF GitHub Bot commented on GEODE-3283:
---
Github user agingade commented on a diff in the pull request:
https://github.com/apache/geode/pull/753#discussion_r136644610
--- Diff:
geode-core/src/main/java/org/apache/geode/management/internal/cli/functions/ImportDataFunction.java
---
@@ -40,9 +40,13 @@ public void execute(FunctionContext context) {
final Object[] args = (Object[]) context.getArguments();
final String regionName = (String) args[0];
final String importFileName = (String) args[1];
-boolean invokeCallbacks = false;
+boolean parallel = false;
if (args.length > 2) {
--- End diff --
agingade just now Contributor
Don't we need to check for the total args size? which is always 4. What if
an old gfsh client connected to newer server executes this function (which is
not supported...yet one could do it)...in that case, won't invoke callbacks
value get set to parallel?
> Add gfsh option on export/import to parallelize a snapshot for PRs
> --
>
> Key: GEODE-3283
> URL: https://issues.apache.org/jira/browse/GEODE-3283
> Project: Geode
> Issue Type: Sub-task
> Components: snapshot
>Reporter: Fred Krone
>Assignee: Nick Reich
>
> This is related to another ticket to improve snapshot export time
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (GEODE-3283) Add gfsh option on export/import to parallelize a snapshot for PRs
[
https://issues.apache.org/jira/browse/GEODE-3283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16151023#comment-16151023
]
ASF GitHub Bot commented on GEODE-3283:
---
Github user agingade commented on a diff in the pull request:
https://github.com/apache/geode/pull/753#discussion_r136644394
--- Diff:
geode-core/src/main/java/org/apache/geode/management/internal/cli/functions/ImportDataFunction.java
---
@@ -40,9 +40,13 @@ public void execute(FunctionContext context) {
final Object[] args = (Object[]) context.getArguments();
final String regionName = (String) args[0];
final String importFileName = (String) args[1];
-boolean invokeCallbacks = false;
+boolean parallel = false;
if (args.length > 2) {
--- End diff --
Don't we need to check for the total args size? which is always 4. What if
an old gfsh client connected to newer server executes this function (which is
not supported...yet one could do it)...in that case, won't invoke callbacks
value get set to parallel?
> Add gfsh option on export/import to parallelize a snapshot for PRs
> --
>
> Key: GEODE-3283
> URL: https://issues.apache.org/jira/browse/GEODE-3283
> Project: Geode
> Issue Type: Sub-task
> Components: snapshot
>Reporter: Fred Krone
>Assignee: Nick Reich
>
> This is related to another ticket to improve snapshot export time
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (GEODE-3283) Add gfsh option on export/import to parallelize a snapshot for PRs
[ https://issues.apache.org/jira/browse/GEODE-3283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16151015#comment-16151015 ] ASF GitHub Bot commented on GEODE-3283: --- Github user nreich commented on a diff in the pull request: https://github.com/apache/geode/pull/753#discussion_r136643154 --- Diff: geode-core/src/main/java/org/apache/geode/internal/cache/snapshot/RegionSnapshotServiceImpl.java --- @@ -342,6 +342,7 @@ private void exportOnMember(File snapshot, SnapshotFormat format, SnapshotOption long count = 0; long start = CachePerfStats.getStatTime(); +snapshot.getParentFile().mkdirs(); --- End diff -- You are correct: if only a relative route to a specific file is provided (which would be an error condition in this case), getParentFile() will return null. I can handle that case more gracefully. > Add gfsh option on export/import to parallelize a snapshot for PRs > -- > > Key: GEODE-3283 > URL: https://issues.apache.org/jira/browse/GEODE-3283 > Project: Geode > Issue Type: Sub-task > Components: snapshot >Reporter: Fred Krone >Assignee: Nick Reich > > This is related to another ticket to improve snapshot export time -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (GEODE-3283) Add gfsh option on export/import to parallelize a snapshot for PRs
[
https://issues.apache.org/jira/browse/GEODE-3283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16151013#comment-16151013
]
ASF GitHub Bot commented on GEODE-3283:
---
Github user nreich commented on a diff in the pull request:
https://github.com/apache/geode/pull/753#discussion_r136642718
--- Diff:
geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/ImportDataIntegrationTest.java
---
@@ -0,0 +1,158 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
contributor license
+ * agreements. See the NOTICE file distributed with this work for
additional information regarding
+ * copyright ownership. The ASF licenses this file to You under the Apache
License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance with the
License. You may obtain a
+ * copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
distributed under the License
+ * is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF
ANY KIND, either express
+ * or implied. See the License for the specific language governing
permissions and limitations under
+ * the License.
+ *
+ */
+
+package org.apache.geode.management.internal.cli.commands;
+
+import static org.assertj.core.api.Assertions.assertThat;
+import static org.junit.Assert.assertEquals;
+
+import java.util.stream.IntStream;
+
+import org.junit.Test;
+import org.junit.experimental.categories.Category;
+
+import org.apache.geode.management.internal.cli.i18n.CliStrings;
+import org.apache.geode.management.internal.cli.util.CommandStringBuilder;
+import org.apache.geode.test.junit.categories.IntegrationTest;
+
+@Category(IntegrationTest.class)
+public class ImportDataIntegrationTest extends SnapshotDataIntegrationTest
{
--- End diff --
I tried to include only pretty generic code to share between the two tests,
though (as with any code) it is always possible that they could diverge in the
future, making the abstract class less / no longer valuable. I am not opposed
to duplicating the shared code in each location instead if there is a stronger
preference towards ease of test extension / modification over DRYness.
> Add gfsh option on export/import to parallelize a snapshot for PRs
> --
>
> Key: GEODE-3283
> URL: https://issues.apache.org/jira/browse/GEODE-3283
> Project: Geode
> Issue Type: Sub-task
> Components: snapshot
>Reporter: Fred Krone
>Assignee: Nick Reich
>
> This is related to another ticket to improve snapshot export time
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (GEODE-3547) Simplify behavior for non-writable deploy directory
[ https://issues.apache.org/jira/browse/GEODE-3547?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jared Stewart resolved GEODE-3547. -- Resolution: Fixed > Simplify behavior for non-writable deploy directory > --- > > Key: GEODE-3547 > URL: https://issues.apache.org/jira/browse/GEODE-3547 > Project: Geode > Issue Type: Improvement > Components: management >Reporter: Jared Stewart >Assignee: Jared Stewart > Fix For: 1.3.0 > > > The JarDeployer that writes user-deployed jar files to disk has some > needlessly complex retry logic for when the specified deploy directory is not > writable, that involves waiting up to 200 seconds for permissions to write to > that directory to appear. It would be much simpler to fail immediately when > we don't have security permissions to write to the deploy directory. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (GEODE-3283) Add gfsh option on export/import to parallelize a snapshot for PRs
[
https://issues.apache.org/jira/browse/GEODE-3283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16151005#comment-16151005
]
ASF GitHub Bot commented on GEODE-3283:
---
Github user nreich commented on a diff in the pull request:
https://github.com/apache/geode/pull/753#discussion_r136641632
--- Diff:
geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/ExportDataCommand.java
---
@@ -87,4 +80,45 @@ public Result exportData(
}
return result;
}
+
+ private Result getFunctionResult(ResultCollector rc) {
+Result result;
+List results = (List) rc.getResult();
+if (results != null) {
+ Object resultObj = results.get(0);
+ if (resultObj instanceof String) {
+result = ResultBuilder.createInfoResult((String) resultObj);
+ } else if (resultObj instanceof Exception) {
+result = ResultBuilder.createGemFireErrorResult(((Exception)
resultObj).getMessage());
+ } else {
+result = ResultBuilder.createGemFireErrorResult(
+CliStrings.format(CliStrings.COMMAND_FAILURE_MESSAGE,
CliStrings.EXPORT_DATA));
+ }
+} else {
+ result = ResultBuilder.createGemFireErrorResult(
+ CliStrings.format(CliStrings.COMMAND_FAILURE_MESSAGE,
CliStrings.EXPORT_DATA));
+}
+return result;
+ }
+
+ private String defaultFileName(String dirPath, String regionName) {
+return new File(dirPath, regionName +
RegionSnapshotService.SNAPSHOT_FILE_EXTENSION)
+.getAbsolutePath();
+ }
+
+ private Optional validatePath(String filePath, String dirPath,
boolean parallel) {
--- End diff --
I thought about having them both extend the same abstract base class: that
would remove the duplicate code. The method is not dependant on state of the
object, so it could be extracted into a static helper method (suggestions on
where would be best to put it if this route is desirable?).
> Add gfsh option on export/import to parallelize a snapshot for PRs
> --
>
> Key: GEODE-3283
> URL: https://issues.apache.org/jira/browse/GEODE-3283
> Project: Geode
> Issue Type: Sub-task
> Components: snapshot
>Reporter: Fred Krone
>Assignee: Nick Reich
>
> This is related to another ticket to improve snapshot export time
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (GEODE-3547) Simplify behavior for non-writable deploy directory
[ https://issues.apache.org/jira/browse/GEODE-3547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16151003#comment-16151003 ] ASF subversion and git services commented on GEODE-3547: Commit 836451a5acd939d54b1d45ad8701fac7ec54ac53 in geode's branch refs/heads/develop from [~jstewart] [ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=836451a ] GEODE-3547: Simplify behavior for non-writable deploy directory - Also fixes the flaky JarDeployerIntegrationTest > Simplify behavior for non-writable deploy directory > --- > > Key: GEODE-3547 > URL: https://issues.apache.org/jira/browse/GEODE-3547 > Project: Geode > Issue Type: Improvement > Components: management >Reporter: Jared Stewart >Assignee: Jared Stewart > Fix For: 1.3.0 > > > The JarDeployer that writes user-deployed jar files to disk has some > needlessly complex retry logic for when the specified deploy directory is not > writable, that involves waiting up to 200 seconds for permissions to write to > that directory to appear. It would be much simpler to fail immediately when > we don't have security permissions to write to the deploy directory. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (GEODE-3283) Add gfsh option on export/import to parallelize a snapshot for PRs
[ https://issues.apache.org/jira/browse/GEODE-3283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16150993#comment-16150993 ] ASF GitHub Bot commented on GEODE-3283: --- Github user agingade commented on a diff in the pull request: https://github.com/apache/geode/pull/753#discussion_r136640863 --- Diff: geode-core/src/main/java/org/apache/geode/internal/cache/snapshot/RegionSnapshotServiceImpl.java --- @@ -342,6 +342,7 @@ private void exportOnMember(File snapshot, SnapshotFormat format, SnapshotOption long count = 0; long start = CachePerfStats.getStatTime(); +snapshot.getParentFile().mkdirs(); --- End diff -- Can getParentFile() return null...How about handling failure during mkdirs()... > Add gfsh option on export/import to parallelize a snapshot for PRs > -- > > Key: GEODE-3283 > URL: https://issues.apache.org/jira/browse/GEODE-3283 > Project: Geode > Issue Type: Sub-task > Components: snapshot >Reporter: Fred Krone >Assignee: Nick Reich > > This is related to another ticket to improve snapshot export time -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (GEODE-3539) Add more test coverage for p2p commands
[ https://issues.apache.org/jira/browse/GEODE-3539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16150989#comment-16150989 ] ASF subversion and git services commented on GEODE-3539: Commit dedfd8ec3fbc140917de876f0345be7e9ddab65f in geode's branch refs/heads/develop from [~jstewart] [ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=dedfd8e ] GEODE-3539: Add tests for List Members and Describe Member > Add more test coverage for p2p commands > --- > > Key: GEODE-3539 > URL: https://issues.apache.org/jira/browse/GEODE-3539 > Project: Geode > Issue Type: Improvement > Components: gfsh >Reporter: Jinmei Liao > > Add more command tests that would eventually get rid of the legacy tests. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (GEODE-3283) Add gfsh option on export/import to parallelize a snapshot for PRs
[
https://issues.apache.org/jira/browse/GEODE-3283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16150981#comment-16150981
]
ASF GitHub Bot commented on GEODE-3283:
---
Github user jinmeiliao commented on a diff in the pull request:
https://github.com/apache/geode/pull/753#discussion_r136638437
--- Diff:
geode-core/src/main/java/org/apache/geode/management/internal/cli/functions/ImportDataFunction.java
---
@@ -40,9 +40,13 @@ public void execute(FunctionContext context) {
final Object[] args = (Object[]) context.getArguments();
final String regionName = (String) args[0];
final String importFileName = (String) args[1];
-boolean invokeCallbacks = false;
+boolean parallel = false;
if (args.length > 2) {
--- End diff --
is the args length check necessary? would caller present different args at
different times?
> Add gfsh option on export/import to parallelize a snapshot for PRs
> --
>
> Key: GEODE-3283
> URL: https://issues.apache.org/jira/browse/GEODE-3283
> Project: Geode
> Issue Type: Sub-task
> Components: snapshot
>Reporter: Fred Krone
>Assignee: Nick Reich
>
> This is related to another ticket to improve snapshot export time
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (GEODE-3283) Add gfsh option on export/import to parallelize a snapshot for PRs
[ https://issues.apache.org/jira/browse/GEODE-3283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16150978#comment-16150978 ] ASF GitHub Bot commented on GEODE-3283: --- Github user jinmeiliao commented on a diff in the pull request: https://github.com/apache/geode/pull/753#discussion_r136637196 --- Diff: geode-core/src/main/java/org/apache/geode/management/internal/cli/i18n/CliStrings.java --- @@ -1351,6 +1351,12 @@ "File to which the exported data will be written. The file must have an extension of \".gfd\"."; public static final String EXPORT_DATA__MEMBER__HELP = "Name/Id of a member which hosts the region. The data will be exported to the specified file on the host where the member is running."; + public static final String EXPORT_DATA__DIR = "directory"; --- End diff -- I think most commands will use "dir" instead of "directory" > Add gfsh option on export/import to parallelize a snapshot for PRs > -- > > Key: GEODE-3283 > URL: https://issues.apache.org/jira/browse/GEODE-3283 > Project: Geode > Issue Type: Sub-task > Components: snapshot >Reporter: Fred Krone >Assignee: Nick Reich > > This is related to another ticket to improve snapshot export time -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (GEODE-3283) Add gfsh option on export/import to parallelize a snapshot for PRs
[
https://issues.apache.org/jira/browse/GEODE-3283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16150979#comment-16150979
]
ASF GitHub Bot commented on GEODE-3283:
---
Github user jinmeiliao commented on a diff in the pull request:
https://github.com/apache/geode/pull/753#discussion_r136638047
--- Diff:
geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/ExportDataCommand.java
---
@@ -41,44 +44,34 @@ public Result exportData(
@CliOption(key = CliStrings.EXPORT_DATA__REGION, mandatory = true,
optionContext = ConverterHint.REGION_PATH,
help = CliStrings.EXPORT_DATA__REGION__HELP) String regionName,
- @CliOption(key = CliStrings.EXPORT_DATA__FILE, mandatory = true,
+ @CliOption(key = CliStrings.EXPORT_DATA__FILE,
help = CliStrings.EXPORT_DATA__FILE__HELP) String filePath,
+ @CliOption(key = CliStrings.EXPORT_DATA__DIR,
+ help = CliStrings.EXPORT_DATA__DIR__HELP) String dirPath,
@CliOption(key = CliStrings.MEMBER, optionContext =
ConverterHint.MEMBERIDNAME,
- mandatory = true, help = CliStrings.EXPORT_DATA__MEMBER__HELP)
String memberNameOrId) {
+ mandatory = true, help = CliStrings.EXPORT_DATA__MEMBER__HELP)
String memberNameOrId,
+ @CliOption(key = CliStrings.EXPORT_DATA__PARALLEL,
unspecifiedDefaultValue = "false",
--- End diff --
also, since there is a unspecified default value (false), is it really
necessary to make it a mandatory option if "dir" is specified? can we just make
it default to false(or true, whatever sensible) if user didn't add --parallel,
but specified --dir?
> Add gfsh option on export/import to parallelize a snapshot for PRs
> --
>
> Key: GEODE-3283
> URL: https://issues.apache.org/jira/browse/GEODE-3283
> Project: Geode
> Issue Type: Sub-task
> Components: snapshot
>Reporter: Fred Krone
>Assignee: Nick Reich
>
> This is related to another ticket to improve snapshot export time
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (GEODE-3283) Add gfsh option on export/import to parallelize a snapshot for PRs
[
https://issues.apache.org/jira/browse/GEODE-3283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16150980#comment-16150980
]
ASF GitHub Bot commented on GEODE-3283:
---
Github user jinmeiliao commented on a diff in the pull request:
https://github.com/apache/geode/pull/753#discussion_r136639140
--- Diff:
geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/ImportDataIntegrationTest.java
---
@@ -0,0 +1,158 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
contributor license
+ * agreements. See the NOTICE file distributed with this work for
additional information regarding
+ * copyright ownership. The ASF licenses this file to You under the Apache
License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance with the
License. You may obtain a
+ * copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
distributed under the License
+ * is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF
ANY KIND, either express
+ * or implied. See the License for the specific language governing
permissions and limitations under
+ * the License.
+ *
+ */
+
+package org.apache.geode.management.internal.cli.commands;
+
+import static org.assertj.core.api.Assertions.assertThat;
+import static org.junit.Assert.assertEquals;
+
+import java.util.stream.IntStream;
+
+import org.junit.Test;
+import org.junit.experimental.categories.Category;
+
+import org.apache.geode.management.internal.cli.i18n.CliStrings;
+import org.apache.geode.management.internal.cli.util.CommandStringBuilder;
+import org.apache.geode.test.junit.categories.IntegrationTest;
+
+@Category(IntegrationTest.class)
+public class ImportDataIntegrationTest extends SnapshotDataIntegrationTest
{
--- End diff --
In general we would want to discourage usage of abstract test classes and
in favor of rules. If there is minimum set up needed using the rules, we don't
mind a few lines of duplicate code for set up to avoid entangling of the tests.
What if in the future you want to change the setup of one test instead of
another. Extending a common abstract class makes it harder to add on to the
test.
> Add gfsh option on export/import to parallelize a snapshot for PRs
> --
>
> Key: GEODE-3283
> URL: https://issues.apache.org/jira/browse/GEODE-3283
> Project: Geode
> Issue Type: Sub-task
> Components: snapshot
>Reporter: Fred Krone
>Assignee: Nick Reich
>
> This is related to another ticket to improve snapshot export time
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (GEODE-3283) Add gfsh option on export/import to parallelize a snapshot for PRs
[
https://issues.apache.org/jira/browse/GEODE-3283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16150977#comment-16150977
]
ASF GitHub Bot commented on GEODE-3283:
---
Github user jinmeiliao commented on a diff in the pull request:
https://github.com/apache/geode/pull/753#discussion_r136638194
--- Diff:
geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/ExportDataCommand.java
---
@@ -87,4 +80,45 @@ public Result exportData(
}
return result;
}
+
+ private Result getFunctionResult(ResultCollector rc) {
+Result result;
+List results = (List) rc.getResult();
+if (results != null) {
+ Object resultObj = results.get(0);
+ if (resultObj instanceof String) {
+result = ResultBuilder.createInfoResult((String) resultObj);
+ } else if (resultObj instanceof Exception) {
+result = ResultBuilder.createGemFireErrorResult(((Exception)
resultObj).getMessage());
+ } else {
+result = ResultBuilder.createGemFireErrorResult(
+CliStrings.format(CliStrings.COMMAND_FAILURE_MESSAGE,
CliStrings.EXPORT_DATA));
+ }
+} else {
+ result = ResultBuilder.createGemFireErrorResult(
+ CliStrings.format(CliStrings.COMMAND_FAILURE_MESSAGE,
CliStrings.EXPORT_DATA));
+}
+return result;
+ }
+
+ private String defaultFileName(String dirPath, String regionName) {
+return new File(dirPath, regionName +
RegionSnapshotService.SNAPSHOT_FILE_EXTENSION)
+.getAbsolutePath();
+ }
+
+ private Optional validatePath(String filePath, String dirPath,
boolean parallel) {
--- End diff --
this seems to be duplicated between import/export, any way we can use the
same code base?
> Add gfsh option on export/import to parallelize a snapshot for PRs
> --
>
> Key: GEODE-3283
> URL: https://issues.apache.org/jira/browse/GEODE-3283
> Project: Geode
> Issue Type: Sub-task
> Components: snapshot
>Reporter: Fred Krone
>Assignee: Nick Reich
>
> This is related to another ticket to improve snapshot export time
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (GEODE-3283) Add gfsh option on export/import to parallelize a snapshot for PRs
[
https://issues.apache.org/jira/browse/GEODE-3283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16150982#comment-16150982
]
ASF GitHub Bot commented on GEODE-3283:
---
Github user jinmeiliao commented on a diff in the pull request:
https://github.com/apache/geode/pull/753#discussion_r136638633
--- Diff:
geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/ExportDataIntegrationTest.java
---
@@ -0,0 +1,127 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
contributor license
+ * agreements. See the NOTICE file distributed with this work for
additional information regarding
+ * copyright ownership. The ASF licenses this file to You under the Apache
License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance with the
License. You may obtain a
+ * copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
distributed under the License
+ * is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF
ANY KIND, either express
+ * or implied. See the License for the specific language governing
permissions and limitations under
+ * the License.
+ *
+ */
+
+package org.apache.geode.management.internal.cli.commands;
+
+import static org.assertj.core.api.Assertions.assertThat;
+import static org.junit.Assert.assertFalse;
+import static org.junit.Assert.assertTrue;
+
+import java.nio.file.Files;
+
+import org.junit.Test;
+import org.junit.experimental.categories.Category;
+
+import org.apache.geode.management.internal.cli.i18n.CliStrings;
+import org.apache.geode.management.internal.cli.util.CommandStringBuilder;
+import org.apache.geode.test.junit.categories.IntegrationTest;
+
+@Category(IntegrationTest.class)
+public class ExportDataIntegrationTest extends SnapshotDataIntegrationTest
{
+ @Test
+ public void testExport() throws Exception {
+String exportCommand = buildBaseExportCommand()
+.addOption(CliStrings.EXPORT_DATA__FILE,
getSnapshotFile().toString()).getCommandString();
+gfsh.executeCommand(exportCommand);
--- End diff --
recommend using executeCommandAndVerify
> Add gfsh option on export/import to parallelize a snapshot for PRs
> --
>
> Key: GEODE-3283
> URL: https://issues.apache.org/jira/browse/GEODE-3283
> Project: Geode
> Issue Type: Sub-task
> Components: snapshot
>Reporter: Fred Krone
>Assignee: Nick Reich
>
> This is related to another ticket to improve snapshot export time
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (GEODE-3285) New protocol authentication with SASL
[ https://issues.apache.org/jira/browse/GEODE-3285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Baynes updated GEODE-3285: Issue Type: Wish (was: New Feature) > New protocol authentication with SASL > - > > Key: GEODE-3285 > URL: https://issues.apache.org/jira/browse/GEODE-3285 > Project: Geode > Issue Type: Wish > Components: client/server >Reporter: Brian Baynes > > As a user of the new client/server protocol, I need to be able to > authenticate clients to my grid. Using a standard framework with minimal > upfront setup would be most preferred. > Implement client authentication using SASL (Simple Authentication and > Security Layer) and the PLAIN mechanism. SASL should tie into existing > security manager for processing auth. Protocol clients should be able to > pass user/pass and authenticate the socket in use. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (GEODE-3088) Failed to properly release resources held by the HTTP service: !STOPPED
[ https://issues.apache.org/jira/browse/GEODE-3088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirk Lund updated GEODE-3088: - Fix Version/s: 1.2.0 > Failed to properly release resources held by the HTTP service: !STOPPED > --- > > Key: GEODE-3088 > URL: https://issues.apache.org/jira/browse/GEODE-3088 > Project: Geode > Issue Type: Bug > Components: gfsh, pulse >Affects Versions: 1.1.0, 1.1.1 >Reporter: Zachary Hansen > Fix For: 1.2.0 > > > Failed to properly release resources held by the HTTP service: !STOPPED > java.lang.IllegalStateException: !STOPPED > at > org.eclipse.jetty.server.handler.HandlerWrapper.destroy(HandlerWrapper.java:134) > at > org.apache.geode.management.internal.ManagementAgent.stopHttpService(ManagementAgent.java:339) > at > org.apache.geode.management.internal.ManagementAgent.stopAgent(ManagementAgent.java:157) > at > org.apache.geode.management.internal.SystemManagementService.close(SystemManagementService.java:265) > at > org.apache.geode.management.internal.beans.ManagementAdapter.handleCacheRemoval(ManagementAdapter.java:735) > at > org.apache.geode.management.internal.beans.ManagementListener.handleEvent(ManagementListener.java:117) > at > org.apache.geode.distributed.internal.InternalDistributedSystem.notifyResourceEventListeners(InternalDistributedSystem.java:2162) > at > org.apache.geode.distributed.internal.InternalDistributedSystem.handleResourceEvent(InternalDistributedSystem.java:535) > at > org.apache.geode.internal.cache.GemFireCacheImpl.close(GemFireCacheImpl.java:2145) > at > org.apache.geode.distributed.internal.InternalDistributedSystem.disconnect(InternalDistributedSystem.java:1323) > at > org.apache.geode.distributed.internal.InternalDistributedSystem.disconnect(InternalDistributedSystem.java:973) > at > org.apache.geode.management.internal.cli.functions.ShutDownFunction.lambda$disconnectInNonDaemonThread$0(ShutDownFunction.java:72) > at > org.apache.geode.management.internal.cli.functions.ShutDownFunction$$Lambda$32/939474416.run(Unknown > Source) > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > Getting this error when running embedded pulse on GemFire 9.0.4. When pulse > is accessed via browser and left running, this error occurs when issuing a > shutdown command via gfsh. Locator hangs and does not gracefully shutdown. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (GEODE-3088) Failed to properly release resources held by the HTTP service: !STOPPED
[ https://issues.apache.org/jira/browse/GEODE-3088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirk Lund resolved GEODE-3088. -- Resolution: Fixed > Failed to properly release resources held by the HTTP service: !STOPPED > --- > > Key: GEODE-3088 > URL: https://issues.apache.org/jira/browse/GEODE-3088 > Project: Geode > Issue Type: Bug > Components: gfsh, pulse >Affects Versions: 1.1.0, 1.1.1 >Reporter: Zachary Hansen > Fix For: 1.2.0 > > > Failed to properly release resources held by the HTTP service: !STOPPED > java.lang.IllegalStateException: !STOPPED > at > org.eclipse.jetty.server.handler.HandlerWrapper.destroy(HandlerWrapper.java:134) > at > org.apache.geode.management.internal.ManagementAgent.stopHttpService(ManagementAgent.java:339) > at > org.apache.geode.management.internal.ManagementAgent.stopAgent(ManagementAgent.java:157) > at > org.apache.geode.management.internal.SystemManagementService.close(SystemManagementService.java:265) > at > org.apache.geode.management.internal.beans.ManagementAdapter.handleCacheRemoval(ManagementAdapter.java:735) > at > org.apache.geode.management.internal.beans.ManagementListener.handleEvent(ManagementListener.java:117) > at > org.apache.geode.distributed.internal.InternalDistributedSystem.notifyResourceEventListeners(InternalDistributedSystem.java:2162) > at > org.apache.geode.distributed.internal.InternalDistributedSystem.handleResourceEvent(InternalDistributedSystem.java:535) > at > org.apache.geode.internal.cache.GemFireCacheImpl.close(GemFireCacheImpl.java:2145) > at > org.apache.geode.distributed.internal.InternalDistributedSystem.disconnect(InternalDistributedSystem.java:1323) > at > org.apache.geode.distributed.internal.InternalDistributedSystem.disconnect(InternalDistributedSystem.java:973) > at > org.apache.geode.management.internal.cli.functions.ShutDownFunction.lambda$disconnectInNonDaemonThread$0(ShutDownFunction.java:72) > at > org.apache.geode.management.internal.cli.functions.ShutDownFunction$$Lambda$32/939474416.run(Unknown > Source) > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > Getting this error when running embedded pulse on GemFire 9.0.4. When pulse > is accessed via browser and left running, this error occurs when issuing a > shutdown command via gfsh. Locator hangs and does not gracefully shutdown. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (GEODE-3088) Failed to properly release resources held by the HTTP service: !STOPPED
[ https://issues.apache.org/jira/browse/GEODE-3088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirk Lund updated GEODE-3088: - Affects Version/s: (was: 1.2.0) 1.1.0 1.1.1 > Failed to properly release resources held by the HTTP service: !STOPPED > --- > > Key: GEODE-3088 > URL: https://issues.apache.org/jira/browse/GEODE-3088 > Project: Geode > Issue Type: Bug > Components: gfsh, pulse >Affects Versions: 1.1.0, 1.1.1 >Reporter: Zachary Hansen > Fix For: 1.2.0 > > > Failed to properly release resources held by the HTTP service: !STOPPED > java.lang.IllegalStateException: !STOPPED > at > org.eclipse.jetty.server.handler.HandlerWrapper.destroy(HandlerWrapper.java:134) > at > org.apache.geode.management.internal.ManagementAgent.stopHttpService(ManagementAgent.java:339) > at > org.apache.geode.management.internal.ManagementAgent.stopAgent(ManagementAgent.java:157) > at > org.apache.geode.management.internal.SystemManagementService.close(SystemManagementService.java:265) > at > org.apache.geode.management.internal.beans.ManagementAdapter.handleCacheRemoval(ManagementAdapter.java:735) > at > org.apache.geode.management.internal.beans.ManagementListener.handleEvent(ManagementListener.java:117) > at > org.apache.geode.distributed.internal.InternalDistributedSystem.notifyResourceEventListeners(InternalDistributedSystem.java:2162) > at > org.apache.geode.distributed.internal.InternalDistributedSystem.handleResourceEvent(InternalDistributedSystem.java:535) > at > org.apache.geode.internal.cache.GemFireCacheImpl.close(GemFireCacheImpl.java:2145) > at > org.apache.geode.distributed.internal.InternalDistributedSystem.disconnect(InternalDistributedSystem.java:1323) > at > org.apache.geode.distributed.internal.InternalDistributedSystem.disconnect(InternalDistributedSystem.java:973) > at > org.apache.geode.management.internal.cli.functions.ShutDownFunction.lambda$disconnectInNonDaemonThread$0(ShutDownFunction.java:72) > at > org.apache.geode.management.internal.cli.functions.ShutDownFunction$$Lambda$32/939474416.run(Unknown > Source) > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > Getting this error when running embedded pulse on GemFire 9.0.4. When pulse > is accessed via browser and left running, this error occurs when issuing a > shutdown command via gfsh. Locator hangs and does not gracefully shutdown. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (GEODE-3088) Failed to properly release resources held by the HTTP service: !STOPPED
[ https://issues.apache.org/jira/browse/GEODE-3088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16150903#comment-16150903 ] Kirk Lund commented on GEODE-3088: -- Please note that Geode 1.2.0 is NOT in GemFire 9.0.4. Because this ticket is for Geode, I'm going to close it out as fixed in Geode 1.2.0. > Failed to properly release resources held by the HTTP service: !STOPPED > --- > > Key: GEODE-3088 > URL: https://issues.apache.org/jira/browse/GEODE-3088 > Project: Geode > Issue Type: Bug > Components: gfsh, pulse >Affects Versions: 1.1.0, 1.1.1 >Reporter: Zachary Hansen > Fix For: 1.2.0 > > > Failed to properly release resources held by the HTTP service: !STOPPED > java.lang.IllegalStateException: !STOPPED > at > org.eclipse.jetty.server.handler.HandlerWrapper.destroy(HandlerWrapper.java:134) > at > org.apache.geode.management.internal.ManagementAgent.stopHttpService(ManagementAgent.java:339) > at > org.apache.geode.management.internal.ManagementAgent.stopAgent(ManagementAgent.java:157) > at > org.apache.geode.management.internal.SystemManagementService.close(SystemManagementService.java:265) > at > org.apache.geode.management.internal.beans.ManagementAdapter.handleCacheRemoval(ManagementAdapter.java:735) > at > org.apache.geode.management.internal.beans.ManagementListener.handleEvent(ManagementListener.java:117) > at > org.apache.geode.distributed.internal.InternalDistributedSystem.notifyResourceEventListeners(InternalDistributedSystem.java:2162) > at > org.apache.geode.distributed.internal.InternalDistributedSystem.handleResourceEvent(InternalDistributedSystem.java:535) > at > org.apache.geode.internal.cache.GemFireCacheImpl.close(GemFireCacheImpl.java:2145) > at > org.apache.geode.distributed.internal.InternalDistributedSystem.disconnect(InternalDistributedSystem.java:1323) > at > org.apache.geode.distributed.internal.InternalDistributedSystem.disconnect(InternalDistributedSystem.java:973) > at > org.apache.geode.management.internal.cli.functions.ShutDownFunction.lambda$disconnectInNonDaemonThread$0(ShutDownFunction.java:72) > at > org.apache.geode.management.internal.cli.functions.ShutDownFunction$$Lambda$32/939474416.run(Unknown > Source) > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > Getting this error when running embedded pulse on GemFire 9.0.4. When pulse > is accessed via browser and left running, this error occurs when issuing a > shutdown command via gfsh. Locator hangs and does not gracefully shutdown. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (GEODE-2724) NPE shutting down locator
[
https://issues.apache.org/jira/browse/GEODE-2724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16150896#comment-16150896
]
Kirk Lund commented on GEODE-2724:
--
Here's the commit with the fix:
{noformat}
commit 31b650742d7552d12495bc10f7d7a8a88b78370d
Author: Patrick Rhomberg
Date: Wed Mar 22 13:27:34 2017 -0700
GEODE-1274: Migration from PulseLogWriter to Log4j standard and removal of
associated classes.
* To avoid dependency on geode-core, the pulse loggers are instantiated
directly from LogManager, rather than canonical LogService (which itself
extends LogManager).
* Significant reduction of logging level state checks, relying on Log4j
handling.
* Significant reduction of string concatenation, relying on Log4j2 string
substitutions.
* Reduction of logging using an exception e.getMessage, favoring instead
passing the exception itself for the stacktrace.
* Multiple identical exception blocks collapsed.
* this closes #446
{noformat}
> NPE shutting down locator
> -
>
> Key: GEODE-2724
> URL: https://issues.apache.org/jira/browse/GEODE-2724
> Project: Geode
> Issue Type: Bug
> Components: pulse
>Reporter: Bruce Schuchardt
>Assignee: Jared Stewart
> Fix For: 1.2.0
>
>
> Locator shutdown threw an NPE when stopping a Jetty server in Pulse code:
> {code}
> [warning 2017/03/28 08:56:25.493 IST locator1 tid=0x4a] Failed to
> stop the HTTP service because: null
> java.lang.NullPointerException
> at
> org.apache.geode.tools.pulse.internal.data.Repository.removeAllClusters(Repository.java:225)
> at
> org.apache.geode.tools.pulse.internal.PulseAppListener.contextDestroyed(PulseAppListener.java:84)
> at
> org.eclipse.jetty.server.handler.ContextHandler.callContextDestroyed(ContextHandler.java:843)
> at
> org.eclipse.jetty.servlet.ServletContextHandler.callContextDestroyed(ServletContextHandler.java:543)
> at
> org.eclipse.jetty.server.handler.ContextHandler.stopContext(ContextHandler.java:824)
> at
> org.eclipse.jetty.servlet.ServletContextHandler.stopContext(ServletContextHandler.java:353)
> at
> org.eclipse.jetty.webapp.WebAppContext.stopWebapp(WebAppContext.java:1385)
> at
> org.eclipse.jetty.webapp.WebAppContext.stopContext(WebAppContext.java:1349)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doStop(ContextHandler.java:872)
> at
> org.eclipse.jetty.servlet.ServletContextHandler.doStop(ServletContextHandler.java:269)
> at org.eclipse.jetty.webapp.WebAppContext.doStop(WebAppContext.java:541)
> at
> org.eclipse.jetty.util.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:89)
> at
> org.eclipse.jetty.util.component.ContainerLifeCycle.stop(ContainerLifeCycle.java:143)
> at
> org.eclipse.jetty.util.component.ContainerLifeCycle.doStop(ContainerLifeCycle.java:161)
> at
> org.eclipse.jetty.server.handler.AbstractHandler.doStop(AbstractHandler.java:73)
> at
> org.eclipse.jetty.util.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:89)
> at
> org.eclipse.jetty.util.component.ContainerLifeCycle.stop(ContainerLifeCycle.java:143)
> at
> org.eclipse.jetty.util.component.ContainerLifeCycle.doStop(ContainerLifeCycle.java:161)
> at
> org.eclipse.jetty.server.handler.AbstractHandler.doStop(AbstractHandler.java:73)
> at org.eclipse.jetty.server.Server.doStop(Server.java:476)
> at
> org.eclipse.jetty.util.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:89)
> at
> org.apache.geode.management.internal.ManagementAgent.stopHttpService(ManagementAgent.java:328)
> at
> org.apache.geode.management.internal.ManagementAgent.stopAgent(ManagementAgent.java:156)
> at
> org.apache.geode.management.internal.SystemManagementService.close(SystemManagementService.java:265)
> at
> org.apache.geode.management.internal.beans.ManagementAdapter.handleCacheRemoval(ManagementAdapter.java:735)
> at
> org.apache.geode.management.internal.beans.ManagementListener.handleEvent(ManagementListener.java:117)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.notifyResourceEventListeners(InternalDistributedSystem.java:2146)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.handleResourceEvent(InternalDistributedSystem.java:536)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.close(GemFireCacheImpl.java:2149)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.disconnect(InternalDistributedSystem.java:1314)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.disconnect(InternalDistributedSystem.java:964)
> at
> org.apache.geode.management.internal.beans.MemberMBeanBridge$1.run(MemberMBeanBridge.java:1000)
> at
[jira] [Commented] (GEODE-3191) NPE in pulse prevents locator shutdown
[
https://issues.apache.org/jira/browse/GEODE-3191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16150898#comment-16150898
]
Kirk Lund commented on GEODE-3191:
--
Here's the commit with the fix:
{noformat}
commit 31b650742d7552d12495bc10f7d7a8a88b78370d
Author: Patrick Rhomberg
Date: Wed Mar 22 13:27:34 2017 -0700
GEODE-1274: Migration from PulseLogWriter to Log4j standard and removal of
associated classes.
* To avoid dependency on geode-core, the pulse loggers are instantiated
directly from LogManager, rather than canonical LogService (which itself
extends LogManager).
* Significant reduction of logging level state checks, relying on Log4j
handling.
* Significant reduction of string concatenation, relying on Log4j2 string
substitutions.
* Reduction of logging using an exception e.getMessage, favoring instead
passing the exception itself for the stacktrace.
* Multiple identical exception blocks collapsed.
* this closes #446
{noformat}
> NPE in pulse prevents locator shutdown
> --
>
> Key: GEODE-3191
> URL: https://issues.apache.org/jira/browse/GEODE-3191
> Project: Geode
> Issue Type: Bug
> Components: pulse
>Reporter: Swapnil Bawaskar
> Fix For: 1.2.0
>
>
> We found that when there is an open connection to pulse `gfsh stop locator`
> fails to correctly stop the locator process. In the locator logs we see:
> {noformat}
> [warning 2017/07/11 21:13:44.713 UTC
> locator-ced56c23-6523-413c-9b24-dadf10683b89 10.0.8.7> tid=0xe] Failed to stop the HTTP service because: null
> java.lang.NullPointerException
> at
> org.apache.geode.tools.pulse.internal.data.Repository.removeAllClusters(Repository.java:226)
> at
> org.apache.geode.tools.pulse.internal.PulseAppListener.contextDestroyed(PulseAppListener.java:83)
> at
> org.eclipse.jetty.server.handler.ContextHandler.callContextDestroyed(ContextHandler.java:843)
> at
> org.eclipse.jetty.servlet.ServletContextHandler.callContextDestroyed(ServletContextHandler.java:543)
> at
> org.eclipse.jetty.server.handler.ContextHandler.stopContext(ContextHandler.java:824)
> at
> org.eclipse.jetty.servlet.ServletContextHandler.stopContext(ServletContextHandler.java:353)
> at
> org.eclipse.jetty.webapp.WebAppContext.stopWebapp(WebAppContext.java:1385)
> at
> org.eclipse.jetty.webapp.WebAppContext.stopContext(WebAppContext.java:1349)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doStop(ContextHandler.java:872)
> at
> org.eclipse.jetty.servlet.ServletContextHandler.doStop(ServletContextHandler.java:269)
> at org.eclipse.jetty.webapp.WebAppContext.doStop(WebAppContext.java:541)
> at
> org.eclipse.jetty.util.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:89)
> at
> org.eclipse.jetty.util.component.ContainerLifeCycle.stop(ContainerLifeCycle.java:143)
> at
> org.eclipse.jetty.util.component.ContainerLifeCycle.doStop(ContainerLifeCycle.java:161)
> at
> org.eclipse.jetty.server.handler.AbstractHandler.doStop(AbstractHandler.java:73)
> at
> org.eclipse.jetty.util.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:89)
> at
> org.eclipse.jetty.util.component.ContainerLifeCycle.stop(ContainerLifeCycle.java:143)
> at
> org.eclipse.jetty.util.component.ContainerLifeCycle.doStop(ContainerLifeCycle.java:161)
> at
> org.eclipse.jetty.server.handler.AbstractHandler.doStop(AbstractHandler.java:73)
> at org.eclipse.jetty.server.Server.doStop(Server.java:476)
> at
> org.eclipse.jetty.util.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:89)
> at
> org.apache.geode.management.internal.ManagementAgent.stopHttpService(ManagementAgent.java:334)
> at
> org.apache.geode.management.internal.ManagementAgent.stopAgent(ManagementAgent.java:157)
> at
> org.apache.geode.management.internal.SystemManagementService.close(SystemManagementService.java:265)
> at
> org.apache.geode.management.internal.beans.ManagementAdapter.handleCacheRemoval(ManagementAdapter.java:735)
> at
> org.apache.geode.management.internal.beans.ManagementListener.handleEvent(ManagementListener.java:117)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.notifyResourceEventListeners(InternalDistributedSystem.java:2162)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.handleResourceEvent(InternalDistributedSystem.java:535)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.close(GemFireCacheImpl.java:2145)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.close(GemFireCacheImpl.java:1988)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.close(GemFireCacheImpl.java:1984)
> at
>
[jira] [Commented] (GEODE-3442) Update ACE to 6.4.4
[ https://issues.apache.org/jira/browse/GEODE-3442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16150740#comment-16150740 ] ASF subversion and git services commented on GEODE-3442: Commit d73030bb8e1550505a078bd97a0c8976a046c33e in geode-native's branch refs/heads/develop from [~mhansonp] [ https://gitbox.apache.org/repos/asf?p=geode-native.git;h=d73030b ] GEODE-3442: Upgrade ACE to 6.4.4 > Update ACE to 6.4.4 > --- > > Key: GEODE-3442 > URL: https://issues.apache.org/jira/browse/GEODE-3442 > Project: Geode > Issue Type: Task > Components: native client >Reporter: Jacob S. Barrett > > https://github.com/DOCGroup/ACE_TAO/releases/tag/ACE%2BTAO-6_4_4 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (GEODE-3088) Failed to properly release resources held by the HTTP service: !STOPPED
[ https://issues.apache.org/jira/browse/GEODE-3088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jared Stewart updated GEODE-3088: - Affects Version/s: 1.2.0 > Failed to properly release resources held by the HTTP service: !STOPPED > --- > > Key: GEODE-3088 > URL: https://issues.apache.org/jira/browse/GEODE-3088 > Project: Geode > Issue Type: Bug > Components: gfsh, pulse >Affects Versions: 1.2.0 >Reporter: Zachary Hansen > > Failed to properly release resources held by the HTTP service: !STOPPED > java.lang.IllegalStateException: !STOPPED > at > org.eclipse.jetty.server.handler.HandlerWrapper.destroy(HandlerWrapper.java:134) > at > org.apache.geode.management.internal.ManagementAgent.stopHttpService(ManagementAgent.java:339) > at > org.apache.geode.management.internal.ManagementAgent.stopAgent(ManagementAgent.java:157) > at > org.apache.geode.management.internal.SystemManagementService.close(SystemManagementService.java:265) > at > org.apache.geode.management.internal.beans.ManagementAdapter.handleCacheRemoval(ManagementAdapter.java:735) > at > org.apache.geode.management.internal.beans.ManagementListener.handleEvent(ManagementListener.java:117) > at > org.apache.geode.distributed.internal.InternalDistributedSystem.notifyResourceEventListeners(InternalDistributedSystem.java:2162) > at > org.apache.geode.distributed.internal.InternalDistributedSystem.handleResourceEvent(InternalDistributedSystem.java:535) > at > org.apache.geode.internal.cache.GemFireCacheImpl.close(GemFireCacheImpl.java:2145) > at > org.apache.geode.distributed.internal.InternalDistributedSystem.disconnect(InternalDistributedSystem.java:1323) > at > org.apache.geode.distributed.internal.InternalDistributedSystem.disconnect(InternalDistributedSystem.java:973) > at > org.apache.geode.management.internal.cli.functions.ShutDownFunction.lambda$disconnectInNonDaemonThread$0(ShutDownFunction.java:72) > at > org.apache.geode.management.internal.cli.functions.ShutDownFunction$$Lambda$32/939474416.run(Unknown > Source) > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > Getting this error when running embedded pulse on GemFire 9.0.4. When pulse > is accessed via browser and left running, this error occurs when issuing a > shutdown command via gfsh. Locator hangs and does not gracefully shutdown. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
