Re: Node discovery
Sorry, my mistake. I realized it was a networking issue. Its fixed now. What ports should I be whitelisting for the setup to work in a firewall? On Mon, Mar 21, 2016 at 11:33 AM, babu prasad wrote: > Thank you! > Here is the configuration. > > > > > http://www.springframework.org/schema/beans"; >xmlns:util="http://www.springframework.org/schema/util"; >xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; >xsi:schemaLocation=" >http://www.springframework.org/schema/beans >http://www.springframework.org/schema/beans/spring-beans.xsd >http://www.springframework.org/schema/util >http://www.springframework.org/schema/util/spring-util.xsd";> > >class="org.apache.ignite.configuration.IgniteConfiguration"> > > > > > > > > >class="org.apache.ignite.cache.eviction.lru.LruEvictionPolicy"> > > > > > > > > > > > > > class="org.apache.ignite.spi.discovery.tcp.ipfinder.vm.TcpDiscoveryVmIpFinder"> > > > 127.0.0.1:47500..47509 > > > > > > > > > class="org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi"> > > > > > > > On Mon, Mar 21, 2016 at 1:39 AM, Vladimir Ozerov > wrote: > >> Hi, >> >> Looks like a kind of misconfiguration or networking problem. Please >> provide XML configuration you used to build the cluster. >> >> Vladimir. >> >> On Mon, Mar 21, 2016 at 10:29 AM, babu prasad wrote: >> >>> Hi, >>> >>> I am trying to automate ignite cluster build. >>> I am using apache-ignite-fabric-1.5.0.final-bin.zip. >>> Looks like the nodes are starting up as individual nodes and not as part >>> of the cluster. >>> >>> I tried using both the AWS configuration(using S3) and static IP and I >>> am still running into the issue where the nodes are not discovered as part >>> of the cluster. >>> >>> Could something be broken? >>> >>> Thanks! >>> >>> -Babu >>> >> >> >
Re: Node discovery
Thank you! Here is the configuration. http://www.springframework.org/schema/beans"; xmlns:util="http://www.springframework.org/schema/util"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xsi:schemaLocation=" http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd http://www.springframework.org/schema/util http://www.springframework.org/schema/util/spring-util.xsd";> 127.0.0.1:47500..47509 On Mon, Mar 21, 2016 at 1:39 AM, Vladimir Ozerov wrote: > Hi, > > Looks like a kind of misconfiguration or networking problem. Please > provide XML configuration you used to build the cluster. > > Vladimir. > > On Mon, Mar 21, 2016 at 10:29 AM, babu prasad wrote: > >> Hi, >> >> I am trying to automate ignite cluster build. >> I am using apache-ignite-fabric-1.5.0.final-bin.zip. >> Looks like the nodes are starting up as individual nodes and not as part >> of the cluster. >> >> I tried using both the AWS configuration(using S3) and static IP and I am >> still running into the issue where the nodes are not discovered as part of >> the cluster. >> >> Could something be broken? >> >> Thanks! >> >> -Babu >> > >
Node discovery
Hi, I am trying to automate ignite cluster build. I am using apache-ignite-fabric-1.5.0.final-bin.zip. Looks like the nodes are starting up as individual nodes and not as part of the cluster. I tried using both the AWS configuration(using S3) and static IP and I am still running into the issue where the nodes are not discovered as part of the cluster. Could something be broken? Thanks! -Babu
Re: Cache.put latencies high
All nodes are in same az. 1-2 ms ping times.
Sent from my iPhone
> On Jan 17, 2016, at 10:52 PM, Jörn Franke wrote:
>
> Are you using AWS ? What is the ping time between the nodes?
>
>> On 18 Jan 2016, at 06:48, Babu Prasad wrote:
>>
>> I did simple sequential puts to the cache. The latencies kept spiking
>> intermittently to 30ms or higher.
>> The test took about 30 minutes to load 1M records. I am using the s3 ip
>> finder for discovery.
>> I would expect 1-2 ms at max putting to a cache per request, but 30 ms seems
>> a little higher.
>> Are there best practices I should follow to tune the server and the client
>> for better latency?
>>
>> Sent from my iPhone
>>
>>> On Jan 12, 2016, at 11:59 PM, Dmitriy Setrakyan
>>> wrote:
>>>
>>> This is usually a problem with one-threaded benchmarks.
>>>
>>> 1. You should add a warm up step, i.e. have your system work for about a
>>> minute before starting measuring.
>>>
>>> 2. You should decide whether your application will be single-threaded or
>>> multi-threaded. If it is multi-threaded, then your test should also be
>>> multi-threaded.
>>>
>>> 3. And finally you should verify that network works well in your
>>> environment. Do you have 10G ethernet?
>>>
>>> D.
>>>
>>>> On Tue, Jan 12, 2016 at 8:27 PM, babu prasad wrote:
>>>> Hi,
>>>>
>>>> I have configured 2 ignite servers with a heap size of 8G each.
>>>> Running with backups=1 and primary_sync mode.
>>>>
>>>> Ignite servers are being used as a write behind cache for my Aurora
>>>> database.
>>>>
>>>> I am trying to run a load test with 3 clients talking to the remote cache
>>>> in the 2 ignite servers.
>>>> All the hosts are in the same availability zone.
>>>>
>>>> My clients do a simple put and I calculate time taken for put on the
>>>> client side.
>>>>
>>>> long startTime = System.currentTimeMillis();
>>>> cache.put(k, c1);
>>>> long elapsedTime = System.currentTimeMillis() - startTime;
>>>> System.out.println("Total elapsed timein milliseconds: " + elapsedTime);
>>>>
>>>> Here is the latency from the last few requests:
>>>> Total elapsed timein milliseconds: 31
>>>> Total elapsed timein milliseconds: 29
>>>> Total elapsed timein milliseconds: 26
>>>> Total elapsed timein milliseconds: 28
>>>> Total elapsed timein milliseconds: 28
>>>> Total elapsed timein milliseconds: 27
>>>> Total elapsed timein milliseconds: 27
>>>> Total elapsed timein milliseconds: 29
>>>> Total elapsed timein milliseconds: 26
>>>> Total elapsed timein milliseconds: 26
>>>> Total elapsed timein milliseconds: 27
>>>> Total elapsed timein milliseconds: 27
>>>> Total elapsed timein milliseconds: 28
>>>> Total elapsed timein milliseconds: 28
>>>> Total elapsed timein milliseconds: 27
>>>> Total elapsed timein milliseconds: 26
>>>> Total elapsed timein milliseconds: 27
>>>> Total elapsed timein milliseconds: 28
>>>> Total elapsed timein milliseconds: 27
>>>> Total elapsed timein milliseconds: 26
>>>> Total elapsed timein milliseconds: 26
>>>> Total elapsed timein milliseconds: 29
>>>> Total elapsed timein milliseconds: 26
>>>> Total elapsed timein milliseconds: 27
>>>> Total elapsed timein milliseconds: 26
>>>> Total elapsed timein milliseconds: 27
>>>> Total elapsed timein milliseconds: 29
>>>> Total elapsed timein milliseconds: 27
>>>> Total elapsed timein milliseconds: 28
>>>> Total elapsed timein milliseconds: 26
>>>> Total elapsed timein milliseconds: 27
>>>> Total elapsed timein milliseconds: 27
>>>> Total elapsed timein milliseconds: 27
>>>> Total elapsed timein milliseconds: 29
>>>>
>>>> Not sure what is going on here. I am pretty sure I am doing something
>>>> wrong here.
>>>>
>>>>
>>>> Thanks!
>>>
Re: Cache.put latencies high
I did simple sequential puts to the cache. The latencies kept spiking
intermittently to 30ms or higher.
The test took about 30 minutes to load 1M records. I am using the s3 ip finder
for discovery.
I would expect 1-2 ms at max putting to a cache per request, but 30 ms seems a
little higher.
Are there best practices I should follow to tune the server and the client for
better latency?
Sent from my iPhone
> On Jan 12, 2016, at 11:59 PM, Dmitriy Setrakyan wrote:
>
> This is usually a problem with one-threaded benchmarks.
>
> 1. You should add a warm up step, i.e. have your system work for about a
> minute before starting measuring.
>
> 2. You should decide whether your application will be single-threaded or
> multi-threaded. If it is multi-threaded, then your test should also be
> multi-threaded.
>
> 3. And finally you should verify that network works well in your environment.
> Do you have 10G ethernet?
>
> D.
>
>> On Tue, Jan 12, 2016 at 8:27 PM, babu prasad wrote:
>> Hi,
>>
>> I have configured 2 ignite servers with a heap size of 8G each.
>> Running with backups=1 and primary_sync mode.
>>
>> Ignite servers are being used as a write behind cache for my Aurora database.
>>
>> I am trying to run a load test with 3 clients talking to the remote cache in
>> the 2 ignite servers.
>> All the hosts are in the same availability zone.
>>
>> My clients do a simple put and I calculate time taken for put on the client
>> side.
>>
>> long startTime = System.currentTimeMillis();
>> cache.put(k, c1);
>> long elapsedTime = System.currentTimeMillis() - startTime;
>> System.out.println("Total elapsed timein milliseconds: " + elapsedTime);
>>
>> Here is the latency from the last few requests:
>> Total elapsed timein milliseconds: 31
>> Total elapsed timein milliseconds: 29
>> Total elapsed timein milliseconds: 26
>> Total elapsed timein milliseconds: 28
>> Total elapsed timein milliseconds: 28
>> Total elapsed timein milliseconds: 27
>> Total elapsed timein milliseconds: 27
>> Total elapsed timein milliseconds: 29
>> Total elapsed timein milliseconds: 26
>> Total elapsed timein milliseconds: 26
>> Total elapsed timein milliseconds: 27
>> Total elapsed timein milliseconds: 27
>> Total elapsed timein milliseconds: 28
>> Total elapsed timein milliseconds: 28
>> Total elapsed timein milliseconds: 27
>> Total elapsed timein milliseconds: 26
>> Total elapsed timein milliseconds: 27
>> Total elapsed timein milliseconds: 28
>> Total elapsed timein milliseconds: 27
>> Total elapsed timein milliseconds: 26
>> Total elapsed timein milliseconds: 26
>> Total elapsed timein milliseconds: 29
>> Total elapsed timein milliseconds: 26
>> Total elapsed timein milliseconds: 27
>> Total elapsed timein milliseconds: 26
>> Total elapsed timein milliseconds: 27
>> Total elapsed timein milliseconds: 29
>> Total elapsed timein milliseconds: 27
>> Total elapsed timein milliseconds: 28
>> Total elapsed timein milliseconds: 26
>> Total elapsed timein milliseconds: 27
>> Total elapsed timein milliseconds: 27
>> Total elapsed timein milliseconds: 27
>> Total elapsed timein milliseconds: 29
>>
>> Not sure what is going on here. I am pretty sure I am doing something wrong
>> here.
>>
>>
>> Thanks!
>
Re: Help with Ignite-Zeppelin
I was using Amazon EMR. Looks like there 1.4 jars.
Copied over the 1.5 jars, created a new ignite-jdbc.xml and updated the
jdbc url to use the new jdbc url.
Did the trick!
On Sun, Jan 17, 2016 at 3:50 PM, babu prasad wrote:
> Hi,
>
> I have been trying to setup Zeppelin to talk to Apache Ignite, but no
> success.
>
> I have my ignite servers running on remote nodes.
> I keep getting this error.
>
> I followed this documentation to set it up -
> http://apacheignite.gridgain.org/v1.1/docs/data-analysis-with-apache-zeppelin
>
>
> ERROR [2016-01-17 23:44:24,598] ({pool-2-thread-2}
> IgniteSqlInterpreter.java[open]:100) - Can't open connection:
> java.sql.SQLException: Failed to establish connection.
> at
> org.apache.ignite.internal.jdbc.JdbcConnection.isValid(JdbcConnection.java:447)
> at
> org.apache.ignite.internal.jdbc.JdbcConnection.(JdbcConnection.java:123)
> at
> org.apache.ignite.IgniteJdbcDriver.connect(IgniteJdbcDriver.java:347)
> at java.sql.DriverManager.getConnection(DriverManager.java:571)
> at java.sql.DriverManager.getConnection(DriverManager.java:233)
> at
> org.apache.zeppelin.ignite.IgniteSqlInterpreter.open(IgniteSqlInterpreter.java:95)
> at
> org.apache.zeppelin.interpreter.ClassloaderInterpreter.open(ClassloaderInterpreter.java:74)
> at
> org.apache.zeppelin.interpreter.LazyOpenInterpreter.open(LazyOpenInterpreter.java:68)
> at
> org.apache.zeppelin.interpreter.LazyOpenInterpreter.interpret(LazyOpenInterpreter.java:92)
> at
> org.apache.zeppelin.interpreter.remote.RemoteInterpreterServer$InterpretJob.jobRun(RemoteInterpreterServer.java:276)
> at org.apache.zeppelin.scheduler.Job.run(Job.java:170)
> at
> org.apache.zeppelin.scheduler.FIFOScheduler$1.run(FIFOScheduler.java:118)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: class
> org.apache.ignite.internal.client.GridClientDisconnectedException: Latest
> topology update failed.
> at
> org.apache.ignite.internal.client.impl.connection.GridClientTopology.nodes(GridClientTopology.java:335)
> at
> org.apache.ignite.internal.client.impl.GridClientAbstractProjection.projectionNodes(GridClientAbstractProjection.java:312)
> at
> org.apache.ignite.internal.client.impl.GridClientAbstractProjection.balancedNode(GridClientAbstractProjection.java:352)
> at
> org.apache.ignite.internal.client.impl.GridClientAbstractProjection.withReconnectHandling(GridClientAbstractProjection.java:109)
> at
> org.apache.ignite.internal.client.impl.GridClientComputeImpl.executeAsync(GridClientComputeImpl.java:132)
> at
> org.apache.ignite.internal.jdbc.JdbcConnection.isValid(JdbcConnection.java:444)
> ... 18 more
> Caused by: class
> org.apache.ignite.internal.client.GridServerUnreachableException: Failed to
> connect to any of the servers in list: [/127.0.0.1:40075]
> at
> org.apache.ignite.internal.client.impl.connection.GridClientConnectionManagerAdapter.connect(GridClientConnectionManagerAdapter.java:414)
> at
> org.apache.ignite.internal.client.impl.connection.GridClientConnectionManagerAdapter.init(GridClientConnectionManagerAdapter.java:226)
> at
> org.apache.ignite.internal.client.impl.GridClientImpl.tryInitTopology(GridClientImpl.java:498)
> at
> org.apache.ignite.internal.client.impl.GridClientImpl.(GridClientImpl.java:194)
> at
> org.apache.ignite.internal.client.GridClientFactory.start(GridClientFactory.java:58)
> at
> org.apache.ignite.internal.jdbc.JdbcConnection.(JdbcConnection.java:117)
> ... 17 more
> Caused by: java.net.ConnectException: Connection refused
> at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method)
> at
> sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:744)
> at sun.nio.ch.SocketAdaptor.connect(SocketAdaptor.java:117)
> at
> org.apache.ignite.internal.client.impl.connection.GridClientNioTcpConnection.(GridClientNioTcpConnection.java:217)
> at
> org.apache.ignite.internal.client.impl.connection.GridClientConnectionManagerAdapter.connect(GridClientConnectionManagerAdapter.java:463)
> at
> org.apache.ignite.internal.client.impl.connection.GridClientConnectionManagerAdapter.connect(GridClientConnectionManagerAdapter.java:399)
>
>
>
Help with Ignite-Zeppelin
Hi,
I have been trying to setup Zeppelin to talk to Apache Ignite, but no
success.
I have my ignite servers running on remote nodes.
I keep getting this error.
I followed this documentation to set it up -
http://apacheignite.gridgain.org/v1.1/docs/data-analysis-with-apache-zeppelin
ERROR [2016-01-17 23:44:24,598] ({pool-2-thread-2}
IgniteSqlInterpreter.java[open]:100) - Can't open connection:
java.sql.SQLException: Failed to establish connection.
at
org.apache.ignite.internal.jdbc.JdbcConnection.isValid(JdbcConnection.java:447)
at
org.apache.ignite.internal.jdbc.JdbcConnection.(JdbcConnection.java:123)
at org.apache.ignite.IgniteJdbcDriver.connect(IgniteJdbcDriver.java:347)
at java.sql.DriverManager.getConnection(DriverManager.java:571)
at java.sql.DriverManager.getConnection(DriverManager.java:233)
at
org.apache.zeppelin.ignite.IgniteSqlInterpreter.open(IgniteSqlInterpreter.java:95)
at
org.apache.zeppelin.interpreter.ClassloaderInterpreter.open(ClassloaderInterpreter.java:74)
at
org.apache.zeppelin.interpreter.LazyOpenInterpreter.open(LazyOpenInterpreter.java:68)
at
org.apache.zeppelin.interpreter.LazyOpenInterpreter.interpret(LazyOpenInterpreter.java:92)
at
org.apache.zeppelin.interpreter.remote.RemoteInterpreterServer$InterpretJob.jobRun(RemoteInterpreterServer.java:276)
at org.apache.zeppelin.scheduler.Job.run(Job.java:170)
at
org.apache.zeppelin.scheduler.FIFOScheduler$1.run(FIFOScheduler.java:118)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
Caused by: class
org.apache.ignite.internal.client.GridClientDisconnectedException: Latest
topology update failed.
at
org.apache.ignite.internal.client.impl.connection.GridClientTopology.nodes(GridClientTopology.java:335)
at
org.apache.ignite.internal.client.impl.GridClientAbstractProjection.projectionNodes(GridClientAbstractProjection.java:312)
at
org.apache.ignite.internal.client.impl.GridClientAbstractProjection.balancedNode(GridClientAbstractProjection.java:352)
at
org.apache.ignite.internal.client.impl.GridClientAbstractProjection.withReconnectHandling(GridClientAbstractProjection.java:109)
at
org.apache.ignite.internal.client.impl.GridClientComputeImpl.executeAsync(GridClientComputeImpl.java:132)
at
org.apache.ignite.internal.jdbc.JdbcConnection.isValid(JdbcConnection.java:444)
... 18 more
Caused by: class
org.apache.ignite.internal.client.GridServerUnreachableException: Failed to
connect to any of the servers in list: [/127.0.0.1:40075]
at
org.apache.ignite.internal.client.impl.connection.GridClientConnectionManagerAdapter.connect(GridClientConnectionManagerAdapter.java:414)
at
org.apache.ignite.internal.client.impl.connection.GridClientConnectionManagerAdapter.init(GridClientConnectionManagerAdapter.java:226)
at
org.apache.ignite.internal.client.impl.GridClientImpl.tryInitTopology(GridClientImpl.java:498)
at
org.apache.ignite.internal.client.impl.GridClientImpl.(GridClientImpl.java:194)
at
org.apache.ignite.internal.client.GridClientFactory.start(GridClientFactory.java:58)
at
org.apache.ignite.internal.jdbc.JdbcConnection.(JdbcConnection.java:117)
... 17 more
Caused by: java.net.ConnectException: Connection refused
at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method)
at
sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:744)
at sun.nio.ch.SocketAdaptor.connect(SocketAdaptor.java:117)
at
org.apache.ignite.internal.client.impl.connection.GridClientNioTcpConnection.(GridClientNioTcpConnection.java:217)
at
org.apache.ignite.internal.client.impl.connection.GridClientConnectionManagerAdapter.connect(GridClientConnectionManagerAdapter.java:463)
at
org.apache.ignite.internal.client.impl.connection.GridClientConnectionManagerAdapter.connect(GridClientConnectionManagerAdapter.java:399)
Apache Ignite client on AWS Lambda
Hi, I almost got Ignite client running on AWS Lambda. But then, I hit this error, Caused by: class org.apache.ignite.IgniteCheckedException: Failed to bind time server socket within specified port range [locHost=ip-10-0-73-203.ec2.internal/10.0.73.203, startPort=31100, endPort=31199] at org.apache.ignite.internal.processors.clock.GridClockServer.start(GridClockServer.java:101) at org.apache.ignite.internal.processors.clock.GridClockSyncProcessor.start(GridClockSyncProcessor.java:96) at org.apache.ignite.internal.IgniteKernal.startProcessor(IgniteKernal.java:1523) ... 9 more This may not be an ignite issue at all, but wanted to check if there are any workarounds and what it is trying to do here? Thanks!
Compression on Ignite
Does ignite compress data in memory or is the data stored as such? If there is no default compression, do you intend to provide an option at a later point? While storing large amounts of data in a distributed cache, compression may help a lot.
Re: Loadcache behavior
localloadcache() would still load only a single local cache node right? Is there a way I can run a single instance of the query from the client and load it in the distributed cache that partitions the result across all nodes? On Fri, Jan 15, 2016 at 1:23 PM, vkulichenko wrote: > Vinay, > > Local cache has the same issue as others - load will be triggered on all > nodes. I added a comment in the ticket. > > As a workaround you can simply call localLoadCache() method instead of > loadCache() - this should do the trick. > > -Val > > > > -- > View this message in context: > http://apache-ignite-users.70518.x6.nabble.com/Loadcache-behavior-tp2571p2590.html > Sent from the Apache Ignite Users mailing list archive at Nabble.com. >
Re: Loadcache behavior
Thanks! This may still not help because my underlying datastore is a warehouse where only batch queries are efficient, Also, it looks like the key to partition mapping could change if the no of partitions in the aff function , which will result in unnecessary backfills. I think I might need to go one step forward in the ingestion process and use the datastreamer and consume from my event bus which is kinesis. Sent from my iPhone > On Jan 15, 2016, at 5:11 AM, Alexey Goncharuk > wrote: > > Btw, > > Even though the same query is executed on all nodes, Ignite will > automatically filter out the keys that does not belong to the local node upon > cache loading. When the number of nodes is high, this is not very effective > since only a small part of data (roughly K/N, where K is the number of > backups + 1, N is the number of nodes in a cluster) will loaded to the cache > for each node. > > This may be optimized if you store the partition ID alongside with the data > record in your database. Take a look at this topic in the documentation [1]. > In this case each node will select only those records that belong to this > node, which substantially decreases the database load. Applying this will > also allow you to workaround the bug related to running a cache query on > client nodes. > > Hope this helps, > AG > > --- > [1] > https://apacheignite.readme.io/docs/data-loading#section-partition-aware-data-loading
Loadcache behavior
I was loading data from AWS Redshift into Ignite through the loadcache API. cache.loadCache(null, "java.lang.Integer", "select * from lineorder where lo_orderdate > 19970101"); I ran this from a single client. The query basically ran on all the nodes. I had 1 client and 2 servers and the same query ran thrice on the database server. Is this expected behaviour? Thanks!
Cache.put latencies high
Hi,
I have configured 2 ignite servers with a heap size of 8G each.
Running with backups=1 and primary_sync mode.
Ignite servers are being used as a write behind cache for my Aurora
database.
I am trying to run a load test with 3 clients talking to the remote cache
in the 2 ignite servers.
All the hosts are in the same availability zone.
My clients do a simple put and I calculate time taken for put on the client
side.
long startTime = System.currentTimeMillis();
cache.put(k, c1);
long elapsedTime = System.currentTimeMillis() - startTime;
System.out.println("Total elapsed timein milliseconds: " + elapsedTime);
Here is the latency from the last few requests:
Total elapsed timein milliseconds: 31
Total elapsed timein milliseconds: 29
Total elapsed timein milliseconds: 26
Total elapsed timein milliseconds: 28
Total elapsed timein milliseconds: 28
Total elapsed timein milliseconds: 27
Total elapsed timein milliseconds: 27
Total elapsed timein milliseconds: 29
Total elapsed timein milliseconds: 26
Total elapsed timein milliseconds: 26
Total elapsed timein milliseconds: 27
Total elapsed timein milliseconds: 27
Total elapsed timein milliseconds: 28
Total elapsed timein milliseconds: 28
Total elapsed timein milliseconds: 27
Total elapsed timein milliseconds: 26
Total elapsed timein milliseconds: 27
Total elapsed timein milliseconds: 28
Total elapsed timein milliseconds: 27
Total elapsed timein milliseconds: 26
Total elapsed timein milliseconds: 26
Total elapsed timein milliseconds: 29
Total elapsed timein milliseconds: 26
Total elapsed timein milliseconds: 27
Total elapsed timein milliseconds: 26
Total elapsed timein milliseconds: 27
Total elapsed timein milliseconds: 29
Total elapsed timein milliseconds: 27
Total elapsed timein milliseconds: 28
Total elapsed timein milliseconds: 26
Total elapsed timein milliseconds: 27
Total elapsed timein milliseconds: 27
Total elapsed timein milliseconds: 27
Total elapsed timein milliseconds: 29
Not sure what is going on here. I am pretty sure I am doing something wrong
here.
Thanks!
Re: Apache Ignite - RDS Aurora Question
Thanks for the quick response Val! Turns out I missed the default constructor in my POJO class. All good now. However, when running a live setup, having the ability to troubleshoot without turning off write behind would be great and I think the jira will help address it. Thanks again! On Mon, Jan 11, 2016 at 8:35 PM, vkulichenko wrote: > Hi babu, > > Looks like the exception trace is swallowed and it is hard to see the > reason > of the error. Can you temporarily switch off write-behind (set > writeBehindEnabled property to false) and try to run your test? The > database > will be updated synchronously in this case and you will be able to see the > full exception trace. > > I also created a ticket for exception handling issue: > https://issues.apache.org/jira/browse/IGNITE-2358 > > -Val > > > > -- > View this message in context: > http://apache-ignite-users.70518.x6.nabble.com/Apache-Ignite-RDS-Aurora-Question-tp2505p2506.html > Sent from the Apache Ignite Users mailing list archive at Nabble.com. >
Apache Ignite - RDS Aurora Question
Hi,
I am a Solutions Architect with AWS.
I have been trying to evaluate Apache Ignite by configuring write behind
and read through to RDS Aurora(Mysql).
I tried setting this up, but everytime I perform a cache write, it is not
able to write to the underlying database.
[03:45:14,763][WARNING][flusher-0-#47%null%][GridCacheWriteBehindStore]
Unable to update underlying store:
o.a.i.cache.store.jdbc.CacheJdbcPojoStore@7d721f3
Attaching the ignite config xml I used(Obscured the sensitive fields).
Let me know if you need more information.
Any insights you could provide to help me solve this is highly appreciated.
Thank you!
{\rtf1\ansi\ansicpg1252\cocoartf1348\cocoasubrtf170
{\fonttbl\f0\fnil\fcharset0 Menlo-Regular;}
{\colortbl;\red255\green255\blue255;}
\margl1440\margr1440\vieww25400\viewh13540\viewkind0
\pard\tx560\tx1120\tx1680\tx2240\tx2800\tx3360\tx3920\tx4480\tx5040\tx5600\tx6160\tx6720\pardirnatural
\f0\fs22 \cf0 \CocoaLigature0 \
\
\
\
http://www.springframework.org/schema/beans"\
xmlns:util="http://www.springframework.org/schema/util"\
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"\
xsi:schemaLocation="\
http://www.springframework.org/schema/beans\
http://www.springframework.org/schema/beans/spring-beans.xsd\
http://www.springframework.org/schema/util\
http://www.springframework.org/schema/util/spring-util.xsd";>\
\
\
\
>\'94 />\
>\'94 />\
\
\
\
\
\
\
\
\
\
\
\
\
\
\
\
\
\
\
\
\
\
\
\
\
\
\
\
\
\
\
\
\
\
\
\
\
\
\
\
\
\
\
\
\
\
\
\
\
\
\
\
\
\
\
\
\
\
\
\
\
\
\
\
\
\
\
\
\
\
\
\
\
\
\
\
\
\
\
\
\
\
\
\
\
\
\
\
\
\
\
\
\
\
\
\
\
>\'94/>\
\
\
\
\
\
\
\
\
\
\
\
\
>\'93 />\
>\'94 />\
\
}
