[jira] [Created] (IGNITE-11099) Implement test framework for measuring heap utilization

[Alexei Scherbakov (JIRA)]

Alexei Scherbakov created IGNITE-11099:
--

 Summary: Implement test framework for measuring heap utilization
 Key: IGNITE-11099
 URL: https://issues.apache.org/jira/browse/IGNITE-11099
 Project: Ignite
  Issue Type: Task
Reporter: Alexei Scherbakov
 Fix For: 2.8


It's necessary to create special test framwork capable of heap usage comparison 
in "before optimization" vs "after opitmization" modes.

Most probably it should be implemented as special test suite running with 
instrumentation support.



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

[jira] [Created] (IGNITE-11098) Web console: font cleanup

[Ilya Borisov (JIRA)]

Ilya Borisov created IGNITE-11098:
-

 Summary: Web console: font cleanup
 Key: IGNITE-11098
 URL: https://issues.apache.org/jira/browse/IGNITE-11098
 Project: Ignite
  Issue Type: Improvement
Reporter: Ilya Borisov
Assignee: Ilya Borisov


Web console font should be set in a single place and should not be hardcoded 
into SCSS.

Places to check:
1. SCSS variables passed into Bootstrap.
2. Component styles that explicitly use Roboto font (they should not).
3. Font preload meta tags.





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

Re: SQL View with list of existing indexes

[Vladimir Ozerov]

Hi Yuriy,

Yes, I believe we will have columns view(s) at some point in time for sure.

On Thu, Jan 24, 2019 at 7:08 PM Юрий  wrote:

> Hi Vladimir,
>
> Thanks for your comments,
>
> 1) Agree.
> 2) Ok.
> 3) We create number of index copies depend on query parallelism. But seems
> you are right - it should be exposed on TABLES level.
> 4) Approx. inline size shouldn't be used here, due to the value depend on
> node and not has single value.
> 5) Do we have a plans for some view with table columns? If yes, may be will
> be better have just array with column order from the columns view. For
> example you want to know which columns are indexed already. In case we will
> have plain comma-separated form it can't be achieved.
>
>
>
>
>
> чт, 24 янв. 2019 г. в 18:09, Vladimir Ozerov :
>
> > Hi Yuriy,
> >
> > Please note that MySQL link is about SHOW command, which is a different
> > beast. In general I think that PG approach is better as it allows user to
> > get quick overview of index content without complex JOINs. I would start
> > with plain single view and add columns view later if we found it useful.
> As
> > far as view columns:
> > 1) I would add both cache ID/name and cache group ID/name
> > 2) Number of columns does not look as a useful info to me
> > 3) Query parallelism is related to cache, not index, so it should be in
> > IGNITE.TABLES view instead
> > 4) Inline size is definitely useful metric. Not sure about approximate
> > inline size
> > 5) I would add list of columns in plain comma-separated form with
> ASC/DESC
> > modifiers
> >
> > Thoughts?
> >
> > Vladimir.
> >
> > On Thu, Jan 24, 2019 at 3:52 PM Юрий 
> wrote:
> >
> > > Hi Igniters,
> > >
> > > As part of IEP-29: SQL management and monitoring
> > > <
> > >
> >
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-29%3A+SQL+management+and+monitoring
> > > >
> > > I'm going to implement SQL view with list of existing indexes.
> > > I've investigate how it expose by ORACLE, MySQL and Postgres.
> > > ORACLE -
> > >
> > >
> >
> https://docs.oracle.com/en/database/oracle/oracle-database/18/refrn/ALL_INDEXES.html#GUID-E39825BA-70AC-45D8-AF30-C7FF561373B6
> > >
> > > MySQL - https://dev.mysql.com/doc/refman/8.0/en/show-index.html
> > > Postgres - https://www.postgresql.org/docs/11/view-pg-indexes.html ,
> > > https://www.postgresql.org/docs/11/catalog-pg-index.html
> > >
> > > All vendors have such views which show at least following information:
> > > schema name   - Name of schema related to table and index.
> > > table name- Name of table related to an index.
> > > index name   - Name of index.
> > > list of columns   - All columns and their order included into
> an
> > > index.
> > > collation - ASC or DESC sort for each columns.
> > >
> > > + many specific information which different form vendor to vendor.
> > >
> > > In our case such specific information could be at least:
> > >
> > >1. Owning cache ID   - not sure, but may
> > be
> > >useful to join with other our views.
> > >2. number of columns at the index- just to know how many
> > result
> > >should be in columns view
> > >3. query parallelism   - It's
> > configuration
> > >parameter show how many thread can be used to execute query.
> > >4. inline size   - inline
> size
> > >used for this index.
> > >5. is affinity - boolean
> > >parameter show that affinity key index
> > >6. is pk-
> boolean
> > >parameter show that PK index
> > >7. approx recommended inline size- dynamically calculated
> > >recommended inline size for this index to show required size to keep
> > > whole
> > >indexed columns as inlined.
> > >
> > >
> > >
> > > All vendors have different ways  to present information about index
> > > columns:
> > > PG - use array of index table columns and second array for collation
> each
> > > of columns.
> > > MySQL - each row in index view contains information about one of
> indexed
> > > columsn with ther position at the index. So for one index there are
> many
> > > columns.
> > > ORACLE,  - use separate view where each of row present column included
> > into
> > > index with all required information and can be joined by schema, table
> > and
> > > index names.
> > > ORACLE indexed columns view -
> > >
> > >
> >
> https://docs.oracle.com/cd/B19306_01/server.102/b14237/statviews_1064.htm#i1577532
> > > MySql -
> > >
> > > I propose use ORACLE way and have second view to represent column
> > included
> > > into indexes.
> > >
> > > In this case such view can have the following information:
> > > schema name   - Name of schema related to table and index.
> > > table name- Name of table related to an index.
> > > index name   

[jira] [Created] (IGNITE-11110) UnsupportedOperationException: null when stopping grid

[Jens Borgland (JIRA)]

Jens Borgland created IGNITE-0:
--

 Summary: UnsupportedOperationException: null when stopping grid
 Key: IGNITE-0
 URL: https://issues.apache.org/jira/browse/IGNITE-0
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.7
Reporter: Jens Borgland


After upgrading to 2.7 we've started getting these errors when stopping grids:
{noformat}
java.lang.UnsupportedOperationException: null
at 
org.jsr166.ConcurrentLinkedHashMap.clear(ConcurrentLinkedHashMap.java:1551) 
~[ignite-core-2.7.0.jar:2.7.0]
at 
org.apache.ignite.internal.processors.job.GridJobProcessor.stop(GridJobProcessor.java:264)
 ~[ignite-core-2.7.0.jar:2.7.0]
at 
org.apache.ignite.internal.IgniteKernal.stop0(IgniteKernal.java:2356) 
~[ignite-core-2.7.0.jar:2.7.0]
at org.apache.ignite.internal.IgniteKernal.stop(IgniteKernal.java:2228) 
~[ignite-core-2.7.0.jar:2.7.0]
at 
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop0(IgnitionEx.java:2612)
 ~[ignite-core-2.7.0.jar:2.7.0]
at 
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop(IgnitionEx.java:2575)
 ~[ignite-core-2.7.0.jar:2.7.0]
at org.apache.ignite.internal.IgnitionEx.stop(IgnitionEx.java:379) 
~[ignite-core-2.7.0.jar:2.7.0]
at org.apache.ignite.Ignition.stop(Ignition.java:225) 
~[ignite-core-2.7.0.jar:2.7.0]
at 
org.apache.ignite.internal.IgniteKernal.close(IgniteKernal.java:3568) 
~[ignite-core-2.7.0.jar:2.7.0]
{noformat}

At first glance it looks likely that it was introduced with commit 
[d04d764|https://github.com/apache/ignite/commit/d04d76440ce86873de7aebc8c03d39484cd1e3e5]
 (the {{GridJobProcessor}} still calls {{clear()}} on maps).



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

[jira] [Created] (IGNITE-11109) DistributedMetaStorageTest should be moved into different test suite

[Ivan Bessonov (JIRA)]

Ivan Bessonov created IGNITE-11109:
--

 Summary: DistributedMetaStorageTest should be moved into different 
test suite
 Key: IGNITE-11109
 URL: https://issues.apache.org/jira/browse/IGNITE-11109
 Project: Ignite
  Issue Type: Test
Reporter: Ivan Bessonov
Assignee: Ivan Bessonov


DistributedMetaStorageTest should be moved into different test suite:

https://ci.ignite.apache.org/viewLog.html?buildId=2930324=buildResultsDiv=IgniteTests24Java8_DiskPageCompressions#testNameId5631188409568136213



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

[jira] [Created] (IGNITE-11111) DistributedMetaStoragePersistentTest doesn't work on Zookeeper SPI

[Ivan Bessonov (JIRA)]

Ivan Bessonov created IGNITE-1:
--

 Summary: DistributedMetaStoragePersistentTest doesn't work on 
Zookeeper SPI
 Key: IGNITE-1
 URL: https://issues.apache.org/jira/browse/IGNITE-1
 Project: Ignite
  Issue Type: Bug
Reporter: Ivan Bessonov
Assignee: Ivan Bessonov


Accepting of joining node data is implemented in #collectGridNodeData which is 
wrong, because this method is invoked on coordinator only in case of Zookeeper 
SPI.



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

[jira] [Created] (IGNITE-11112) control.sh incorrect work with the key '--force'.

[Andrey Kalinin (JIRA)]

Andrey Kalinin created IGNITE-2:
---

 Summary: control.sh incorrect work with the key '--force'.
 Key: IGNITE-2
 URL: https://issues.apache.org/jira/browse/IGNITE-2
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.5
Reporter: Andrey Kalinin


control.sh --wal delete with the key --force produces the error

control.sh --host  --wal delete --force
{code:java}
Control utility [ver. 2.5.1-p142#20181016-sha1:f983e74f]
2018 Copyright(C) Apache Software Foundation
User: ***

Warning: the command will delete unused WAL segments.
Press 'y' to continue . . . Error: Task map operation produced no mapped jobs: 
GridTaskSessionImpl 
[taskName=org.apache.ignite.internal.visor.misc.VisorWalTask, 
dep=GridDeployment [...]
    at 
org.apache.ignite.internal.processors.task.GridTaskWorker.body(GridTaskWorker.java:528)
    at 
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
    at 
org.apache.ignite.internal.processors.task.GridTaskProcessor.startTask(GridTaskProcessor.java:764)
    at 
org.apache.ignite.internal.processors.task.GridTaskProcessor.execute(GridTaskProcessor.java:509)
    at 
org.apache.ignite.internal.processors.task.GridTaskProcessor.execute(GridTaskProcessor.java:489)
    at 
org.apache.ignite.internal.processors.rest.handlers.task.GridTaskCommandHandler.handleAsyncUnsafe(GridTaskCommandHandler.java:227)
    at 
org.apache.ignite.internal.processors.rest.handlers.task.GridTaskCommandHandler.handleAsync(GridTaskCommandHandler.java:163)
    at 
org.apache.ignite.internal.processors.rest.GridRestProcessor.handleRequest(GridRestProcessor.java:318)
    at 
org.apache.ignite.internal.processors.rest.GridRestProcessor.access$100(GridRestProcessor.java:99)
    at 
org.apache.ignite.internal.processors.rest.GridRestProcessor$2.body(GridRestProcessor.java:174)
    at 
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
    at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
    at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
    at java.lang.Thread.run(Thread.java:748)

{code}



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

[jira] [Created] (IGNITE-11108) Zookeeper handles DataBags differently

[Ivan Bessonov (JIRA)]

Ivan Bessonov created IGNITE-11108:
--

 Summary: Zookeeper handles DataBags differently
 Key: IGNITE-11108
 URL: https://issues.apache.org/jira/browse/IGNITE-11108
 Project: Ignite
  Issue Type: Bug
Reporter: Ivan Bessonov
Assignee: Eduard Shangareev


Trying to run DistributedMetaStoragePersistentTest in Zookeeper Discovery suite 
I found that GridComponent#validateNode(ClusterNode, JoiningNodeDiscoveryData) 
is never invoked so node validation might work incorrectly.



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

[jira] [Created] (IGNITE-11113) JVM 9-11 startup parameters have to be mentioned in every section of getting started

[Denis Magda (JIRA)]

Denis Magda created IGNITE-3:


 Summary: JVM 9-11 startup parameters have to be mentioned in every 
section of getting started
 Key: IGNITE-3
 URL: https://issues.apache.org/jira/browse/IGNITE-3
 Project: Ignite
  Issue Type: Task
  Components: documentation
Reporter: Artem Budnikov


Ignite.sh fails on Mac OS with JDK 11. The following startup parameters [1] 
have to be mentioned in callout blocks of every section in the getting started 
guide [2] where it's explained how to start a node with ignite.sh or launch an 
application. 

The user has to know how to:
* Fix ignite.sh/ignite.bat to make them workable
* What to do in an IDEA like IntellijIdean and Eclipse to make examples and 
apps workable

[1] 
https://apacheignite.readme.io/docs/getting-started#section-running-ignite-with-java-9-10-11
[2] https://apacheignite.readme.io/docs/getting-started



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

Addressing usability issues with JDK 9-11

[Denis Magda]

Igniters,

I played with the latest Oracle JDK 11 on Mac OS Mojave. Results are sad:

   - Starting a node from cmd (ignite.sh) - FAILED
   - Opening Ignite examples - BAD EXPERIENCE
  - pom.xml wasn't detected automatically, had to select it manually
  - was hard to start the code samples (same issue as with cmd). As a
  committer, I know how to fix it (
  
https://apacheignite.readme.io/docs/getting-started#section-running-ignite-with-java-9-10-11),
  but most of the developers have no glue and will give up
  - The step above have to be repeated for every single sample

We briefly discussed this with some community managers and our fellows will
share the fix plan here.

In the meantime

   - Artem agreed to help on the docs side:
   https://issues.apache.org/jira/browse/IGNITE-3
   - I've added "How to Use Ignite on JDK 9, 10, 11" as a top banner of
   Ignite website: https://ignite.apache.org/index.html


-
Denis

Unable to form connection between ignite(v 2.7) node inside kubernetes-1.11.3

[Lalit Jadhav]

While starting one node it gets up with time delay around 50-60 sec. but
when we scale deployment to 2-3 then those nodes are unable to connect to
st node.

Also getting below error on 2nd and 3rd node.

ERROR TcpDiscoverySpi:586 - Failed to get registered addresses from IP
> finder on start (retrying every 2000ms; change 'reconnectDelay' to
> configure the frequency of retries). class
> org.apache.ignite.spi.IgniteSpiException: Failed to retrieve Ignite pods IP
> addresses. at
> org.apache.ignite.spi.discovery.tcp.ipfinder.kubernetes.TcpDiscoveryKubernetesIpFinder.getRegisteredAddresses(TcpDiscoveryKubernetesIpFinder.java:172)
> at
> org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.registeredAddresses(TcpDiscoverySpi.java:1900)
> at
> org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.resolvedAddresses(TcpDiscoverySpi.java:1848)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl.sendJoinRequestMessage(ServerImpl.java:1049)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl.joinTopology(ServerImpl.java:910)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl.spiStart(ServerImpl.java:391)
> at
> org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.spiStart(TcpDiscoverySpi.java:2020)
> at
> org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:297)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager.start(GridDiscoveryManager.java:939)
> at
> org.apache.ignite.internal.IgniteKernal.startManager(IgniteKernal.java:1682)
> at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1066) at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2038)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1730)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1158) at
> org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:678) at
> org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:618) at
> org.apache.ignite.Ignition.getOrStart(Ignition.java:415) at
> com.cloud.ignite.server.IgniteServer.startIgnite(IgniteServer.java:57) at
> com.cloud.ignite.server.IgniteServer.(IgniteServer.java:39) at
> com.cloud.ignite.server.IgniteServer.getInstance(IgniteServer.java:107) at
> com.cloud.ignite.server.IgniteServer.main(IgniteServer.java:133) Caused by:
> java.net.ConnectException: Connection refused (Connection refused) at
> java.net.PlainSocketImpl.socketConnect(Native Method) at
> java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350)
> at
> java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
> at
> java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188)
> at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392) at
> java.net.Socket.connect(Socket.java:589) at
> sun.security.ssl.SSLSocketImpl.connect(SSLSocketImpl.java:673) at
> sun.security.ssl.BaseSSLSocketImpl.connect(BaseSSLSocketImpl.java:173) at
> sun.net.NetworkClient.doConnect(NetworkClient.java:180) at
> sun.net.www.http.HttpClient.openServer(HttpClient.java:463) at
> sun.net.www.http.HttpClient.openServer(HttpClient.java:558) at
> sun.net.www.protocol.https.HttpsClient.(HttpsClient.java:264) at
> sun.net.www.protocol.https.HttpsClient.New(HttpsClient.java:367) at
> sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.getNewHttpClient(AbstractDelegateHttpsURLConnection.java:191)
> at
> sun.net.www.protocol.http.HttpURLConnection.plainConnect0(HttpURLConnection.java:1156)
> at
> sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:1050)
> at
> sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:177)
> at
> sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1564)
> at
> sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1492)
> at
> sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream(HttpsURLConnectionImpl.java:263)
> at
> org.apache.ignite.spi.discovery.tcp.ipfinder.kubernetes.TcpDiscoveryKubernetesIpFinder.getRegisteredAddresses(TcpDiscoveryKubernetesIpFinder.java:153)




-- 
Thanks and Regards,
Lalit Jadhav.

[jira] [Created] (IGNITE-11114) Web console: add onhover state to the icons in the left menu

[Ilya Borisov (JIRA)]

Ilya Borisov created IGNITE-4:
-

 Summary: Web console: add onhover state to the icons in the left 
menu
 Key: IGNITE-4
 URL: https://issues.apache.org/jira/browse/IGNITE-4
 Project: Ignite
  Issue Type: Improvement
Reporter: Ilya Borisov
Assignee: Ilya Borisov


Add hover state (red icon color) to icons in the left menu, like the "Contact" 
link.



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

Re: H2 license and vulnerabilities

[Vladimir Ozerov]

Hi Steve,

H2 cannot be removed from Ignite easily as it is integrated pretty deep
into indexing module. Good news is that our usage of H2 is pretty limited -
we only use it's parser, planner and execution pipeline. We do not use H2
as data storage.
Please let me know if you need any additional clarifications.

Vladimir.

On Tue, Jan 29, 2019 at 10:35 AM steve.hostett...@gmail.com <
steve.hostett...@gmail.com> wrote:

> Hello,
> I am using Apache Ignite in an financial setting and it gets reported as a
> high risk because of one of its dependencies : H2
>
> The blackduck report warns the following:
> 1) The H2 license being weak reciprocal it is not the prefered type of OSS
> licenses (e.g., Apache, MIT)
> 2) There are known vulnerabulities for now more than a year that do not get
> fixed:
>
> https://www.cvedetails.com/vulnerability-list/vendor_id-17893/product_id-45580/year-2018/H2database-H2.html
>
> So here are my questions :
> 1) is there any plan to swap H2 by another in memory database and if not
> what is the view of the community on the above points.
> 2) Does ignite uses the part of H2 that is vulnerable (disk backup)?
>
> Many thanks in advance
>
>
>
> --
> Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/
>

[jira] [Created] (IGNITE-11115) Binary: rework thread-local binary context to avoid set() operation

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-5:


 Summary: Binary: rework thread-local binary context to avoid set() 
operation
 Key: IGNITE-5
 URL: https://issues.apache.org/jira/browse/IGNITE-5
 Project: Ignite
  Issue Type: Task
  Components: binary
Reporter: Vladimir Ozerov
Assignee: Vladimir Ozerov
 Fix For: 2.8


Currently we call {{ThreadLocal.set()}} on every serialization/deserialization 
(see {{GridBinaryMarshaller#BINARY_CTX}} usages). This may lead to high CPU 
usage, especially during SQL query execution. 
Let's refactor access patterns to work only with {{ThreadLocal.get()}} 
operation.



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

H2 license and vulnerabilities

[steve.hostett...@gmail.com]

Hello,
I am using Apache Ignite in an financial setting and it gets reported as a
high risk because of one of its dependencies : H2

The blackduck report warns the following:
1) The H2 license being weak reciprocal it is not the prefered type of OSS
licenses (e.g., Apache, MIT)
2) There are known vulnerabulities for now more than a year that do not get
fixed:
https://www.cvedetails.com/vulnerability-list/vendor_id-17893/product_id-45580/year-2018/H2database-H2.html

So here are my questions : 
1) is there any plan to swap H2 by another in memory database and if not
what is the view of the community on the above points.
2) Does ignite uses the part of H2 that is vulnerable (disk backup)?

Many thanks in advance



--
Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/

Re: H2 license and vulnerabilities

[steve.hostett...@gmail.com]

Hello Vladimir,

thanks a lot for the quick turnaround. That answers my question and clears
the vulnerability part.

Best Regards



--
Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/

[jira] [Created] (IGNITE-11105) [TC Bot] Support Teamcity servers aliases

[Dmitriy Pavlov (JIRA)]

Dmitriy Pavlov created IGNITE-11105:
---

 Summary: [TC Bot] Support Teamcity servers aliases
 Key: IGNITE-11105
 URL: https://issues.apache.org/jira/browse/IGNITE-11105
 Project: Ignite
  Issue Type: Task
Reporter: Dmitriy Pavlov
Assignee: Dmitriy Pavlov


Implement feature of aliasing TeamCity builds bat. Alias will act as a pointer 
to the real name of a server.

It is necessary for a feature of linking builds with separate JIRA projects 
and/or GitHub forks without duplicating of all builds database.



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

[jira] [Created] (IGNITE-11106) MVCC: Test CacheMvccVacuumTest.testStartStopVacuumPersistence fails sporadically

[Roman Kondakov (JIRA)]

Roman Kondakov created IGNITE-11106:
---

 Summary: MVCC: Test 
CacheMvccVacuumTest.testStartStopVacuumPersistence fails sporadically
 Key: IGNITE-11106
 URL: https://issues.apache.org/jira/browse/IGNITE-11106
 Project: Ignite
  Issue Type: Bug
  Components: mvcc
Reporter: Roman Kondakov


Test CacheMvccVacuumTest.testStartStopVacuumPersistence 
[fails|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8==testDetails=77684316754382=TEST_STATUS_DESC_IgniteTests24Java8=__all_branches__=50]
 sporadically. Looks like sometimes vacuum starts on non-activated cluster. It 
should be investigated.

Stack trace:


{noformat}
junit.framework.AssertionFailedError: Expected:  but was: [GridWorker 
[name=vacuum-scheduler, igniteInstanceName=mvcc.CacheMvccVacuumTest0, 
finished=false, heartbeatTs=1547451366552, hashCode=1061063110, 
interrupted=false, runner=vacuum-scheduler-#40457%mvcc.CacheMvccVacuumTest0%], 
GridWorker [name=vacuum-cleaner, igniteInstanceName=mvcc.CacheMvccVacuumTest0, 
finished=false, heartbeatTs=1547451366552, hashCode=706935731, 
interrupted=false, runner=vacuum-cleaner-#40458%mvcc.CacheMvccVacuumTest0%], 
GridWorker [name=vacuum-cleaner, igniteInstanceName=mvcc.CacheMvccVacuumTest0, 
finished=false, heartbeatTs=1547451366552, hashCode=507659668, 
interrupted=false, runner=vacuum-cleaner-#40459%mvcc.CacheMvccVacuumTest0%]]
at junit.framework.Assert.fail(Assert.java:57)
at junit.framework.Assert.assertTrue(Assert.java:22)
at junit.framework.Assert.assertNull(Assert.java:277)
at junit.framework.Assert.assertNull(Assert.java:268)
at 
org.apache.ignite.internal.processors.cache.mvcc.CacheMvccVacuumTest.ensureNoVacuum(CacheMvccVacuumTest.java:196)
at 
org.apache.ignite.internal.processors.cache.mvcc.CacheMvccVacuumTest.testStartStopVacuumPersistence(CacheMvccVacuumTest.java:128)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
at 
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at 
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
at 
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at 
org.apache.ignite.testframework.junits.GridAbstractTest$6.run(GridAbstractTest.java:2088)
at java.lang.Thread.run(Thread.java:748)
{noformat}




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

[jira] [Created] (IGNITE-11107) MVCC: IgniteCachePartitionLossPolicySelfTest.testReadWriteSafeAfterKillTwoNodes hangs sometimes

[Roman Kondakov (JIRA)]

Roman Kondakov created IGNITE-11107:
---

 Summary: MVCC: 
IgniteCachePartitionLossPolicySelfTest.testReadWriteSafeAfterKillTwoNodes hangs 
sometimes
 Key: IGNITE-11107
 URL: https://issues.apache.org/jira/browse/IGNITE-11107
 Project: Ignite
  Issue Type: Bug
  Components: mvcc
Reporter: Roman Kondakov


Sometimes 
IgniteCachePartitionLossPolicySelfTest.testReadWriteSafeAfterKillTwoNodes hangs 
on PME. Some partitions have not changed their state from {{RENTING}} to 
{{OWNING}}.


{noformat}
[2019-01-27 07:20:23,420][WARN 
][test-runner-#32729%distributed.IgniteCachePartitionLossPolicySelfTest%][root] 
Finished waiting for topology map update 
[igniteInstanceName=distributed.IgniteCachePartitionLossPolicySelfTest4, p=0, 
duration=1415ms]
[2019-01-27 07:20:23,421][WARN 
][test-runner-#32729%distributed.IgniteCachePartitionLossPolicySelfTest%][root] 
Waiting for correct partition state part=2, should be OWNING [state=RENTING], 
node=distributed.IgniteCachePartitionLossPolicySelfTest4, cache=default
[2019-01-27 07:20:25,023][WARN 
][test-runner-#32729%distributed.IgniteCachePartitionLossPolicySelfTest%][root] 
Waiting for correct partition state part=13, should be OWNING [state=RENTING], 
node=distributed.IgniteCachePartitionLossPolicySelfTest4, cache=default

Thread 
[name="test-runner-#32729%distributed.IgniteCachePartitionLossPolicySelfTest%", 
id=35714, state=RUNNABLE, blockCnt=93, waitCnt=1033]
at sun.management.ThreadImpl.dumpThreads0(Native Method)
at sun.management.ThreadImpl.dumpAllThreads(ThreadImpl.java:454)
at o.a.i.i.util.IgniteUtils.dumpThreads(IgniteUtils.java:1370)
at 
o.a.i.testframework.junits.common.GridCommonAbstractTest.awaitPartitionMapExchange(GridCommonAbstractTest.java:792)
at 
o.a.i.testframework.junits.common.GridCommonAbstractTest.awaitPartitionMapExchange(GridCommonAbstractTest.java:569)
at 
o.a.i.i.processors.cache.distributed.IgniteCachePartitionLossPolicySelfTest.checkLostPartition(IgniteCachePartitionLossPolicySelfTest.java:560)
at 
o.a.i.i.processors.cache.distributed.IgniteCachePartitionLossPolicySelfTest.testReadWriteSafeAfterKillTwoNodes(IgniteCachePartitionLossPolicySelfTest.java:258)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
at 
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at 
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
at 
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at 
o.a.i.testframework.junits.GridAbstractTest$6.run(GridAbstractTest.java:2088)
at java.lang.Thread.run(Thread.java:748)

{noformat}




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

Re: Want to help with newbie issues

[Dmitriy Pavlov]

Hi Sergey,

Thank you for interest in Apache Ignite.

Welcome onboard, I've added you to the list of contributors.

Following is a couple of links should help during joining to the community
Short 'How to start' guide
https://github.com/apache/ignite/blob/master/CONTRIBUTING.md#contributing-to-apache-ignite

and full guide version
https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute

Should you have any questions please do not hesitate to contact Ignite
developers here.

Sincerely,
Dmitriy Pavlov

пн, 28 янв. 2019 г. в 13:21, Sergey Moldachev :

> Hi Ignite Developers,
> I would like to fix this the issue: IGNITE-8550
> .
>
> It will be my first contribution, my JIRA username is *smoldachev*.
>
> Is there anything else required from me?
>
> Best regards,
> Sergey Moldachev
>

Re: failure due to IGNITE_BPLUS_TREE_LOCK_RETRIES

[Ilya Kasnacheev]

Hello!

This is highly unusual, I guess the default value for this property should
be far larger that anything attainable in practice.

Dmitriy, Alexey, can you please clarify?

Regards.
-- 
Ilya Kasnacheev


вс, 27 янв. 2019 г. в 21:16, mahesh76private :

> Increasing the size of IGNITE_BPLUS_TREE_LOCK_RETRIES makes the issue go
> away.
> But the explanation that is occurs due to contention is somewhat not
> clear.
>
> In all cases, in occurred to be when I was creating an index. Feels like it
> is somehow related to the height of the tree... and this variable seems to
> limit the height.
>
>
>
>
> --
> Sent from: http://apache-ignite-users.70518.x6.nabble.com/
>

[jira] [Created] (IGNITE-11104) Remove Java 7 leftovers from IgniteSystemProperties

[Ilya Kasnacheev (JIRA)]

Ilya Kasnacheev created IGNITE-11104:


 Summary: Remove Java 7 leftovers from IgniteSystemProperties
 Key: IGNITE-11104
 URL: https://issues.apache.org/jira/browse/IGNITE-11104
 Project: Ignite
  Issue Type: Improvement
  Components: general
Affects Versions: 2.7
Reporter: Ilya Kasnacheev
Assignee: Ilya Kasnacheev


IGNITE_FORCE_START_JAVA7 can no longer do anything useful, for example. Should 
remove it right away since it's noop.



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

[jira] [Created] (IGNITE-11100) AssertionError LocalJoinCachesContext occurs in sequential cluster restart

[Dmitry Sherstobitov (JIRA)]

Dmitry Sherstobitov created IGNITE-11100:


 Summary: AssertionError LocalJoinCachesContext occurs in 
sequential cluster restart
 Key: IGNITE-11100
 URL: https://issues.apache.org/jira/browse/IGNITE-11100
 Project: Ignite
  Issue Type: Bug
Reporter: Dmitry Sherstobitov


Same scenario as in https://issues.apache.org/jira/browse/IGNITE-10878

{code}
[2019-01-26T03:32:22,226][ERROR][tcp-disco-msg-worker-#2][TcpDiscoverySpi] 
TcpDiscoverSpi's message worker thread failed abnormally. Stopping the node in 
order to prevent cluster wide instability.
java.lang.AssertionError: LocalJoinCachesContext 
[locJoinStartCaches=[IgniteBiTuple [val1=DynamicCacheDescriptor 
[deploymentId=bc3e0978861-fb98885f-92a5-47d2-9475-00173fab8ee1, staticCfg=true, 
sql=false, cacheType=UTILITY, template=false, updatesAllowed=true, 
cacheId=-2100569601, rcvdFrom=f97e4743-6cf2-488e-a7fc-14707e9a8eb0, 
objCtx=null, rcvdOnDiscovery=false, startTopVer=null, rcvdFromVer=null, 
clientCacheStartVer=null, schema=QuerySchema [], grpDesc=CacheGroupDescriptor 
[grpId=-2100569601, grpName=null, startTopVer=null, 
rcvdFrom=f97e4743-6cf2-488e-a7fc-14707e9a8eb0, 
deploymentId=bc3e0978861-fb98885f-92a5-47d2-9475-00173fab8ee1, 
caches={ignite-sys-cache=-2100569601}, rcvdFromVer=null, 
persistenceEnabled=false, walEnabled=false, cacheName=ignite-sys-cache], 
cacheName=ignite-sys-cache], val2=null], IgniteBiTuple 
[val1=DynamicCacheDescriptor 
[deploymentId=60771978861-398164df-6240-4d19-ad0b-308768d2a095, 
staticCfg=false, sql=false, cacheType=USER, template=false, 
updatesAllowed=true, cacheId=-1901084566, 
rcvdFrom=f00ec506-fc6c-45c5-b550-9308d17a39cf, objCtx=null, 
rcvdOnDiscovery=true, startTopVer=null, rcvdFromVer=null, 
clientCacheStartVer=null, schema=QuerySchema [], grpDesc=CacheGroupDescriptor 
[grpId=-1901084566, grpName=null, startTopVer=AffinityTopologyVersion 
[topVer=13, minorTopVer=20], rcvdFrom=f00ec506-fc6c-45c5-b550-9308d17a39cf, 
deploymentId=60771978861-398164df-6240-4d19-ad0b-308768d2a095, 
caches={config_third_copy=-1901084566}, rcvdFromVer=null, 
persistenceEnabled=false, walEnabled=false, cacheName=config_third_copy], 
cacheName=config_third_copy], val2=null], IgniteBiTuple 
[val1=DynamicCacheDescriptor 
[deploymentId=01771978861-398164df-6240-4d19-ad0b-308768d2a095, 
staticCfg=false, sql=false, cacheType=USER, template=false, 
updatesAllowed=true, cacheId=-1858528402, 
rcvdFrom=f00ec506-fc6c-45c5-b550-9308d17a39cf, objCtx=null, 
rcvdOnDiscovery=true, startTopVer=null, rcvdFromVer=null, 
clientCacheStartVer=null, schema=QuerySchema [], grpDesc=CacheGroupDescriptor 
[grpId=-1858528402, grpName=null, startTopVer=AffinityTopologyVersion 
[topVer=13, minorTopVer=22], rcvdFrom=f00ec506-fc6c-45c5-b550-9308d17a39cf, 
deploymentId=01771978861-398164df-6240-4d19-ad0b-308768d2a095, 
caches={trans_forth_copy=-1858528402}, rcvdFromVer=null, 
persistenceEnabled=false, walEnabled=false, cacheName=trans_forth_copy], 
cacheName=trans_forth_copy], val2=null], IgniteBiTuple 
[val1=DynamicCacheDescriptor 
[deploymentId=51771978861-398164df-6240-4d19-ad0b-308768d2a095, 
staticCfg=false, sql=false, cacheType=USER, template=false, 
updatesAllowed=true, cacheId=-1502999781, 
rcvdFrom=f00ec506-fc6c-45c5-b550-9308d17a39cf, objCtx=null, 
rcvdOnDiscovery=true, startTopVer=null, rcvdFromVer=null, 
clientCacheStartVer=null, schema=QuerySchema [], grpDesc=CacheGroupDescriptor 
[grpId=-1502999781, grpName=null, startTopVer=AffinityTopologyVersion 
[topVer=13, minorTopVer=23], rcvdFrom=f00ec506-fc6c-45c5-b550-9308d17a39cf, 
deploymentId=51771978861-398164df-6240-4d19-ad0b-308768d2a095, 
caches={id_forth_copy=-1502999781}, rcvdFromVer=null, persistenceEnabled=false, 
walEnabled=false, cacheName=id_forth_copy], cacheName=id_forth_copy], 
val2=null], IgniteBiTuple [val1=DynamicCacheDescriptor 
[deploymentId=8a671978861-398164df-6240-4d19-ad0b-308768d2a095, 
staticCfg=false, sql=false, cacheType=USER, template=false, 
updatesAllowed=true, cacheId=-1354792126, 
rcvdFrom=f00ec506-fc6c-45c5-b550-9308d17a39cf, objCtx=null, 
rcvdOnDiscovery=true, startTopVer=null, rcvdFromVer=null, 
clientCacheStartVer=null, schema=QuerySchema [], grpDesc=CacheGroupDescriptor 
[grpId=-1354792126, grpName=null, startTopVer=AffinityTopologyVersion 
[topVer=13, minorTopVer=5], rcvdFrom=f00ec506-fc6c-45c5-b550-9308d17a39cf, 
deploymentId=8a671978861-398164df-6240-4d19-ad0b-308768d2a095, 
caches={config=-1354792126}, rcvdFromVer=null, persistenceEnabled=false, 
walEnabled=false, cacheName=config], cacheName=config], val2=null], 
IgniteBiTuple [val1=DynamicCacheDescriptor 
[deploymentId=6d671978861-398164df-6240-4d19-ad0b-308768d2a095, 
staticCfg=false, sql=false, cacheType=USER, template=false, 
updatesAllowed=true, cacheId=-1176672452, 
rcvdFrom=f00ec506-fc6c-45c5-b550-9308d17a39cf, objCtx=null, 
rcvdOnDiscovery=true, startTopVer=null, rcvdFromVer=null, 

[jira] [Created] (IGNITE-11103) "Control utility --cache idle_verify --dump --cache-filter ALL" comand result doesn't contain ignite-sys-cache group

[ARomantsov (JIRA)]

ARomantsov created IGNITE-11103:
---

 Summary: "Control utility --cache idle_verify --dump 
--cache-filter ALL" comand result doesn't contain ignite-sys-cache group
 Key: IGNITE-11103
 URL: https://issues.apache.org/jira/browse/IGNITE-11103
 Project: Ignite
  Issue Type: Bug
Reporter: ARomantsov


Look at functional add in https://issues.apache.org/jira/browse/IGNITE-9980 and 
find that issue



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

Re: Baseline auto-adjust`s discuss

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

Anton,

Great feature!

Could you please clarify a bit about implementation details? As I
understood auto-adjust properties is meant to be consistent across the
cluster. And baseline adjustment is put into some delay queue. Do we
put event into a queue on each node? Or is there some dedicated node
driving baseline adjustment?

пт, 25 янв. 2019 г. в 16:31, Anton Kalashnikov :
>
> Initially, hard timeout should protect grid from constantly changing 
> topology(constantly blinking node). But in fact if we have constantly 
> changing topology, baseline adjust operation is failed in most cases. As 
> result hard timeout only added complexity but it don't give any new 
> guarantee. So I think we can skip it in first implementation.
>
> First of all timeout protect us from unnecessary adjust of baseline . If node 
> left the grid and immediately(or after some time less than us timeout) it 
> join back to grid. Also timeout is helpful in other cases when some events 
> happened one after another.
>
> This feature doesn't have any complex heuristic to react, except of described 
> in restrictions section.
>
> Also I want to notes that this feature isn't protect us from constantly 
> blinking node. We need one more heuristic mechanism for detect this situation 
> and doing some actions like removing this node from grid.
>
> --
> Best regards,
> Anton Kalashnikov
>
>
> 25.01.2019, 15:43, "Sergey Chugunov" :
> > Anton,
> >
> > As I understand from the IEP document policy was supposed to support two
> > timeouts: soft and hard, so here you're proposing a bit simpler
> > functionality.
> >
> > Just to clarify, do I understand correctly that this feature when enabled
> > will auto-adjust blt on each node join/node left event, and timeout is
> > necessary to protect us from blinking nodes?
> > So no complexities with taking into account number of alive backups or
> > something like that?
> >
> > On Fri, Jan 25, 2019 at 1:11 PM Vladimir Ozerov 
> > wrote:
> >
> >>  Got it, makes sense.
> >>
> >>  On Fri, Jan 25, 2019 at 11:06 AM Anton Kalashnikov 
> >>  wrote:
> >>
> >>  > Vladimir, thanks for your notes, both of them looks good enough but I
> >>  > have two different thoughts about it.
> >>  >
> >>  > I think I agree about enabling only one of manual/auto adjustment. It is
> >>  > easier than current solution and in fact as extra feature we can allow
> >>  > user to force task to execute(if they doesn't want to wait until timeout
> >>  > expired).
> >>  > But about second one I don't sure that one parameters instead of two
> >>  would
> >>  > be more convenient. For example: in case when user changed timeout and
> >>  then
> >>  > disable auto-adjust after then when someone will want to enable it they
> >>  > should know what value of timeout was before auto-adjust was disabled. I
> >>  > think "negative value" pattern good choice for always usable parameters
> >>  > like timeout of connection (ex. -1 equal to endless waiting) and so on,
> >>  but
> >>  > in our case we want to disable whole functionality rather than change
> >>  > parameter value.
> >>  >
> >>  > --
> >>  > Best regards,
> >>  > Anton Kalashnikov
> >>  >
> >>  >
> >>  > 24.01.2019, 22:03, "Vladimir Ozerov" :
> >>  > > Hi Anton,
> >>  > >
> >>  > > This is great feature, but I am a bit confused about automatic
> >>  disabling
> >>  > of
> >>  > > a feature during manual baseline adjustment. This may lead to
> >>  unpleasant
> >>  > > situations when a user enabled auto-adjustment, then re-adjusted it
> >>  > > manually somehow (e.g. from some previously created script) so that
> >>  > > auto-adjustment disabling went unnoticed, then added more nodes hoping
> >>  > that
> >>  > > auto-baseline is still active, etc.
> >>  > >
> >>  > > Instead, I would rather make manual and auto adjustment mutually
> >>  > exclusive
> >>  > > - baseline cannot be adjusted manually when auto mode is set, and vice
> >>  > > versa. If exception is thrown in that cases, administrators will 
> >> always
> >>  > > know current behavior of the system.
> >>  > >
> >>  > > As far as configuration, wouldn’t it be enough to have a single long
> >>  > value
> >>  > > as opposed to Boolean + long? Say, 0 - immediate auto adjustment,
> >>  > negative
> >>  > > - disabled, positive - auto adjustment after timeout.
> >>  > >
> >>  > > Thoughts?
> >>  > >
> >>  > > чт, 24 янв. 2019 г. в 18:33, Anton Kalashnikov :
> >>  > >
> >>  > >> Hello, Igniters!
> >>  > >>
> >>  > >> Work on the Phase II of IEP-4 (Baseline topology) [1] has started. I
> >>  > want
> >>  > >> to start to discuss of implementation of "Baseline auto-adjust" [2].
> >>  > >>
> >>  > >> "Baseline auto-adjust" feature implements mechanism of auto-adjust
> >>  > >> baseline corresponding to current topology after event join/left was
> >>  > >> appeared. It is required because when a node left the grid and nobody
> >>  > would
> >>  > >> change baseline manually it can lead to lost data(when some more
> >>  nodes
> >>  > left

[jira] [Created] (IGNITE-11101) Web console: validation does not work properly in corner case in Firefox

[Pavel Konstantinov (JIRA)]

Pavel Konstantinov created IGNITE-11101:
---

 Summary: Web console: validation does not work properly in corner 
case in Firefox
 Key: IGNITE-11101
 URL: https://issues.apache.org/jira/browse/IGNITE-11101
 Project: Ignite
  Issue Type: Bug
  Components: wizards
Reporter: Pavel Konstantinov
Assignee: Ilya Borisov
 Attachments: screenshot-1.png

You should use Firefox
Configuration - Cluster - Advanced - Data storage configuration
Enter a literal value into System region / Initial size
Save






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

[jira] [Created] (IGNITE-11102) ODBC: Uninstall windows driver with different binaries version

[Stepan Pilschikov (JIRA)]

Stepan Pilschikov created IGNITE-11102:
--

 Summary: ODBC: Uninstall windows driver with different binaries 
version
 Key: IGNITE-11102
 URL: https://issues.apache.org/jira/browse/IGNITE-11102
 Project: Ignite
  Issue Type: Bug
  Components: odbc
Reporter: Stepan Pilschikov


Failed to uninstall ignite dirver with different version of binary file 
platforms\cpp\bin\odbc\ignite-odbc-amd64.msi

{code}
cmd> msiexec.exe /i ignite-2.5.0\platforms\cpp\bin\odbc\ignite-odbc-amd64.msi 
/n - OK
cmd> msiexec.exe /uninstall 
ignite-2.6.0\platforms\cpp\bin\odbc\ignite-odbc-amd64.msi /n - Error: Different 
version of product already installed
{code}

It failed between all versions of ignite 2.7 -> 2.6, 2.6 -> 2.5 e.t.c.



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

Want to help with newbie issues

[Sergey Moldachev]

Hi Ignite Developers,
I would like to fix this the issue: IGNITE-8550
.

It will be my first contribution, my JIRA username is *smoldachev*.

Is there anything else required from me?

Best regards,
Sergey Moldachev