[jira] [Created] (IGNITE-8354) Ignite Continuosly refreshes Cassandra Session when there is an Exception in execute method of CassandraSessionImpl

[Yashasvi Kotamraju (JIRA)]

Yashasvi Kotamraju created IGNITE-8354:
--

 Summary: Ignite Continuosly refreshes Cassandra Session when there 
is an Exception in  execute method of CassandraSessionImpl
 Key: IGNITE-8354
 URL: https://issues.apache.org/jira/browse/IGNITE-8354
 Project: Ignite
  Issue Type: Bug
  Components: cassandra
Reporter: Yashasvi Kotamraju
Assignee: Igor Rudyak


*In CassandraSessionImpl.java* 

When handlePreparedStatementClusterError method is called during Exception, the 
session is refreshed.There might be many preparedstatements created with old 
session(since a session object can be shared between different batches). So 
when we execute the preparedstatements created with old session on a new 
session created , we get the the Exception 
"com.datastax.driver.core.exceptions.InvalidQueryException You may have used a 
PreparedStatement that was created with another Cluster instance". Which would 
again call handlePreparedStatementClusterError  and refresh session again and 
this happens continuously. We have observed continuous cassandra session 
refresh warnings when this scenario occurred. 



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

Re: write-through when using SQL updates

[Dmitriy Setrakyan]

On Sun, Apr 22, 2018 at 10:16 PM, Denis Magda  wrote:

> If a table is created with CREATE TABLE command then:
>
>- Ignite creates two custom binary types (one for the key and one for
>the value) the columns will be wrapped into. A primary key defines what
>goes into the key. It happens automatically unless...
>- You define names of existing business objects the columns will be
>mapped to. Use KEY_TYPE and VALUE_TYPE parameters for that.
>
> Read more here:
> https://apacheignite-sql.readme.io/docs/create-table#section-description


Finally, I see the documentation. We need a separate section for it with a
proper title. To the least, we will be able to provide a direct link to it
when people ask questions.

D.

Re: write-through when using SQL updates

[Denis Magda]

If a table is created with CREATE TABLE command then:

   - Ignite creates two custom binary types (one for the key and one for
   the value) the columns will be wrapped into. A primary key defines what
   goes into the key. It happens automatically unless...
   - You define names of existing business objects the columns will be
   mapped to. Use KEY_TYPE and VALUE_TYPE parameters for that.

Read more here:
https://apacheignite-sql.readme.io/docs/create-table#section-description

--
Denis

On Sun, Apr 22, 2018 at 9:58 PM, Dmitriy Setrakyan 
wrote:

> Denis, I get that we support it, but I still do not understand how. Given
> an SQL table in Ignite with several columns, what is the key class and what
> is the value class? Where do we document how SQL types map to key-value
> types?
>
> D.
>
> On Sun, Apr 22, 2018 at 1:43 PM, Denis Magda  wrote:
>
> > Dmitriy,
> >
> > According to the docs, INSERTS are transformed into cache.putIfAbsent or
> > cache.invokeAll operations:
> > https://apacheignite-sql.readme.io/docs/insert#section-description
> >
> > UPDATES are turned into cache.invokeAll all the times:
> > https://apacheignite-sql.readme.io/docs/update#section-description
> >
> > Once an SQL statement becomes a key-value operation(s) we should update
> > both RAM and a 3rd party database following a standard contract:
> > https://apacheignite.readme.io/docs/3rd-party-store
> >
> > SQL experts, please confirm my understanding is correct.
> >
> > --
> > Denis
> >
> >
> > On Sun, Apr 22, 2018 at 7:54 AM, Dmitriy Setrakyan <
> dsetrak...@apache.org>
> > wrote:
> >
> > > Igniters,
> > >
> > > Do we support write-through to a 3rd party database when performing SQL
> > > inserts and updates? If yes, how does the mapping between SQL and
> > > CacheStore key-value API happen?
> > >
> > > D.
> > >
> >
>

Re: write-through when using SQL updates

[Dmitriy Setrakyan]

Denis, I get that we support it, but I still do not understand how. Given
an SQL table in Ignite with several columns, what is the key class and what
is the value class? Where do we document how SQL types map to key-value
types?

D.

On Sun, Apr 22, 2018 at 1:43 PM, Denis Magda  wrote:

> Dmitriy,
>
> According to the docs, INSERTS are transformed into cache.putIfAbsent or
> cache.invokeAll operations:
> https://apacheignite-sql.readme.io/docs/insert#section-description
>
> UPDATES are turned into cache.invokeAll all the times:
> https://apacheignite-sql.readme.io/docs/update#section-description
>
> Once an SQL statement becomes a key-value operation(s) we should update
> both RAM and a 3rd party database following a standard contract:
> https://apacheignite.readme.io/docs/3rd-party-store
>
> SQL experts, please confirm my understanding is correct.
>
> --
> Denis
>
>
> On Sun, Apr 22, 2018 at 7:54 AM, Dmitriy Setrakyan 
> wrote:
>
> > Igniters,
> >
> > Do we support write-through to a 3rd party database when performing SQL
> > inserts and updates? If yes, how does the mapping between SQL and
> > CacheStore key-value API happen?
> >
> > D.
> >
>

Re: GA Grid Documentation for 2.5

[techbysample]

Akmal,

I have updated documentation for GA Grid in support of Ignite 2.5.

Please review.

https://issues.apache.org/jira/browse/IGNITE-8350

Best,
Turik





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

Re: write-through when using SQL updates

[Denis Magda]

Dmitriy,

According to the docs, INSERTS are transformed into cache.putIfAbsent or
cache.invokeAll operations:
https://apacheignite-sql.readme.io/docs/insert#section-description

UPDATES are turned into cache.invokeAll all the times:
https://apacheignite-sql.readme.io/docs/update#section-description

Once an SQL statement becomes a key-value operation(s) we should update
both RAM and a 3rd party database following a standard contract:
https://apacheignite.readme.io/docs/3rd-party-store

SQL experts, please confirm my understanding is correct.

--
Denis


On Sun, Apr 22, 2018 at 7:54 AM, Dmitriy Setrakyan 
wrote:

> Igniters,
>
> Do we support write-through to a 3rd party database when performing SQL
> inserts and updates? If yes, how does the mapping between SQL and
> CacheStore key-value API happen?
>
> D.
>

[jira] [Created] (IGNITE-8353) Failed to deserialize stored cache data from Ignite 2.4 on master

[Alexey Goncharuk (JIRA)]

Alexey Goncharuk created IGNITE-8353:


 Summary: Failed to deserialize stored cache data from Ignite 2.4 
on master
 Key: IGNITE-8353
 URL: https://issues.apache.org/jira/browse/IGNITE-8353
 Project: Ignite
  Issue Type: Bug
Reporter: Alexey Goncharuk


Got the following exception when starting a node with db from version 2.4 when 
eviction policy is configured.
{code}
[20:53:25,573][SEVERE][main][IgniteKernal] Exception during start processors, 
node will be stopped and close connections
class org.apache.ignite.IgniteCheckedException: Failed to start processor: 
GridProcessorAdapter []
at 
org.apache.ignite.internal.IgniteKernal.startProcessor(IgniteKernal.java:1717)
at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:962)
at 
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2014)
at 
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1723)
at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1151)
at 
org.apache.ignite.internal.IgnitionEx.startConfigurations(IgnitionEx.java:1069)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:955)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:854)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:724)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:693)
at org.apache.ignite.Ignition.start(Ignition.java:352)
at 
org.apache.ignite.startup.cmdline.CommandLineStartup.main(CommandLineStartup.java:301)
Caused by: class org.apache.ignite.IgniteCheckedException: Failed to 
deserialize object with given class loader: 
sun.misc.Launcher$AppClassLoader@764c12b6
at 
org.apache.ignite.marshaller.jdk.JdkMarshaller.unmarshal0(JdkMarshaller.java:147)
at 
org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.unmarshal(AbstractNodeNameAwareMarshaller.java:94)
at 
org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.readCacheData(FilePageStoreManager.java:672)
at 
org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.readCacheGroupCaches(FilePageStoreManager.java:658)
at 
org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.readCacheConfigurations(FilePageStoreManager.java:638)
at 
org.apache.ignite.internal.processors.cache.GridCacheProcessor.addCacheOnJoinFromConfig(GridCacheProcessor.java:811)
at 
org.apache.ignite.internal.processors.cache.GridCacheProcessor.start(GridCacheProcessor.java:706)
at 
org.apache.ignite.internal.IgniteKernal.startProcessor(IgniteKernal.java:1714)
... 11 more
{code}

The class has changed because {{LongAdder8}} was replaced with java8 native 
{{LongAdder}}.



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

write-through when using SQL updates

[Dmitriy Setrakyan]

Igniters,

Do we support write-through to a 3rd party database when performing SQL
inserts and updates? If yes, how does the mapping between SQL and
CacheStore key-value API happen?

D.

[GitHub] ignite pull request #3897: IGNITE-6538: test 500 times

[Mmuzaf]

GitHub user Mmuzaf opened a pull request:

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

IGNITE-6538: test 500 times



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

$ git pull https://github.com/Mmuzaf/ignite check-ignite-6538

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

https://github.com/apache/ignite/pull/3897.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 #3897


commit 5496341a7ccca6edb553af6f4ee4e2f8859ce015
Author: Maxim Muzafarov 
Date:   2018-04-22T14:00:01Z

IGNITE-6538: test 500 times




---

[jira] [Created] (IGNITE-8352) IgniteStandByClusterSuite: IgniteClusterActivateDeactivateTest.testClientReconnectClusterDeactivateInProgress flaky fail rate 12%

[Maxim Muzafarov (JIRA)]

Maxim Muzafarov created IGNITE-8352:
---

 Summary: IgniteStandByClusterSuite: 
IgniteClusterActivateDeactivateTest.testClientReconnectClusterDeactivateInProgress
 flaky fail rate 12%
 Key: IGNITE-8352
 URL: https://issues.apache.org/jira/browse/IGNITE-8352
 Project: Ignite
  Issue Type: Bug
Reporter: Maxim Muzafarov
Assignee: Maxim Muzafarov
 Fix For: 2.6


IgniteStandByClusterSuite: 
IgniteClusterActivateDeactivateTest.testClientReconnectClusterDeactivateInProgress
 (master fail rate 12,8%) 
[https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=5210129488604303757=%3Cdefault%3E=testDetails]

 



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

[jira] [Created] (IGNITE-8351) PME isStaleUpdate() method documentation mismatch

[Andrew Medvedev (JIRA)]

Andrew Medvedev created IGNITE-8351:
---

 Summary: PME isStaleUpdate() method documentation mismatch
 Key: IGNITE-8351
 URL: https://issues.apache.org/jira/browse/IGNITE-8351
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.4
Reporter: Andrew Medvedev


Method 
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl#isStaleUpdate
 documents: "New partition map is stale if topology version or update sequence 
are less than of current map"

Code however checks for non-strong equality for updateSequence():

```return currentMap != null &&
 (newMap.topologyVersion().compareTo(currentMap.topologyVersion()) < 0 ||
 newMap.topologyVersion().compareTo(currentMap.topologyVersion()) == 0 && 
newMap.updateSequence() <= currentMap.updateSequence());```

 

We have lots of Stale update WARN msgs as in 
https://issues.apache.org/jira/browse/IGNITE-8226 (status is proposed to change 
from WARN to DEBUG, not yet merged) and on further research it looks that the 
code is right, the documentation is wrong.

 

Coupled together with WARN status messages however,  documentation for 
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl#isStaleUpdate
  causes concerns...

 



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

Re: Service grid redesign

[Dmitriy Setrakyan]

Thanks! The IEP looks very big.

I would like to remind everyone that one of the biggest problems we have
with services is that it uses a replicated cache internally to do the
deployment. When all nodes have the same service configured in the XML
file, then all nodes will try to initiate a put into the replicated cache
at the same time for the same key, which results in lots of contention and
significantly slows down the startup speed.

In my view, this is what needs to be fixed first. Is there a ticket for it?

D.

On Sat, Apr 21, 2018 at 11:16 AM, Denis Magda  wrote:

> Dmitriy,
>
> Consider IEP page as a summary that was updated along the way:
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-
> 17%3A+Oil+Change+in+Service+Grid
>
> As far as I understand, Denis is going to create JIRA tickets basing on the
> discussion results.
>
> --
> Denis
>
> On Sat, Apr 21, 2018 at 3:04 AM, Dmitriy Setrakyan 
> wrote:
>
> > I am not sure why we are discussing a potential removal of the "init"
> > method. I think it is useful, as the service may have to do some
> > initialization before it goes online. I do not think this method is
> hurting
> > anyone.
> >
> > This thread is getting too long, and I am sure that most readers are
> > already getting lost in the proposed design. I would start a new thread
> > with a summary of all proposed changes.
> >
> > D.
> >
> > On Fri, Apr 20, 2018 at 5:25 PM, Valentin Kulichenko <
> > valentin.kuliche...@gmail.com> wrote:
> >
> > > Denis,
> > >
> > > > On the other hand, if exception is thrown from the *execute()
> *method,
> > > then service won't be undeployed.
> > >
> > > This is actually weird... What is going to happen in this case and how
> > user
> > > would handle this?
> > >
> > > -Val
> > >
> > > On Fri, Apr 20, 2018 at 1:10 AM, Denis Mekhanikov <
> dmekhani...@gmail.com
> > >
> > > wrote:
> > >
> > > > Val,
> > > >
> > > > *init()* method is executed before a service is considered deployed.
> > > > If any exception is thrown from it, then it will be handled as
> > deployment
> > > > failure.
> > > >
> > > > *execute() *method is run after the service is deployed, and it can
> > keep
> > > > running until the service is cancelled.
> > > > This method has its own thread, so it can perform some background
> work.
> > > >
> > > > Suppose you want to deploy HTTP server as a service on one of your
> > nodes.
> > > > You can place HTTP server creation logic in the *init() *method.
> > > > If some nodes don't have a permission to listen to needed ports,
> then a
> > > > corresponding exception will be propagated to the user code.
> > > > On the other hand, if exception is thrown from the *execute()
> *method,
> > > then
> > > > service won't be undeployed.
> > > >
> > > > Denis
> > > >
> > > > пт, 20 апр. 2018 г. в 2:35, Valentin Kulichenko <
> > > > valentin.kuliche...@gmail.com>:
> > > >
> > > > > Denis,
> > > > >
> > > > > I totally agree with you. I'm just not sure why do we need two
> > methods
> > > > > (init and execute) that have virtually same semantics. With the new
> > > > design,
> > > > > what would be the difference between these methods from user point
> of
> > > > view,
> > > > > and how one would determine what exactly should go in each of them?
> > > > Unless
> > > > > I'm missing something, it looks like unnecessary complication.
> > > > >
> > > > > -Val
> > > > >
> > > > > On Tue, Apr 17, 2018 at 1:00 AM, Denis Mekhanikov <
> > > dmekhani...@gmail.com
> > > > >
> > > > > wrote:
> > > > >
> > > > > > Val,
> > > > > >
> > > > > > Service initialisation is not going to happen in the discovery
> > > thread.
> > > > > > It should be done asynchronously, and initialisation results
> should
> > > be
> > > > > sent
> > > > > > to the coordinator over communication.
> > > > > > This is described in the IEP:
> > > > > > https://cwiki.apache.org/confluence/display/IGNITE/IEP-
> > > > > > 17%3A+Oil+Change+in+Service+Grid#IEP-17:OilChangeinServiceGrid-
> > > > > > Successfulscenario
> > > > > >
> > > > > > *init()* method is a validation step, making sure, that service
> is
> > > > ready
> > > > > > for work.
> > > > > > And deployment shouldn't be considered successful until *init()*
> > > > methods
> > > > > > finish their work on the assigned nodes.
> > > > > > Also *cancel() *and *init() *methods may be useful if we decide
> to
> > > > > > implement moving existing services to new nodes
> > > > > >  > > > > > 17%3A+Oil+Change+in+Service+Grid#IEP-17:OilChangeinServiceGrid-
> > > > > > Movingexistingservicestonewnodes>
> > > > > >  in
> > > > > > future.
> > > > > > These methods can be used to save and restore service's state
> from
> > > > cache,
> > > > > > when it is rebalanced to another node.
> > > > > >
> > > > > > As Denis said, if we are not going to prevent nodes from starting
> > on
> > > > > > service failures, then we should at least generate 

[GitHub] ignite pull request #3896: IGNITE-8070 FailureHandlers added to Ignite.NET c...

[ivandasch]

GitHub user ivandasch opened a pull request:

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

IGNITE-8070  FailureHandlers added to Ignite.NET configuration  



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

$ git pull https://github.com/ivandasch/ignite ignite-8070

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

https://github.com/apache/ignite/pull/3896.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 #3896


commit 257e9b98e1eccf63b3f977fa7e186686a658e427
Author: Ivan Daschinskiy 
Date:   2018-04-22T09:33:22Z

IGNITE-8070 wip.




---