[MTCGA]: new failures in builds [3159869] needs to be handled

[dpavlov . tasks]

Hi Igniters,

 I've detected some new issue on TeamCity to be handled. You are more than 
welcomed to help.

 If your changes can lead to this failure(s): We're grateful that you were a 
volunteer to make the contribution to this project, but things change and you 
may no longer be able to finalize your contribution.
 Could you respond to this email and indicate if you wish to continue and fix 
test failures or step down and some committer may revert you commit. 

 *Recently contributed test failed in master tests: 
Apache\Ignite\Tests\CacheKeyValueOpsTestCase: 
Apache\Ignite\Tests\CacheKeyValueOpsTestCase::testCacheGetAndReplaceWrongArgs 
https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-8544380800226166911=%3Cdefault%3E=testDetails

 *Recently contributed test failed in master tests: 
Apache\Ignite\Tests\CacheKeyValueOpsTestCase: 
Apache\Ignite\Tests\CacheKeyValueOpsTestCase::testCacheReplaceIfEqualsWrongArgs 
https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=7510292952369692624=%3Cdefault%3E=testDetails

 *Recently contributed test failed in master tests: 
Apache\Ignite\Tests\CacheKeyValueOpsTestCase: 
Apache\Ignite\Tests\CacheKeyValueOpsTestCase::testCacheGetAndRemoveWrongArgs 
https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=6767768552589233912=%3Cdefault%3E=testDetails

 *Recently contributed test failed in master tests: 
Apache\Ignite\Tests\CacheKeyValueOpsTestCase: 
Apache\Ignite\Tests\CacheKeyValueOpsTestCase::testCacheGetAllWrongArgs 
https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=8010201874973788100=%3Cdefault%3E=testDetails

 *Recently contributed test failed in master tests: 
Apache\Ignite\Tests\CacheKeyValueOpsTestCase: 
Apache\Ignite\Tests\CacheKeyValueOpsTestCase::testCachePutIfAbsentWrongArgs 
https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-5231476146734727890=%3Cdefault%3E=testDetails

 *Recently contributed test failed in master tests: 
Apache\Ignite\Tests\CacheKeyValueOpsTestCase: 
Apache\Ignite\Tests\CacheKeyValueOpsTestCase::testContainsKeyWrongArgs 
https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=8278104022332781338=%3Cdefault%3E=testDetails

 *Recently contributed test failed in master tests: 
Apache\Ignite\Tests\CacheKeyValueOpsTestCase: 
Apache\Ignite\Tests\CacheKeyValueOpsTestCase::testCacheContainsKeysWrongArgs 
https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=8508115998050634179=%3Cdefault%3E=testDetails

 *Recently contributed test failed in master tests: 
Apache\Ignite\Tests\CacheKeyValueOpsTestCase: 
Apache\Ignite\Tests\CacheKeyValueOpsTestCase::testCacheRemoveKeysWrongArgs 
https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-5512920338110762681=%3Cdefault%3E=testDetails

 *Recently contributed test failed in master tests: 
Apache\Ignite\Tests\CacheKeyValueOpsTestCase: 
Apache\Ignite\Tests\CacheKeyValueOpsTestCase::testCacheGetSizeWrongArgs 
https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=8039044665871263128=%3Cdefault%3E=testDetails

 *Recently contributed test failed in master tests: 
Apache\Ignite\Tests\CacheKeyValueOpsTestCase: 
Apache\Ignite\Tests\CacheKeyValueOpsTestCase::testCacheReplaceWrongArgs 
https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=2601421891678519225=%3Cdefault%3E=testDetails

 *Recently contributed test failed in master tests: 
Apache\Ignite\Tests\CacheKeyValueOpsTestCase: 
Apache\Ignite\Tests\CacheKeyValueOpsTestCase::testCacheRemoveKeyWrongArgs 
https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-165170373995072247=%3Cdefault%3E=testDetails

 *Recently contributed test failed in master tests: 
Apache\Ignite\Tests\CacheKeyValueOpsTestCase: 
Apache\Ignite\Tests\CacheKeyValueOpsTestCase::testCacheGetWrongArgs 
https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-2711660524736740778=%3Cdefault%3E=testDetails

 *Recently contributed test failed in master tests: 
Apache\Ignite\Tests\CacheKeyValueOpsTestCase: 
Apache\Ignite\Tests\CacheKeyValueOpsTestCase::testCachePutWrongArgs 
https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-7419076455473690169=%3Cdefault%3E=testDetails

 *Recently contributed test failed in master tests: 
Apache\Ignite\Tests\CacheKeyValueOpsTestCase: 
Apache\Ignite\Tests\CacheKeyValueOpsTestCase::testCacheGetAndPutIfAbsentWrongArgs
 
https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=6918523075100081828=%3Cdefault%3E=testDetails

 *Recently contributed test failed in master tests: 
Apache\Ignite\Tests\CacheKeyValueOpsTestCase: 
Apache\Ignite\Tests\CacheKeyValueOpsTestCase::testCacheGetAndPutWrongArgs 
https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=1431371577522230596=%3Cdefault%3E=testDetails

 *Recently contributed test failed in master tests: 

[jira] [Created] (IGNITE-11535) AtomicLong cannot be found after creation

[Vyacheslav Koptilin (JIRA)]

Vyacheslav Koptilin created IGNITE-11535:


 Summary: AtomicLong cannot be found after creation
 Key: IGNITE-11535
 URL: https://issues.apache.org/jira/browse/IGNITE-11535
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.7
Reporter: Vyacheslav Koptilin
Assignee: Vyacheslav Koptilin






--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[MTCGA]: new failures in builds [3298550] needs to be handled

[dpavlov . tasks]

Hi Igniters,

 I've detected some new issue on TeamCity to be handled. You are more than 
welcomed to help.

 If your changes can lead to this failure(s): We're grateful that you were a 
volunteer to make the contribution to this project, but things change and you 
may no longer be able to finalize your contribution.
 Could you respond to this email and indicate if you wish to continue and fix 
test failures or step down and some committer may revert you commit. 

 *New Critical Failure in master Platform C++ (Win x64 | Release) 
https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_PlatformCWinX64Release=%3Cdefault%3E=buildTypeStatusDiv
 No changes in the build

 - Here's a reminder of what contributors were agreed to do 
https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute 
 - Should you have any questions please contact dev@ignite.apache.org 

Best Regards,
Apache Ignite TeamCity Bot 
https://github.com/apache/ignite-teamcity-bot
Notification generated at 01:19:15 13-03-2019 

[MTCGA]: new failures in builds [3163283] needs to be handled

[dpavlov . tasks]

Hi Igniters,

 I've detected some new issue on TeamCity to be handled. You are more than 
welcomed to help.

 If your changes can lead to this failure(s): We're grateful that you were a 
volunteer to make the contribution to this project, but things change and you 
may no longer be able to finalize your contribution.
 Could you respond to this email and indicate if you wish to continue and fix 
test failures or step down and some committer may revert you commit. 

 *Recently contributed test failed in master client.SslParametersTest 
https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-3963130275918866534=%3Cdefault%3E=testDetails
 No changes in the build

 - Here's a reminder of what contributors were agreed to do 
https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute 
 - Should you have any questions please contact dev@ignite.apache.org 

Best Regards,
Apache Ignite TeamCity Bot 
https://github.com/apache/ignite-teamcity-bot
Notification generated at 00:49:17 13-03-2019 

Re: Consistent ID specification from previous random UUID

[Alexey Goncharuk]

Igniters,

I came across the same issue during development and found no sane
workaround for this issue. I believe the solution should be as simple as
possible because we are already adding a warning to let users know that it
is good to specify a consistent ID in production deployments.

As for the current solution, I do not like adding a new configuration
property like 'storageFolder' because it's another way to shoot yourself in
the leg (e.g. different nodes have different consistent IDs but configured
to have the same storage folder).
Why can't we:
 - either check if consistent ID is an instance of UUID and then take the
appropriate folder. This approach is straightforward, but may affect
current users
 - check if consistent ID is set to a string 'nodeXX-UUID'. In this case
the consistent ID is set to UUID, and the storage folder is chosen
according to the proper rules. This change has a minimal chance to affect
current users because it's unlikely that somebody is using auto-generated
folder naming scheme as consistent ID.

Thoughts?

вт, 12 мар. 2019 г. в 16:51, Dmitriy Pavlov :

> Hi Igniters,
>
> A full description can be found at wiki page
>
> https://cwiki.apache.org/confluence/display/IGNITE/Ignite+Persistent+Store+-+under+the+hood#IgnitePersistentStore-underthehood-SubfoldersGeneration
>
> I like the idea of introducing a property like nodeStorageName to specify
> exactly name of a directory to use. For example, it could have higher
> priority then IgniteConfiguration.getConsistentId(). It will impact the
> mentioned algorithm, but it seems to be easier to understand by users.
>
> If nobody else minds, I will try to implement this idea.
>
> Sincerely,
> Dmitriy Pavlov
>
>
> сб, 2 мар. 2019 г. в 08:33, Павлухин Иван :
>
> > Dmitriy,
> >
> > You wrote
> > > we need an order to scan and lock random-UUID based folders.
> >
> > It would be great if you provide a discussion about that order to
> > complete the picture. Currently I cannot understand why the order is
> > important.
> >
> > Also, couple of raw thoughts:
> > 1. Can we extend a directory lookup procedure when consistent id is
> > specified to check nodeXX-consistentId directories as well?
> > 2. Can we introduce a property like nodeStorageName to specify exact
> > name of a directory to use? It looks like a straightforward and
> > universal workaround. Or is node index better in some sense? Why?
> >
> > Please, share your thoughts.
> >
> > чт, 28 февр. 2019 г. в 17:43, Dmitriy Pavlov :
> > >
> > > Hi Ivan,
> > >
> > > Yes, you catch me, I'm a little bit cheating with lazy consensus on
> code
> > > modification without providing a PR because I was expecting that nobody
> > > comes to discussion. I will prepare PR shortly. And since we anyway
> have
> > a
> > > discussion, I will not apply anything by lazy approval.
> > >
> > > - storageNodeIndex without consistent ID will not work.
> > >  cfg.getDataStorageConfiguration().setNodeIdx() will be required only
> for
> > > case we have consistent ID.
> > >
> > > Hi Stanislav,
> > >
> > > We can't use only consistent ID because
> > >
> > > 1) we need an order to scan and lock random-UUID based folders.  Node
> > index
> > > provides the order of scan. I can find the corresponding discussion,
> but
> > I
> > > guess it is not needed.
> > > 2) we need to separate backward compatible folders from new random-UUID
> > > based folders. Using UUID as folder will not allow us to scan only new
> > name
> > > format folders.
> > >
> > > I guess specifying node index is a quite rare case and good JavaDoc
> will
> > > always help.
> > >
> > > DataStorageConfiguration().setNodeIdx()  JavaDoc may include following
> > > notes:
> > > Node index used for persistent store folders in case several nodes
> reuse
> > > one persistent store root folder.
> > >
> > > Sincerely,
> > > Dmitriy Pavlov
> > >
> > > чт, 28 февр. 2019 г. в 08:03, Павлухин Иван :
> > >
> > > > Dmitiy,
> > > >
> > > > Could please clarify one thing:
> > > > 1. Will it be enough to use only storageNodeIndex in order to reuse
> > > > the same persistence folders when consistentId is auto-generated?
> E.g.
> > > > I have a configuration with storageNodeIndex=1 and without explicitly
> > > > specified consistentId, will the node after restart use the same
> > > > persistence folder as before restart?
> > > >
> > > > Also a side note:
> > > > > Please share your vision. I'm going to apply this change by lazy
> > > > consensus
> > > > in 3 days.
> > > > What do you mean by "apply"? I have not seen any PR yet.
> > > >
> > > > ср, 27 февр. 2019 г. в 21:12, Dmitriy Pavlov :
> > > > >
> > > > > Hi Igniters,
> > > > >
> > > > > I would like to fix the issue
> > > > > https://issues.apache.org/jira/browse/IGNITE-11432 about
> specifying
> > some
> > > > > previous randomly generated UUID as a new consistent ID. Folder
> > > > generation
> > > > > algorithm here (
> > > > >
> > > >
> >
> 

Re: Consistent ID specification from previous random UUID

[Dmitriy Pavlov]

Hi Igniters,

A full description can be found at wiki page
https://cwiki.apache.org/confluence/display/IGNITE/Ignite+Persistent+Store+-+under+the+hood#IgnitePersistentStore-underthehood-SubfoldersGeneration

I like the idea of introducing a property like nodeStorageName to specify
exactly name of a directory to use. For example, it could have higher
priority then IgniteConfiguration.getConsistentId(). It will impact the
mentioned algorithm, but it seems to be easier to understand by users.

If nobody else minds, I will try to implement this idea.

Sincerely,
Dmitriy Pavlov


сб, 2 мар. 2019 г. в 08:33, Павлухин Иван :

> Dmitriy,
>
> You wrote
> > we need an order to scan and lock random-UUID based folders.
>
> It would be great if you provide a discussion about that order to
> complete the picture. Currently I cannot understand why the order is
> important.
>
> Also, couple of raw thoughts:
> 1. Can we extend a directory lookup procedure when consistent id is
> specified to check nodeXX-consistentId directories as well?
> 2. Can we introduce a property like nodeStorageName to specify exact
> name of a directory to use? It looks like a straightforward and
> universal workaround. Or is node index better in some sense? Why?
>
> Please, share your thoughts.
>
> чт, 28 февр. 2019 г. в 17:43, Dmitriy Pavlov :
> >
> > Hi Ivan,
> >
> > Yes, you catch me, I'm a little bit cheating with lazy consensus on code
> > modification without providing a PR because I was expecting that nobody
> > comes to discussion. I will prepare PR shortly. And since we anyway have
> a
> > discussion, I will not apply anything by lazy approval.
> >
> > - storageNodeIndex without consistent ID will not work.
> >  cfg.getDataStorageConfiguration().setNodeIdx() will be required only for
> > case we have consistent ID.
> >
> > Hi Stanislav,
> >
> > We can't use only consistent ID because
> >
> > 1) we need an order to scan and lock random-UUID based folders.  Node
> index
> > provides the order of scan. I can find the corresponding discussion, but
> I
> > guess it is not needed.
> > 2) we need to separate backward compatible folders from new random-UUID
> > based folders. Using UUID as folder will not allow us to scan only new
> name
> > format folders.
> >
> > I guess specifying node index is a quite rare case and good JavaDoc will
> > always help.
> >
> > DataStorageConfiguration().setNodeIdx()  JavaDoc may include following
> > notes:
> > Node index used for persistent store folders in case several nodes reuse
> > one persistent store root folder.
> >
> > Sincerely,
> > Dmitriy Pavlov
> >
> > чт, 28 февр. 2019 г. в 08:03, Павлухин Иван :
> >
> > > Dmitiy,
> > >
> > > Could please clarify one thing:
> > > 1. Will it be enough to use only storageNodeIndex in order to reuse
> > > the same persistence folders when consistentId is auto-generated? E.g.
> > > I have a configuration with storageNodeIndex=1 and without explicitly
> > > specified consistentId, will the node after restart use the same
> > > persistence folder as before restart?
> > >
> > > Also a side note:
> > > > Please share your vision. I'm going to apply this change by lazy
> > > consensus
> > > in 3 days.
> > > What do you mean by "apply"? I have not seen any PR yet.
> > >
> > > ср, 27 февр. 2019 г. в 21:12, Dmitriy Pavlov :
> > > >
> > > > Hi Igniters,
> > > >
> > > > I would like to fix the issue
> > > > https://issues.apache.org/jira/browse/IGNITE-11432 about specifying
> some
> > > > previous randomly generated UUID as a new consistent ID. Folder
> > > generation
> > > > algorithm here (
> > > >
> > >
> https://cwiki.apache.org/confluence/display/IGNITE/Ignite+Persistent+Store+-+under+the+hood
> > > )
> > > > allows two options
> > > > -node00+random UUID
> > > > - consistendId
> > > >
> > > > I would like to add to Ignite configuration new property nodeIndex in
> > > > addition to consistent Id. New Property will be named as
> > > storageNodeIndex,
> > > > int, zero-based.
> > > > This will add the third option of subfolders processing:
> > > > node{storageNodeIndex}+consistentID
> > > >
> > > > Please share your vision. I'm going to apply this change by lazy
> > > consensus
> > > > in 3 days.
> > > >
> > > > Sincerely,
> > > > Dmitriy Pavlov
> > >
> > >
> > >
> > > --
> > > Best regards,
> > > Ivan Pavlukhin
> > >
>
>
>
> --
> Best regards,
> Ivan Pavlukhin
>

[jira] [Created] (IGNITE-11534) Partition loss policy is not handled properly for implicit single key transactions

[Ivan Pavlukhin (JIRA)]

Ivan Pavlukhin created IGNITE-11534:
---

 Summary: Partition loss policy is not handled properly for 
implicit single key transactions
 Key: IGNITE-11534
 URL: https://issues.apache.org/jira/browse/IGNITE-11534
 Project: Ignite
  Issue Type: Bug
  Components: cache
Affects Versions: 2.7
Reporter: Ivan Pavlukhin
Assignee: Ivan Pavlukhin
 Fix For: 2.8


There is a bug in handling partition loss policies for single put operations 
over {{TRANSACTIONAL}} cache (implicit transaction). Key values are passed 
improperly for validation.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: I would like to pick up JIRA Ticket IGNITE-11508

[Ilya Kasnacheev]

Hello!

Your JIRA login ARAVINDAREDDY was added to list of contributors, you can
assign tickets to yourself.

Please read
https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute
You can notify me (@ilyak) for review in JIRA once you have anything in
Patch Available.

Regards,
-- 
Ilya Kasnacheev


пн, 11 мар. 2019 г. в 08:30, aravinda reddy :

> (IGNITE-11508) Yarn Ignite deployment: Add support to override queue name
> through cluster properties
>
> Thanks,
> Aravinda
>

Re: Review of IGNITE-11521

[Lukas Polacek]

Hi,
I didn't know that IgniteConfiguration#setLocalEventListeners existed,
since we followed the documentation at readme.io
 which only mentions
'Ignite.events().localListen'. We'll try it to see if it works for us.

In the meantime I'll expand the JIRA ticket.


On Tue, Mar 12, 2019 at 1:33 PM Павлухин Иван  wrote:

> Hi Lukas,
>
> Thank you for your efforts! I am not 100% sure but perhaps
> IgniteConfiguration#setLocalEventListeners can help in your use case?
> But added BEFORE_CLUSTER_CONNNECTION lifecycle event can be still
> valuable. It is good idea to describe implemented approach in jira
> ticket and how can it be used to register listeners before joining the
> cluster.
>
> вт, 12 мар. 2019 г. в 14:48, Lukas Polacek  >:
> >
> > Hi,
> > this is my first contribution to Apache Ignite. I've created a bug
> > , made a pull
> request
> >  which the TC Bot is happy
> about
> > <
> https://issues.apache.org/jira/browse/IGNITE-11521?focusedCommentId=16790439=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16790439
> >.
> > What are the next steps? Will someone review it?
> >
> > Cheers,
> > Lukas Polacek
>
>
>
> --
> Best regards,
> Ivan Pavlukhin
>

Re: Review of IGNITE-11521

[Павлухин Иван]

Hi Lukas,

Thank you for your efforts! I am not 100% sure but perhaps
IgniteConfiguration#setLocalEventListeners can help in your use case?
But added BEFORE_CLUSTER_CONNNECTION lifecycle event can be still
valuable. It is good idea to describe implemented approach in jira
ticket and how can it be used to register listeners before joining the
cluster.

вт, 12 мар. 2019 г. в 14:48, Lukas Polacek :
>
> Hi,
> this is my first contribution to Apache Ignite. I've created a bug
> , made a pull request
>  which the TC Bot is happy about
> .
> What are the next steps? Will someone review it?
>
> Cheers,
> Lukas Polacek



-- 
Best regards,
Ivan Pavlukhin

Review of IGNITE-11521

[Lukas Polacek]

Hi,
this is my first contribution to Apache Ignite. I've created a bug
, made a pull request
 which the TC Bot is happy about
.
What are the next steps? Will someone review it?

Cheers,
Lukas Polacek

[jira] [Created] (IGNITE-11533) Improve memory usage reporting in the logs

[Stanislav Lukyanov (JIRA)]

Stanislav Lukyanov created IGNITE-11533:
---

 Summary: Improve memory usage reporting in the logs
 Key: IGNITE-11533
 URL: https://issues.apache.org/jira/browse/IGNITE-11533
 Project: Ignite
  Issue Type: Improvement
Reporter: Stanislav Lukyanov


Currently node's memory usage is reported in the log like this
{code}
^-- PageMemory [pages=66407]
^-- Heap [used=303MB, free=91,6%, comm=849MB]
^-- Off-heap [used=260MB, free=62,73%, comm=580MB]
^--   sysMemPlc region [used=0MB, free=99,21%, comm=40MB]
^--   TxLog region [used=0MB, free=100%, comm=40MB]
^--   Default_Region region [used=260MB, free=47,97%, comm=500MB]
{code}
And it also used to report "Non heap" metrics which were removed in IGNITE-9305.

This has several issues
1. "PageMemory" line alone doesn't help to understand the Ignite off-heap 
memory usage - page size is needed to calculated the used size, and maxSize of 
the data regions are needed to calculate the amount of the memory left.
2. "Non heap" could actually be useful. The line used to show "free=-1%" in 
most setups. This is because metaspace pool of the JVM is not limited by 
default which makes the total size unlimited. In general, it would be good to 
see distribution among the non-heap pools (metaspace, direct buffers) to be 
able to tune JVM settings accordingly.

Let's do the following:
- Don't print "PageMemory" line - it's cryptic and adds little value to the 
"Off-heap" section
- Bring "Non heap" back in some way
-- Don't print "free=-1%" - either print "N/A" or don't print "free" at all
-- Add a suggestion to limit metaspace (same as we do for direct memory) - 
which will enable correct "free" calculation
-- Look into possibility of showing distinct metrics for direct memory and 
metaspace, so that the user can tell which to tune



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-11532) Performance trace of executed query

[Yury Gerzhedovich (JIRA)]

Yury Gerzhedovich created IGNITE-11532:
--

 Summary: Performance trace of executed query
 Key: IGNITE-11532
 URL: https://issues.apache.org/jira/browse/IGNITE-11532
 Project: Ignite
  Issue Type: Task
Reporter: Yury Gerzhedovich


Need to add ability to trace and view performance of execution of SQL query 
with splitting by sql fragments.

 

Additional details will be added after more deep investigate what exists in 
products another DB vendors.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-11531) Merge concurrent registrations of the same binary type

[Denis Mekhanikov (JIRA)]

Denis Mekhanikov created IGNITE-11531:
-

 Summary: Merge concurrent registrations of the same binary type
 Key: IGNITE-11531
 URL: https://issues.apache.org/jira/browse/IGNITE-11531
 Project: Ignite
  Issue Type: Improvement
  Components: binary
Reporter: Denis Mekhanikov


When a binary type is registered multiple times simultaneously, then a lot of 
type versions are generated with the same schema. It leads to long binary type 
registration especially on big topologies.

The following code sample demonstrates the problem:
{code:java}
public class LongRegistration {
public static void main(String[] args) throws InterruptedException {
Ignite ignite = Ignition.start(igniteConfig());

int threadsNum = 50;

ExecutorService exec = Executors.newFixedThreadPool(threadsNum);

CyclicBarrier barrier = new CyclicBarrier(threadsNum);

long startTime = System.currentTimeMillis();

// register(ignite);

for (int i = 0; i < threadsNum; i++)
exec.submit(new TypeRegistrator(ignite, barrier));

exec.shutdown();
exec.awaitTermination(Long.MAX_VALUE, TimeUnit.SECONDS);

System.out.println("Total registration time: " + 
(System.currentTimeMillis() - startTime));
}

private static IgniteConfiguration igniteConfig() {
IgniteConfiguration igniteCfg = new IgniteConfiguration();

TcpDiscoveryVmIpFinder ipFinder = new TcpDiscoveryVmIpFinder();

ipFinder.setAddresses(Collections.singletonList("127.0.0.1:47500..47509"));

TcpDiscoverySpi discoverySpi = new TcpDiscoverySpi();
discoverySpi.setLocalAddress("127.0.0.1");
discoverySpi.setLocalPort(47500);
discoverySpi.setIpFinder(ipFinder);

igniteCfg.setDiscoverySpi(discoverySpi);

return igniteCfg;
}

private static void register(Ignite ignite) {
long startTime = System.currentTimeMillis();

IgniteBinary binary = ignite.binary();

BinaryObjectBuilder builder = binary.builder("TestType");

builder.setField("intField", 1);

builder.build();

System.out.println("Registration time: " + (System.currentTimeMillis() 
- startTime));
}

private static class TypeRegistrator implements Runnable {
private Ignite ignite;
private CyclicBarrier cyclicBarrier;

TypeRegistrator(Ignite ignite, CyclicBarrier cyclicBarrier) {
this.ignite = ignite;
this.cyclicBarrier = cyclicBarrier;
}

@Override public void run() {
try {
cyclicBarrier.await();

register(ignite);
} catch (InterruptedException | BrokenBarrierException e) {
e.printStackTrace();
}
}
}
}
{code}

This code sample leads to registration of 50 versions of the same type. The 
effect is more noticeable if a cluster contains a lot of nodes.

If you uncomment the call to {{register()}} method, then overall registration 
becomes 10 times faster on topology of 5 nodes.

Registration of matching types should be merged to avoid long processing of 
such cases.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-11530) SQL Index performance monitoring

[Yury Gerzhedovich (JIRA)]

Yury Gerzhedovich created IGNITE-11530:
--

 Summary: SQL Index performance monitoring
 Key: IGNITE-11530
 URL: https://issues.apache.org/jira/browse/IGNITE-11530
 Project: Ignite
  Issue Type: Task
  Components: sql
Reporter: Yury Gerzhedovich
 Fix For: 2.8


We need to gather performance statistics for SQL indexes.

Consider at least BTREE indexes, however may be we can also do it for all other 
types of indexes.

It should be at least number of look up, scans, inline miss.

Also need to investigate which statistics can be added here.

 

After the ticket will be done we should expose it through JMX and SQL system 
view.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-11529) SQL: Deprecate SqlQuery for nodejs platform

[Taras Ledkov (JIRA)]

Taras Ledkov created IGNITE-11529:
-

 Summary: SQL: Deprecate SqlQuery for nodejs platform
 Key: IGNITE-11529
 URL: https://issues.apache.org/jira/browse/IGNITE-11529
 Project: Ignite
  Issue Type: Task
  Components: platforms
Affects Versions: 2.7
Reporter: Taras Ledkov
 Fix For: 2.8


This API is very limited comparing to SqlFieldsQuery. Let's deprecate it with 
proper links to SqlFieldsQuery. This should be not only deprecation on public 
API, but removal from examples as well.

Parent ticket: IGNITE-11334
Ticket for documentation: IGNITE-11370




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-11528) SQL: Deprecate SqlQuery for python platform

[Taras Ledkov (JIRA)]

Taras Ledkov created IGNITE-11528:
-

 Summary: SQL: Deprecate SqlQuery for python platform
 Key: IGNITE-11528
 URL: https://issues.apache.org/jira/browse/IGNITE-11528
 Project: Ignite
  Issue Type: Task
  Components: platforms
Affects Versions: 2.7
Reporter: Taras Ledkov
 Fix For: 2.8


This API is very limited comparing to SqlFieldsQuery. Let's deprecate it with 
proper links to SqlFieldsQuery. This should be not only deprecation on public 
API, but removal from examples as well.

Parent ticket: IGNITE-11334
Ticket for documentation: IGNITE-11370




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-11527) SQL: Deprecate SqlQuery for php platform

[Taras Ledkov (JIRA)]

Taras Ledkov created IGNITE-11527:
-

 Summary: SQL: Deprecate SqlQuery for php platform
 Key: IGNITE-11527
 URL: https://issues.apache.org/jira/browse/IGNITE-11527
 Project: Ignite
  Issue Type: Task
  Components: platforms
Reporter: Taras Ledkov


This API is very limited comparing to SqlFieldsQuery. Let's deprecate it with 
proper links to SqlFieldsQuery. This should be not only deprecation on public 
API, but removal from examples as well.

Parent ticket: IGNITE-11334
Ticket for documentation: IGNITE-11370




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-11526) SQL: Deprecate SqlQuery for c++ platform

[Taras Ledkov (JIRA)]

Taras Ledkov created IGNITE-11526:
-

 Summary: SQL: Deprecate SqlQuery for c++ platform
 Key: IGNITE-11526
 URL: https://issues.apache.org/jira/browse/IGNITE-11526
 Project: Ignite
  Issue Type: Task
  Components: platforms
Reporter: Taras Ledkov
 Fix For: 2.8


This API is very limited comparing to SqlFieldsQuery. Let's deprecate it with 
proper links to SqlFieldsQuery. This should be not only deprecation on public 
API, but removal from examples as well.

Parent ticket: IGNITE-11334
Ticket for documentation: IGNITE-11370




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-11525) SQL: Deprecate SqlQuery for .NET platform

[Taras Ledkov (JIRA)]

Taras Ledkov created IGNITE-11525:
-

 Summary: SQL: Deprecate SqlQuery for .NET platform
 Key: IGNITE-11525
 URL: https://issues.apache.org/jira/browse/IGNITE-11525
 Project: Ignite
  Issue Type: Task
  Components: platforms
Reporter: Taras Ledkov


This API is very limited comparing to SqlFieldsQuery. Let's deprecate it with 
proper links to SqlFieldsQuery. This should be not only deprecation on public 
API, but removal from examples as well.

Parent ticket: IGNITE-11334
Ticket for documentation: IGNITE-11370



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-11524) Memory leak caused by executing an jdbc prepared statement

[Pavel Vinokurov (JIRA)]

Pavel Vinokurov created IGNITE-11524:


 Summary: Memory leak caused by executing an jdbc prepared statement
 Key: IGNITE-11524
 URL: https://issues.apache.org/jira/browse/IGNITE-11524
 Project: Ignite
  Issue Type: Bug
  Components: sql, thin client
Reporter: Pavel Vinokurov
 Fix For: 2.7
 Attachments: PreparedStatementOOMReproducer.java

Executing a prepared statement multiple times lead to OOM.
VisualVM indicates that heap contains  a lot of JdbcThinPreparedStatament 
objects.

The reproducer is attached.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)