Re: Re[2]: Deprecating LOCAL cache

2022-08-04 Thread Maxim Muzafarov
Folks,


Let's back to discussion.
We've already deprecated local caches [1], so it's time to remove them.


I've prepared the PR, please check:

- https://issues.apache.org/jira/browse/IGNITE-15759
- https://github.com/apache/ignite/pull/10157


[1] https://issues.apache.org/jira/browse/IGNITE-15756

On Wed, 15 Sept 2021 at 09:33, Zhenya Stanilovsky
 wrote:
>
>
>
> Ok, we can use node filters in such a case, i understand )
>
>
>
> >I just dream up ) If some one have cached web session layer over
> >ignite with sticky cookie [1] and cross cache transaction logic through
> >local and global caches how this schema will transform without local ?
> >
> >[1]
> >https://www.imperva.com/learn/availability/sticky-session-persistence-and-cookies/
> >
> >
> >> I am not about creation per se, but creation from a thin client side.
> >>
> >> This feature simply doesn't work as expected, broken and impossible to
> >> fix.
> >> It cannot broke any code, because it was already broken and it is
> >> impossible to use in production.
> >> But it still can embarrass newcomers and brings a lot of frustration.
> >>
> >> It is much more safe to ban a creation of LOCAL caches from thin clients.
> >>
> >> But it can survive for a while for ignite cluster nodes, client and
> >> server.
> >>
> >> вт, 14 сент. 2021 г. в 14:06, Maxim Muzafarov <  mmu...@apache.org >:
> >>
> >>> Ivan,
> >>>
> >>> I don't think we should rush with this. Banning the creation of LOCAL
> >>> caches without a warning through the code sounds not good. Will it be
> >>> better to do everything in three steps (releases)? 2.12 deprecate,
> >>> 2.13 forbid new cache creation, 2.14 remove.
> >>>
> >>> On Tue, 14 Sept 2021 at 12:09, Ivan Daschinsky <  ivanda...@gmail.com >
> >>> wrote:
> >>> >
> >>> > Few thoughts about LOCAL caches on thin client:
> >>> >
> >>> > 1. If partition awareness is disabled:
> >>> > a. Inconsistent behaviour if node to which client is connected goes
> >>> down.
> >>> > 2. If partition awareness is enabled:
> >>> > a. For Java and .NET -- same as 1a
> >>> > b. For C++ and python -- use random routing for caches that are not
> >>> > PARTITIONED, so inconsistent behaviour from the beginning.
> >>> >
> >>> > So I suppose we should ban creation of LOCAL caches from thin client
> >>> in
> >>> > 2.12 (fail attempt to create such caches in ClientRequestHandler
> >>> >
> >>> > вт, 14 сент. 2021 г. в 11:31, Ivan Daschinsky <  ivanda...@gmail.com >:
> >>> >
> >>> > > >> Unsupported operation exception.
> >>> > > Binary protocol doesn't have a concept of exception, only error
> >>> status
> >>> and
> >>> > > message, but it is just a remark
> >>> > > I suppose that response with error status and message is ok, but
> >>> may be
> >>> > > others have different opinion?
> >>> > >
> >>> > > >> Removal should happen at 2.13.
> >>> > > A few thin clients are released separately. I suppose that it is
> >>> better to
> >>> > > remove this feature from pyignite a little bit earlier.
> >>> > >
> >>> > > вт, 14 сент. 2021 г. в 11:21, Anton Vinogradov <  a...@apache.org >:
> >>> > >
> >>> > >> > 1. What is expected behaviour if an old thin client requests
> >>> creation of
> >>> > >> > LOCAL cache on the newest ignite cluster?
> >>> > >> Unsupported operation exception.
> >>> > >>
> >>> > >> > 2. Should we completely remove LOCAL caches support in thin
> >>> clients
> >>> > >> (i.e.
> >>> > >> pyignite) before 2.13 release?
> >>> > >> Removal should happen at 2.13.
> >>> > >>
> >>> > >> On Tue, Sep 14, 2021 at 10:30 AM Ivan Daschinsky <
> >>>  ivanda...@gmail.com
> >>> >
> >>> > >> wrote:
> >>> > >>
> >>> > >> > >> 2. 2.13 - complete removal LOCAL caches from codebase.
> >>> > >> > Let's discuss this step with more details.
> >>> > >> > 1. What is expected behaviour if an old thin client requests
> >>> creation of
> >>> > >> > LOCAL cache on the newest ignite cluster?
> >>> > >> > 2. Should we completely remove LOCAL caches support in thin
> >>> clients
> >>> > >> (i.e.
> >>> > >> > pyignite) before 2.13 release?
> >>> > >> >
> >>> > >> > вт, 14 сент. 2021 г. в 10:11, Nikolay Izhikov <
> >>>  nizhi...@apache.org
> >>> >:
> >>> > >> >
> >>> > >> > > I proposed the following plan:
> >>> > >> > >
> >>> > >> > > 1. 2.12 - deprecation of LOCAL caches.
> >>> > >> > > 2. 2.13 - complete removal LOCAL caches from codebase.
> >>> > >> > >
> >>> > >> > > > 13 сент. 2021 г., в 13:30, Ivan Daschinsky <
> >>>  ivanda...@gmail.com
> >>> >
> >>> > >> > > написал(а):
> >>> > >> > > >
> >>> > >> > > > I personally support deprecation, but we should at least
> >>> have a
> >>> > >> plan.
> >>> > >> > > > I suppose that putting annotations and removing documentation
> >>> are
> >>> > >> not
> >>> > >> > > > enough.
> >>> > >> > > >
> >>> > >> > > >
> >>> > >> > > > пн, 13 сент. 2021 г. в 13:22, Maxim Muzafarov <
> >>>  mmu...@apache.org >:
> >>> > >> > > >
> >>> > >> > > >> Ivan,
> >>> > >> > > >>
> >>> > >> > > >> I don't think we can remove LOCAL caches at the nearest
> >>> 

Re: [CATCH All] team city bot permissions to trigger builds

2022-08-04 Thread Sergey Korotkov

Hello Petr,

On 03.08.2022 15:39, Petr Ivanov wrote:

Hi, Sergey.


What bot?



I mean this one: https://mtcga.ignite.apache.org/

But the problem was resolved for me already.

Thanks,

--

   Sergey




Regards,
Petr Ivanov
Head of IT
IT & Development Solutions | GRIDGAIN SYSTEMS
+7 (911) 945-00-59


On 3 Aug 2022, at 11:33, Sergey Korotkov  wrote:

Hello colleagues,

I have troubles invoking builds and re-runs from the team city bot interface.

If I click on the corresponding buttons ("Trigger build" or "Re-run possible blockers") 
it shows the "Internal Server Error [500]." in the UI and the chrome dev tools shows that bot 
backend actually return the following error message:

--

Service https://ci.ignite.apache.org/app/rest/buildQueue returned Invalid 
Response Code : 403:
Responding with error, status code: 403 (Forbidden).
Details: jetbrains.buildServer.serverSide.auth.AccessDeniedException: You do not have 
"Comment build" permission in project with internal id: project17
Access denied. Check the user has enough permissions to perform the operation.

--


Is it a bug or I need more permissions in fact?

If my current permissions are not enough would you please give me more?


My teamcity user name is: serge.korotkov


Thanks,

--

Sergey




Re: [CATCH All] team city bot permissions to trigger builds

2022-08-04 Thread Petr Ivanov
Hi, Sergey.


What bot?


Regards,
Petr Ivanov
Head of IT
IT & Development Solutions | GRIDGAIN SYSTEMS
+7 (911) 945-00-59

> On 3 Aug 2022, at 11:33, Sergey Korotkov  wrote:
> 
> Hello colleagues,
> 
> I have troubles invoking builds and re-runs from the team city bot interface.
> 
> If I click on the corresponding buttons ("Trigger build" or "Re-run possible 
> blockers") it shows the "Internal Server Error [500]." in the UI and the 
> chrome dev tools shows that bot backend actually return the following error 
> message:
> 
> --
> 
> Service https://ci.ignite.apache.org/app/rest/buildQueue returned Invalid 
> Response Code : 403:
> Responding with error, status code: 403 (Forbidden).
> Details: jetbrains.buildServer.serverSide.auth.AccessDeniedException: You do 
> not have "Comment build" permission in project with internal id: project17
> Access denied. Check the user has enough permissions to perform the operation.
> 
> --
> 
> 
> Is it a bug or I need more permissions in fact?
> 
> If my current permissions are not enough would you please give me more?
> 
> 
> My teamcity user name is: serge.korotkov
> 
> 
> Thanks,
> 
> --
> 
>Sergey



Your receipt from Bugyard #2593-7835

2022-08-04 Thread Bugyard
Bugyard (https://bugyard.io)

Bugyard

Receipt from Bugyard €9.00 (invoice illustration 
[https://stripe-images.s3.amazonaws.com/emails/invoices_invoice_illustration.png])
 Download invoice 
(https://pay.stripe.com/invoice/acct_18krqLGD1aL32z09/live_YWNjdF8xOGtycUxHRDFhTDMyejA5LF9NQjVxTFhVckNaeXh6ZzF5S1lwUDlraTRTNHpPRXFzLDUwMDg1NjQ20200Qb3ZdXNJ/pdf?s=em)
 Download receipt 
(https://dashboard.stripe.com/receipts/invoices/CAcQARoXChVhY2N0XzE4a3JxTEdEMWFMMzJ6MDkojsqqlwYyBtqORUXQnjovFpgP8ZTxyUQmHl0_ynavMxwb2oDs_lTaEzkZ7K3hTSjxmszaDfBGovmxV4Qjf8g/pdf?s=em)
 Receipt number 2593-7835 Invoice number 3E1F868C-0013 Payment method - 5384

Receipt #2593-7835 Aug 3 – Sep 3, 2022 Freelancer Qty 1 €9.00 Total €9.00 
Amount paid €9.00 Questions? Contact us at supp...@bugyard.io 
(supp...@bugyard.io) or call us at +33 6 60 80 35 68 (tel:33660803568).

Powered bystripe logo  (https://stripe.com)  |   Learn more about Stripe 
Billing (https://stripe.com/billing)

Re: Performance of cancelling services (related to IGNITE-17274)

2022-08-04 Thread Pavel Tupitsyn
The change looks good to me, good catch.

>  I can create a new Jira ticket and pull request.
Please do, let's merge it.

On Thu, Aug 4, 2022 at 2:11 AM Arthur Naseef  wrote:

> Testing with 60,000+ services, found that cancelling large numbers of
> services takes significant time.  Found another linear lookup that can be
> optimized with a map.
>
> Here is a commit that fixes the problem in local testing:
>
>
> https://github.com/artnaseef/ignite/commit/4ca87f7f6e7aae193faf1404736e0b4ee7168752
>
>
> The difference, on my local system, with and without the patch:
>
> CANCEL 60,000 *WITHOUT PATCH* = 67s 358ms
>
> CANCEL 60,000 *PATCHED* = 1s 323ms
>
>
> Note that, with the IGNITE-17274 fix, startup of the same 60,000 services
> only takes ~ 9s.
>
> Appreciate any feedback, and I hope we can push this fix forward.  I can
> create a new Jira ticket and pull request.
>
> Art
>