I like this but it might be even better if ServerLauncher gave access to
the CacheServer it launched and CacheServer gave access to its cache.
The Locator interface, as well, could have a getCache() method and
deprecate the getDistributedSystem() method. These days a Locator
always has a
In the meantime, a PutMessage is being processed by a P2P message reader
thread. This is a send of a primary put from another server. As part of that
put operation, its delivering the event to a gateway sender which ultimately
causes a VSDCountersManager to be instantiated. This is blocked
We will need to wrap up this discussion with a decision. Looks like we are
skeptical about #4, and it's proven to work with #3 since our current jdk11
pipeline is green with this approach.
Can I propose we do #3 and document the extra configuration needed for
jdk11 for now and then work towards
Above that, though, in the acquisition of the *geode* resource, we see
/opt/resource/lib/commands/in.rb:23:in `output': *PR has merge conflicts*
(RuntimeError)
from /opt/resource/lib/commands/in.rb:110:in `'
That resource could not then be passed to the lower tasks *rsync_code_down *et
al,
Well, ServerLauncher may or may not create a CacheServer instance when it
starts a server. A server can be created without a CacheServer, for
instance, when in *Gfsh* `start server --disable-default-server` option is
specified.
In addition, you can always find or get the list of CacheServers (if
Hi everyone,
It's time to cut the release branch, since we are moving to time based
releases. Are there any reasons why a release branch should not be cut as
soon as possible?
I am happy to take on the role for the 1.8 release.
On Wed, Oct 31, 2018 at 8:58 AM Dan Smith wrote:
> We are coming up on the date where we said we would start the 1.8 release
> (Nov 1st).
>
> Any volunteers to be release manager for this release?
>
> -Dan
>
Can you start a thread to figure out where things are at and if we’re ready?
Anthony
> On Nov 1, 2018, at 8:48 AM, Alexander Murmann wrote:
>
> I am happy to take on the role for the 1.8 release.
>
> On Wed, Oct 31, 2018 at 8:58 AM Dan Smith wrote:
>
>> We are coming up on the date where
In case anyone else's email broke the thread, below is a link to the
previous thread in the mail archive for context.
https://markmail.org/thread/xt224pvavxu3d54p
On Thu, Nov 1, 2018 at 9:35 AM, Jinmei Liao wrote:
> We will need to wrap up this discussion with a decision. Looks like we are
>
I would like to get this PR in the release:
https://github.com/apache/geode/pull/2757
I'm testing the merge to develop now
On 11/1/18 1:18 PM, Sai Boorlagadda wrote:
Sure! agree that we should hold the releases unless there is a
critical issue.
This is not a gating issue and the code is
This PR has been merged to develop
On 11/1/18 1:35 PM, Bruce Schuchardt wrote:
I would like to get this PR in the release:
https://github.com/apache/geode/pull/2757
I'm testing the merge to develop now
On 11/1/18 1:18 PM, Sai Boorlagadda wrote:
Sure! agree that we should hold the releases
The geode-native source headers I mentioned in [1] need to be cleaned up.
Anthony
[1]
https://lists.apache.org/thread.html/8c9da19d7c0ef0149b1ed79bf0cecde38f17a854ecfa0f0a42f1ff0b@%3Cdev.geode.apache.org%3E
> On Nov 1, 2018, at 2:01 PM, Bruce Schuchardt wrote:
>
> This PR has been merged to
Sure! agree that we should hold the releases unless there is a
critical issue.
This is not a gating issue and the code is already committed to develop.
Sai
On Thu, Nov 1, 2018 at 1:03 PM Alexander Murmann
wrote:
> In the spirit of the previously discussed timed releases, we should only
> hold
In the spirit of the previously discussed timed releases, we should only
hold cutting the release for critical issues, that for some reason (not
sure how that might be) should not be fixed after the branch has been cut.
Waiting for features leads us down the slippery slope we are trying to
avoid
and PR 390 has been approved and merged
On Thu, Nov 1, 2018 at 5:10 PM Ernest Burghardt
wrote:
> geode-native fixes are in https://github.com/apache/geode-native/pull/390
>
> On Thu, Nov 1, 2018 at 4:06 PM Anthony Baker wrote:
>
>> The geode-native source headers I mentioned in [1] need to be
geode-native fixes are in https://github.com/apache/geode-native/pull/390
On Thu, Nov 1, 2018 at 4:06 PM Anthony Baker wrote:
> The geode-native source headers I mentioned in [1] need to be cleaned up.
>
> Anthony
>
> [1]
>
I would like to resolve GEODE-5338 as it is currently waiting for
doc update.
Sai
On Thu, Nov 1, 2018 at 10:00 AM Alexander Murmann
wrote:
> Hi everyone,
>
> It's time to cut the release branch, since we are moving to time based
> releases. Are there any reasons why a release branch should not
A couple of questions:
1) Are you proposing changing gfsh start server to automatically add these
add-opens, or are you suggesting users will have to do that?
2) Are these add-opens required for running a geode client?
-Dan
On Thu, Nov 1, 2018 at 9:48 AM Patrick Rhomberg
wrote:
> In case
1) yes, gfsh script will need to be updated to add these configurations.
2) yes, these ad-opens are required to run geode clients as well. We will
need to document them.
On Thu, Nov 1, 2018 at 10:31 AM Dan Smith wrote:
> A couple of questions:
>
> 1) Are you proposing changing gfsh start server
But when I sent the email, the PR page on github stated:
This branch has no conflicts with the base branchMerging can be performed
automatically.
Which, in my understanding means there are no merge conflicts.
Stuff is flaky and that's ok. I just want to know how it's supposed to work
so I know
And one disclaimer I have to add is that these "--add-opens" are the ones
uncovered by our current set of tests, there might be more needed in areas
that are not covered by our tests. So to say the most, our current jdk11
support is still in beta mode.
On Thu, Nov 1, 2018 at 10:33 AM Jinmei Liao
21 matches
Mail list logo
