IGNITE-2399: Implement acquireAndExecute Utility Method

[Atri Sharma]

Hi All,

Please help in reviewing the following PR:

https://github.com/apache/ignite/pull/8820

Regards,

Atri

-- 
Regards,

Atri
Apache Concerted

[jira] [Created] (IGNITE-14220) Shuffle server addresses for thin clients

[Stephen Darlington (Jira)]

Stephen Darlington created IGNITE-14220:
---

 Summary: Shuffle server addresses for thin clients
 Key: IGNITE-14220
 URL: https://issues.apache.org/jira/browse/IGNITE-14220
 Project: Ignite
  Issue Type: Improvement
  Components: thin client
Affects Versions: 2.9.1
Reporter: Stephen Darlington


To connect to a grid from a thin-client, we provide a list of servers and 
ports. If partition awareness is disabled, Ignite connects to the first node.

In the case where there are lots of thin clients, they all end up connecting to 
the same server node.

This is improved somewhat when partition awareness is enabled. JCache requests 
go directly to the data node in question. But SQL queries will all be sent to 
the same node (since the algorithm is deterministic).

If the list were "shuffled" before use, the load would end up balanced across 
the cluster. 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Re: Apache Ignite 3.x: order in repository

[Stephen Darlington]

I think we need to be able answer the question “Why are there so many inactive 
PRs?" before we automate their removal. If perfectly good changes are being 
ignored, we have a problem.

Removing branches of merged PRs and protecting the main branch make sense.

> On 20 Feb 2021, at 18:30, Pavel Tupitsyn  wrote:
> 
> +1
> 
> - Close inactive PRs (1 month or so?)
> - Enable main branch protection (no force pushes, require linear history,
> require status checks)
> 
> On Sat, Feb 20, 2021 at 2:31 PM Petr Ivanov  wrote:
> 
>> Hi, Igniters!
>> 
>> 
>> When we started Ignite 3.x in new repository, not only we have received a
>> chance to cleanup codebase, but to maintain some order in development
>> tools, like GitHub.
>> Currently in 2.x repository we have lots of stalled PRs and branches,
>> which not only clog the repository, but also indirectly influence TC
>> performance (due to necessity to check for updates every ref: branches and
>> PRs).
>> 
>> Could I suggest we devise some recommendations for using PR's and branches
>> in new repo and add some rules about stalled PRs at least, like closing
>> them if inactive for some time.
>> Also we can activate some settings in repo's configuration, like auto
>> delete branch after PR is merged.
>> 
>> 
>> WDYT?