[jira] [Created] (IGNITE-9137) Web console: UI of 'select node' modal a little bit broken

[Pavel Konstantinov (JIRA)]

Pavel Konstantinov created IGNITE-9137:
--

 Summary: Web console: UI of 'select node' modal a little bit broken
 Key: IGNITE-9137
 URL: https://issues.apache.org/jira/browse/IGNITE-9137
 Project: Ignite
  Issue Type: Bug
  Components: wizards
Reporter: Pavel Konstantinov
Assignee: Dmitriy Shabalin
 Attachments: screenshot-1.png





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

[jira] [Created] (IGNITE-9136) Web console: hide\disable cluster activation switcher if cluster has no persistent configuration

[Pavel Konstantinov (JIRA)]

Pavel Konstantinov created IGNITE-9136:
--

 Summary: Web console: hide\disable cluster activation switcher if 
cluster has no persistent configuration
 Key: IGNITE-9136
 URL: https://issues.apache.org/jira/browse/IGNITE-9136
 Project: Ignite
  Issue Type: Bug
  Components: wizards
Reporter: Pavel Konstantinov
Assignee: Alexey Kuznetsov


I faced with exception when tried to activate a cluster of version 7.x due to 
that version of ignite has no persistent at all.
{code}
Caused by: java.lang.ClassNotFoundException: 
org.apache.ignite.internal.visor.misc.VisorChangeGridActiveStateTaskArg
at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:349)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:264)
at 
org.apache.ignite.internal.visor.compute.VisorGatewayTask$VisorGatewayJob.execute(VisorGatewayTask.java:313)
... 21 more
{code}



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

Re: Thin Client lib: Python

[Dmitriy Setrakyan]

Now we are talking. A much better and more user-friendly API.

D.

On Fri, Jul 27, 2018 at 7:19 AM, Dmitry Melnichuk <
dmitry.melnic...@nobitlost.com> wrote:

> Dmitriy, Igor, Ilya, Sergey!
>
> Thank you for sharing your ideas, concerns and criticism with me. I do
> appreciate it.
>
> I already made some changes in my API, influenced by your feedback. I also
> plan to add a certain set of features, that will make my UX closer to what
> you can see from other Ignite clients.
>
> I stopped using `hashcode` in my examples. Integer cache IDs and cache
> names now can be used interchangeably, with primary focus on cache names.
>
> I will add a Cache class as a primary interface for cache operations, so
> that earlier examples:
>
> ```
> conn = Connection()
> conn.connect('127.0.0.1', 10800)
>
> cache_create(conn, 'my cache')
>
> cache_put(conn, 'my cache', 'my key', 42)
> result = my_cache.get('my key')
>
> cache_destroy(conn, 'my cache')
> conn.close()
> ```
>
> could be reiterated as:
>
> ```
> conn = Connection()
> conn.connect('127.0.0.1', 10800)
>
> my_cache = conn.create_cache('my cache')
>
> my_cache.put('my key', 42)
> result = my_cache.get('my key')
>
> my_cache.destroy('my cache')
> conn.close()
> ```
>
> I will also make `Connection.connect()` accept any iterable (including
> simple list) as a connection parameter. I will provide user with some basic
> connection generators instead of what is done in my current connection
> failover example.
>
>
> On 07/27/2018 07:41 AM, Dmitriy Setrakyan wrote:
>
>> Dmitriy,
>>
>> I would stop using the word "hashcode" in this context. Hash code has a
>> special meaning in Ignite and is used to determine key-to-node affinity. I
>> agree that passing "cache_name" is the best option. I have no idea when
>> "cache_name" is not going to be known and do not think we need to support
>> this case at all. My suggestion is to drop the cache_id use case
>> altogether.
>>
>> Also I am really surprised that we do not have a cache abstraction in
>> python and need to pass cache name and connection into every method. To be
>> honest, this smells really bad that such a popular modern language like
>> Python forces us to have such a clumsy API. Can you please take a look at
>> the Redis python clients and see if there is a better way to support this?
>>
>> https://redis.io/clients#python
>>
>> D.
>>
>

automatic node failure

[Dmitriy Setrakyan]

Igniters,

I remember that we have added automatic node failure in case of unknown
errors or events that may be fatal. Does this extend to the actual user
exceptions?

The reason I am asking is because of this thread on SO:
https://stackoverflow.com/questions/51556794/ignite-server-node-crashes-on-
throwing-user-defined-exceptions-from-the-cache-st

Andrey Gura, as the expert on the automatic node failure feature, can you
please comment?

D.

[jira] [Created] (IGNITE-9135) TcpDiscovery - High Workload in Stable topology

[Sergey Kosarev (JIRA)]

Sergey Kosarev created IGNITE-9135:
--

 Summary: TcpDiscovery - High Workload in Stable topology
 Key: IGNITE-9135
 URL: https://issues.apache.org/jira/browse/IGNITE-9135
 Project: Ignite
  Issue Type: Bug
Reporter: Sergey Kosarev


On High topology (about 200 servers/ 50 clients) we see often  via jmx 
(TcpDiscoverySpiMBean) high MessageWorkerQueueSize peaks (>100) in stable 
cluster topology. Also very high number (about 25) of ProcesedMessages, 
ReceivedMessages for TcpDiscoveryStatusCheckMessage, whereas 
TcpDiscoveryMetricsUpdateMessage is about 11.

it looks like

org.apache.ignite.spi.discovery.tcp.ServerImpl.RingMessageWorker#metricsCheckFreq

value does not depend on topology size

private long metricsCheckFreq = 3 * spi.metricsUpdateFreq + 50;

 

 

 



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

Re: [jira] [Assigned] (IGNITE-9113) Allocate memory for a data region when first cache assigned to this region is created

[Dmitriy Setrakyan]

Dmitriy,

I am still struggling to understand which portion of the code of conduct is
being violated. BTW, this point was raised during the Ignite incubation
process and the community agreed that it is up to the project community
itself to decide on the best process here. This is not an Apache matter (I
am too lazy to look for the thread now).

I have been on this project long enough to have a good understanding who in
the community has the best knowledge to fix a certain issue. When an issue
requires strong domain expertise, I will assign a ticket to a certain
domain expert to ensure that he or she are at least aware of it and try to
address it. If they cannot, then they can always unassign it.

I also use the table at the bottom of this page to find out domain experts
on different sections of the project:
https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute

BTW, this ticket in particular is absolutely not a casual newbie ticket and
can have dire consequences on the project quality if done wrong. Therefore,
I have picked the best domain expert to implement it or at least to comment
on it. I will assign it back to AG, unless we decide as a community that it
is a wrong process.

If you disagree with the process, please do not unassign any ticket
yourself. Feel free to start a separate discussion and we can have a PMC or
community decision on it.

D.

On Mon, Jul 30, 2018 at 3:22 AM, Dmitriy Pavlov 
wrote:

> Hi Dmitriy, Igniters,
>
> I would like to ask an assistance from experienced Ignite contributors
> here. I'm still trying to find clear reference on that.
>
> In the same time I beleive that assignment to other person, who probably
> will not work on issue, confronts at least with Code of conduct
> http://www.apache.org/foundation/policies/conduct.html This policy is to
> be
> followed in spirit as much as in the letter.
>
> Assigning issue means no one else in the community can begin working on it.
> Let's suppose contributor would like to complete issue, than he or she will
> have to ask assignee to move issue to unassigned before he or she can
> start. It is not welcoming and discourage people from contribution.
>
> So my proposal is as follows:
> - to encourage particular contibutor to pay attention let's use
>  -- direct mention in issue comments (it has almost the same effect: email
> will be sent)
> --  dev. list and CC to contributor's email
>
> - and keep ticket unassigned
> -- until contributor starts
> -- or going to start actual implementation.
>
> Sincerely,
> Dmitriy Pavlov
>
> сб, 28 июл. 2018 г. в 15:50, Dmitriy Setrakyan :
>
> > On Sat, Jul 28, 2018 at 2:20 AM, Dmitriy Pavlov 
> > wrote:
> >
> > > Hi Dmitriy,
> > >
> > > As far as I know this approach is contlicting with the Apache Way. We
> > > should be absolutely sure that assignee is agree and going to do this
> > task.
> > > But in our case domain expert did not replied to dev list topic.
> > >
> >
> > I do not see any conflict with any Apache rule at all. By assigning a
> > ticket to someone I am suggesting that as a domain expert it is
> preferable
> > that he or she looks at it. If not, these people can un-assign or
> reassign
> > the ticket.
> >
> > If you believe there is a conflict with some Apache principle, please
> > provide a link so we could all learn about it.
> >
> > To solve lost ticket problem I suggest to use dev. list and bumping
> up/ping
> > > messages.
> > >
> >
> > Agree, I do that too.
> >
> >
> > > I hope it makes sense to you. If not, I will do my absolute best to
> find
> > > out corresponding ASF policy.
> > >
> >
> > Please do.
> >
> >
> > >
> > > Sincerely,
> > > Dmitriy Pavlov
> > >
> > > сб, 28 июл. 2018 г. в 3:28, Dmitriy Setrakyan :
> > >
> > > > On Fri, Jul 27, 2018 at 3:02 PM, Dmitriy Pavlov <
> dpavlov@gmail.com
> > >
> > > > wrote:
> > > >
> > > > > Hi Igniters,
> > > > >
> > > > > I would discourage all Igniters from direct assigning issues to
> > anyone
> > > > > else. Of cource excepting the case it was directly discussed with
> > > > asignee.
> > > > > Any contributor should be able to assign issue to himself.
> > > > >
> > > > > I left issue unassigned until Alex G would assign it.
> > > > >
> > > >
> > > > Dmitriy, I disagree. If there is a domain expert, then the issue
> should
> > > be
> > > > assigned to him/her whenever possible. If that person is too busy,
> > he/she
> > > > could ask someone else for help. This way the tickets will get
> > attention
> > > > faster and will get resolved faster.
> > > >
> > > > https://issues.apache.org/jira/browse/IGNITE-9113
> > > >
> > > > D.
> > > >
> > >
> >
>

[jira] [Created] (IGNITE-9134) ZookeeperDiscoverySpiTest#testLargeUserAttribute3 fails with OOME

[Vitaliy Biryukov (JIRA)]

Vitaliy Biryukov created IGNITE-9134:


 Summary: ZookeeperDiscoverySpiTest#testLargeUserAttribute3 fails 
with OOME
 Key: IGNITE-9134
 URL: https://issues.apache.org/jira/browse/IGNITE-9134
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.6
Reporter: Vitaliy Biryukov
Assignee: Vitaliy Biryukov
 Fix For: 2.7






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

[jira] [Created] (IGNITE-9133) SQL TX: Proper empty DHT transactions handling.

[Roman Kondakov (JIRA)]

Roman Kondakov created IGNITE-9133:
--

 Summary: SQL TX: Proper empty DHT transactions handling.
 Key: IGNITE-9133
 URL: https://issues.apache.org/jira/browse/IGNITE-9133
 Project: Ignite
  Issue Type: Bug
Reporter: Roman Kondakov


In the cases when DHT transaction is empty (i.e. no keys were enlisted) after 
the enlist step, we need to rollback local DHT transaction to exclude it from 
the further transaction flow in order to performance increasing.

An ordinary Dht tx rollback {{GridDhtTxLocal#rollbackDhtLocalAsync}} is not 
suitable in this situation because it adds tx to 
{{IgniteTxManager#completedVersHashMap}} which is unacceptable because this 
action prevents possible Dht transaction creation if the next tx statements 
enlist some keys at this node in the future. As well as direct tx map cleaning 
by means of {{IgniteTxManager#rollbackTx(tx, true, true)}} is not an aid 
because leads to grid hanging due to undiscovered reasons.  In order to 
reproduce hanging you need to reapply commit d231a81 and run 
{{CacheMvccPartitionedSqlCoordinatorFailoverTest}}. Example of hanged thread 
stack is listed below.

Our goal is the proper Dht transaction rollback without adding it to 
{{IgniteTxManager#completedVersHashMap.}}
{code:java}
Thread [name="writer-2", id=2281, state=WAITING, blockCnt=40, waitCnt=10260]
at sun.misc.Unsafe.park(Native Method)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
at 
o.a.i.i.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:177)
at o.a.i.i.util.future.GridFutureAdapter.get(GridFutureAdapter.java:140)
at 
o.a.i.i.processors.query.h2.DmlStatementsProcessor.executeUpdateStatement(DmlStatementsProcessor.java:560)
at 
o.a.i.i.processors.query.h2.DmlStatementsProcessor.updateSqlFields(DmlStatementsProcessor.java:185)
at 
o.a.i.i.processors.query.h2.DmlStatementsProcessor.updateSqlFieldsDistributed(DmlStatementsProcessor.java:358)
at 
o.a.i.i.processors.query.h2.IgniteH2Indexing.doRunPrepared(IgniteH2Indexing.java:2132)
at 
o.a.i.i.processors.query.h2.IgniteH2Indexing.querySqlFields(IgniteH2Indexing.java:2083)
at 
o.a.i.i.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:2139)
at 
o.a.i.i.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:2134)
at o.a.i.i.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
at 
o.a.i.i.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:2682)
at 
o.a.i.i.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:2148)
at 
o.a.i.i.processors.cache.IgniteCacheProxyImpl.query(IgniteCacheProxyImpl.java:668)
at 
o.a.i.i.processors.cache.IgniteCacheProxyImpl.query(IgniteCacheProxyImpl.java:619)
at 
o.a.i.i.processors.cache.GatewayProtectedCacheProxy.query(GatewayProtectedCacheProxy.java:388)
at 
o.a.i.i.processors.cache.mvcc.CacheMvccAbstractTest.removeSql(CacheMvccAbstractTest.java:832)
at 
o.a.i.i.processors.cache.mvcc.CacheMvccAbstractTest.access$400(CacheMvccAbstractTest.java:104)
at 
o.a.i.i.processors.cache.mvcc.CacheMvccAbstractTest$2.apply(CacheMvccAbstractTest.java:494)
at 
o.a.i.i.processors.cache.mvcc.CacheMvccAbstractTest$2.apply(CacheMvccAbstractTest.java:401)
at 
o.a.i.i.processors.cache.mvcc.CacheMvccAbstractTest$9.call(CacheMvccAbstractTest.java:1294)
at 
o.a.i.i.processors.cache.mvcc.CacheMvccAbstractTest$9.call(CacheMvccAbstractTest.java:1289)
at o.a.i.testframework.GridTestThread.run(GridTestThread.java:86)
{code}
 



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

[GitHub] ignite pull request #4450: IGNITE-9127: ZooKeeper (Discovery) 1 timeout.

[asfgit]

Github user asfgit closed the pull request at:

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


---

[jira] [Created] (IGNITE-9132) Update Apache Camel dependency version

[Dmitriy Pavlov (JIRA)]

Dmitriy Pavlov created IGNITE-9132:
--

 Summary: Update Apache Camel dependency version
 Key: IGNITE-9132
 URL: https://issues.apache.org/jira/browse/IGNITE-9132
 Project: Ignite
  Issue Type: Task
Reporter: Dmitriy Pavlov
Assignee: Dmitriy Pavlov
 Fix For: 2.7


Upgrade Apache Camel Dependency to version 2.20.1 or later.



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

[GitHub] ignite pull request #4458: IGNITE-9130: Test fixed.

[BiryukovVA]

GitHub user BiryukovVA opened a pull request:

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

IGNITE-9130: Test fixed.



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/BiryukovVA/ignite IGNITE-9130

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/4458.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #4458


commit d077e8c0af3ee2a7c3d5cef41005b451c205a708
Author: Vitaliy Biryukov 
Date:   2018-07-30T16:48:42Z

IGNITE-9130: Test fixed.




---

[GitHub] ignite pull request #4457: IGNITE-9129 Request for user-classes with enabled...

[Jokser]

GitHub user Jokser opened a pull request:

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

IGNITE-9129 Request for user-classes with enabled P2P only after local node 
join



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/gridgain/apache-ignite ignite-9129

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/4457.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #4457


commit 60f3e7fd019b3c5d7c86f0cfc57f89eaf15a78e4
Author: Pavel Kovalenko 
Date:   2018-07-30T16:37:13Z

IGNITE-9129 Request for user-classes with enabled P2P asynchronously after 
local node join




---

[jira] [Created] (IGNITE-9131) Upgrade guava version in Apache Ignite

[Dmitriy Pavlov (JIRA)]

Dmitriy Pavlov created IGNITE-9131:
--

 Summary: Upgrade guava version in Apache Ignite
 Key: IGNITE-9131
 URL: https://issues.apache.org/jira/browse/IGNITE-9131
 Project: Ignite
  Issue Type: Task
Reporter: Dmitriy Pavlov
 Fix For: 2.7


In most cases guava is used only for testing, but for some modules it is used 
for production code.

Current version is 18 
https://mvnrepository.com/artifact/com.google.guava/guava/18.0, which was 
released in 2014.

It is suggested to upgrade to fresh version of library, e.g. to 
https://mvnrepository.com/artifact/com.google.guava/guava/25.1-jre 




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

[jira] [Created] (IGNITE-9130) ZookeeperDiscoverySpiTest#testDuplicatedNodeId fails

[Vitaliy Biryukov (JIRA)]

Vitaliy Biryukov created IGNITE-9130:


 Summary: ZookeeperDiscoverySpiTest#testDuplicatedNodeId fails
 Key: IGNITE-9130
 URL: https://issues.apache.org/jira/browse/IGNITE-9130
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.6
Reporter: Vitaliy Biryukov
Assignee: Vitaliy Biryukov






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

[jira] [Created] (IGNITE-9129) P2P class deployment is failed when using ZK discovery

[Pavel Kovalenko (JIRA)]

Pavel Kovalenko created IGNITE-9129:
---

 Summary: P2P class deployment is failed when using ZK discovery
 Key: IGNITE-9129
 URL: https://issues.apache.org/jira/browse/IGNITE-9129
 Project: Ignite
  Issue Type: Bug
  Components: cache
Affects Versions: 2.6, 2.5
Reporter: Pavel Kovalenko
Assignee: Pavel Kovalenko
 Fix For: 2.7


In case of using Zookeeper Discovery, cluster node which joins to a cluster 
receives information that some user-classes have been already deployed but 
doesn't exist in the local classpath. In this case, the node tries to request 
for these classes from nodes that contain it, but do it synchronously during 
Zookeeper Discovery starting and gets NullPointer when first topology snapshot 
has not initialized yet.
We should request for user-classes asynchronously and only after the first 
topology has initialized.



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

Re: SSLParameters for SslContextFactory

[Ilya Kasnacheev]

Hello!

Thank you! I have commented your change: setProtocols is still redundant
since we have protocol in sslContextFactory.

BTW, there is a caveat with ciphers list: by default SSL will fail if you
ever list a cipher there that is not present in current JVM, even if the
rest of them are present and can be used. Thus the configuration becomes
fragile. However I don't think it's our job to take care of that.

Regards,

-- 
Ilya Kasnacheev

2018-07-30 18:12 GMT+03:00 Michael Cherkasov :

> Hi all,
>
> as was suggested, I removed all mention about SSLParameters and replaced it
> with a simple String[].
> I added configurations for protocols and cipher suites.
>
> Please, review .
>
> Thanks,
> Mike.
>
>
>
> 2018-07-30 13:58 GMT+03:00 Vladimir Ozerov :
>
> > Agree. It is much easier for user to set a collection of strings
> > (especially from Spring), rather than construct some complex Java 8
> object.
> > Also we need to remember that this feature should be propagated to all
> thin
> > clients and .NET integration. String getter/setter is only way to
> maintain
> > API consistency across various platforms.
> >
> > On Thu, Jul 26, 2018 at 9:16 PM Ilya Kasnacheev <
> ilya.kasnach...@gmail.com
> > >
> > wrote:
> >
> > > Hello!
> > >
> > > I really dislike the fact that SSLParameters has 6 setter methods, and
> we
> > > only support one of them, when two more clash with SSL settings which
> are
> > > set elsewhere.
> > >
> > > I.e. what happens if I pass SSLParameters with
> setAlgorithmConstraints()
> > or
> > > setProtocols() called on them?
> > >
> > > Is it possible that we will just have an array of allowed ciphers in
> > > configuration?
> > >
> > > Regards,
> > >
> > > --
> > > Ilya Kasnacheev
> > >
> > > 2018-07-26 20:16 GMT+03:00 Michael Cherkasov <
> > michael.cherka...@gmail.com
> > > >:
> > >
> > > > Hi all,
> > > >
> > > > I want to add SSLParameters for SslContextFactory.
> > > >
> > > > Right now there's no way to specify a particular set of cipher suites
> > > that
> > > > you want to use.
> > > > there's even old request to add this functionality:
> > > > https://issues.apache.org/jira/browse/IGNITE-6167
> > > > even with current API you can achieve this, but this requires a lot
> of
> > > > boilerplate code, to avoid this I added SSLParameters, that would be
> > > > applied to all SSL connections, please review my pull request:
> > > > https://github.com/apache/ignite/pull/4440
> > > >
> > > > I think this patch covers 6167, so I want to push it in context of
> this
> > > > ticket.
> > > >
> > > > Thanks,
> > > > Mike.
> > > >
> > >
> >
>

[jira] [Created] (IGNITE-9128) Continuous query handlers don't clean up after cache was stopped.

[Pavel Pereslegin (JIRA)]

Pavel Pereslegin created IGNITE-9128:


 Summary: Continuous query handlers don't clean up after cache was 
stopped.
 Key: IGNITE-9128
 URL: https://issues.apache.org/jira/browse/IGNITE-9128
 Project: Ignite
  Issue Type: Bug
  Components: cache
Affects Versions: 2.6
Reporter: Pavel Pereslegin


Continuous query handlers don't clean up after the cache was stopped.

Reproducer shows resource leak:
{code:java}
public class Reproducer extends GridCommonAbstractTest {
/** */
private static final String CACHE1 = "cache1";

/** */
public void testCacheRecreate() throws Exception {
IgniteEx node = startGrid(0);

int hndCntr = 0;

try {
for (int i = 0; i < 100; i++) {
IgniteCache cache = node.createCache(CACHE1);

cache.query(new ContinuousQuery<>().setLocalListener(evts -> 
{}));

cache.put(1, 1);

cache.destroy();
}

for (Object locInfo : ((Map)U.field(node.context().continuous(), 
"locInfos")).values()) {
GridContinuousHandler hnd = U.field(locInfo, "hnd");

if (CACHE1.equals(hnd.cacheName()))
++hndCntr;
}

assertEquals("No local handlers expected after cache was stopped.", 
0, hndCntr);
}
finally {
stopAllGrids();
}
}
}
{code}

Output:
{noformat}
junit.framework.AssertionFailedError: No local handlers expected after cache 
was stopped. 
Expected :0
Actual   :100
{noformat}




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

Re: SSLParameters for SslContextFactory

[Michael Cherkasov]

Hi all,

as was suggested, I removed all mention about SSLParameters and replaced it
with a simple String[].
I added configurations for protocols and cipher suites.

Please, review .

Thanks,
Mike.



2018-07-30 13:58 GMT+03:00 Vladimir Ozerov :

> Agree. It is much easier for user to set a collection of strings
> (especially from Spring), rather than construct some complex Java 8 object.
> Also we need to remember that this feature should be propagated to all thin
> clients and .NET integration. String getter/setter is only way to maintain
> API consistency across various platforms.
>
> On Thu, Jul 26, 2018 at 9:16 PM Ilya Kasnacheev  >
> wrote:
>
> > Hello!
> >
> > I really dislike the fact that SSLParameters has 6 setter methods, and we
> > only support one of them, when two more clash with SSL settings which are
> > set elsewhere.
> >
> > I.e. what happens if I pass SSLParameters with setAlgorithmConstraints()
> or
> > setProtocols() called on them?
> >
> > Is it possible that we will just have an array of allowed ciphers in
> > configuration?
> >
> > Regards,
> >
> > --
> > Ilya Kasnacheev
> >
> > 2018-07-26 20:16 GMT+03:00 Michael Cherkasov <
> michael.cherka...@gmail.com
> > >:
> >
> > > Hi all,
> > >
> > > I want to add SSLParameters for SslContextFactory.
> > >
> > > Right now there's no way to specify a particular set of cipher suites
> > that
> > > you want to use.
> > > there's even old request to add this functionality:
> > > https://issues.apache.org/jira/browse/IGNITE-6167
> > > even with current API you can achieve this, but this requires a lot of
> > > boilerplate code, to avoid this I added SSLParameters, that would be
> > > applied to all SSL connections, please review my pull request:
> > > https://github.com/apache/ignite/pull/4440
> > >
> > > I think this patch covers 6167, so I want to push it in context of this
> > > ticket.
> > >
> > > Thanks,
> > > Mike.
> > >
> >
>

[jira] [Created] (IGNITE-9127) ZooKeeper (Discovery) 1 suite hang.

[Vitaliy Biryukov (JIRA)]

Vitaliy Biryukov created IGNITE-9127:


 Summary: ZooKeeper (Discovery) 1 suite hang.
 Key: IGNITE-9127
 URL: https://issues.apache.org/jira/browse/IGNITE-9127
 Project: Ignite
  Issue Type: Bug
Reporter: Vitaliy Biryukov
Assignee: Vitaliy Biryukov






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

[jira] [Created] (IGNITE-9126) Update Apache Kafka dependency

[Dmitriy Pavlov (JIRA)]

Dmitriy Pavlov created IGNITE-9126:
--

 Summary: Update Apache Kafka dependency
 Key: IGNITE-9126
 URL: https://issues.apache.org/jira/browse/IGNITE-9126
 Project: Ignite
  Issue Type: Task
Reporter: Dmitriy Pavlov
Assignee: Dmitriy Pavlov
 Fix For: 2.7


It is suggested to update kafka in accordance with scala update, e.g. to
https://mvnrepository.com/artifact/org.apache.kafka/kafka_2.11/1.0.2




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

[jira] [Created] (IGNITE-9125) MVCC SQL: Streaming SQL data load operations support

[Ivan Pavlukhin (JIRA)]

Ivan Pavlukhin created IGNITE-9125:
--

 Summary: MVCC SQL: Streaming SQL data load operations support
 Key: IGNITE-9125
 URL: https://issues.apache.org/jira/browse/IGNITE-9125
 Project: Ignite
  Issue Type: Improvement
Reporter: Ivan Pavlukhin
Assignee: Ivan Pavlukhin


Since DataStreamer is already enabled for MVCC COPY command and *streaming* 
INSERT operations should be enabled.



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

[GitHub] ignite pull request #4456: Ignite 2.5.1 p12

[vldpyatkov]

GitHub user vldpyatkov opened a pull request:

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

Ignite 2.5.1 p12



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/gridgain/apache-ignite ignite-2.5.1-p12

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/4456.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #4456


commit b6ad3705c1e68683b72d2237037af66fea23a7ae
Author: devozerov 
Date:   2018-04-11T13:44:33Z

IGNITE-8148: JDBC thin: semicolon as delimiter for properties. This closes 
#3794.

commit e6c30e17c6f0f1852fa781078ee54ccf8c654846
Author: Pavel Kovalenko 
Date:   2018-04-11T11:12:50Z

IGNITE-7871 Check local join future on error. - Fixes #3793.

Signed-off-by: dpavlov 

commit 2769981a5df64f3cd0c38b7599c49580c66192fa
Author: Aleksey Plekhanov 
Date:   2018-04-11T15:24:51Z

IGNITE-6892 OOM should be covered by failure handling

Signed-off-by: Andrey Gura 

commit 687194461f445be9902752f38f873d321cde1d85
Author: Ilya Borisov 
Date:   2018-04-06T04:17:05Z

IGNITE-7996 Move configuration form templates.

(cherry picked from commit c2c03a9)

commit 9955728a72e0f9c11faa313a521d4566b5a93dc1
Author: Ilya Borisov 
Date:   2018-04-06T04:19:07Z

IGNITE-7996 Move config state module index.

(cherry picked from commit d5e0be0)

commit 536d8b2080b93505e67206a240385baced150674
Author: Ilya Borisov 
Date:   2018-04-06T04:20:13Z

IGNITE-7996 Use configuration.state for state registration only.

(cherry picked from commit 2800ef0)

commit a2d9f97c0ae77e81344849bc2c3cba2d3964cf01
Author: Ilya Borisov 
Date:   2018-04-06T04:20:39Z

IGNITE-7996 Rename configuration.state to states.

(cherry picked from commit 14dd2df)

commit 1d5f45b4eb900a3c4cc0bedb8919b35f2a0032c8
Author: Ilya Borisov 
Date:   2018-04-06T04:22:20Z

IGNITE-7996 Move configuration assets into page-configure module.

(cherry picked from commit d02e87b)

commit a5a83d211a572b8419866fabbc31975168157729
Author: Alexey Kuznetsov 
Date:   2018-04-12T04:21:23Z

IGNITE-7996 Merge with master.

commit dbf2d722b0563a9637cc72fe2fcdf3dbd07291fc
Author: devozerov 
Date:   2018-04-12T07:37:36Z

IGNITE-8042: .NET thin client: authentication support. This closes #3790.

commit 72259b01e0c6d72794eca4c28c9d9d848b0ff97f
Author: dmitrievanthony 
Date:   2018-04-12T08:16:22Z

IGNITE-8176: Integrate gradient descent linear regression with partition 
based dataset

this closes #3787

(cherry picked from commit df6356d)

commit f143ad0057ddb326f6d8199bf660b354913e6b61
Author: devozerov 
Date:   2018-04-12T12:02:57Z

IGNITE-8135: SQL: authentication for CREATE TABLE and DROP TABLE commands. 
This closes #3801.

commit 2c4a7a2e366d7308485ae5cc95d4b60e66b09589
Author: devozerov 
Date:   2018-04-12T12:13:51Z

IGNITE-8230: SQL: Fixed backup number propagation in CREATE TABLE command. 
This closes #3803.

commit 80f4340f61742988aaf9437eb08ed76644a1c8ca
Author: Pavel Kovalenko 
Date:   2018-04-12T11:29:43Z

IGNITE-7871 Fixed condition for cache partitions validation. - Fixes #3804.

Signed-off-by: dpavlov 

(cherry picked from commit 7a1d0ea)

commit dfe17074593d9d12cbab7b60aa73e73c37bbffb7
Author: Anton Kurbanov 
Date:   2018-04-12T17:31:50Z

IGNITE-8110 GridCacheWriteBehindStore.Flusher thread uses the wrong 
transformation from milliseconds to nanoseconds. - Fixes #3742.

Signed-off-by: dpavlov 

(cherry picked from commit adaedb4)

commit fe99497528cd040ab3b4d5f7bfc40e788393a5ed
Author: Andrey Kuznetsov 
Date:   2018-04-12T18:23:28Z

IGNITE-7983: NPE fixed in transactions

Signed-off-by: Andrey Gura 

commit 6a77dd8b182091fe4e38850098c6334597c14a6d
Author: zaleslaw 
Date:   2018-04-13T09:49:56Z

IGNITE-7829: Adopt kNN regression example to the new Partitioned Dataset

this closes #3798

(cherry picked from commit 8550d61)

commit 687ae653bd66745c49ba9f85a169e27191ddc16c
Author: Pavel Tupitsyn 
Date:   2018-04-13T09:28:19Z

IGNITE-8240 .NET: Use default scheduler when starting Tasks

This closes #3812

commit 0a64e4affae9ec2e16c3a99128985f6bd9c788cb
Author: Pavel Tupitsyn 
Date:   2018-04-13T09:44:17Z

IGNITE-8042: .NET: Thin client: authentication support - fix naming and 
inspections

commit 6072af825ca1507ad9d8143ca73e556539960e1d
Author: Pavel Tupitsyn 
Date:   2018-04-13T10:36:20Z

IGNITE-8042: .NET: Thin client: authentication support - fix 
TestAuthenticationEmptyCredentials

commit 78e7414cf568ef7e3f7567fdb74334012896b632
Author: Dmitriy Shabalin 
Date:   2018-04-13T10:55:02Z

IGNITE-8245 Fixed input appearance position with error.

(cherry picked from commit 56e3f43)

commit db3099e079022a8acc081b284f96583280742567

Re: [ML] Machine Learning Pipeline Improvement

[Alexey Zinoviev]

Could you please create a ticket for this task?

2018-07-20 16:47 GMT+06:00 Yury Babak :

> Alexey,
>
> I like this idea, this should improve usability of our ML module.
>
> Regards,
> Yury
>
>
>
> --
> Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/
>

[GitHub] ignite pull request #4455: IGNITE-9111 Do not wait for deactivation cluster ...

[Jokser]

GitHub user Jokser opened a pull request:

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

IGNITE-9111 Do not wait for deactivation cluster transition



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/gridgain/apache-ignite ignite-9111

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/4455.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #4455


commit 2a7f6501e06c9c5c2ab4db521ef4f37419d753bc
Author: Pavel Kovalenko 
Date:   2018-07-30T11:44:32Z

IGNITE-9111 Do not wait for deactivation.

commit 247b8babb49baecc00e91d541dd9f3cecda5675e
Author: Pavel Kovalenko 
Date:   2018-07-30T13:23:03Z

IGNITE-9111 Added test.




---

[jira] [Created] (IGNITE-9124) Remove some dead code in math.exceptions and optimization packages of ML module

[Oleg Ignatenko (JIRA)]

Oleg Ignatenko created IGNITE-9124:
--

 Summary: Remove some dead code in math.exceptions and optimization 
packages of ML module
 Key: IGNITE-9124
 URL: https://issues.apache.org/jira/browse/IGNITE-9124
 Project: Ignite
  Issue Type: Task
  Components: ml
Affects Versions: 2.5
Reporter: Oleg Ignatenko


Doing code coverage analysis discovered a bit of unused code:

# in package 
[math.exceptions|https://github.com/apache/ignite/tree/master/modules/ml/src/main/java/org/apache/ignite/ml/math/exceptions]
 - classes ConvergenceException / MathIllegalStateException, 
InsufficientDataException, MathArithmeticException, MathIllegalNumberException 
/ NumberIsTooSmallException, NonPositiveDefiniteMatrixException, 
NonSymmetricMatrixException, NullArgumentException, SingularMatrixException, 
UnknownProviderException. In very early releases of ML these exceptions were 
used by some linear algebra code. This code has been very deeply reworked since 
but outdated exceptions were left hanging unattended, making rather confusing 
impression of the current API.
# in 
[optimization|https://github.com/apache/ignite/tree/master/modules/ml/src/main/java/org/apache/ignite/ml/optimization]
 - interface Updater and two classes implementing it: BarzilaiBorweinUpdater 
and SimpleUpdater. This code has left hanging after cleanup that was made for 
release 2.5 (IGNITE-8232). Per my discussion with [~dmitrievanthony] (who most 
actively maintains this package) it would be better to remove this code.

This task is to remove code mentioned above.



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

[jira] [Created] (IGNITE-9123) Update Apache commons-collections in ignite-yarn module

[Dmitriy Pavlov (JIRA)]

Dmitriy Pavlov created IGNITE-9123:
--

 Summary: Update Apache commons-collections in ignite-yarn module
 Key: IGNITE-9123
 URL: https://issues.apache.org/jira/browse/IGNITE-9123
 Project: Ignite
  Issue Type: Bug
Reporter: Dmitriy Pavlov
Assignee: Dmitriy Pavlov
 Fix For: 2.7


It seems commons-collections version is not applied to some module.

It was updated to 3.2.2 in 2016, but this update has no effect.



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

[jira] [Created] (IGNITE-9122) Control.sh transactions utility not kill hang rollback transaction

[Alexand Polyakov (JIRA)]

Alexand Polyakov created IGNITE-9122:


 Summary: Control.sh transactions utility not kill hang rollback 
transaction
 Key: IGNITE-9122
 URL: https://issues.apache.org/jira/browse/IGNITE-9122
 Project: Ignite
  Issue Type: Bug
Reporter: Alexand Polyakov


Transaction for a long time in status rollback

After run "–tx xid XID kill" nothing happens. The transaction displayed in list.



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

[jira] [Created] (IGNITE-9121) Revisit future.get() usages when process message from Communication SPI

[Pavel Kovalenko (JIRA)]

Pavel Kovalenko created IGNITE-9121:
---

 Summary: Revisit future.get() usages when process message from 
Communication SPI
 Key: IGNITE-9121
 URL: https://issues.apache.org/jira/browse/IGNITE-9121
 Project: Ignite
  Issue Type: Improvement
  Components: cache
Affects Versions: 2.6, 2.5
Reporter: Pavel Kovalenko


Currently, we use explicit synchronous future.get() when process messages from 
Communication SPI. This potentially may lead to deadlocks to thread-pool 
exhausting as was showed in IGNITE-9111 e.g.
To fix the problem we should determine all places in the code where we 
synchronously wait for some futures and try to either refactor these places or 
implement a special exception (which will contain such future) with subsequent 
retrying a runnable in low-level Communication SPI processing when future will 
be completed. 



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

Re: Relevance of IGNITE-6409

[Dmitriy Pavlov]

Hi Vladimir,

Could you please confirm if this ticket is actual AMD worth to be done.

Sincerely,
Dmitriy Pavlov

вс, 8 июл. 2018 г., 3:53 Amir Akhmedov :

> Hi Igniters,
>
> I want to work on IGNITE-6409 (SQL: bypass H2 during index update) and want
> to ask about it's status. Is it still relevant ticket to work on?
>
> Vladimir Ozerov, as a reporter, can you please give your feedback please?
>
> Thanks,
> Amir
>

[GitHub] ignite pull request #4444: IGNITE-9073 Use jackson2 dependency instead of ja...

[zzzadruga]

GitHub user zzzadruga reopened a pull request:

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

IGNITE-9073 Use jackson2 dependency instead of jackson1 and remove un…

…used dependencies

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/zzzadruga/ignite IGNITE-9073

Alternatively you can review and apply these changes as the patch at:

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

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #


commit e6c7ec4b00c6f1fb470d64f098719f513f22469c
Author: zzzadruga 
Date:   2018-07-30T11:20:55Z

IGNITE-9073 Use jackson2 dependency instead of jackson1 and remove unused 
dependencies




---

[GitHub] ignite pull request #4454: IGNITE-8939 Catch and proper propagate transactio...

[zstan]

GitHub user zstan opened a pull request:

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

IGNITE-8939 Catch and proper propagate transaction string reprsentation

i have no reproducer here, but sometimes when schema for object can`t be 
found in server side tx toString can throw exception which can lead into 
failure handler.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/gridgain/apache-ignite ignite-8939-zstan

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/4454.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #4454


commit a7dca517e72fa318c38e01cdce8d0c641151e6ba
Author: Evgeny Stanilovskiy 
Date:   2018-07-30T11:03:29Z

IGNITE-8939 Catch and proper propagate transaction string reprsentation




---

Re: Pushing forward IGNITE-6826: Change default DiscoverySpi ipFinder type for examples

[Dmitriy Pavlov]

Hi Stan,

any news on this?

Sincerely

пт, 20 июл. 2018 г., 4:12 Dmitriy Setrakyan :

> Why not use a combination of Multicast and VM finders? This way we do not
> have to make any sacrifices.
>
> D.
>
> On Wed, Jul 18, 2018 at 9:38 PM, Vladimir Ozerov 
> wrote:
>
> > TcpDiscoveryVmIpFinder can be configured with 127.0.0.1. Example with
> > remote nodes will work fine on a single machine. Users rarely run
> examples
> > on multiple machines.
> >
> > чт, 19 июля 2018 г. в 5:30, Dmitriy Setrakyan :
> >
> > > I am confused, the TcpDiscoveryVmIpFinder will only discover nodes with
> > > specified list of IPs. Don't we have examples that require remote nodes
> > to
> > > join?
> > >
> > > D.
> > >
> > > On Wed, Jul 18, 2018 at 7:52 AM, Stanislav Lukyanov <
> > > stanlukya...@gmail.com>
> > > wrote:
> > >
> > > > > It can seem not important, but saves a minute for everyone.
> > > > No, it actually does seem important when you think about it :) Thanks
> > for
> > > > the suggestion.
> > > > Let me correct this then.
> > > >
> > > > The issue is
> > > > IGNITE-6826: Change default DiscoverySpi ipFinder type for examples
> > > > https://issues.apache.org/jira/browse/IGNITE-6826
> > > > It is about changing the ipFinders used in the Ignite examples from
> > > > TcpDiscoveryMulticastIpFinder to TcpDiscoveryVmIpFinder.
> > > >
> > > > Thanks,
> > > > Stan
> > > >
> > > > From: Dmitry Pavlov
> > > > Sent: 18 июля 2018 г. 17:30
> > > > To: dev@ignite.apache.org
> > > > Cc: antkr@gmail.com; somefire...@gmail.com; ptupit...@apache.org
> > > > Subject: Re: Pushing IGNITE-6826 forward
> > > >
> > > > Hi Stanislav,
> > > >
> > > > I wish this push will have effect.
> > > >
> > > > Just two proposals that will help Igniters to easily jump into such
> > > emails:
> > > > 1. Include ticket short description into subject, not only number.
> > > > 2. Include link to JIRA issue into body so it could be easily clicked
> > to
> > > > find out details.
> > > > It can seem not important, but saves a minute for everyone.
> > > >
> > > > Sincerely,
> > > > Dmitriy Pavlov
> > > >
> > > > ср, 18 июл. 2018 г. в 16:32, Stanislav Lukyanov <
> > stanlukya...@gmail.com
> > > >:
> > > >
> > > > > Hi Igniters,
> > > > >
> > > > > There is a small but annoying issue with examples using
> > > MulticastIpFinder
> > > > > by default.
> > > > > The JIRA is  IGNITE-6826.
> > > > >
> > > > > AntonK and DmitriiR have suggested PRs to fix this, but PavelT had
> > some
> > > > > concerns and the fix stuck as the result.
> > > > >
> > > > > Pavel, could you please suggest necessary changes to the PRs so
> that
> > > guys
> > > > > can move forward with integration?
> > > > >
> > > > > Thanks,
> > > > > Stan
> > > > >
> > > >
> > > >
> > >
> >
>

Re: Need review IGNITE-9050

[Dmitriy Pavlov]

Bumping up.

ср, 25 июл. 2018 г., 18:01 Dmitry Pavlov :

> Hi, Igniters, especially Native Persistence Experts, please step in.
>
> Tests are still running, so I suggest to avoid merge until we'll get
> run-all results.
>
> Sincerely,
> Dmitriy Pavlov
>
> ср, 25 июл. 2018 г. в 16:24, Dmitriy Govorukhin <
> dmitriy.govoruk...@gmail.com>:
>
>> Igniters,
>>
>> I completed work on
>> IGNITE-9050 
>> (WALIterator
>> should throw an exception if iterator stopped in the WAL archive but not
>> in
>> WAL work).
>>
>> review link - CR-697
>> 
>>
>

[GitHub] ignite pull request #4444: IGNITE-9073 Use jackson2 dependency instead of ja...

[zzzadruga]

Github user zzzadruga closed the pull request at:

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


---

Re: Quick questions on segments and page map buckets

[Dmitriy Pavlov]

Hi,

Brief look to the code give an idea that segment count is different in
persistence and in in-memory modes.

I hope someone in the community can approve that this idea is correct.

Sincerely,
Dmitriy Pavlov

пн, 23 июл. 2018 г., 23:46 John Wilson :

> I'm talking about PageMemoryNostoreImpl here:
>
> https://github.com/apache/ignite/blob/ce8e31e28e16c7c22fe88ab6b1a1304b14f6881d/modules/core/src/main/java/org/apache/ignite/internal/pagemem/impl/PageMemoryNoStoreImpl.java#L109
> and
>
> https://github.com/apache/ignite/blob/ce8e31e28e16c7c22fe88ab6b1a1304b14f6881d/modules/core/src/main/java/org/apache/ignite/internal/pagemem/impl/PageMemoryNoStoreImpl.java#L208
>
> Thanks,
>
> On Thu, Jul 12, 2018 at 10:31 AM, Dmitry Pavlov 
> wrote:
>
> > Hi, I've double checked code regarding question 1:
> >
> > PageMemoryImpl#segments segments count (len) comes from sizes array len.
> > Sizes array come to page memory from
> > GridCacheDatabaseSharedManager.calculateFragmentSizes(). This method
> which
> > gets availableProcessors from runtime (CPU count). I didn't find any
> shift
> > to SEG_BITS.
> >
> > It can be chaged by DataStorageConfiguration.setConcurrencyLevel() but by
> > default is the same with #CPU.
> >
> > Which is why I mentioned segments count = CPU count by default in wiki.
> >
> > Recenly some member of community proposed update to offical doc about
> > segments count. So now it states #segments=#CPU.
> >
> > So I guess for 8 CPU we will have 8 segments.
> >
> > Please correct me if I missing something.
> >
> > Sincerely,
> > Dmitriy Pavlov
> >
> > ср, 27 июн. 2018 г. в 15:30, Eduard Shangareev <
> > eduard.shangar...@gmail.com
> > >:
> >
> > > Dmitry,
> > >
> > > I mean Chugunov, but I have questioned him. His answer was the A.
> > Goncharuk
> > > should now the answer.
> > >
> > > On Wed, Jun 27, 2018 at 2:58 PM, Dmitry Pavlov 
> > > wrote:
> > >
> > > > John, is this question still actual?
> > > >
> > > > пт, 22 июн. 2018 г. в 15:18, Dmitry Pavlov :
> > > >
> > > > > Hi Ed,
> > > > >
> > > > > Which Sergey do you mean? I know a number of contributors.
> > > > >
> > > > > Sincerely,
> > > > >
> > > > >
> > > > > вт, 19 июн. 2018 г. в 22:15, Eduard Shangareev <
> > > > > eduard.shangar...@gmail.com>:
> > > > >
> > > > >> Hi,
> > > > >>
> > > > >> 1. It looks weird, yeah. Need to ask Sergey, who has changed it
> last
> > > > time.
> > > > >>
> > > > >> 2. Because we could reuse memory. For example, after cache destroy
> > or
> > > > >> something like that.
> > > > >>
> > > > >> On Tue, Jun 19, 2018 at 9:58 PM, John Wilson <
> > sami.hailu...@gmail.com
> > > >
> > > > >> wrote:
> > > > >>
> > > > >> > Hi,
> > > > >> >
> > > > >> > Two quick questions:
> > > > >> >
> > > > >> >
> > > > >> >1. The design documentation here,
> > > > >> >https://cwiki.apache.org/confluence/display/IGNITE/
> > > > >> > Ignite+Durable+Memory+-+under+the+hood,
> > > > >> >states that the default segment count is equal to the number
> of
> > > > >> logical
> > > > >> >cores available in the underlying machine. However, the
> > segments
> > > > >> array
> > > > >> > in
> > > > >> >PageMemory indicates that the maximum number of segments is:
> 1
> > <<
> > > > >> > SEG_BITS.
> > > > >> >Since SEG_BITS = 4, the max # segments is 16. Did I miss
> > > something
> > > > >> here?
> > > > >> >2. Reading the code in PageMemoryNoStoreImp, it looks like
> > pages
> > > > are
> > > > >> >allocated segment sequentially in a bump-the-pointer strategy
> > > where
> > > > >> the
> > > > >> >first 8 bytes of a segment hold a pointer to the index of the
> > > last
> > > > >> >allocated page. If this is true, then I don't understand the
> > > point
> > > > of
> > > > >> >having a page map buckets. Why not use a simple arithmetic
> > index
> > > *
> > > > >> > pageSize
> > > > >> >to get the offset of a page?
> > > > >> >
> > > > >> > Thanks.
> > > > >> > John
> > > > >> >
> > > > >>
> > > > >
> > > >
> > >
> >
>

Re: SSLParameters for SslContextFactory

[Vladimir Ozerov]

Agree. It is much easier for user to set a collection of strings
(especially from Spring), rather than construct some complex Java 8 object.
Also we need to remember that this feature should be propagated to all thin
clients and .NET integration. String getter/setter is only way to maintain
API consistency across various platforms.

On Thu, Jul 26, 2018 at 9:16 PM Ilya Kasnacheev 
wrote:

> Hello!
>
> I really dislike the fact that SSLParameters has 6 setter methods, and we
> only support one of them, when two more clash with SSL settings which are
> set elsewhere.
>
> I.e. what happens if I pass SSLParameters with setAlgorithmConstraints() or
> setProtocols() called on them?
>
> Is it possible that we will just have an array of allowed ciphers in
> configuration?
>
> Regards,
>
> --
> Ilya Kasnacheev
>
> 2018-07-26 20:16 GMT+03:00 Michael Cherkasov  >:
>
> > Hi all,
> >
> > I want to add SSLParameters for SslContextFactory.
> >
> > Right now there's no way to specify a particular set of cipher suites
> that
> > you want to use.
> > there's even old request to add this functionality:
> > https://issues.apache.org/jira/browse/IGNITE-6167
> > even with current API you can achieve this, but this requires a lot of
> > boilerplate code, to avoid this I added SSLParameters, that would be
> > applied to all SSL connections, please review my pull request:
> > https://github.com/apache/ignite/pull/4440
> >
> > I think this patch covers 6167, so I want to push it in context of this
> > ticket.
> >
> > Thanks,
> > Mike.
> >
>

[jira] [Created] (IGNITE-9120) Metadata writer does not propagate error to failure handler

[Alexand Polyakov (JIRA)]

Alexand Polyakov created IGNITE-9120:


 Summary: Metadata writer does not propagate error to failure 
handler
 Key: IGNITE-9120
 URL: https://issues.apache.org/jira/browse/IGNITE-9120
 Project: Ignite
  Issue Type: Bug
Reporter: Alexand Polyakov


In logs
{code:java}
[WARN] [tcp-disco-msg-worker- # 2% DPL_GRID% DplGridNodeName%] 
[o.a.i.i.p.c.b.CacheObjectBinaryProcessorImpl] Failed to save metadata for 
typeId: 978611101; The exception was selected: there was no space left on the 
device{code}
Node does not shut down
With time, detected endless transactions.



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

[GitHub] ignite pull request #4453: IGNITE-9114

[devozerov]

GitHub user devozerov opened a pull request:

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

IGNITE-9114



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/gridgain/apache-ignite ignite-9114

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/4453.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #4453


commit a96cc8a0747275a6b310286e2fa4bc6e96da4e8b
Author: devozerov 
Date:   2018-07-30T08:05:16Z

Logging on mapper.

commit 767789142208343d3b4b680532e19e7b03f351aa
Author: devozerov 
Date:   2018-07-30T10:36:31Z

Done.




---

Re: [jira] [Assigned] (IGNITE-9113) Allocate memory for a data region when first cache assigned to this region is created

[Dmitriy Pavlov]

Hi Dmitriy, Igniters,

I would like to ask an assistance from experienced Ignite contributors
here. I'm still trying to find clear reference on that.

In the same time I beleive that assignment to other person, who probably
will not work on issue, confronts at least with Code of conduct
http://www.apache.org/foundation/policies/conduct.html This policy is to be
followed in spirit as much as in the letter.

Assigning issue means no one else in the community can begin working on it.
Let's suppose contributor would like to complete issue, than he or she will
have to ask assignee to move issue to unassigned before he or she can
start. It is not welcoming and discourage people from contribution.

So my proposal is as follows:
- to encourage particular contibutor to pay attention let's use
 -- direct mention in issue comments (it has almost the same effect: email
will be sent)
--  dev. list and CC to contributor's email

- and keep ticket unassigned
-- until contributor starts
-- or going to start actual implementation.

Sincerely,
Dmitriy Pavlov

сб, 28 июл. 2018 г. в 15:50, Dmitriy Setrakyan :

> On Sat, Jul 28, 2018 at 2:20 AM, Dmitriy Pavlov 
> wrote:
>
> > Hi Dmitriy,
> >
> > As far as I know this approach is contlicting with the Apache Way. We
> > should be absolutely sure that assignee is agree and going to do this
> task.
> > But in our case domain expert did not replied to dev list topic.
> >
>
> I do not see any conflict with any Apache rule at all. By assigning a
> ticket to someone I am suggesting that as a domain expert it is preferable
> that he or she looks at it. If not, these people can un-assign or reassign
> the ticket.
>
> If you believe there is a conflict with some Apache principle, please
> provide a link so we could all learn about it.
>
> To solve lost ticket problem I suggest to use dev. list and bumping up/ping
> > messages.
> >
>
> Agree, I do that too.
>
>
> > I hope it makes sense to you. If not, I will do my absolute best to find
> > out corresponding ASF policy.
> >
>
> Please do.
>
>
> >
> > Sincerely,
> > Dmitriy Pavlov
> >
> > сб, 28 июл. 2018 г. в 3:28, Dmitriy Setrakyan :
> >
> > > On Fri, Jul 27, 2018 at 3:02 PM, Dmitriy Pavlov  >
> > > wrote:
> > >
> > > > Hi Igniters,
> > > >
> > > > I would discourage all Igniters from direct assigning issues to
> anyone
> > > > else. Of cource excepting the case it was directly discussed with
> > > asignee.
> > > > Any contributor should be able to assign issue to himself.
> > > >
> > > > I left issue unassigned until Alex G would assign it.
> > > >
> > >
> > > Dmitriy, I disagree. If there is a domain expert, then the issue should
> > be
> > > assigned to him/her whenever possible. If that person is too busy,
> he/she
> > > could ask someone else for help. This way the tickets will get
> attention
> > > faster and will get resolved faster.
> > >
> > > https://issues.apache.org/jira/browse/IGNITE-9113
> > >
> > > D.
> > >
> >
>

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

[Dmitriy Pavlov]

Hi Maxim,

thank you for checking this failure. I hope so too.

Sincerely,

вс, 29 июл. 2018 г. в 15:52, Maxim Muzafarov :

> Hello,
>
> I've checked this execution timeout failure and seems it relates to ticket
> [1].
> Already "In progress" state, so hope it will be fixed soon.
>
> [1] https://issues.apache.org/jira/browse/IGNITE-8220
>
> On Sun, 29 Jul 2018 at 03:12  wrote:
>
> > Hi Ignite Developer,
> >
> > I am MTCGA.Bot, and I've detected some issue on TeamCity to be addressed.
> > I hope you can help.
> >
> >  *New Critical Failure in master PDS 1
> >
> https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_Pds1=%3Cdefault%3E=buildTypeStatusDiv
> >  No changes in build
> >
> > - If your changes can led to this failure(s), please create issue
> > with label MakeTeamCityGreenAgain and assign it to you.
> > -- If you have fix, please set ticket to PA state and write to
> dev
> > list fix is ready
> > -- For case fix will require some time please mute test and set
> > label Muted_Test to issue
> > - If you know which change caused failure please contact change
> > author directly
> > - If you don't know which change caused failure please send
> > message to dev list to find out
> > Should you have any questions please contact dpav...@apache.org or write
> > to dev.list
> > Best Regards,
> > MTCGA.Bot
> > Notification generated at Sun Jul 29 03:12:41 MSK 2018
> >
> --
> --
> Maxim Muzafarov
>

[jira] [Created] (IGNITE-9119) Missed dumpDebugInfo for rebalance

[Maxim Muzafarov (JIRA)]

Maxim Muzafarov created IGNITE-9119:
---

 Summary: Missed dumpDebugInfo for rebalance
 Key: IGNITE-9119
 URL: https://issues.apache.org/jira/browse/IGNITE-9119
 Project: Ignite
  Issue Type: Task
Affects Versions: 2.6
Reporter: Maxim Muzafarov
Assignee: Maxim Muzafarov


Since [Improve Ignite troubleshooting 
logging|https://issues.apache.org/jira/browse/IGNITE-3336] have been 
implemented, we should provide additional information about pending rebalance 
futures.

See, {{GridDhtPreloader#dumpDebugInfo}} for details. For each cache group we 
should dump at least info about:
* Uncomplete rebalance future
* Cache group name
* Rebalance topology version
* Collection of remainig supplier nodes to request
* Missed partition info (if exists)
* Collection of completed supplier requests (optional)



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

Re: [jira] [Created] (IGNITE-9117) Need to log GridReduceQueryExecutor#query long execution

[Dmitriy Pavlov]

Hi Ruchir,

I can see now issue is resolved as duplicated.

Hi Evgenii,

could you please link two issues which were duplicated?

Sincerely,
Dmitriy Pavlov

пн, 30 июл. 2018 г. в 3:55, ruchirc :

> Wanted to check with you, can i takeup IGNITE-9117 ticket.
>
> Regards,
> Ruchir
>
>
>
> -
> thank you,
> Ruchir
> --
> Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/
>