Pipeline results can be found at:
Concourse:
https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/308
Pipeline results can be found at:
Concourse:
https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/FlakyTest/builds/476
Hi, John, I was also surprised with the old behavior. I believe it's a bug
that just accidentally served as a "feature".
On Fri, Apr 27, 2018 at 3:42 PM, John Blum wrote:
> Hi Jinmei-
>
> Regarding this...
>
> "
>
> *So the current behavior is, when a customer starts a server with
> cache.xmltha
Hi, Jason, I am able to start two servers using different cache.xml that
each define a region with the same name but with different attribute. This
might be because on one server, the region is defined as "local".
ServerA.xml
http://www.w3.org/2001/XMLSchema-instance"; xmlns="
http://geode.apache
---
Spring Data GemFire > Nightly-ApacheGeode > #900 was successful (rerun once).
---
This build was rerun by John Blum.
2380 tests in total.
https://build.sprin
---
Spring Data GemFire > Nightly-ApacheGeode > #900 failed.
---
Scheduled with changes by John Blum.
1/2380 tests failed.
https://build.spring.io/browse/SGF-NAG
Hi Jinmei-
Regarding this...
"
*So the current behavior is, when a customer starts a server with
cache.xmlthat has a region defined, and then later on issues a gfsh command
`createindex` on that region, the command output would be something like:*
*>create index .Member |
Status--
*correction to my last email, I was using java api and not cache.xml
On Fri, Apr 27, 2018 at 3:40 PM Jason Huynh wrote:
> Hi Jinmei and Naba,
>
> I don't think you can define two regions with the same name and different
> types. We would throw an IllegalStateException for the node that tried to
Hi Jinmei and Naba,
I don't think you can define two regions with the same name and different
types. We would throw an IllegalStateException for the node that tried to
create the region second. At least that was the behavior I was seeing when
I tried to create a replicate region and a partitione
Hi, Naba, I believe this is possible even before, with or without using
cluster configuration. That's why we have to say stuff defined using
cache.xml is not mean to be a cluster wide configuration.
On Fri, Apr 27, 2018 at 2:40 PM, Nabarun Nag wrote:
> With the new implementation, will it allow
With the new implementation, will it allow two different regions with the
same exact name to exist in the cluster ?
I meant like server A had a cache.xml with region “test” with different
properties as to the cache.xml in server B for region “test”. And the
locator had an empty cluster config.
So
My point is: we can't keep "mending" the wrong behavior, otherwise we can
not move forward.
On Fri, Apr 27, 2018 at 2:22 PM, Jinmei Liao wrote:
> So the current behavior is, when a customer starts a server with cache.xml
> that has a region defined, and then later on issues a gfsh command `creat
So the current behavior is, when a customer starts a server with cache.xml
that has a region defined, and then later on issues a gfsh command `create
index` on that region, the command output would be something like:
>create index .
Member | Status
server-1 |
Thanks for catching that tag error Anthony.
I fixed it to have the SHA matching the build.
If you're good with this could you change your -1 to a +1 so the vote can
continue?
On Thu, Apr 26, 2018 at 2:05 PM, Mike Stolz wrote:
> This is the first release candidate for Apache Geode, version 1.6.
I would also ask/remind us to carefully consider anything that might be
needed, or required, in the API as well.
We must thoughtfully compliment the, or a, API (i.e. programmatically) with
anything you can do in/from *Gfsh*.
The API is a first class citizen and how most users will consume product
I talked with Barbara and understand the long term effort to deprecate
cache.xml in favor of cluster config and I heartily agree.
I think a good step in that direction is to provide a migration tool for
users that reads all cache.xml files for current members and store them in
cluster config, throw
The decision is to go with the new behavior (I believe :-)). The region
does not exist in the cluster configuration to begin with since it's not
created using gfsh, so we have no way of checking unless we make an extra
trip to the region to find out what kind of region it is, but again
different s
Since we are working on enhancing Lucene support to allow adding a Lucene
index to an existing region containing data, I am very interested in the
decision here.
Like Mike, I also prefer keeping the original behavior of updating cluster
config with both the region and the index if it was not there
- checked signatures
- checked hashes
- build from source
- ran examples
The tag for the geode repo differs from the source and binary release archives:
~/working/apache-geode-1.6.0$ bin/gfsh version --full
Build-Date: 2018-04-23 14:04:21 -0400
Build-Id: mikestolz 0
Build-Java-Version: 1.8.0_151
19 matches
Mail list logo
