Hibernate connection inspite of jdbc?

[Ravi Puri]

Given below load method of cachejdbcpersonstore. this is done using
preparedstatement n resultset. I want to implement the same using hibernate
n hql query

how to do this ?

and what is CacheStoreSession  ? where to use the same if i want to
implement using hibernate by replacing this Connection conn =
ses.attachment();???
 



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/Hibernate-connection-inspite-of-jdbc-tp3412.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: java.lang.IllegalStateException: Cache has been stopped

[ght230]

following is the detailed log, thank you for help me to check it.

2016-03-04 20:39:26 STDIO [ERROR] Mar 04, 2016 8:39:26 PM
org.apache.ignite.logger.java.JavaLogger error
SEVERE: Failed to send local partition map to node [node=TcpDiscoveryNode
[id=6701f10e-8319-47ac-99b2-3521cfaf91ca, addrs=[127.0.0.1, 192.168.70.19,
192.168.100.19, 192.168.200.19, 192.168.210.19],
sockAddrs=[HDD019/192.168.70.19:47500, /127.0.0.1:47500,
/192.168.200.19:47500, /192.168.70.19:47500, /192.168.100.19:47500,
/192.168.100.19:47500, /192.168.210.19:47500, /192.168.200.19:47500,
/192.168.210.19:47500], discPort=47500, order=75, intOrder=39,
lastExchangeTime=1457092565397, loc=false, ver=1.4.1#20150925-sha1:f051e49f,
isClient=false], exchId=null]
class org.apache.ignite.IgniteCheckedException: Failed to send message (node
may have left the grid or TCP connection cannot be established due to
firewall issues) [node=TcpDiscoveryNode
[id=6701f10e-8319-47ac-99b2-3521cfaf91ca, addrs=[127.0.0.1, 192.168.70.19,
192.168.100.19, 192.168.200.19, 192.168.210.19],
sockAddrs=[HDD019/192.168.70.19:47500, /127.0.0.1:47500,
/192.168.200.19:47500, /192.168.70.19:47500, /192.168.100.19:47500,
/192.168.100.19:47500, /192.168.210.19:47500, /192.168.200.19:47500,
/192.168.210.19:47500], discPort=47500, order=75, intOrder=39,
lastExchangeTime=1457092565397, loc=false, ver=1.4.1#20150925-sha1:f051e49f,
isClient=false], topic=TOPIC_CACHE, msg=GridDhtPartitionsSingleMessage
[parts={-2100569601=GridDhtPartitionMap
[nodeId=6704f7fd-a285-401c-8563-1c704b8f0b08, updateSeq=996, moving=0,
size=100], 689859866=GridDhtPartitionMap
[nodeId=6704f7fd-a285-401c-8563-1c704b8f0b08, updateSeq=928, moving=0,
size=28], 1325947219=GridDhtPartitionMap
[nodeId=6704f7fd-a285-401c-8563-1c704b8f0b08, updateSeq=918, moving=0,
size=20]}, client=false, super=GridDhtPartitionsAbstractMessage
[exchId=null, lastVer=GridCacheVersion [topVer=68560288, nodeOrderDrId=115,
globalTime=1457095166517, order=1457168152279], super=GridCacheMessage
[msgId=369, depInfo=null, err=null, skipPrepare=false]]], policy=2]
at
org.apache.ignite.internal.managers.communication.GridIoManager.send(GridIoManager.java:1071)
at
org.apache.ignite.internal.managers.communication.GridIoManager.send(GridIoManager.java:1214)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.sendNoRetry(GridCacheIoManager.java:873)
at
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.sendLocalPartitions(GridCachePartitionExchangeManager.java:760)
at
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.refreshPartitions(GridCachePartitionExchangeManager.java:671)
at
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.refreshPartitions(GridCachePartitionExchangeManager.java:690)
at
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.access$1800(GridCachePartitionExchangeManager.java:95)
at
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:1152)
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
at java.lang.Thread.run(Thread.java:745)
Caused by: class org.apache.ignite.spi.IgniteSpiException: Failed to send
message to remote node: TcpDiscoveryNode
[id=6701f10e-8319-47ac-99b2-3521cfaf91ca, addrs=[127.0.0.1, 192.168.70.19,
192.168.100.19, 192.168.200.19, 192.168.210.19],
sockAddrs=[HDD019/192.168.70.19:47500, /127.0.0.1:47500,
/192.168.200.19:47500, /192.168.70.19:47500, /192.168.100.19:47500,
/192.168.100.19:47500, /192.168.210.19:47500, /192.168.200.19:47500,
/192.168.210.19:47500], discPort=47500, order=75, intOrder=39,
lastExchangeTime=1457092565397, loc=false, ver=1.4.1#20150925-sha1:f051e49f,
isClient=false]
at
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage0(TcpCommunicationSpi.java:1940)
at
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage(TcpCommunicationSpi.java:1880)
at
org.apache.ignite.internal.managers.communication.GridIoManager.send(GridIoManager.java:1066)
... 9 more
Caused by: class org.apache.ignite.IgniteCheckedException: Failed to connect
to node (is node still alive?). Make sure that each GridComputeTask and
GridCacheTransaction has a timeout set in order to prevent parties from
waiting forever in case of network issues
[nodeId=6701f10e-8319-47ac-99b2-3521cfaf91ca,
addrs=[HDD019/192.168.70.19:47100, /192.168.200.19:47100,
/192.168.100.19:47100, /192.168.210.19:47100, /127.0.0.1:47100]]
at
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createTcpClient(TcpCommunicationSpi.java:2421)
at
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createNioClient(TcpCommunicationSpi.java:2074)
at

C++ Client for SQL Queries

[arthi]

Hi,

We need to get a C++ client to run SQL queries on caches built from our
server ignite components.
I am not seeing an example for this in the GIT HUB, can you please help? I
need to understand how the objects are defined for SQL queries (query
entities or annotations) and how they are indexed in the configuration.

Thanks,
Arthi



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/C-Client-for-SQL-Queries-tp3407.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: java.lang.IllegalStateException: Cache has been stopped

[vkulichenko]

Anyway, I would check the logs. Are there any errors? Did the topology
change? Was the node stopped?

If you upload your log files somewhere, I will take a look.

-Val



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/java-lang-IllegalStateException-Cache-has-been-stopped-tp3389p3406.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: visor command line authentication.

[vkulichenko]

Start command essentially connects to the remote host using SSH and executes
ignite.sh script there. Username and password here are for SSH connection.

-Val



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/visor-command-line-authentication-tp3395p3405.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Inserts stalled by write-behind process

[Dmitriy Setrakyan]

Agree with Valentin. One other thing you may wish to check is whether you
are doing a bulk insert to the database, or multiple individual inserts.
Bulk insert should perform better, of course.

D.

On Tue, Mar 8, 2016 at 4:50 PM, vkulichenko 
wrote:

> Hi,
>
> You're right, write-behind store has a back pressure mechanism that starts
> to update DB synchronously if the queue is too long. Otherwise you will
> most
> likely eventually get out of memory error.
>
> The backlog size is controlled by
> CacheConfiguration.setWriteBehindFlushSize() property. When this size is
> reached, the store will start flushing to the database in the background.
> If
> it will detect that the flushing process is slower than cache updates
> (i.e.,
> the backlog continuous growing above the setting), it will switch to sync
> updates.
>
> Makes sense?
>
> -Val
>
>
>
> --
> View this message in context:
> http://apache-ignite-users.70518.x6.nabble.com/Inserts-stalled-by-write-behind-process-tp3390p3399.html
> Sent from the Apache Ignite Users mailing list archive at Nabble.com.
>

Re: visor command line authentication.

[krishna]

Sorry I wasn't clear earlier.

I would like to start an ignite node on a remote host that's part of my
discoveryspi ip address list.
So, in order to use the command something like at visor cmd

visor> start -h=myhostip -uname=username -pw=password -n=2

I would like to know that username and password I need to provide as they
are not optional parameters.

Thanks for taking a look.



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/visor-command-line-authentication-tp3395p3403.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: java.lang.IllegalStateException: Cache has been stopped

[ght230]

No, I only do cache.get from the same server node.



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/java-lang-IllegalStateException-Cache-has-been-stopped-tp3389p3402.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: java.lang.IllegalStateException: Cache has been stopped

[vkulichenko]

Hi,

Are you doing cache.get from a client node? If so, is it possible that it
was disconnected from topology and then reconnected back? There are
scenarios when you can get this exception after this happens [1].

I would start with checking if there are any exceptions and/or warnings in
the logs.

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

-Val



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/java-lang-IllegalStateException-Cache-has-been-stopped-tp3389p3398.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Continuously running jobs

[Dmitriy Setrakyan]

Hi,

Sorry, somehow I missed this question.

Sounds like Ignite compute grid should be perfect for your task. Ignite
load balances the jobs within the cluster automatically, with several load
balancing policies available, so you should be able to simply unicast or
broadcast closures and have them equally distributed within the cluster.
The jobs are simple closures, so you should be able to implement any logic
you need.

For more information on the compute grid, scheduling, and load balancing,
please refer to Ignite documentation:

https://apacheignite.readme.io/docs/clustering
https://apacheignite.readme.io/docs/compute-grid
https://apacheignite.readme.io/docs/load-balancing
https://apacheignite.readme.io/docs/job-scheduling

D.


On Tue, Mar 8, 2016 at 1:44 PM, KSzabolcs  wrote:

> Was I not clear enough? Did I ask for something stupid?
>

Re: Continuously running jobs

[KSzabolcs]

Was I not clear enough? Did I ask for something stupid?

Re: Atomicity mode and read-after-write consistency

[Alexey Goncharuk]

Hi,

Consistency between nodes is guaranteed in ATOMIC mode, however, the
read-after-write guarantee is met in the following cases:
 - cache write synchronization mode is FULL_SYNC. In this mode cache.put()
will not return control until all data nodes (primary and backup)
responsible for the data are updated. See
CacheConfiguration.setWriteSynchronizationMode()
 - cache write synchronization mode is PRIMARY_SYNC, but reads from backups
are forbidden by setting CacheConfiguration#readFromBackup to false. In
this mode cache.put() will return control after the primary node has been
updated (backup nodes may not be updated yet), the the read consistency is
guaranteed because reads always happen from primary nodes.

Both modes have it's implications on performance - FULL_SYNC mode comes at
a slightly slower update performance while it allows more frequent local
reads using backups; PRIMARY_SYNC allows for a better update performance,
but the restriction for always-primary reads will result in more frequent
network calls for reads. It's up to you to decide which configuration suits
better for your use-case.

Hop this helps,
--AG

Re: A Question About Behavior

[Kevin Daly]

We were directly Manipulating the Cache.Entry and it was
reflecting directly in the H2 Indexes.. Not sure if it's desired behavior or
not.. But a definite Gotcha

To fix this we just call VALUE = ingintecache.get(KEY) to retrieve the value
rather than getting it directly from the entry (VALUE = entry.getValue(); 

I still owe you some code :)

Just been pegged I will revisit this this week..



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/A-Question-About-Behavior-tp3235p3392.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Atomicity mode and read-after-write consistency

[bsmets]

I have a question about consistency between nodes in an ignite cluster. We
are writing entries into an ignite cache on one node and reading the same
entry on another node just 1 second later but we observe that this second
node does not yet contain the entry. Is this normal behaviour?

Note that we are not using any transactions.

I read on http://apacheignite.gridgain.org/v1.2/docs/transactions that even
when using atomic mode, atomicity and consistency across nodes is
guaranteed. Does this mean that reads after a write are always guaranteed to
return the written value?



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/Atomicity-mode-and-read-after-write-consistency-tp3391.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Inserts stalled by write-behind process

[bsmets]

We are currently using an ignite setup with caches with very large offheap
sizes (10GB+) and in these caches we are inserting entries of roughly 30 kB.
We flush the entries to disk every minute using write-behind.

What we observe is that after a while, the inserts of new entries into the
cache seem to become synchronized with the writing of entries to disk.
Considering our disk is much slower than writing in memory, this is
effectively throttling our inserts. 

We noticed that the WriteBehindTotalCriticalOverflowCount in the metrics is
pretty high as well, which leads us to believe that inserts are waiting for
entries to be written to disk. 

Is this correct, and if so, how can we increase the write-behind backlog?



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/Inserts-stalled-by-write-behind-process-tp3390.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.