[jira] [Commented] (GEODE-3416) Reduce blocking for SocketCloser.asyncClose

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-3416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16128269#comment-16128269
 ] 

ASF GitHub Bot commented on GEODE-3416:
---

Github user kohlmu-pivotal commented on a diff in the pull request:

https://github.com/apache/geode/pull/702#discussion_r133353995
  
--- Diff: 
geode-core/src/main/java/org/apache/geode/internal/tcp/ConnectionTable.java ---
@@ -929,10 +929,6 @@ protected void removeEndpoint(DistributedMember 
memberID, String reason,
   owner.getDM().getMembershipManager().getShutdownCause());
 }
   }
-
-  if (remoteAddress != null) {
-
this.socketCloser.releaseResourcesForAddress(remoteAddress.toString());
-  }
--- End diff --

it does a missed revert...


> Reduce blocking for SocketCloser.asyncClose 
> 
>
> Key: GEODE-3416
> URL: https://issues.apache.org/jira/browse/GEODE-3416
> Project: Geode
>  Issue Type: Bug
>  Components: client/server
>Affects Versions: 1.1.0, 1.1.1, 1.2.0, 1.2.1
>Reporter: Udo Kohlmeyer
>Assignee: Udo Kohlmeyer
> Fix For: 1.3.0
>
>
> In the SocketCloser.asyncClose method, there is a synchronization block 
> around at HashMap. This synchronization will cause an effective 
> single-threaded processing capability when closing sockets. this effect 
> becomes more evident with a high number of clients.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (GEODE-3395) Variable-ize product version and name in user guide

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-3395?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16128057#comment-16128057
 ] 

ASF subversion and git services commented on GEODE-3395:


Commit bb988caa5969d35948fd603f73bb1a32e879ef78 in geode's branch 
refs/heads/develop from [~dbarnes97]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=bb988ca ]

GEODE-3395 Variable-ize product version and name in user guide - Tools & Modules


>  Variable-ize product version and name in user guide
> 
>
> Key: GEODE-3395
> URL: https://issues.apache.org/jira/browse/GEODE-3395
> Project: Geode
>  Issue Type: New Feature
>  Components: docs
>Reporter: Dave Barnes
>Assignee: Dave Barnes
>
> The Guide contains many occurrences of the product version string ("1.2", 
> "1.1", and "1.0-incubating" are recent examples) scattered over about 900 
> files.  It would be a great convenience to those who write and edit these 
> files to define the version number symbolically so it could be updated in one 
> central location. A template variable in the book's config.yml file would be 
> an obvious candidate for the implementation.
> Similarly, it would be handy to provide symbolic identifiers for the product 
> name, long and short: "Apache Geode" and "Geode", respectively.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (GEODE-3249) Validate internal client/server messages

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-3249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16128046#comment-16128046
 ] 

ASF subversion and git services commented on GEODE-3249:


Commit f8e7ddd5e4696907ce60a14f581ef1ca83e65232 in geode's branch 
refs/heads/feature/GEODE-3249b from [~bschuchardt]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=f8e7ddd ]

GEODE-3249: Validate internal client/server messages

This was merely a matter of changing the server to require the credentials
and changing the client to send credentials.  I removed the general overriding
of AbstractOp.processSecureBytes() because it made no sense.  If the server
sends a secure byte "part" in a message the client is obligated to process
it or the next message it sends will cause a security violation.

I've added a server-side property that folks can set to allow old clients
to continue to work.  This must be used to roll the servers forward to the
new version that contains this change.  Clients must then be rolled
forward & the servers can then be rolled once again without the property set.

The system property is
  geode.allow-internal-messages-without-credentials=true


> Validate internal client/server messages
> 
>
> Key: GEODE-3249
> URL: https://issues.apache.org/jira/browse/GEODE-3249
> Project: Geode
>  Issue Type: Bug
>  Components: messaging
>Reporter: Anthony Baker
>Assignee: Bruce Schuchardt
> Fix For: 1.2.1
>
>
> Some message types can not be invoked directly by an end user.  For 
> validation purposes, we should treat these messages the same way we treat 
> normal messages.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (GEODE-3249) Validate internal client/server messages

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-3249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16128029#comment-16128029
 ] 

ASF subversion and git services commented on GEODE-3249:


Commit 5987dd000e9ac8b254be097f5ac5c4d11857fb74 in geode's branch 
refs/heads/feature/GEODE-3249 from [~bschuchardt]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=5987dd0 ]

Merge branch 'feature/GEODE-3249' of 
https://git-wip-us.apache.org/repos/asf/geode into feature/GEODE-3249


> Validate internal client/server messages
> 
>
> Key: GEODE-3249
> URL: https://issues.apache.org/jira/browse/GEODE-3249
> Project: Geode
>  Issue Type: Bug
>  Components: messaging
>Reporter: Anthony Baker
>Assignee: Bruce Schuchardt
> Fix For: 1.2.1
>
>
> Some message types can not be invoked directly by an end user.  For 
> validation purposes, we should treat these messages the same way we treat 
> normal messages.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (GEODE-3249) Validate internal client/server messages

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-3249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16128025#comment-16128025
 ] 

ASF subversion and git services commented on GEODE-3249:


Commit 6c2ea4ac87298feedd44df40aa3df1899a0f6880 in geode's branch 
refs/heads/feature/GEODE-3249 from [~bschuchardt]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=6c2ea4a ]

GEODE-3249: Validate internal client/server messages

Work in progress.

Messages that could harm a server now send credentials.
TODO: perform authorization checks on the server


> Validate internal client/server messages
> 
>
> Key: GEODE-3249
> URL: https://issues.apache.org/jira/browse/GEODE-3249
> Project: Geode
>  Issue Type: Bug
>  Components: messaging
>Reporter: Anthony Baker
>Assignee: Bruce Schuchardt
> Fix For: 1.2.1
>
>
> Some message types can not be invoked directly by an end user.  For 
> validation purposes, we should treat these messages the same way we treat 
> normal messages.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (GEODE-3249) Validate internal client/server messages

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-3249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16128026#comment-16128026
 ] 

ASF subversion and git services commented on GEODE-3249:


Commit a07d987d25da37231acf0315d5376a3ec39cbb59 in geode's branch 
refs/heads/feature/GEODE-3249 from [~bschuchardt]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=a07d987 ]

GEODE-3249

Moved new test code into a new test method instead of overloading
an existing test method.


> Validate internal client/server messages
> 
>
> Key: GEODE-3249
> URL: https://issues.apache.org/jira/browse/GEODE-3249
> Project: Geode
>  Issue Type: Bug
>  Components: messaging
>Reporter: Anthony Baker
>Assignee: Bruce Schuchardt
> Fix For: 1.2.1
>
>
> Some message types can not be invoked directly by an end user.  For 
> validation purposes, we should treat these messages the same way we treat 
> normal messages.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (GEODE-3249) Validate internal client/server messages

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-3249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16128030#comment-16128030
 ] 

ASF subversion and git services commented on GEODE-3249:


Commit 5987dd000e9ac8b254be097f5ac5c4d11857fb74 in geode's branch 
refs/heads/feature/GEODE-3249 from [~bschuchardt]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=5987dd0 ]

Merge branch 'feature/GEODE-3249' of 
https://git-wip-us.apache.org/repos/asf/geode into feature/GEODE-3249


> Validate internal client/server messages
> 
>
> Key: GEODE-3249
> URL: https://issues.apache.org/jira/browse/GEODE-3249
> Project: Geode
>  Issue Type: Bug
>  Components: messaging
>Reporter: Anthony Baker
>Assignee: Bruce Schuchardt
> Fix For: 1.2.1
>
>
> Some message types can not be invoked directly by an end user.  For 
> validation purposes, we should treat these messages the same way we treat 
> normal messages.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (GEODE-3249) Validate internal client/server messages

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-3249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16128027#comment-16128027
 ] 

ASF subversion and git services commented on GEODE-3249:


Commit e0fbb3cce45528362c1df67bf191ddc4846a9a7f in geode's branch 
refs/heads/feature/GEODE-3249 from [~bschuchardt]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=e0fbb3c ]

GEODE-3249: internal messages should have credentials

added a system property to allow old clients to not send credentials and
a unit test of this change


> Validate internal client/server messages
> 
>
> Key: GEODE-3249
> URL: https://issues.apache.org/jira/browse/GEODE-3249
> Project: Geode
>  Issue Type: Bug
>  Components: messaging
>Reporter: Anthony Baker
>Assignee: Bruce Schuchardt
> Fix For: 1.2.1
>
>
> Some message types can not be invoked directly by an end user.  For 
> validation purposes, we should treat these messages the same way we treat 
> normal messages.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (GEODE-3448) Complete and expose parallel snapshot importing feature

[Nick Reich (JIRA)]

Nick Reich created GEODE-3448:
-

 Summary: Complete and expose parallel snapshot importing feature
 Key: GEODE-3448
 URL: https://issues.apache.org/jira/browse/GEODE-3448
 Project: Geode
  Issue Type: Sub-task
  Components: snapshot
Reporter: Nick Reich


Tests have suggested that parallelizing the importing of a snapshot (using the 
multiple files created in a parallel export) has significant advantages as the 
cluster increased in size. The ability to do this conveniently (instead of 
running an import manually on each member of the cluster) should be exposed.

The implementation will assume that each member of the cluster has the 
specified directory locally available (or at least every member where there is 
data that needs import). However, this means that it will not be possible to do 
a parallel import directly from a shared network disk: if we require such 
functionality, a flag will need to be added to indicate the use of a shared 
location, otherwise, all data will be imported by each member, rather than just 
once.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (GEODE-3448) Complete and expose parallel snapshot importing feature

[Nick Reich (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-3448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Nick Reich reassigned GEODE-3448:
-

Assignee: Nick Reich

> Complete and expose parallel snapshot importing feature
> ---
>
> Key: GEODE-3448
> URL: https://issues.apache.org/jira/browse/GEODE-3448
> Project: Geode
>  Issue Type: Sub-task
>  Components: snapshot
>Reporter: Nick Reich
>Assignee: Nick Reich
>
> Tests have suggested that parallelizing the importing of a snapshot (using 
> the multiple files created in a parallel export) has significant advantages 
> as the cluster increased in size. The ability to do this conveniently 
> (instead of running an import manually on each member of the cluster) should 
> be exposed.
> The implementation will assume that each member of the cluster has the 
> specified directory locally available (or at least every member where there 
> is data that needs import). However, this means that it will not be possible 
> to do a parallel import directly from a shared network disk: if we require 
> such functionality, a flag will need to be added to indicate the use of a 
> shared location, otherwise, all data will be imported by each member, rather 
> than just once.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (GEODE-3447) Implement client authorization for the new protocol

[Brian Baynes (JIRA)]

Brian Baynes created GEODE-3447:
---

 Summary: Implement client authorization for the new protocol
 Key: GEODE-3447
 URL: https://issues.apache.org/jira/browse/GEODE-3447
 Project: Geode
  Issue Type: New Feature
  Components: client/server
Reporter: Brian Baynes


As a user of the new client/server protocol, I need to make sure the clients 
using the protocol to access my grid are authorized to perform each operation 
they attempt.

Implement client authorization for operations in new protocol based on existing 
authorization configuration.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (GEODE-3446) Add cloud store option for export / import

[Fred Krone (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-3446?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Fred Krone updated GEODE-3446:
--
Description: 
Users would like the ability to export a region to an external cloudstore like 
S3, Azure, or GoogleCloud.  

A few things to think about is how to handle the credentials.  

Should we create a new gfsh command to configure an S3 connection which can be 
used anytime?  Or should that be handled inline with the export command?


  was:
Users would like the ability to export a region to an external cloudstore like 
S3, Azure, or GoogleCloud.  

A few things to think about is how to handle the credentials.  

Should we create a new gfsh command to configure an S3 connection which can be 
used anytime?  Or should that be handled inline with the export command?

We need to encrypt and decrypt the data before sending it to S3.


> Add cloud store option for export / import
> --
>
> Key: GEODE-3446
> URL: https://issues.apache.org/jira/browse/GEODE-3446
> Project: Geode
>  Issue Type: Sub-task
>  Components: snapshot
>Reporter: Fred Krone
>
> Users would like the ability to export a region to an external cloudstore 
> like S3, Azure, or GoogleCloud.  
> A few things to think about is how to handle the credentials.  
> Should we create a new gfsh command to configure an S3 connection which can 
> be used anytime?  Or should that be handled inline with the export command?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (GEODE-3107) Improve gfsh export time when doing a snapshot

[Fred Krone (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-3107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Fred Krone resolved GEODE-3107.
---
Resolution: Not A Problem

This is covered in GEODE-3300. 

> Improve gfsh export time when doing a snapshot
> --
>
> Key: GEODE-3107
> URL: https://issues.apache.org/jira/browse/GEODE-3107
> Project: Geode
>  Issue Type: Sub-task
>  Components: snapshot
>Affects Versions: 1.3.0
>Reporter: Fred Krone
>Assignee: Nick Reich
>  Labels: storage_1
>
> Currently a large snapshot puts a lot of pressure on the locator which needs 
> to hold all keys and they do not get destroyed.
> Snapshot goes through the JMX manager but snapshots can also be parallelized 
> and in theory this will probably improve performance.
> It would be useful to benchmark the current gfsh export time on 1 TB region 
> and compare it with performance improvements from this ticket.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (GEODE-3446) Add cloud store option for export / import

[Fred Krone (JIRA)]

Fred Krone created GEODE-3446:
-

 Summary: Add cloud store option for export / import
 Key: GEODE-3446
 URL: https://issues.apache.org/jira/browse/GEODE-3446
 Project: Geode
  Issue Type: Sub-task
  Components: snapshot
Reporter: Fred Krone


Users would like the ability to export a region to an external cloudstore like 
S3, Azure, or GoogleCloud.  

A few things to think about is how to handle the credentials.  

Should we create a new gfsh command to configure an S3 connection which can be 
used anytime?  Or should that be handled inline with the export command?

We need to encrypt and decrypt the data before sending it to S3.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (GEODE-3020) Use standard types in map

[Addison (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-3020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Addison closed GEODE-3020.
--

> Use standard types in map
> -
>
> Key: GEODE-3020
> URL: https://issues.apache.org/jira/browse/GEODE-3020
> Project: Geode
>  Issue Type: New Feature
>  Components: native client
>Reporter: Ernest Burghardt
>
> in Struct.hpp
>   typedef std::unordered_map  dereference_hash,
>  dereference_equal_to>



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (GEODE-3184) Clean up session replication testing

[David Anuta (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-3184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

David Anuta reassigned GEODE-3184:
--

Assignee: David Anuta

> Clean up session replication testing
> 
>
> Key: GEODE-3184
> URL: https://issues.apache.org/jira/browse/GEODE-3184
> Project: Geode
>  Issue Type: Improvement
>  Components: http session
>Reporter: David Anuta
>Assignee: David Anuta
>Priority: Minor
>
> Would be good to review  the code base and make sure methods are properly 
> organized.
> Also, the previous session replication testing is still in place in the 
> extensions folder. This needs to be reviewed and any tests not covered by 
> cargo should be transferred over into the new cargo replication testing. An 
> example of something within this that needs to be cleaned up would be 
> QueryCommand and CommandServlet classes, which are both in the 
> extensions/geode-modules and extensions/session-testing-war projects. the 
> QueryCommand and Command Servlet class within the extensions/geode-modules 
> project could be removed if the previous session tests were all ported to 
> cargo and then removed.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (GEODE-3412) Implement a basic authentication mechanism for the new protocol

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-3412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16127854#comment-16127854
 ] 

ASF GitHub Bot commented on GEODE-3412:
---

Github user asfgit closed the pull request at:

https://github.com/apache/geode/pull/714


> Implement a basic authentication mechanism for the new protocol
> ---
>
> Key: GEODE-3412
> URL: https://issues.apache.org/jira/browse/GEODE-3412
> Project: Geode
>  Issue Type: New Feature
>  Components: client/server
>Reporter: Brian Rowe
>Assignee: Brian Rowe
>
> Implement a simple username/password authentication for the new protocol.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (GEODE-3412) Implement a basic authentication mechanism for the new protocol

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-3412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16127853#comment-16127853
 ] 

ASF subversion and git services commented on GEODE-3412:


Commit bc655eb9b3683282705e7449f0f7a720c1a6243d in geode's branch 
refs/heads/develop from [~WireBaron]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=bc655eb ]

GEODE-3412: adding files missing from last commit. This now closes #714


> Implement a basic authentication mechanism for the new protocol
> ---
>
> Key: GEODE-3412
> URL: https://issues.apache.org/jira/browse/GEODE-3412
> Project: Geode
>  Issue Type: New Feature
>  Components: client/server
>Reporter: Brian Rowe
>Assignee: Brian Rowe
>
> Implement a simple username/password authentication for the new protocol.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (GEODE-1229) LocatorLauncherRemoteJUnitTest.testStartOverwritesStalePidFile

[Kirk Lund (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-1229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kirk Lund resolved GEODE-1229.
--
   Resolution: Fixed
Fix Version/s: 1.3.0

> LocatorLauncherRemoteJUnitTest.testStartOverwritesStalePidFile
> --
>
> Key: GEODE-1229
> URL: https://issues.apache.org/jira/browse/GEODE-1229
> Project: Geode
>  Issue Type: Bug
>Reporter: xiaojian zhou
>Assignee: Kirk Lund
>  Labels: CI, Flaky, LauncherTest
> Fix For: 1.3.0
>
>
> {noformat}
> Geode_develop_IntegrationTests/2383
> java.lang.AssertionError: waiting for process to start: Locator in 
> /tmp/junit4779681895097860734 on null is currently not responding.
>   at org.junit.Assert.fail(Assert.java:88)
>   at org.junit.Assert.assertTrue(Assert.java:41)
>   at 
> com.gemstone.gemfire.distributed.AbstractLauncherJUnitTestCase.assertEventuallyTrue(AbstractLauncherJUnitTestCase.java:237)
>   at 
> com.gemstone.gemfire.distributed.AbstractLocatorLauncherJUnitTestCase.waitForLocatorToStart(AbstractLocatorLauncherJUnitTestCase.java:64)
>   at 
> com.gemstone.gemfire.distributed.AbstractLocatorLauncherJUnitTestCase.waitForLocatorToStart(AbstractLocatorLauncherJUnitTestCase.java:87)
>   at 
> com.gemstone.gemfire.distributed.LocatorLauncherRemoteJUnitTest.testStartOverwritesStalePidFile(LocatorLauncherRemoteJUnitTest.java:307)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
>   at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>   at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
>   at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>   at 
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
>   at org.junit.rules.Verifier$1.evaluate(Verifier.java:35)
>   at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
>   at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
>   at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
>   at org.junit.rules.RunRules.evaluate(RunRules.java:20)
>   at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
>   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
>   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:105)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:56)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:64)
>   at 
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:50)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at 
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
>   at 
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
>   at 
> org.gradle.messaging.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
>   at 
> org.gradle.messaging.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
>   at com.sun.proxy.$Proxy2.processTestClass(Unknown Source)
>   at 
> org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:106)
>   at 

[jira] [Resolved] (GEODE-1309) CI failure: ServerLauncherTest.testSetServerBindAddressToNonLocalHost

[Kirk Lund (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-1309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kirk Lund resolved GEODE-1309.
--
   Resolution: Fixed
Fix Version/s: 1.3.0

> CI failure: ServerLauncherTest.testSetServerBindAddressToNonLocalHost
> -
>
> Key: GEODE-1309
> URL: https://issues.apache.org/jira/browse/GEODE-1309
> Project: Geode
>  Issue Type: Bug
>  Components: gfsh
>Reporter: Eric Shu
>Assignee: Kirk Lund
>  Labels: DNS, Flaky, LauncherTest, UnitTest
> Fix For: 1.3.0
>
>
> {noformat}
> Error Message
> java.lang.Exception: Unexpected exception, 
> expected but 
> was
> Stacktrace
> java.lang.Exception: Unexpected exception, 
> expected but 
> was
>   at 
> org.junit.internal.runners.statements.ExpectException.evaluate(ExpectException.java:28)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>   at 
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
>   at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
>   at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
>   at org.junit.rules.RunRules.evaluate(RunRules.java:20)
>   at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
>   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
>   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:105)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:56)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:64)
>   at 
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:50)
>   at sun.reflect.GeneratedMethodAccessor5.invoke(Unknown Source)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at 
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
>   at 
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
>   at 
> org.gradle.messaging.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
>   at 
> org.gradle.messaging.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
>   at com.sun.proxy.$Proxy2.processTestClass(Unknown Source)
>   at 
> org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:106)
>   at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at 
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
>   at 
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
>   at 
> org.gradle.messaging.remote.internal.hub.MessageHub$Handler.run(MessageHub.java:360)
>   at 
> org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:54)
>   at 
> org.gradle.internal.concurrent.StoppableExecutorImpl$1.run(StoppableExecutorImpl.java:40)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>   at java.lang.Thread.run(Thread.java:745)
> Caused by: org.junit.ComparisonFailure: expected:<[yahoo.com is not an 
> address for this machine].> but was:<[The hostname/IP address to which the 
> Server will be bound is unknown].>
>   at org.junit.Assert.assertEquals(Assert.java:115)
>   at org.junit.Assert.assertEquals(Assert.java:144)
>   at 
> com.gemstone.gemfire.distributed.ServerLauncherJUnitTest.testSetServerBindAddressToNonLocalHost(ServerLauncherJUnitTest.java:263)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> 

[jira] [Resolved] (GEODE-2791) LocatorLauncherAssemblyIntegrationTest.testLocatorStopsWhenJmxPortIsNonZero fails intermittently with AssertionError

[Kirk Lund (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-2791?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kirk Lund resolved GEODE-2791.
--
   Resolution: Fixed
Fix Version/s: 1.3.0

NOTE: LocatorLauncherAssemblyIntegrationTest was deleted after moving tests 
from it to other test classes.

> LocatorLauncherAssemblyIntegrationTest.testLocatorStopsWhenJmxPortIsNonZero 
> fails intermittently with AssertionError
> 
>
> Key: GEODE-2791
> URL: https://issues.apache.org/jira/browse/GEODE-2791
> Project: Geode
>  Issue Type: Bug
>  Components: gfsh, tests
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>  Labels: LauncherTest
> Fix For: 1.3.0
>
>
> {noformat}
> org.apache.geode.distributed.LocatorLauncherAssemblyIntegrationTest > 
> testLocatorStopsWhenJmxPortIsNonZero[1] FAILED
> java.lang.AssertionError: expected:<4> but was:<15>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:834)
> at org.junit.Assert.assertEquals(Assert.java:645)
> at org.junit.Assert.assertEquals(Assert.java:631)
> at 
> org.apache.geode.distributed.LocatorLauncherAssemblyIntegrationTest.performTest(LocatorLauncherAssemblyIntegrationTest.java:148)
> at 
> org.apache.geode.distributed.LocatorLauncherAssemblyIntegrationTest.testLocatorStopsWhenJmxPortIsNonZero(LocatorLauncherAssemblyIntegrationTest.java:89)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (GEODE-3413) Overhaul launcher tests and process tests

[Kirk Lund (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-3413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kirk Lund resolved GEODE-3413.
--
   Resolution: Fixed
Fix Version/s: 1.3.0

> Overhaul launcher tests and process tests
> -
>
> Key: GEODE-3413
> URL: https://issues.apache.org/jira/browse/GEODE-3413
> Project: Geode
>  Issue Type: Improvement
>  Components: gfsh
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>  Labels: LauncherTest, ProcessTest
> Fix For: 1.3.0
>
>
> The launcher and process tests are closely related and in need of overhauling 
> to improve debugging and remove flakiness.
> In addition, the org.apache.geode.internal.process package is need of 
> improving the test code coverage.
> Launcher tests:
> * 
> geode-assembly/src/test/java/org/apache/geode/distributed/LocatorLauncherAssemblyIntegrationTest.java
> * 
> geode-core/src/test/java/org/apache/geode/distributed/AbstractLauncherIntegrationTest.java
> * 
> geode-core/src/test/java/org/apache/geode/distributed/AbstractLauncherServiceStatusTest.java
> * 
> geode-core/src/test/java/org/apache/geode/distributed/AbstractLauncherTest.java
> * 
> geode-core/src/test/java/org/apache/geode/distributed/LauncherMemberMXBeanIntegrationTest.java
> * 
> geode-core/src/test/java/org/apache/geode/distributed/LocatorLauncherIntegrationTest.java
> * 
> geode-core/src/test/java/org/apache/geode/distributed/LocatorLauncherLocalFileIntegrationTest.java
> * 
> geode-core/src/test/java/org/apache/geode/distributed/LocatorLauncherLocalIntegrationTest.java
> * 
> geode-core/src/test/java/org/apache/geode/distributed/LocatorLauncherRemoteFileIntegrationTest.java
> * 
> geode-core/src/test/java/org/apache/geode/distributed/LocatorLauncherRemoteIntegrationTest.java
> * 
> geode-core/src/test/java/org/apache/geode/distributed/LocatorLauncherRemoteWithCustomLoggingIntegrationTest.java
> * 
> geode-core/src/test/java/org/apache/geode/distributed/LocatorLauncherTest.java
> * geode-core/src/test/java/org/apache/geode/distributed/LocatorStateTest.java
> * 
> geode-core/src/test/java/org/apache/geode/distributed/ServerLauncherIntegrationTest.java
> * 
> geode-core/src/test/java/org/apache/geode/distributed/ServerLauncherLocalFileIntegrationTest.java
> * 
> geode-core/src/test/java/org/apache/geode/distributed/ServerLauncherLocalIntegrationTest.java
> * 
> geode-core/src/test/java/org/apache/geode/distributed/ServerLauncherRemoteFileIntegrationTest.java
> * 
> geode-core/src/test/java/org/apache/geode/distributed/ServerLauncherRemoteIntegrationTest.java
> * 
> geode-core/src/test/java/org/apache/geode/distributed/ServerLauncherRemoteWithCustomLoggingIntegrationTest.java
> * 
> geode-core/src/test/java/org/apache/geode/distributed/ServerLauncherRemoteWithCustomLoggingIntegrationTest.java
> * 
> geode-core/src/test/java/org/apache/geode/distributed/ServerLauncherTest.java
> * 
> geode-core/src/test/java/org/apache/geode/distributed/ServerLauncherWithProviderIntegrationTest.java
> Process tests:
> * 
> geode-core/src/test/java/org/apache/geode/internal/process/BlockingProcessStreamReaderJUnitTest.java
> * 
> geode-core/src/test/java/org/apache/geode/internal/process/FileProcessControllerIntegrationJUnitTest.java
> * 
> geode-core/src/test/java/org/apache/geode/internal/process/LocalProcessControllerJUnitTest.java
> * 
> geode-core/src/test/java/org/apache/geode/internal/process/LocalProcessLauncherDUnitTest.java
> * 
> geode-core/src/test/java/org/apache/geode/internal/process/LocalProcessLauncherJUnitTest.java
> * 
> geode-core/src/test/java/org/apache/geode/internal/process/NonBlockingProcessStreamReaderJUnitTest.java
> * 
> geode-core/src/test/java/org/apache/geode/internal/process/PidFileJUnitTest.java
> * 
> geode-core/src/test/java/org/apache/geode/internal/process/ProcessControllerFactoryJUnitTest.java



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (GEODE-3414) Cleanup org.apache.geode.internal.process package

[Kirk Lund (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-3414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kirk Lund resolved GEODE-3414.
--
   Resolution: Fixed
Fix Version/s: 1.3.0

> Cleanup org.apache.geode.internal.process package
> -
>
> Key: GEODE-3414
> URL: https://issues.apache.org/jira/browse/GEODE-3414
> Project: Geode
>  Issue Type: Improvement
>  Components: gfsh
>Reporter: Kirk Lund
>Assignee: Kirk Lund
> Fix For: 1.3.0
>
>
> The org.apache.geode.internal.process package is in need of refactoring and 
> general cleanup.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Reopened] (GEODE-3328) Need official GemFire properties to set Key/Trust Store Type for SSL configuration

[Kirk Lund (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-3328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kirk Lund reopened GEODE-3328:
--
  Assignee: Kirk Lund  (was: Jinmei Liao)

> Need official GemFire properties to set Key/Trust Store Type for SSL 
> configuration
> --
>
> Key: GEODE-3328
> URL: https://issues.apache.org/jira/browse/GEODE-3328
> Project: Geode
>  Issue Type: Bug
>  Components: docs
>Reporter: Jinmei Liao
>Assignee: Kirk Lund
> Fix For: 1.3.0
>
>
> Need official GemFire properties to set Key/Trust Store Type for SSL 
> configuration rather than the following undocumented java system properties.
> {noformat}
> javax.net.ssl.keyStoreType
> javax.net.ssl.trustStoreType
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (GEODE-3328) Need official GemFire properties to set Key/Trust Store Type for SSL configuration

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-3328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16127750#comment-16127750
 ] 

ASF subversion and git services commented on GEODE-3328:


Commit 27475ea80374e6fb00d6b77cee8bb7301a161bf5 in geode's branch 
refs/heads/GEODE-3328 from [~apa...@the9muses.net]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=27475ea ]

GEODE-3328: fix testAddGemFirePropertyFileToCommandLineNew on Windows

Modification of ca4b81 committed by Jinmei Liao


> Need official GemFire properties to set Key/Trust Store Type for SSL 
> configuration
> --
>
> Key: GEODE-3328
> URL: https://issues.apache.org/jira/browse/GEODE-3328
> Project: Geode
>  Issue Type: Bug
>  Components: docs
>Reporter: Jinmei Liao
>Assignee: Jinmei Liao
> Fix For: 1.3.0
>
>
> Need official GemFire properties to set Key/Trust Store Type for SSL 
> configuration rather than the following undocumented java system properties.
> {noformat}
> javax.net.ssl.keyStoreType
> javax.net.ssl.trustStoreType
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (GEODE-3249) Validate internal client/server messages

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-3249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16127721#comment-16127721
 ] 

ASF subversion and git services commented on GEODE-3249:


Commit 6ee5771dd1156b3d754662259e30e635702721b8 in geode's branch 
refs/heads/feature/GEODE-3249 from [~bschuchardt]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=6ee5771 ]

GEODE-3249: internal messages should have credentials

Require all client-side message classes to invoke processSecureBytes().

Allow client PR metadata fetch from a background thread with no
credentials.


> Validate internal client/server messages
> 
>
> Key: GEODE-3249
> URL: https://issues.apache.org/jira/browse/GEODE-3249
> Project: Geode
>  Issue Type: Bug
>  Components: messaging
>Reporter: Anthony Baker
>Assignee: Bruce Schuchardt
> Fix For: 1.2.1
>
>
> Some message types can not be invoked directly by an end user.  For 
> validation purposes, we should treat these messages the same way we treat 
> normal messages.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (GEODE-3412) Implement a basic authentication mechanism for the new protocol

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-3412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16127710#comment-16127710
 ] 

ASF GitHub Bot commented on GEODE-3412:
---

GitHub user WireBaron opened a pull request:

https://github.com/apache/geode/pull/714

GEODE-3412: adding files missing from last commit

This is adding some files which should have been in the last commit for 
this feature.

Thank you for submitting a contribution to Apache Geode.

In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:

### For all changes:
- [x] Is there a JIRA ticket associated with this PR? Is it referenced in 
the commit message?

- [x] Has your PR been rebased against the latest commit within the target 
branch (typically `develop`)?

- [x] Is your initial contribution a single, squashed commit?

- [ ] Does `gradlew build` run cleanly?

- [ ] Have you written or updated unit tests to verify your changes?

- [ ] If adding new dependencies to the code, are these dependencies 
licensed in a way that is compatible for inclusion under [ASF 
2.0](http://www.apache.org/legal/resolved.html#category-a)?

### Note:
Please ensure that once the PR is submitted, you check travis-ci for build 
issues and
submit an update to your PR as soon as possible. If you need help, please 
send an
email to d...@geode.apache.org.


You can merge this pull request into a Git repository by running:

$ git pull https://github.com/WireBaron/geode feature/GEODE3412

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/geode/pull/714.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #714


commit 1022f323a0061f43155bd5ea74879981b8bc8ffc
Author: Brian Rowe 
Date:   2017-08-15T18:21:51Z

GEODE-3412: adding files missing from last commit




> Implement a basic authentication mechanism for the new protocol
> ---
>
> Key: GEODE-3412
> URL: https://issues.apache.org/jira/browse/GEODE-3412
> Project: Geode
>  Issue Type: New Feature
>  Components: client/server
>Reporter: Brian Rowe
>Assignee: Brian Rowe
>
> Implement a simple username/password authentication for the new protocol.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (GEODE-3445) Add Gfsh Connect option --skip-ssl-validation

[Jared Stewart (JIRA)]

Jared Stewart created GEODE-3445:


 Summary: Add Gfsh Connect option --skip-ssl-validation
 Key: GEODE-3445
 URL: https://issues.apache.org/jira/browse/GEODE-3445
 Project: Geode
  Issue Type: New Feature
  Components: gfsh
Reporter: Jared Stewart


We have users who would like to connect to a locator from gfsh over HTTPS 
without verifying the hostname of the locator.  (This is a common pattern in 
testing environments or where self-signed certificates are used.)  We already 
have some code used for tests to enable this behavior:

{noformat}
   // This is for testing purpose only. If we remove this piece of code we will
// get a java.security.cert.CertificateException
// as matching hostname can not be obtained in all test environment.
HttpsURLConnection.setDefaultHostnameVerifier(new HostnameVerifier() {
  @Override
  public boolean verify(String string, SSLSession ssls) {
return true;
  }
});
{noformat}

We just need to conditionally call this code inside Gfsh Connect if the 
--skip-ssl-validation option is specified.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (GEODE-3412) Implement a basic authentication mechanism for the new protocol

[Brian Baynes (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-3412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Brian Baynes reassigned GEODE-3412:
---

Assignee: Brian Rowe

> Implement a basic authentication mechanism for the new protocol
> ---
>
> Key: GEODE-3412
> URL: https://issues.apache.org/jira/browse/GEODE-3412
> Project: Geode
>  Issue Type: New Feature
>  Components: client/server
>Reporter: Brian Rowe
>Assignee: Brian Rowe
>
> Implement a simple username/password authentication for the new protocol.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (GEODE-3416) Reduce blocking for SocketCloser.asyncClose

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-3416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16127649#comment-16127649
 ] 

ASF GitHub Bot commented on GEODE-3416:
---

Github user pivotal-amurmann commented on a diff in the pull request:

https://github.com/apache/geode/pull/702#discussion_r133252327
  
--- Diff: 
geode-core/src/main/java/org/apache/geode/internal/net/SocketCloser.java ---
@@ -96,46 +99,56 @@ public int getMaxThreads() {
 return this.asyncClosePoolMaxThreads;
   }
 
-  private ThreadPoolExecutor getAsyncThreadExecutor(String address) {
-synchronized (asyncCloseExecutors) {
-  ThreadPoolExecutor pool = asyncCloseExecutors.get(address);
-  if (pool == null) {
-final ThreadGroup tg = 
LoggingThreadGroup.createThreadGroup("Socket asyncClose", logger);
-ThreadFactory tf = new ThreadFactory() {
-  public Thread newThread(final Runnable command) {
-Thread thread = new Thread(tg, command);
-thread.setDaemon(true);
-return thread;
-  }
-};
-BlockingQueue workQueue = new 
LinkedBlockingQueue();
-pool = new ThreadPoolExecutor(this.asyncClosePoolMaxThreads, 
this.asyncClosePoolMaxThreads,
-this.asyncClosePoolKeepAliveSeconds, TimeUnit.SECONDS, 
workQueue, tf);
-pool.allowCoreThreadTimeOut(true);
-asyncCloseExecutors.put(address, pool);
+  private ExecutorService getAsyncThreadExecutor(String address) {
+ExecutorService executorService = asyncCloseExecutors.get(address);
+if (executorService == null) {
+  // To be used for pre-1.8 jdk releases.
+  // createThreadPool();
+
+  executorService = 
Executors.newWorkStealingPool(asyncClosePoolMaxThreads);
+
+  ExecutorService previousThreadPoolExecutor =
+  asyncCloseExecutors.putIfAbsent(address, executorService);
+
+  if (previousThreadPoolExecutor != null) {
+executorService.shutdownNow();
+return previousThreadPoolExecutor;
   }
-  return pool;
 }
+return executorService;
+  }
+
+  /**
+   * @deprecated this method is to be used for pre 1.8 jdk.
--- End diff --

I always appreciate it as a consumer if deprecations contain information 
about what the new solution is for the problem that the deprecated code was 
solving.


> Reduce blocking for SocketCloser.asyncClose 
> 
>
> Key: GEODE-3416
> URL: https://issues.apache.org/jira/browse/GEODE-3416
> Project: Geode
>  Issue Type: Bug
>  Components: client/server
>Affects Versions: 1.1.0, 1.1.1, 1.2.0, 1.2.1
>Reporter: Udo Kohlmeyer
>Assignee: Udo Kohlmeyer
> Fix For: 1.3.0
>
>
> In the SocketCloser.asyncClose method, there is a synchronization block 
> around at HashMap. This synchronization will cause an effective 
> single-threaded processing capability when closing sockets. this effect 
> becomes more evident with a high number of clients.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (GEODE-3412) Implement a basic authentication mechanism for the new protocol

[Brian Rowe (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-3412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Brian Rowe resolved GEODE-3412.
---
Resolution: Fixed

> Implement a basic authentication mechanism for the new protocol
> ---
>
> Key: GEODE-3412
> URL: https://issues.apache.org/jira/browse/GEODE-3412
> Project: Geode
>  Issue Type: New Feature
>  Components: client/server
>Reporter: Brian Rowe
>
> Implement a simple username/password authentication for the new protocol.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (GEODE-3434) Allow the modules to be interoperable with current and older versions of tomcat 7

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-3434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16127632#comment-16127632
 ] 

ASF GitHub Bot commented on GEODE-3434:
---

Github user DivineEnder commented on a diff in the pull request:

https://github.com/apache/geode/pull/712#discussion_r133256792
  
--- Diff: 
geode-assembly/src/test/java/org/apache/geode/session/tests/ContainerInstall.java
 ---
@@ -18,6 +18,7 @@
 import java.io.FileInputStream;
 import java.io.FileOutputStream;
 import java.io.IOException;
+import java.net.URI;
--- End diff --

I think this is extraneous. It doesn't seem to be used anywhere in this 
file.


> Allow the modules to be interoperable with current and older versions of 
> tomcat 7 
> --
>
> Key: GEODE-3434
> URL: https://issues.apache.org/jira/browse/GEODE-3434
> Project: Geode
>  Issue Type: Bug
>  Components: http session
>Reporter: Jason Huynh
>Assignee: Jason Huynh
>
> There was a change to the attribute field in tomcat (and we made the 
> necessary changes in geode session modules), but that does not allow our 
> session modules to work with older versions of tomcat 7.  We can probably 
> modify the classes to allow use with of the session module jars across 
> different versions of tomcat 7.
> We should probably add tests that run against older versions of geode to 
> allow backwards compatibility between a geode server and a session module jar 
> from a previous release.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (GEODE-3412) Implement a basic authentication mechanism for the new protocol

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-3412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16127626#comment-16127626
 ] 

ASF GitHub Bot commented on GEODE-3412:
---

Github user asfgit closed the pull request at:

https://github.com/apache/geode/pull/707


> Implement a basic authentication mechanism for the new protocol
> ---
>
> Key: GEODE-3412
> URL: https://issues.apache.org/jira/browse/GEODE-3412
> Project: Geode
>  Issue Type: New Feature
>  Components: client/server
>Reporter: Brian Rowe
>
> Implement a simple username/password authentication for the new protocol.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (GEODE-3412) Implement a basic authentication mechanism for the new protocol

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-3412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16127625#comment-16127625
 ] 

ASF subversion and git services commented on GEODE-3412:


Commit a7a197d633a20ee3a2161d47389581858745c1cc in geode's branch 
refs/heads/develop from [~WireBaron]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=a7a197d ]

GEODE-3412: Add simple authentication flow to protobuf protocol. This now 
closes #707

This change adds a simple username/password validation to the protobuf protocol.
It also adds a new configuration parameter to specify the type of 
authentication required.

Signed-off-by: Galen O'Sullivan 


> Implement a basic authentication mechanism for the new protocol
> ---
>
> Key: GEODE-3412
> URL: https://issues.apache.org/jira/browse/GEODE-3412
> Project: Geode
>  Issue Type: New Feature
>  Components: client/server
>Reporter: Brian Rowe
>
> Implement a simple username/password authentication for the new protocol.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (GEODE-3416) Reduce blocking for SocketCloser.asyncClose

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-3416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16127621#comment-16127621
 ] 

ASF GitHub Bot commented on GEODE-3416:
---

Github user kohlmu-pivotal commented on a diff in the pull request:

https://github.com/apache/geode/pull/702#discussion_r133255222
  
--- Diff: 
geode-core/src/main/java/org/apache/geode/internal/net/SocketCloser.java ---
@@ -96,46 +99,55 @@ public int getMaxThreads() {
 return this.asyncClosePoolMaxThreads;
   }
 
-  private ThreadPoolExecutor getAsyncThreadExecutor(String address) {
-synchronized (asyncCloseExecutors) {
-  ThreadPoolExecutor pool = asyncCloseExecutors.get(address);
-  if (pool == null) {
-final ThreadGroup tg = 
LoggingThreadGroup.createThreadGroup("Socket asyncClose", logger);
-ThreadFactory tf = new ThreadFactory() {
-  public Thread newThread(final Runnable command) {
-Thread thread = new Thread(tg, command);
-thread.setDaemon(true);
-return thread;
-  }
-};
-BlockingQueue workQueue = new 
LinkedBlockingQueue();
-pool = new ThreadPoolExecutor(this.asyncClosePoolMaxThreads, 
this.asyncClosePoolMaxThreads,
-this.asyncClosePoolKeepAliveSeconds, TimeUnit.SECONDS, 
workQueue, tf);
-pool.allowCoreThreadTimeOut(true);
-asyncCloseExecutors.put(address, pool);
+  private ExecutorService getAsyncThreadExecutor(String address) {
+ExecutorService executorService = asyncCloseExecutors.get(address);
+if (executorService == null) {
+  // To be used for pre-1.8 jdk releases.
+  // createThreadPool();
+
+  executorService = 
Executors.newWorkStealingPool(asyncClosePoolMaxThreads);
+
+  ExecutorService previousThreadPoolExecutor =
+  asyncCloseExecutors.putIfAbsent(address, executorService);
+
+  if (previousThreadPoolExecutor != null) {
+executorService.shutdownNow();
+return previousThreadPoolExecutor;
   }
-  return pool;
 }
+return executorService;
+  }
+
+  /**
+   * @deprecated this method is to be used for pre 1.8 jdk.
+   */
+  @Deprecated
+  private void createThreadPool() {
+ExecutorService executorService;
+final ThreadGroup threadGroup =
+LoggingThreadGroup.createThreadGroup("Socket asyncClose", logger);
+ThreadFactory threadFactory = new ThreadFactory() {
+  public Thread newThread(final Runnable command) {
+Thread thread = new Thread(threadGroup, command);
+thread.setDaemon(true);
+return thread;
+  }
+};
+
+executorService = new ThreadPoolExecutor(asyncClosePoolMaxThreads, 
asyncClosePoolMaxThreads,
+asyncCloseWaitTime, asyncCloseWaitUnits, new 
LinkedBlockingQueue<>(), threadFactory);
   }
 
   /**
* Call this method if you know all the resources in the closer for the 
given address are no
* longer needed. Currently a thread pool is kept for each address and 
if you know that an address
* no longer needs its pool then you should call this method.
*/
-  public void releaseResourcesForAddress(String address) {
-synchronized (asyncCloseExecutors) {
-  ThreadPoolExecutor pool = asyncCloseExecutors.get(address);
-  if (pool != null) {
-pool.shutdown();
-asyncCloseExecutors.remove(address);
-  }
-}
-  }
 
-  private boolean isClosed() {
-synchronized (asyncCloseExecutors) {
-  return this.closed;
+  public void releaseResourcesForAddress(String address) {
+ExecutorService executorService = asyncCloseExecutors.remove(address);
+if (executorService != null) {
+  executorService.shutdown();
--- End diff --

Correct and agreed. When the cache closes, I imagine SocketCloser.close() 
is called. Which means the closing of any socket post that would be done 
in-line. 
I don't know what the expected behavior is supposed to be, for the closing 
of the sockets when that cache is closing. But you are correct that it could 
mean that the closing of the socket could be holding up the shutting down of 
the cache.



> Reduce blocking for SocketCloser.asyncClose 
> 
>
> Key: GEODE-3416
> URL: https://issues.apache.org/jira/browse/GEODE-3416
> Project: Geode
>  Issue Type: Bug
>  Components: client/server
>Affects Versions: 1.1.0, 1.1.1, 1.2.0, 1.2.1
>Reporter: Udo Kohlmeyer
>Assignee: Udo Kohlmeyer
> Fix For: 1.3.0
>
>
> In the 

[jira] [Commented] (GEODE-3416) Reduce blocking for SocketCloser.asyncClose

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-3416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16127594#comment-16127594
 ] 

ASF GitHub Bot commented on GEODE-3416:
---

Github user hiteshk25 commented on a diff in the pull request:

https://github.com/apache/geode/pull/702#discussion_r133249141
  
--- Diff: 
geode-core/src/main/java/org/apache/geode/internal/tcp/ConnectionTable.java ---
@@ -929,10 +929,6 @@ protected void removeEndpoint(DistributedMember 
memberID, String reason,
   owner.getDM().getMembershipManager().getShutdownCause());
 }
   }
-
-  if (remoteAddress != null) {
-
this.socketCloser.releaseResourcesForAddress(remoteAddress.toString());
-  }
--- End diff --

This doesn't require??


> Reduce blocking for SocketCloser.asyncClose 
> 
>
> Key: GEODE-3416
> URL: https://issues.apache.org/jira/browse/GEODE-3416
> Project: Geode
>  Issue Type: Bug
>  Components: client/server
>Affects Versions: 1.1.0, 1.1.1, 1.2.0, 1.2.1
>Reporter: Udo Kohlmeyer
>Assignee: Udo Kohlmeyer
> Fix For: 1.3.0
>
>
> In the SocketCloser.asyncClose method, there is a synchronization block 
> around at HashMap. This synchronization will cause an effective 
> single-threaded processing capability when closing sockets. this effect 
> becomes more evident with a high number of clients.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (GEODE-3412) Implement a basic authentication mechanism for the new protocol

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-3412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16127571#comment-16127571
 ] 

ASF GitHub Bot commented on GEODE-3412:
---

Github user pivotal-amurmann commented on a diff in the pull request:

https://github.com/apache/geode/pull/707#discussion_r133246611
  
--- Diff: 
geode-core/src/main/java/org/apache/geode/internal/cache/tier/sockets/ServerConnectionFactory.java
 ---
@@ -22,59 +22,89 @@
 
 import java.io.IOException;
 import java.net.Socket;
+import java.util.HashMap;
 import java.util.Iterator;
+import java.util.Map;
 import java.util.ServiceLoader;
-import javax.management.ServiceNotFoundException;
 
 /**
  * Creates instances of ServerConnection based on the connection mode 
provided.
  */
 public class ServerConnectionFactory {
-  private static ClientProtocolMessageHandler protobufProtocolHandler;
-  private static final Object protocolLoadLock = new Object();
+  private ClientProtocolMessageHandler protobufProtocolHandler;
+  private Map authenticators 
= null;
 
-  private static ClientProtocolMessageHandler 
findClientProtocolMessageHandler() {
+  public ServerConnectionFactory() {}
+
+  private synchronized void initializeAuthenticatorsMap() {
+if (authenticators != null) {
+  return;
+}
+authenticators = new HashMap<>();
+ServiceLoader loader = 
ServiceLoader.load(StreamAuthenticator.class);
+for (StreamAuthenticator streamAuthenticator : loader) {
+  authenticators.put(streamAuthenticator.implementationID(), 
streamAuthenticator.getClass());
+}
+  }
+
+  private synchronized ClientProtocolMessageHandler 
initializeMessageHandler() {
 if (protobufProtocolHandler != null) {
   return protobufProtocolHandler;
 }
+ServiceLoader loader =
+ServiceLoader.load(ClientProtocolMessageHandler.class);
+Iterator iterator = loader.iterator();
 
-synchronized (protocolLoadLock) {
-  if (protobufProtocolHandler != null) {
-return protobufProtocolHandler;
-  }
-
-  ServiceLoader loader =
-  ServiceLoader.load(ClientProtocolMessageHandler.class);
-  Iterator iterator = loader.iterator();
-
-  if (!iterator.hasNext()) {
-throw new ServiceLoadingFailureException(
-"ClientProtocolMessageHandler implementation not found in 
JVM");
-  }
+if (!iterator.hasNext()) {
+  throw new ServiceLoadingFailureException(
+  "There is no ClientProtocolMessageHandler implementation found 
in JVM");
+}
 
-  ClientProtocolMessageHandler returnValue = iterator.next();
+protobufProtocolHandler = iterator.next();
+return protobufProtocolHandler;
+  }
 
-  if (iterator.hasNext()) {
+  private StreamAuthenticator findStreamAuthenticator(String 
implementationID) {
+if (authenticators == null) {
+  initializeAuthenticatorsMap();
+}
+Class streamAuthenticatorClass =
+authenticators.get(implementationID);
+if (streamAuthenticatorClass == null) {
+  throw new ServiceLoadingFailureException(
+  "Could not find implementation for StreamAuthenticator with 
implementation ID "
+  + implementationID);
+} else {
+  try {
+return streamAuthenticatorClass.newInstance();
+  } catch (InstantiationException | IllegalAccessException e) {
 throw new ServiceLoadingFailureException(
-"Multiple service implementations found for 
ClientProtocolMessageHandler");
--- End diff --

Where are we now handling the case of having multiple implementations?


> Implement a basic authentication mechanism for the new protocol
> ---
>
> Key: GEODE-3412
> URL: https://issues.apache.org/jira/browse/GEODE-3412
> Project: Geode
>  Issue Type: New Feature
>  Components: client/server
>Reporter: Brian Rowe
>
> Implement a simple username/password authentication for the new protocol.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (GEODE-3416) Reduce blocking for SocketCloser.asyncClose

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-3416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16127552#comment-16127552
 ] 

ASF subversion and git services commented on GEODE-3416:


Commit 2caddb0dc71649e801bf7c3e763782c891de7317 in geode's branch 
refs/heads/feature/GEODE-3416 from [~ukohlmeyer]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=2caddb0 ]

GEODE-3416: spotlessApply


> Reduce blocking for SocketCloser.asyncClose 
> 
>
> Key: GEODE-3416
> URL: https://issues.apache.org/jira/browse/GEODE-3416
> Project: Geode
>  Issue Type: Bug
>  Components: client/server
>Affects Versions: 1.1.0, 1.1.1, 1.2.0, 1.2.1
>Reporter: Udo Kohlmeyer
>Assignee: Udo Kohlmeyer
> Fix For: 1.3.0
>
>
> In the SocketCloser.asyncClose method, there is a synchronization block 
> around at HashMap. This synchronization will cause an effective 
> single-threaded processing capability when closing sockets. this effect 
> becomes more evident with a high number of clients.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (GEODE-3314) OldGen heap usage grows without increase in data size, large number of DLockTokens

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-3314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16127544#comment-16127544
 ] 

ASF GitHub Bot commented on GEODE-3314:
---

Github user asfgit closed the pull request at:

https://github.com/apache/geode/pull/683


> OldGen heap usage grows without increase in data size, large number of 
> DLockTokens
> --
>
> Key: GEODE-3314
> URL: https://issues.apache.org/jira/browse/GEODE-3314
> Project: Geode
>  Issue Type: Bug
>  Components: distributed lock service
>Reporter: Udo Kohlmeyer
>Assignee: Galen O'Sullivan
> Fix For: 1.2.1
>
>
> When using Global Replicate regions, the DLockTokens are not correctly 
> cleaned up, causing a memory leak.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (GEODE-3416) Reduce blocking for SocketCloser.asyncClose

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-3416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16127507#comment-16127507
 ] 

ASF subversion and git services commented on GEODE-3416:


Commit 170e333a9f07c74297d0875ef244de118a656bd0 in geode's branch 
refs/heads/feature/GEODE-3416 from [~ukohlmeyer]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=170e333 ]

GEODE-3416: Moved the clearing of the map to be outside of the loop
in the close() method
Amended the threadPoolExecutor to set the correct thread timeout. Using
th asyncClosePoolKeepAlive instead of asyncCloseWait.


> Reduce blocking for SocketCloser.asyncClose 
> 
>
> Key: GEODE-3416
> URL: https://issues.apache.org/jira/browse/GEODE-3416
> Project: Geode
>  Issue Type: Bug
>  Components: client/server
>Affects Versions: 1.1.0, 1.1.1, 1.2.0, 1.2.1
>Reporter: Udo Kohlmeyer
>Assignee: Udo Kohlmeyer
> Fix For: 1.3.0
>
>
> In the SocketCloser.asyncClose method, there is a synchronization block 
> around at HashMap. This synchronization will cause an effective 
> single-threaded processing capability when closing sockets. this effect 
> becomes more evident with a high number of clients.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (GEODE-3444) Intermittent ClientServerJTADUnitTest failure

[Nick Reich (JIRA)]

Nick Reich created GEODE-3444:
-

 Summary: Intermittent ClientServerJTADUnitTest failure
 Key: GEODE-3444
 URL: https://issues.apache.org/jira/browse/GEODE-3444
 Project: Geode
  Issue Type: Bug
  Components: transactions
Reporter: Nick Reich


A test in ClientServerJTADUnitTest is failing in an automated test pipeline. I 
have tried to reproduce the issue locally, but was unsuccessful over five 
attempts. The wait timeout suggests a possible race condition.

{code}
```org.apache.geode.internal.jta.ClientServerJTADUnitTest > 
testClientTXStateStubBeforeCompletion FAILED
org.awaitility.core.ConditionTimeoutException: Condition with lambda 
expression in org.apache.geode.internal.jta.ClientServerJTADUnitTest was not 
fulfilled within 30 seconds.
at org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:104)
at 
org.awaitility.core.CallableCondition.await(CallableCondition.java:79)
at 
org.awaitility.core.CallableCondition.await(CallableCondition.java:27)
at org.awaitility.core.ConditionFactory.until(ConditionFactory.java:809)
at org.awaitility.core.ConditionFactory.until(ConditionFactory.java:785)
at 
org.apache.geode.internal.jta.ClientServerJTADUnitTest.testClientTXStateStubBeforeCompletion(ClientServerJTADUnitTest.java:104)```
{code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (GEODE-3444) Intermittent ClientServerJTADUnitTest failure

[Nick Reich (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-3444?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Nick Reich reassigned GEODE-3444:
-

Assignee: Eric Shu

> Intermittent ClientServerJTADUnitTest failure
> -
>
> Key: GEODE-3444
> URL: https://issues.apache.org/jira/browse/GEODE-3444
> Project: Geode
>  Issue Type: Bug
>  Components: transactions
>Reporter: Nick Reich
>Assignee: Eric Shu
>
> A test in ClientServerJTADUnitTest is failing in an automated test pipeline. 
> I have tried to reproduce the issue locally, but was unsuccessful over five 
> attempts. The wait timeout suggests a possible race condition.
> {code}
> ```org.apache.geode.internal.jta.ClientServerJTADUnitTest > 
> testClientTXStateStubBeforeCompletion FAILED
> org.awaitility.core.ConditionTimeoutException: Condition with lambda 
> expression in org.apache.geode.internal.jta.ClientServerJTADUnitTest was not 
> fulfilled within 30 seconds.
> at 
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:104)
> at 
> org.awaitility.core.CallableCondition.await(CallableCondition.java:79)
> at 
> org.awaitility.core.CallableCondition.await(CallableCondition.java:27)
> at 
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:809)
> at 
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:785)
> at 
> org.apache.geode.internal.jta.ClientServerJTADUnitTest.testClientTXStateStubBeforeCompletion(ClientServerJTADUnitTest.java:104)```
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (GEODE-3416) Reduce blocking for SocketCloser.asyncClose

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-3416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16127501#comment-16127501
 ] 

ASF GitHub Bot commented on GEODE-3416:
---

Github user kohlmu-pivotal commented on a diff in the pull request:

https://github.com/apache/geode/pull/702#discussion_r133238599
  
--- Diff: 
geode-core/src/main/java/org/apache/geode/internal/net/SocketCloser.java ---
@@ -96,46 +99,55 @@ public int getMaxThreads() {
 return this.asyncClosePoolMaxThreads;
   }
 
-  private ThreadPoolExecutor getAsyncThreadExecutor(String address) {
-synchronized (asyncCloseExecutors) {
-  ThreadPoolExecutor pool = asyncCloseExecutors.get(address);
-  if (pool == null) {
-final ThreadGroup tg = 
LoggingThreadGroup.createThreadGroup("Socket asyncClose", logger);
-ThreadFactory tf = new ThreadFactory() {
-  public Thread newThread(final Runnable command) {
-Thread thread = new Thread(tg, command);
-thread.setDaemon(true);
-return thread;
-  }
-};
-BlockingQueue workQueue = new 
LinkedBlockingQueue();
-pool = new ThreadPoolExecutor(this.asyncClosePoolMaxThreads, 
this.asyncClosePoolMaxThreads,
-this.asyncClosePoolKeepAliveSeconds, TimeUnit.SECONDS, 
workQueue, tf);
-pool.allowCoreThreadTimeOut(true);
-asyncCloseExecutors.put(address, pool);
+  private ExecutorService getAsyncThreadExecutor(String address) {
+ExecutorService executorService = asyncCloseExecutors.get(address);
+if (executorService == null) {
+  // To be used for pre-1.8 jdk releases.
+  // createThreadPool();
+
+  executorService = 
Executors.newWorkStealingPool(asyncClosePoolMaxThreads);
+
+  ExecutorService previousThreadPoolExecutor =
+  asyncCloseExecutors.putIfAbsent(address, executorService);
+
+  if (previousThreadPoolExecutor != null) {
+executorService.shutdownNow();
+return previousThreadPoolExecutor;
   }
-  return pool;
 }
+return executorService;
+  }
+
+  /**
+   * @deprecated this method is to be used for pre 1.8 jdk.
+   */
+  @Deprecated
+  private void createThreadPool() {
+ExecutorService executorService;
+final ThreadGroup threadGroup =
+LoggingThreadGroup.createThreadGroup("Socket asyncClose", logger);
+ThreadFactory threadFactory = new ThreadFactory() {
+  public Thread newThread(final Runnable command) {
+Thread thread = new Thread(threadGroup, command);
+thread.setDaemon(true);
+return thread;
+  }
+};
+
+executorService = new ThreadPoolExecutor(asyncClosePoolMaxThreads, 
asyncClosePoolMaxThreads,
+asyncCloseWaitTime, asyncCloseWaitUnits, new 
LinkedBlockingQueue<>(), threadFactory);
   }
 
   /**
* Call this method if you know all the resources in the closer for the 
given address are no
* longer needed. Currently a thread pool is kept for each address and 
if you know that an address
* no longer needs its pool then you should call this method.
*/
-  public void releaseResourcesForAddress(String address) {
-synchronized (asyncCloseExecutors) {
-  ThreadPoolExecutor pool = asyncCloseExecutors.get(address);
-  if (pool != null) {
-pool.shutdown();
-asyncCloseExecutors.remove(address);
-  }
-}
-  }
 
-  private boolean isClosed() {
-synchronized (asyncCloseExecutors) {
-  return this.closed;
+  public void releaseResourcesForAddress(String address) {
+ExecutorService executorService = asyncCloseExecutors.remove(address);
+if (executorService != null) {
+  executorService.shutdown();
--- End diff --

ExecutorService.shutdown does protect itself internally with locks, etc.. 
so we don't have to worry about multiple threads calling shutdown on the same 
executor service


> Reduce blocking for SocketCloser.asyncClose 
> 
>
> Key: GEODE-3416
> URL: https://issues.apache.org/jira/browse/GEODE-3416
> Project: Geode
>  Issue Type: Bug
>  Components: client/server
>Affects Versions: 1.1.0, 1.1.1, 1.2.0, 1.2.1
>Reporter: Udo Kohlmeyer
>Assignee: Udo Kohlmeyer
> Fix For: 1.3.0
>
>
> In the SocketCloser.asyncClose method, there is a synchronization block 
> around at HashMap. This synchronization will cause an effective 
> single-threaded processing capability when closing sockets. this effect 
> becomes more evident with a high number of 

[jira] [Commented] (GEODE-3416) Reduce blocking for SocketCloser.asyncClose

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-3416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16127500#comment-16127500
 ] 

ASF GitHub Bot commented on GEODE-3416:
---

Github user kohlmu-pivotal commented on a diff in the pull request:

https://github.com/apache/geode/pull/702#discussion_r133238417
  
--- Diff: 
geode-core/src/main/java/org/apache/geode/internal/net/SocketCloser.java ---
@@ -144,35 +156,22 @@ private boolean isClosed() {
* called then the asyncClose will be done synchronously.
*/
   public void close() {
-synchronized (asyncCloseExecutors) {
+synchronized (closed) {
   if (!this.closed) {
 this.closed = true;
-for (ThreadPoolExecutor pool : asyncCloseExecutors.values()) {
-  pool.shutdown();
-}
-asyncCloseExecutors.clear();
+  } else {
+return;
   }
 }
+for (ExecutorService executorService : asyncCloseExecutors.values()) {
+  executorService.shutdown();
+  asyncCloseExecutors.clear();
--- End diff --

Good catch.


> Reduce blocking for SocketCloser.asyncClose 
> 
>
> Key: GEODE-3416
> URL: https://issues.apache.org/jira/browse/GEODE-3416
> Project: Geode
>  Issue Type: Bug
>  Components: client/server
>Affects Versions: 1.1.0, 1.1.1, 1.2.0, 1.2.1
>Reporter: Udo Kohlmeyer
>Assignee: Udo Kohlmeyer
> Fix For: 1.3.0
>
>
> In the SocketCloser.asyncClose method, there is a synchronization block 
> around at HashMap. This synchronization will cause an effective 
> single-threaded processing capability when closing sockets. this effect 
> becomes more evident with a high number of clients.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (GEODE-3416) Reduce blocking for SocketCloser.asyncClose

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-3416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16127441#comment-16127441
 ] 

ASF GitHub Bot commented on GEODE-3416:
---

Github user WireBaron commented on a diff in the pull request:

https://github.com/apache/geode/pull/702#discussion_r133230527
  
--- Diff: 
geode-core/src/main/java/org/apache/geode/internal/net/SocketCloser.java ---
@@ -96,46 +99,55 @@ public int getMaxThreads() {
 return this.asyncClosePoolMaxThreads;
   }
 
-  private ThreadPoolExecutor getAsyncThreadExecutor(String address) {
-synchronized (asyncCloseExecutors) {
-  ThreadPoolExecutor pool = asyncCloseExecutors.get(address);
-  if (pool == null) {
-final ThreadGroup tg = 
LoggingThreadGroup.createThreadGroup("Socket asyncClose", logger);
-ThreadFactory tf = new ThreadFactory() {
-  public Thread newThread(final Runnable command) {
-Thread thread = new Thread(tg, command);
-thread.setDaemon(true);
-return thread;
-  }
-};
-BlockingQueue workQueue = new 
LinkedBlockingQueue();
-pool = new ThreadPoolExecutor(this.asyncClosePoolMaxThreads, 
this.asyncClosePoolMaxThreads,
-this.asyncClosePoolKeepAliveSeconds, TimeUnit.SECONDS, 
workQueue, tf);
-pool.allowCoreThreadTimeOut(true);
-asyncCloseExecutors.put(address, pool);
+  private ExecutorService getAsyncThreadExecutor(String address) {
+ExecutorService executorService = asyncCloseExecutors.get(address);
+if (executorService == null) {
+  // To be used for pre-1.8 jdk releases.
+  // createThreadPool();
+
+  executorService = 
Executors.newWorkStealingPool(asyncClosePoolMaxThreads);
+
+  ExecutorService previousThreadPoolExecutor =
+  asyncCloseExecutors.putIfAbsent(address, executorService);
+
+  if (previousThreadPoolExecutor != null) {
+executorService.shutdownNow();
+return previousThreadPoolExecutor;
   }
-  return pool;
 }
+return executorService;
+  }
+
+  /**
+   * @deprecated this method is to be used for pre 1.8 jdk.
+   */
+  @Deprecated
+  private void createThreadPool() {
+ExecutorService executorService;
+final ThreadGroup threadGroup =
+LoggingThreadGroup.createThreadGroup("Socket asyncClose", logger);
+ThreadFactory threadFactory = new ThreadFactory() {
+  public Thread newThread(final Runnable command) {
+Thread thread = new Thread(threadGroup, command);
+thread.setDaemon(true);
+return thread;
+  }
+};
+
+executorService = new ThreadPoolExecutor(asyncClosePoolMaxThreads, 
asyncClosePoolMaxThreads,
+asyncCloseWaitTime, asyncCloseWaitUnits, new 
LinkedBlockingQueue<>(), threadFactory);
   }
 
   /**
* Call this method if you know all the resources in the closer for the 
given address are no
* longer needed. Currently a thread pool is kept for each address and 
if you know that an address
* no longer needs its pool then you should call this method.
*/
-  public void releaseResourcesForAddress(String address) {
-synchronized (asyncCloseExecutors) {
-  ThreadPoolExecutor pool = asyncCloseExecutors.get(address);
-  if (pool != null) {
-pool.shutdown();
-asyncCloseExecutors.remove(address);
-  }
-}
-  }
 
-  private boolean isClosed() {
-synchronized (asyncCloseExecutors) {
-  return this.closed;
+  public void releaseResourcesForAddress(String address) {
+ExecutorService executorService = asyncCloseExecutors.remove(address);
+if (executorService != null) {
+  executorService.shutdown();
--- End diff --

This could still race with a thread running the close() method below and 
both could end up calling shutdown on the same service.


> Reduce blocking for SocketCloser.asyncClose 
> 
>
> Key: GEODE-3416
> URL: https://issues.apache.org/jira/browse/GEODE-3416
> Project: Geode
>  Issue Type: Bug
>  Components: client/server
>Affects Versions: 1.1.0, 1.1.1, 1.2.0, 1.2.1
>Reporter: Udo Kohlmeyer
>Assignee: Udo Kohlmeyer
> Fix For: 1.3.0
>
>
> In the SocketCloser.asyncClose method, there is a synchronization block 
> around at HashMap. This synchronization will cause an effective 
> single-threaded processing capability when closing sockets. this effect 
> becomes more evident with a high number of clients.



--
This message was sent by 

[jira] [Commented] (GEODE-3416) Reduce blocking for SocketCloser.asyncClose

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-3416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16127442#comment-16127442
 ] 

ASF GitHub Bot commented on GEODE-3416:
---

Github user WireBaron commented on a diff in the pull request:

https://github.com/apache/geode/pull/702#discussion_r133230687
  
--- Diff: 
geode-core/src/main/java/org/apache/geode/internal/net/SocketCloser.java ---
@@ -144,35 +156,22 @@ private boolean isClosed() {
* called then the asyncClose will be done synchronously.
*/
   public void close() {
-synchronized (asyncCloseExecutors) {
+synchronized (closed) {
   if (!this.closed) {
 this.closed = true;
-for (ThreadPoolExecutor pool : asyncCloseExecutors.values()) {
-  pool.shutdown();
-}
-asyncCloseExecutors.clear();
+  } else {
+return;
   }
 }
+for (ExecutorService executorService : asyncCloseExecutors.values()) {
+  executorService.shutdown();
+  asyncCloseExecutors.clear();
--- End diff --

Shouldn't this be outside the for loop?


> Reduce blocking for SocketCloser.asyncClose 
> 
>
> Key: GEODE-3416
> URL: https://issues.apache.org/jira/browse/GEODE-3416
> Project: Geode
>  Issue Type: Bug
>  Components: client/server
>Affects Versions: 1.1.0, 1.1.1, 1.2.0, 1.2.1
>Reporter: Udo Kohlmeyer
>Assignee: Udo Kohlmeyer
> Fix For: 1.3.0
>
>
> In the SocketCloser.asyncClose method, there is a synchronization block 
> around at HashMap. This synchronization will cause an effective 
> single-threaded processing capability when closing sockets. this effect 
> becomes more evident with a high number of clients.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (GEODE-3386) Create Error type for KeyedErrorResponse and ErrorResponse

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-3386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16127432#comment-16127432
 ] 

ASF GitHub Bot commented on GEODE-3386:
---

Github user asfgit closed the pull request at:

https://github.com/apache/geode/pull/700


> Create Error type for KeyedErrorResponse and ErrorResponse
> --
>
> Key: GEODE-3386
> URL: https://issues.apache.org/jira/browse/GEODE-3386
> Project: Geode
>  Issue Type: Sub-task
>  Components: client/server
>Reporter: Galen O'Sullivan
>
> For logical separation of the new client API, it will be better to have an 
> Error that is contained by ErrorResponse, rather than having 
> KeyedErrorResponse contain an ErrorResponse.
> In pseudo-protobuf,
> {code}
> PutAllResponse {
>   repeated Entry successes = 1,
>   repeated KeyedErrorResponse errors = 2,
> }
> KeyedErrorResponse {
>   Key,
>   ErrorResponse
> }
> ErrorResponse {
>   string
> }
> {code}
> instead,
> {code}
> KeyedErrorResponse {
>   Key,
>   Error,
> }
> {code}
> and 
> {code}
> ErrorResponse {
> Error
> }
> Error {
> string
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (GEODE-2997) New flow: putAll/getAll

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16127437#comment-16127437
 ] 

ASF GitHub Bot commented on GEODE-2997:
---

Github user kohlmu-pivotal commented on the issue:

https://github.com/apache/geode/pull/649
  
@galen-pivotal is this PR active anymore?


> New flow: putAll/getAll
> ---
>
> Key: GEODE-2997
> URL: https://issues.apache.org/jira/browse/GEODE-2997
> Project: Geode
>  Issue Type: Sub-task
>  Components: client/server
>Reporter: Brian Baynes
>
> Create proto message definitions and op handler for putAll/getAll messages.
> Client should be able to complete putAll/getAll of primitives and JSON with 
> response.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (GEODE-3386) Create Error type for KeyedErrorResponse and ErrorResponse

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-3386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16127431#comment-16127431
 ] 

ASF subversion and git services commented on GEODE-3386:


Commit a3c0ebaf0d0246b45900bee257b7893cf3be5dba in geode's branch 
refs/heads/develop from [~ukohlmeyer]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=a3c0eba ]

GEODE-3386: This now closes #700


> Create Error type for KeyedErrorResponse and ErrorResponse
> --
>
> Key: GEODE-3386
> URL: https://issues.apache.org/jira/browse/GEODE-3386
> Project: Geode
>  Issue Type: Sub-task
>  Components: client/server
>Reporter: Galen O'Sullivan
>
> For logical separation of the new client API, it will be better to have an 
> Error that is contained by ErrorResponse, rather than having 
> KeyedErrorResponse contain an ErrorResponse.
> In pseudo-protobuf,
> {code}
> PutAllResponse {
>   repeated Entry successes = 1,
>   repeated KeyedErrorResponse errors = 2,
> }
> KeyedErrorResponse {
>   Key,
>   ErrorResponse
> }
> ErrorResponse {
>   string
> }
> {code}
> instead,
> {code}
> KeyedErrorResponse {
>   Key,
>   Error,
> }
> {code}
> and 
> {code}
> ErrorResponse {
> Error
> }
> Error {
> string
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (GEODE-3386) Create Error type for KeyedErrorResponse and ErrorResponse

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-3386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16127429#comment-16127429
 ] 

ASF subversion and git services commented on GEODE-3386:


Commit bfbe3e5649158f45f797efcc389f77de88ddaf5a in geode's branch 
refs/heads/develop from [~amurmann]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=bfbe3e5 ]

GEODE-3386 - Make KeyedErrorResponse & ErrorResponse siblings


> Create Error type for KeyedErrorResponse and ErrorResponse
> --
>
> Key: GEODE-3386
> URL: https://issues.apache.org/jira/browse/GEODE-3386
> Project: Geode
>  Issue Type: Sub-task
>  Components: client/server
>Reporter: Galen O'Sullivan
>
> For logical separation of the new client API, it will be better to have an 
> Error that is contained by ErrorResponse, rather than having 
> KeyedErrorResponse contain an ErrorResponse.
> In pseudo-protobuf,
> {code}
> PutAllResponse {
>   repeated Entry successes = 1,
>   repeated KeyedErrorResponse errors = 2,
> }
> KeyedErrorResponse {
>   Key,
>   ErrorResponse
> }
> ErrorResponse {
>   string
> }
> {code}
> instead,
> {code}
> KeyedErrorResponse {
>   Key,
>   Error,
> }
> {code}
> and 
> {code}
> ErrorResponse {
> Error
> }
> Error {
> string
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (GEODE-3423) Provide support for running parallel docker builds in Jenkins

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-3423?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16127347#comment-16127347
 ] 

ASF subversion and git services commented on GEODE-3423:


Commit d295876d601300e52515193efcf5fd8549f10dbb in geode's branch 
refs/heads/develop from [~jens.deppe]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=d295876 ]

GEODE-3423: Have Gradle set LOCAL_USER_ID

- This is needed because Jenkins' Gradle job doesn't seem to provide the
  ability to pass environment variables in.


> Provide support for running parallel docker builds in Jenkins
> -
>
> Key: GEODE-3423
> URL: https://issues.apache.org/jira/browse/GEODE-3423
> Project: Geode
>  Issue Type: Improvement
>  Components: build
>Reporter: Jens Deppe
>
> Provide the necessary Dockerfile components to build a docker container which 
> can be used for parallel dunit builds in a jenkins environment.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (GEODE-3443) Format target should only update C++ directories

[Jacob S. Barrett (JIRA)]

Jacob S. Barrett created GEODE-3443:
---

 Summary: Format target should only update C++ directories
 Key: GEODE-3443
 URL: https://issues.apache.org/jira/browse/GEODE-3443
 Project: Geode
  Issue Type: Task
  Components: native client
Reporter: Jacob S. Barrett


After the re-org of sources the format target search all directories and 
updates all C++ including any that may be under build directories like 
dependencies. Update the target to only search the few C++ sources.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)