PS: Sorry if I didn't realize what BRs is :D
On Wed, Jan 26, 2022 at 3:39 PM Kirk Lund wrote:
> Hi BRs/Jakov,
>
> I'm familiar with most of these threads, and these ones I know of do not
> spawn more than one thread total. Most of these are quite old, possibly
> predating Executors in Java. I
Hi BRs/Jakov,
I'm familiar with most of these threads, and these ones I know of do not
spawn more than one thread total. Most of these are quite old, possibly
predating Executors in Java. I doubt using max priority is important for
these threads, but you should probably do some perf testing if
Hi Barry,
Many thanks for dedicating some time testing this.
As you confirmed the scenario also fails using the Java API, so I'll create the
PRs with the solution for both Java and C++ API.
Thanks!
/Mario
From: Barry Oglesby
Sent: Wednesday, January 26, 2022
Mario,
I tried changing optimizeForWrite from true to false in java and the function
execution breaks with this cause:
Caused by: org.apache.geode.cache.client.ServerOperationException: remote
server on localhost: Function attributes at client and server don't match:
UpdateTradeFunction
at
Thanks Ray for proposing this branch and Alexander for suggesting a
branchpoint. I will volunteer as Release Manager.
** The support/1.15 branch has now been cut from the SHA proposed in this
thread and develop is now 1.16. **
Please use your best judgement in determining what to backport.
To be clear, I agree with Donal and Robert.
On 1/26/22, 10:44 AM, "Donal Evans" wrote:
To clarify what I think might be a misunderstanding here, there is zero
evidence of any kind that the large warning clean-up PR has introduced any
issues, performance-related or otherwise.
For my
To clarify what I think might be a misunderstanding here, there is zero
evidence of any kind that the large warning clean-up PR has introduced any
issues, performance-related or otherwise.
For my two cents on cutting the branch at the commit before the big change, I'm
of the same opinion as
This morning we had an unexpected problem with Concourse. The database
volume filled up and locked everything up. The database volume has been
increased in size and everything should be functioning properly again. It's
highly likely that a few jobs failed because of this and we're looking into
it.
BTW, just to clarify, when I officially proposed cutting the branch, I hadn't
intended to volunteer as release manager this round. That said, it's important
to branch at a point we're confident about.
Bisecting a 3K-file change is potentially... complicated. If there's confidence
we can track
First, I think I would suggest that we have someone cut a branch as suggested
and see how long it actually takes.
Second, I would suggest we define a norm if we want to avoid this in the
future.
Third, I don't really like the risk of having this in, but I have only heard
about performance
I think we will probably always have this struggle around the time we cut a new
release branch and then need to decide what changes on develop to also bring to
the release branch. I'm okay with us not including the big cleanup in 1.15
since it is not something we plan on backporting to other
Hi everyone,
During our testing, we have the following scenario:
* We start up a cluster and a geode-native client.
* Load a FunctionService jar into the cluster.
* Execute normal flow of operations (function execs, puts, gets, ...)
* After 5 mins, we update the FunctionService
Owen, I really appreciate your point about the increased cost of backports by
the branches diverging like this. I do wonder how high the cost will be in
practice, given that AFAIK most of these changes limit themselves to a single
line.
From: Owen Nichols
Sent:
Fair point, although my hope is that we continually and incrementally improve
our code base on the /develop branch. Yes, there is an increased cost of back
porting critical changes to support branches but the tradeoff is worth it IMHO.
Anthony
> On Jan 25, 2022, at 11:18 PM, Owen Nichols
14 matches
Mail list logo
