Re: geode-native ipv6

[Jacob Barrett]

You might start by updating the framework’s Cluster class accept a hostname 
that would be used for both Locator and Server classes. Then in an IPv6 tests 
you could set the hostname to '0:0:0:0:0:0:0:1’, which is the loopback address. 
In theory this should work. 

In Cluster.hpp:
Look for all the NamedType definitions and add.
using BindAddress = NamedType;
Plumb it though to Locator and Server.

In your test:
Cluster cluster(…, BindAddress(“0:0:0:0:0:0:0:1"));


Even more simple may be to not allow the hostname but just a flag for IPv4 or 
IPv6 and internally set the hostname to the IPv6 or IPv6 localhost address.

In Cluster.hpp:
using UseIpv6 = NamedType;
Then plumb that through to Locator and Server and select the appropriate 
loopback address.

In your test:
Cluster cluster(…, UseIpv6(true));


I can help you in more detail if you want. 

-Jake


> On Aug 21, 2019, at 12:34 AM, Mario Ivanac  wrote:
> 
> Hi,
> 
> 
> Can you help me, how to simulate ipv6 in new integration test framework?
> 
> 
> BR,
> 
> Mario
> 
> 
> Šalje: Jacob Barrett 
> Poslano: 14. kolovoza 2019. 21:00:35
> Prima: dev@geode.apache.org 
> Predmet: Re: geode-native ipv6
> 
> Can you build an integration test in the new framework?
> 
>> On Aug 14, 2019, at 11:25 AM, Mario Ivanac  wrote:
>> 
>> Hi,
>> 
>> 
>> created https://issues.apache.org/jira/browse/GEODE-7086, and PR with code 
>> impacts.
>> 
>> Proposed solution was tried on IPv6 environment, and basic operations 
>> (PUT/GET) were successful.
>> 
>> Additional test needed.
>> 
>> 
>> BR,
>> 
>> Mario
>> 
>> 
>> Šalje: Blake Bender 
>> Poslano: 9. kolovoza 2019. 0:03:32
>> Prima: dev@geode.apache.org 
>> Predmet: Re: geode-native ipv6
>> 
>> This chunk of code in the client handshake code leads me to believe it is
>> still IPv4 only.  Won't say it's definitive, cause I'm not 100% certain
>> hostaddr is used on the server side, but still...
>> 
>> // writing first 4 bytes of the address. This will be same until
>> // IPV6 support is added in the client
>> uint32_t temp;
>> memcpy(, hostAddr, 4);
>> m_memID.writeInt(static_cast(temp));
>> 
>> 
>>> On Thu, Aug 8, 2019 at 1:18 PM Jacob Barrett  wrote:
>>> 
>>> We are on the latest ACE.
>>> 
 On Aug 8, 2019, at 9:56 AM, Mark Hanson  wrote:
 
 The latest ACE framework seems to have support, but I don’t know how far
>>> off latest we are. I don’t think we test anything in an IPv6 context, so I
>>> would say no that we don’t officially support it in the client. Given some
>>> time, I could do some testing..
 
 Thanks,
 Mark
 
> On Aug 8, 2019, at 7:35 AM, Blake Bender  wrote:
> 
> I'm sure someone will chime in with a more definitive answer, but I'm
> pretty certain the answer is no, sorry.
> 
> Thanks,
> 
> Blake
> 
> 
>> On Thu, Aug 8, 2019 at 4:28 AM Mario Ivanac 
>>> wrote:
>> 
>> Hi,
>> 
>> 
>> can you tell me does geode-native client support ipv6?
>> 
>> 
>> BR,
>> 
>> Mario
>> 
 
>>> 

Re: [DISCUSS] what region types to support in the new management rest api

[Darrel Schneider]

Given the current types that gfsh supports, I don't see that it will be
lots of validation. We have the redundancy level to validate for the
REDUNDANT types. And we have HEAP_LRU and OVERFLOW to validate. That is it.
The only other thing is the partition only attributes should be rejected
when creating a replicate. I think we should just support the types "gfsh
create region" does.

On Tue, Aug 20, 2019 at 7:50 PM Jinmei Liao  wrote:

> Maybe to clarify what I said before (which was certainly unclear ), I am
> not saying we only allow users to create limited set of types of region, we
> COULD still support all of them, but we should not limit ourselves to the
> current ways of doing things. Currently, a flat model of region
> configuration which holds a type and all the possible attributes any type
> of region can have, could lead to these problems:
> 1. the type may be contradictory/redundant to a particular property:
>   for example, the type could "PARTITION_REDUNDANT", but the
> redundantCopies is set to be 0. And the type could be "PARTITION_OVERFLOW",
> but the eviction action is set to be "LOCAL_DESTROY". To avoid this, we
> will need to do a lot of front end validation in order to accept this
> configuration, which is possible to do, but is it really necessary? Should
> we somehow limit the type to something that really indicate the "type"
> instead of just a shortcut that actually sets a set of attributes.
>
> 2. the object can hold lots of unnecessary attributes that only pertains to
> a particular type
> for example, redundantCopies doesn't really apply to replicate regions, but
> it's there for you to configure.
>
> Just some more food for thought.
>
>
>
>
> On Tue, Aug 20, 2019 at 7:34 PM Charlie Black  wrote:
>
> > Yes it is common for 0,1 and 2.   3 enters into gray space of is the cost
> > of redundancy worth it.
> >
> > So voting for exposing the number of copies to be the same as Apache
> Geode
> > Java API.
> >
> > Charlie
> >
> > On Tue, Aug 20, 2019 at 11:38 AM Darrel Schneider  >
> > wrote:
> >
> > > The shortcuts support partitioned regions with 0 and 1 redundant
> copies.
> > Is
> > > redundancies greater than 1 common enough for the rest management api
> to
> > > support it?
> > >
> > > On Tue, Aug 20, 2019 at 11:27 AM Jacob Barrett 
> > > wrote:
> > >
> > > > +1 to Alexander’s statement.
> > > >
> > > > Also, initial revisions need not be feature parity. For us on the
> > common
> > > > use cases. It’s sounds like an advanced use case to have proxy
> regions
> > on
> > > > the server so focus on the common partitioned and replicated first
> for
> > > the
> > > > initial release.
> > > >
> > > > -jake
> > > >
> > > > > On Aug 20, 2019, at 11:07 AM, Alexander Murmann <
> amurm...@apache.org
> > >
> > > > wrote:
> > > > >
> > > > > Hey folks, I want to make sure that any other's product's roadmaps
> > have
> > > > no
> > > > > impact on any decisions we make about Apache Geode.
> > > > >
> > > > > Thanks!
> > > > >
> > > > > On Tue, Aug 20, 2019 at 10:45 AM Darrel Schneider <
> > > dschnei...@pivotal.io
> > > > >
> > > > > wrote:
> > > > >
> > > > >> Is "group" support on the PCC roadmap or is the plan for the
> members
> > > of
> > > > a
> > > > >> cluster to always be uniform?
> > > > >>
> > > > >>> On Tue, Aug 20, 2019 at 9:56 AM Jinmei Liao 
> > > wrote:
> > > > >>>
> > > > >>> So, sound like we still need to support *PROXY types. It's OK to
> > drop
> > > > >>> support for LOCAL* region types in management rest API?
> > > > >>>
> > > > >>> Also, regarding existing region shortcuts, we are also
> > experimenting
> > > > >> using
> > > > >>> different object types to represent different types of region,
> for
> > > > >> example,
> > > > >>> redundantCopies property should only exists in partition regions.
> > > > Instead
> > > > >>> of having a flat object that could have a type of any of these
> > values
> > > > and
> > > > >>> holds all sorts of properties that may/may not make sense for
> that
> > > > type,
> > > > >>> should just have a factory method that given these region
> > shortcuts,
> > > we
> > > > >>> would return a specific region object that's determined by this
> > type?
> > > > >>>
> > > >  On Tue, Aug 20, 2019 at 8:15 AM Jens Deppe 
> > > wrote:
> > > > 
> > > >  Currently, when deployed to the cloud (aka PCC) there is no
> > ability
> > > > >> for a
> > > >  user to group members thus it is also not possible to create
> > regions
> > > > >> (via
> > > >  gfsh at least) that are separated by groups. Typically one would
> > > > >> create a
> > > >  PROXY region against one group and the PARTITION region against
> > > > another
> > > >  group. However, without the ability to assign groups, that is
> not
> > > > >>> possible.
> > > > 
> > > >  --Jens
> > > > 
> > > >  On Tue, Aug 20, 2019 at 7:46 AM Michael Stolz <
> mst...@pivotal.io>
> > > > >> wrote:
> > > > 
> > > > > I know that lots of folks use PROXY 

Re: Rat check reporting error in travis-ci for geode-native

[Dan Smith]

Hi Helena,

I think the problem is that rat is currently broken on geode-native
develop.

-Dan

On Wed, Aug 21, 2019 at 2:55 PM Helena Bales  wrote:

> Hi Alberto,
>
> If you have added a file as part of your PR, please add the header as a
> commit to your working branch and add that as part of the same PR. Your
> branch should be able to pass a build, spotlessCheck, and unit tests as a
> prerequisite for making a pull request.
>
> Please follow up here if you have more questions.
> Thank you,
> Helena Bales
>
> On Tue, Aug 20, 2019 at 7:40 AM Alberto Gomez 
> wrote:
>
> > Hi,
> >
> > I sent a PR for the geode-native repo and the travis-ci is reporting a
> > Rat error on the following file:
> >
> > ./packer/windows/install-doxygen.ps1
> >
> > The reason is that the copyright header is not included in it. I could
> > add it in my PR but I guess it would be more convenient if this is fixed
> > on a independent commit by someone working on it.
> >
> > Could anyone take care of it?
> >
> > Thanks,
> >
> > - Alberto G.
> >
> >
> >
>

Re: Rat check reporting error in travis-ci for geode-native

[Helena Bales]

Hi Alberto,

If you have added a file as part of your PR, please add the header as a
commit to your working branch and add that as part of the same PR. Your
branch should be able to pass a build, spotlessCheck, and unit tests as a
prerequisite for making a pull request.

Please follow up here if you have more questions.
Thank you,
Helena Bales

On Tue, Aug 20, 2019 at 7:40 AM Alberto Gomez 
wrote:

> Hi,
>
> I sent a PR for the geode-native repo and the travis-ci is reporting a
> Rat error on the following file:
>
> ./packer/windows/install-doxygen.ps1
>
> The reason is that the copyright header is not included in it. I could
> add it in my PR but I guess it would be more convenient if this is fixed
> on a independent commit by someone working on it.
>
> Could anyone take care of it?
>
> Thanks,
>
> - Alberto G.
>
>
>

Failed: apache/geode-native#2053 (release/1.9.1 - add53da)

[Travis CI]

Build Update for apache/geode-native
-

Build: #2053
Status: Failed

Duration: 1 hr, 34 mins, and 45 secs
Commit: add53da (release/1.9.1)
Author: Dave Barnes
Message: User Guide: Add a link to the official XSD declarative cache schema

View the changeset: https://github.com/apache/geode-native/compare/release/1.9.1

View the full build log and details: 
https://travis-ci.org/apache/geode-native/builds/574986579?utm_medium=notification_source=email

--

You can unsubscribe from build emails from the apache/geode-native repository 
going to 
https://travis-ci.org/account/preferences/unsubscribe?repository=11948127_medium=notification_source=email.
Or unsubscribe from *all* email updating your settings at 
https://travis-ci.org/account/preferences/unsubscribe?utm_medium=notification_source=email.
Or configure specific recipients for build notifications in your .travis.yml 
file. See https://docs.travis-ci.com/user/notifications.

Errored: apache/geode-examples#338 (release/1.9.1 - 4eb6b07)

[Travis CI]

Build Update for apache/geode-examples
-

Build: #338
Status: Errored

Duration: 13 secs
Commit: 4eb6b07 (release/1.9.1)
Author: Owen Nichols
Message: Upgraded version number for releasing 1.9.1

View the changeset: https://github.com/apache/geode-examples/commit/4eb6b0763402

View the full build log and details: 
https://travis-ci.org/apache/geode-examples/builds/574985988?utm_medium=notification_source=email

--

You can unsubscribe from build emails from the apache/geode-examples repository 
going to 
https://travis-ci.org/account/preferences/unsubscribe?repository=11483039_medium=notification_source=email.
Or unsubscribe from *all* email updating your settings at 
https://travis-ci.org/account/preferences/unsubscribe?utm_medium=notification_source=email.
Or configure specific recipients for build notifications in your .travis.yml 
file. See https://docs.travis-ci.com/user/notifications.

Re: [DISCUSS] Improvements on client function execution API

[Anilkumar Gingade]

Just to be clear between java and native-client api:

- Read timeout in function execution Java client API - This is to change
the java client behavior

And following are the native client problems and solution applies to
native-client?
- Timeout in ResultCollector::getResult() and Execution::execute() blocking

-Anil.


On Wed, Aug 21, 2019 at 8:49 AM Alberto Gomez 
wrote:

> Hi,
>
> I have just added the following proposal in the wiki for discussion and
> would like to get feedback from the community.
>
>
> https://cwiki.apache.org/confluence/display/GEODE/%5BDiscussion%5D+Improvements+on+client+Function+execution+API
>
> Problem
>
> The client API for function execution is inconsistent in the following
> aspects:
>
> 1.Read timeout in function execution client API
>
> The client API for Function execution allows to set a timeout to wait for
> the execution of a function.
>
> Setting this timeout has the effect of setting a read timeout in the
> socket. If the timeout expires during the execution of a function before
> data has been received, the connection is closed and if the number of
> retries is reached, the execute method throws an exception.
>
> Nevertheless, how this timeout is set is not uniform across the different
> clients:
>
>   *   In the native C++ and C# clients, the timeout can be set on a per
> function execution basis by passing the timeout to the Execution::execute()
> method.
>   *   In the Java API, the timeout can only be set globally by a system
> property when starting the client process.
>
> 2. Timeout in ResultCollector::getResult()
>
> Apart from the timeout on the function execution, the client API offers
> the possibility of setting a timeout on the getResult() method of the
> ResultCollector object returned by the Execution::execute() method.
>
> Given that this method is blocking when invoked from a client (until all
> results have been received) then the setting of this timeout has no effect
> at all. In fact, the DefaultResultCollector in the Java API just ignores
> the value of the timeout.
>
> Note that this timeout in the ResultCollector::getResult() method is
> useful when used inside a peer as function invocations are not blocking.
>
> 3. Blocking  Execution::execute()
>
> As mentioned above the Execution::execute() method behavior is different
> when invoked from clients than from peers. When invoked from clients it is
> blocking until all results are received while when invoked from peers it is
> non-blocking and the ResultCollector::getResult() method is used to wait to
> get all the results.
>
> This is not explicit in the documentation of the interface and it has
> already been captured in the following ticket:
> https://issues.apache.org/jira/browse/GEODE-3817
>
> Anti-Goals
>
> -
>
> Solution
>
> In order to make the API more coherent two actions are proposed:
>
> 1. Read timeout in function execution Java client API
>
> Add two new Execution::execute() methods in the Java client to offer the
> possibility to set the timeout for the socket just as it is done in the C++
> and C# clients.
>
> This action is simple to implement and there are no adverse effects
> attached to it.
>
> 2. Timeout in ResultCollector::getResult() and Execution::execute()
> blocking
>
> Regarding the timeout in the ResultCollector::getResult() method problem
> and the blocking/non-blocking confusion for Execution::execute() two
> alternatives are considered:
>
> a) Remove the possibility of setting a timeout on the
> ResultCollector::getResult() method on the client side as with the current
> client implementation it is useless. This could be done by removing the
> method with the timeout parameter from the public API.
>
> It would be advisable to make explicit in the documentation that the
> getResult() method does not wait for results to arrive as that should have
> already been done in the Execution::execute() invocation.
>
> This alternative is very simple and would keep things pretty much as they
> are today.
>
> b) Transform the Execution::execute() method on the client side into a
> non-blocking method.
>
> This alternative is more complex and requires changes in all the clients.
> Apart from that it has implications on the public client API it requires
> moving the exceptions offered currently by the Execution::execute() method
> to the ResultCollector::getResult() and new threads will have to be managed.
>
> An outline of a possible implementation for option b) would be:
>
>   *   Instead of invoking the ServerRegionProxy::executeFunction()
> directly as it is done today, create a Future that invokes this method and
> returns the resultCollector passed as parameter.
>   *   Create a new class (ProxyResultCollector) that will hold a Future
> for a ResultCollector and whose getResult() methods implementation would be
> something like:
>
> return this.future.get().getResult();
>
>   *   After creating the future that invokes
> ServerRegionFunction::executeFunction() create an 

New release branch for Apache Geode 1.9.1

[Owen Nichols]

Hello Geode Dev Community,

We have created a new release branch for Apache Geode 1.9.1 - "release/1.9.1"

Currently it has the two fixes proposed previously[1][2] on the dev list, as 
well as necessary CI updates for pipeline[3].

Please do review and raise any concern with the release branch.
If no concerns are raised, we will start with the voting for the release 
candidate soon.

Regards
Owen Nichols & Kirk Lund

[1] 
https://lists.apache.org/thread.html/4a7a6bc24ad7b9eb535fa3f411b4a5fdc2fc33fe5da76d259f0ebfce@%3Cdev.geode.apache.org%3E
 

 
[2] 
https://lists.apache.org/thread.html/21923df85db9c6a30b177f134bba776043df6ec19e66aad97bc7ba55@%3Cdev.geode.apache.org%3E
 

 
[3] 
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-release-1-9-1-main?groups=complete
 

 

Integration tests on Windows in 1.9.0

[Kirk Lund]

There are several integration tests failing on Windows in our potential
branch for 1.9.1.

*Does anyone know if integration tests were GREEN on Windows in 1.9.0?*

AvailablePortHelperIntegrationTest and BackupIntegrationTest seem to fail
consistently on Windows. ServerLauncherRemoteFileIntegrationTest fails
intermittently.

These failures are not caused by any of the log4j related cherry-picks, and
I doubt the ssl changes would cause these.

*1) AvailablePortHelperIntegrationTest*
org.apache.geode.internal.AvailablePortHelperIntegrationTest >
initializeUniquePortRange_willReturnUniquePortsForUniqueRanges(true) [0]
FAILED
...
not to contain
 <[50075]>
but found
 <[50075]>
at
org.apache.geode.internal.AvailablePortHelperIntegrationTest.initializeUniquePortRange_willReturnUniquePortsForUniqueRanges(AvailablePortHelperIntegrationTest.java:287)

*2) BackupIntegrationTest*
org.apache.geode.internal.cache.backup.BackupIntegrationTest >
testBackupAndRecover FAILED
java.lang.AssertionError: Restore scripts [] expected:<1> but was:<0>
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotEquals(Assert.java:834)
at org.junit.Assert.assertEquals(Assert.java:645)
at
org.apache.geode.internal.cache.backup.BackupIntegrationTest.restoreBackup(BackupIntegrationTest.java:443)
at
org.apache.geode.internal.cache.backup.BackupIntegrationTest.testBackupAndRecover(BackupIntegrationTest.java:160)

org.apache.geode.internal.cache.backup.BackupIntegrationTest >
testIncrementalBackupAndRecover FAILED
java.lang.AssertionError: Restore scripts [] expected:<1> but was:<0>
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotEquals(Assert.java:834)
at org.junit.Assert.assertEquals(Assert.java:645)
at
org.apache.geode.internal.cache.backup.BackupIntegrationTest.restoreBackup(BackupIntegrationTest.java:443)
at
org.apache.geode.internal.cache.backup.BackupIntegrationTest.testIncrementalBackupAndRecover(BackupIntegrationTest.java:235)

*3) ServerLauncherRemoteFileIntegrationTest*
org.apache.geode.distributed.ServerLauncherRemoteFileIntegrationTest >
startDeletesStaleControlFiles FAILED
org.awaitility.core.ConditionTimeoutException: Assertion condition
defined as a lambda expression in
org.apache.geode.distributed.ServerLauncherRemoteIntegrationTestCase
expected:<[online]> but was:<[not responding]> within 300 seconds.

Caused by:
org.junit.ComparisonFailure: expected:<[online]> but was:<[not
responding]>

[DISCUSS] Improvements on client function execution API

[Alberto Gomez]

Hi,

I have just added the following proposal in the wiki for discussion and would 
like to get feedback from the community.

https://cwiki.apache.org/confluence/display/GEODE/%5BDiscussion%5D+Improvements+on+client+Function+execution+API

Problem

The client API for function execution is inconsistent in the following aspects:

1.Read timeout in function execution client API

The client API for Function execution allows to set a timeout to wait for the 
execution of a function.

Setting this timeout has the effect of setting a read timeout in the socket. If 
the timeout expires during the execution of a function before data has been 
received, the connection is closed and if the number of retries is reached, the 
execute method throws an exception.

Nevertheless, how this timeout is set is not uniform across the different 
clients:

  *   In the native C++ and C# clients, the timeout can be set on a per 
function execution basis by passing the timeout to the Execution::execute() 
method.
  *   In the Java API, the timeout can only be set globally by a system 
property when starting the client process.

2. Timeout in ResultCollector::getResult()

Apart from the timeout on the function execution, the client API offers the 
possibility of setting a timeout on the getResult() method of the 
ResultCollector object returned by the Execution::execute() method.

Given that this method is blocking when invoked from a client (until all 
results have been received) then the setting of this timeout has no effect at 
all. In fact, the DefaultResultCollector in the Java API just ignores the value 
of the timeout.

Note that this timeout in the ResultCollector::getResult() method is useful 
when used inside a peer as function invocations are not blocking.

3. Blocking  Execution::execute()

As mentioned above the Execution::execute() method behavior is different when 
invoked from clients than from peers. When invoked from clients it is blocking 
until all results are received while when invoked from peers it is non-blocking 
and the ResultCollector::getResult() method is used to wait to get all the 
results.

This is not explicit in the documentation of the interface and it has already 
been captured in the following ticket: 
https://issues.apache.org/jira/browse/GEODE-3817

Anti-Goals

-

Solution

In order to make the API more coherent two actions are proposed:

1. Read timeout in function execution Java client API

Add two new Execution::execute() methods in the Java client to offer the 
possibility to set the timeout for the socket just as it is done in the C++ and 
C# clients.

This action is simple to implement and there are no adverse effects attached to 
it.

2. Timeout in ResultCollector::getResult() and Execution::execute() blocking

Regarding the timeout in the ResultCollector::getResult() method problem and 
the blocking/non-blocking confusion for Execution::execute() two alternatives 
are considered:

a) Remove the possibility of setting a timeout on the 
ResultCollector::getResult() method on the client side as with the current 
client implementation it is useless. This could be done by removing the method 
with the timeout parameter from the public API.

It would be advisable to make explicit in the documentation that the 
getResult() method does not wait for results to arrive as that should have 
already been done in the Execution::execute() invocation.

This alternative is very simple and would keep things pretty much as they are 
today.

b) Transform the Execution::execute() method on the client side into a 
non-blocking method.

This alternative is more complex and requires changes in all the clients. Apart 
from that it has implications on the public client API it requires moving the 
exceptions offered currently by the Execution::execute() method to the 
ResultCollector::getResult() and new threads will have to be managed.

An outline of a possible implementation for option b) would be:

  *   Instead of invoking the ServerRegionProxy::executeFunction() directly as 
it is done today, create a Future that invokes this method and returns the 
resultCollector passed as parameter.
  *   Create a new class (ProxyResultCollector) that will hold a Future for a 
ResultCollector and whose getResult() methods implementation would be something 
like:

return this.future.get().getResult();

  *   After creating the future that invokes 
ServerRegionFunction::executeFunction() create an instance of 
ProxyResultCollector and call the setFuture() method on it passing the just 
created future and return it.

Changes and Additions to Public Interfaces

Regarding the first action, the Java client API would grow by adding the 
following two methods:

  *

ResultCollector execute(String functionId, long timeout, TimeUnit 
unit) throws FunctionException;

  *

ResultCollector execute(Function function, long timeout, TimeUnit 
unit) throws FunctionException;

Depending on the option selected on the second action:

  *   

Re: Need help: Jetty dunit tests blocking creation of geode-log4j

[Jens Deppe]

I can work with you on this if you're still blocked.

--Jens

On Tue, Aug 20, 2019 at 4:12 PM Kirk Lund  wrote:

> Does anyone know how to debug geode-assembly Jetty dunit tests that fail to
> launch modify_war?
>
> It passes 100% locally in intellij and with gradle cli. It only fails in
> concourse PR precheckin.
>
> Right now, this is the last thing blocking me from submitting a non-draft
> PR to move all log4j-core code from geode-core to geode-log4j. This is
> blocking the creation of geode-log4j.
>
> The only changes in my branch are moving all log4j-core code from
> geode-core to geode-log4j.
>
> If anyone else wants to see this change make it to develop, then I need
> help!
>
> When the test tries to execute modify_war, it fails with the following
> output and stack trace. No other info is available for debugging as
> apparently this kills the gradle daemon.
>
> Failed PR precheckin dunit job:
> https://concourse.apachegeode-ci.info/builds/88240
> PR: https://github.com/apache/geode/pull/3914
>
> > Task :geode-assembly:distributedTest
>
> org.apache.geode.session.tests.Jetty9CachingClientServerTest >
> containersShouldHavePersistentSessionData FAILED
> java.lang.RuntimeException: Something very bad happened when trying to
> start container
>
> JETTY9_client-server_containersShouldHavePersistentSessionData_0_a6ebd229-072b-47db-a9bf-ca3713175f05_
>
> Caused by:
> java.lang.RuntimeException: Something very bad happened to this
> container when starting. Check the cargo_logs folder for container logs.
>
> Caused by:
> java.io.IOException: Unable to run modify_war script, command:
>
> [/tmp/geode_container_install17845041006471328987/cargo_modules/Apache_Geode_Modules-1.11.0-SNAPSHOT-AppServer/bin/modify_war,
> -J, -Xmx2096m, -w,
>
> /home/geode/geode/geode-assembly/build/distributedTest254/../../../extensions/session-testing-war/build/libs/session-testing-war.war,
> -t, client-server, -o,
>
> /tmp/geode_container_install17845041006471328987/cargo_wars/JETTY9_client-server_containersShouldHavePersistentSessionData_0_a6ebd229-072b-47db-a9bf-ca3713175f053692095078744488223.war,
> -p, gemfire.cache.enable_local_cache=true, -p,
>
> gemfire.property.log-file=/home/geode/geode/geode-assembly/build/distributedTest254/cargo_logs/JETTY9_client-server_containersShouldHavePersistentSessionData_0_a6ebd229-072b-47db-a9bf-ca3713175f05/gemfire.log,
> -p,
>
> gemfire.property.cache-xml-file=/home/geode/geode/geode-assembly/build/distributedTest254/cargo_logs/JETTY9_client-server_containersShouldHavePersistentSessionData_0_a6ebd229-072b-47db-a9bf-ca3713175f05/cache-client.xml]
> log file:
> ERROR: Error updating web.xml
> ng: INFO: os::commit_memory(0x00077d00, 2147483648, 0)
> failed; error='Not enough space' (errno=12)
>

Not mixing cache.xml and cluster configuration

[Mario Kevo]

Hi Geode dev,

I've opened ticket about mixing cache.xml and cluster configuration 
https://issues.apache.org/jira/browse/GEODE-7025

According to some comments on tickets(
https://issues.apache.org/jira/browse/GEODE-6772?focusedCommentId=16869670=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16869670
) and testing I think that we need to document this behaviors.

I add two proposals to the ticket, so we can proceed with one of them
if you agree, or if you have any other idea to resolve this problem.

Thanks and BR,
Mario

Re: geode-native ipv6

[Mario Ivanac]

Hi,


Can you help me, how to simulate ipv6 in new integration test framework?


BR,

Mario


Šalje: Jacob Barrett 
Poslano: 14. kolovoza 2019. 21:00:35
Prima: dev@geode.apache.org 
Predmet: Re: geode-native ipv6

Can you build an integration test in the new framework?

> On Aug 14, 2019, at 11:25 AM, Mario Ivanac  wrote:
>
> Hi,
>
>
> created https://issues.apache.org/jira/browse/GEODE-7086, and PR with code 
> impacts.
>
> Proposed solution was tried on IPv6 environment, and basic operations 
> (PUT/GET) were successful.
>
> Additional test needed.
>
>
> BR,
>
> Mario
>
> 
> Šalje: Blake Bender 
> Poslano: 9. kolovoza 2019. 0:03:32
> Prima: dev@geode.apache.org 
> Predmet: Re: geode-native ipv6
>
> This chunk of code in the client handshake code leads me to believe it is
> still IPv4 only.  Won't say it's definitive, cause I'm not 100% certain
> hostaddr is used on the server side, but still...
>
> // writing first 4 bytes of the address. This will be same until
> // IPV6 support is added in the client
> uint32_t temp;
> memcpy(, hostAddr, 4);
> m_memID.writeInt(static_cast(temp));
>
>
>> On Thu, Aug 8, 2019 at 1:18 PM Jacob Barrett  wrote:
>>
>> We are on the latest ACE.
>>
>>> On Aug 8, 2019, at 9:56 AM, Mark Hanson  wrote:
>>>
>>> The latest ACE framework seems to have support, but I don’t know how far
>> off latest we are. I don’t think we test anything in an IPv6 context, so I
>> would say no that we don’t officially support it in the client. Given some
>> time, I could do some testing..
>>>
>>> Thanks,
>>> Mark
>>>
 On Aug 8, 2019, at 7:35 AM, Blake Bender  wrote:

 I'm sure someone will chime in with a more definitive answer, but I'm
 pretty certain the answer is no, sorry.

 Thanks,

 Blake


> On Thu, Aug 8, 2019 at 4:28 AM Mario Ivanac 
>> wrote:
>
> Hi,
>
>
> can you tell me does geode-native client support ipv6?
>
>
> BR,
>
> Mario
>
>>>
>>