SQLQuery and Datatypes

[javastuff....@gmail.com]

Hi 

My cached object is Binarylizable. I am using SQLQuery and SQLFieldQuery. 

In some cases I need to query on a hardcoded/fixed filter e.g. Name = 'xyz'.
Same usecase for Long, Date, TimeStamp datatype as well. 

Basically not using setArgs().

I see it works fine for String, Int, Long. 
- Can I use formatted string for Date, Timestamp and Boolean datatypes? 
- If yes - What format for Date and Timestamp? Is there any disadvantages
because not using proper datatype and setArg?

Thanks,
-Sam   








--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/SQLQuery-and-Datatypes-tp12167.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Master-Worker Pattern Possible In Ignite?

[Sean Winship]

I've used GigaSpaces in the past and I'd like to know if I can use Ignite in a similar fashion. Specifically, I need to implement a master-worker pattern where one set of process writes objects to the in-memory data grid and another set reads those objects, does some processing, and possibly writes results back to the grid. One important GigaSpaces/JavaSpaces feature I need is leasing. If I write an object to the grid and it isn't picked up within a certain time period, it should automatically expire and I should get some kind of notification.

 

Ideally this system should be resilient to failure of one or more nodes.

 

Is Apache Ignite a good match for this use case?

 

Thanks,

 

Sean

 

Re: stdout - Message queue limit is set to 0, potential OOMEs

[javastuff....@gmail.com]

Added below to TcpCommunicationSpi and message went away, able to see the new
value on JMX as well.
//

However, how do I know what is the good or suitable value one need to set? I
have more than 50 different PARTITIONED OFF-HEAP caches defined, most likely
to have 2 to 4 nodes with 20GB each or more.
 
in my opinion, potential OOME is big risk with default configuration.
Everybody needs performance, but no one really need OOME. 

Thanks,
-Sam





--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/stdout-Message-queue-limit-is-set-to-0-potential-OOMEs-tp12048p12165.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Pessimistic TXN did not release lock on a key, all subsequent txns failed

[bintisepaha]

Andrey, we never start a txn on the client side. The key that gets locked on
our end and stays locked even after a successful txn is never read or
updated in a txn from the client side. Are you also able to reproduce the
key remaining locked issue?

Thanks,
Binti



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/Pessimistic-TXN-did-not-release-lock-on-a-key-all-subsequent-txns-failed-tp10536p12164.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Index

[Andrey Mashenkov]

Hi Sam,

Default is 'null' obviously, it is by bad design and here is a ticket [1].
It is already fixed in 2.0, where index is SORTED by default.

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


On Fri, Apr 21, 2017 at 10:00 PM, javastuff@gmail.com <
javastuff@gmail.com> wrote:

> Resolved it!
>
> I used default constructor for QueryIndex and missed setting IndexType.
> This
> resulted into missing index.
> Added /"idx.setIndexType(QueryIndexType.SORTED)"/, able to see index on H2
> debug console.
>
> What is the default IndexType?
> Is it expected to not throw error when IndexType is not set and ignore
> index
> creation? With default constructor this is likely to happen.
>
> Thanks,
> -Sam
>
>
>
> --
> View this message in context: http://apache-ignite-users.
> 70518.x6.nabble.com/Index-tp11969p12162.html
> Sent from the Apache Ignite Users mailing list archive at Nabble.com.
>



-- 
Best regards,
Andrey V. Mashenkov

Re: Index

[javastuff....@gmail.com]

Resolved it!

I used default constructor for QueryIndex and missed setting IndexType. This
resulted into missing index.
Added /"idx.setIndexType(QueryIndexType.SORTED)"/, able to see index on H2
debug console.

What is the default IndexType?
Is it expected to not throw error when IndexType is not set and ignore index
creation? With default constructor this is likely to happen.

Thanks,
-Sam



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

Re: Exceptions while running Closure with task count > 1000

[vdpyatkov]

Hi,

I try to check your example at near time.
But I wan to know hot to do that:

1) I should start empty Ignite server on dedicate machine.
2) After a empty server start, need to begin your example with n more then
1000.

Is it correct scenario?



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/Exceptions-while-running-Closure-with-task-count-1000-tp11989p12161.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: disable fault tolerance

[André Luis Almeida]

Andrey,

 I want to test  "in-memory distributed key-value store (Map)" with  fault
tolerance (fault in a node) enable and disable.

thanks

2017-04-20 17:41 GMT-03:00 Andrey Mashenkov :

> Hi Andre,
>
> What fault tolerance do you mean? Ignite has a number of modules.
>
> On Thu, Apr 20, 2017 at 9:54 PM, André Luis Almeida 
> wrote:
>
>> Igniters,
>>
>>  Is it possible to disable fault tolerance in Apache Ignite?
>>
>> thanks,
>>
>>
>> André Luís B. Almeida
>>
>
>
>
> --
> Best regards,
> Andrey V. Mashenkov
>



-- 
André Luís B. Almeida

Re: What is the difference between starting a node using Java application, and manual starting?

[rick_tem]

Is that entirely true?  Plugins don't start when you simply just start Ignite
with Ignite.bat or Ignite.sh unless you package your particular class among
the Ignite jars and add an org.apache.ignite.plugin.Pluginprovider file to
META-INF/services.  Or am I missing something.

Best,
Rick



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/What-is-the-difference-between-starting-a-node-using-Java-application-and-manual-starting-tp12143p12157.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Failing DataStreamer beacuse of minor version change

[Evgenii Zhuravlev]

You don't need to handle it, as it mentioned in exception message -
"DataStreamer will retry data transfer at stable topology ". It will retry
right after topology will be updated. If you don't have any other
exceptions - data loading finished successfully

2017-04-21 15:54 GMT+03:00 Alper Tekinalp :

> Hi,
>
> So how should I handle that exception? Should I just ignore it? Is
> there a way I can know when the data streamer successfully deliver
> after getting that error? I just want to know if data
> loading/rebalancing finished succesfully.
>
> On Fri, Apr 21, 2017 at 2:10 PM, Evgenii Zhuravlev
>  wrote:
> > Hi,
> >
> > Minor topology version changes when you creating or removing caches and
> at
> > late affinity.
> >
> > Yes, you see this error in log because minor topoly was changed  while
> > datastreamer was running, but you didn't lose any data.
> >
> > According to javadoc:
> >
> >>Note that there is no guarantee that data will be delivered after this
> >> concrete attempt (e.g., it can fail when topology is changing), but it
> won't
> >> be lost anyway.
> >
> > Evgenii
> >
> >
> > 2017-04-21 13:24 GMT+03:00 Alper Tekinalp :
> >>
> >> Hi.
> >>
> >> First of all what is minor topology version and when does it chage?
> >>
> >> Below we got an error while loading data with data streamer:
> >>
> >> 18/Apr/2017 13:50:45   INFO   34391455 [exchange-worker-#31%null%]
> >> org.apache.ignite.internal.processors.cache.GridCacheProcessor(L:475) -
> >> Started cache [name=RECORD_CACHE_XX, mode=PARTITIONED]
> >> ..
> >> 18/Apr/2017 13:50:49   ERROR  34394884 [DeploymentWorker-0]
> >> com.intellica.evam.engine.dynamic.helpers.DeploymentHelper(L:359) -
> Scenario
> >> data could not be preloaded in distributed deployment for scenario [XX].
> >> javax.cache.CacheException: class
> >> org.apache.ignite.IgniteCheckedException: Failed to finish operation
> (too
> >> many remaps): 32
> >> at
> >> org.apache.ignite.internal.processors.cache.GridCacheUtils.
> convertToCacheException(GridCacheUtils.java:1465)
> >> at
> >> org.apache.ignite.internal.processors.datastreamer.
> DataStreamerImpl.close(DataStreamerImpl.java:1160)
> >> at
> >> org.apache.ignite.internal.processors.datastreamer.
> DataStreamerImpl.close(DataStreamerImpl.java:1244)
> >> at
> >> com.intellica.evam.engine.db.dao.ScenarioRecordDao.
> preloadScenarioRecords(ScenarioRecordDao.java:134)
> >> at
> >> com.intellica.evam.engine.dynamic.helpers.cache.PreloadHelper.
> preloadScenarioRecordData(PreloadHelper.java:58)
> >> at
> >> com.intellica.evam.engine.dynamic.helpers.cache.PreloadHelper.
> preloadScenarioData(PreloadHelper.java:24)
> >> at
> >> com.intellica.evam.engine.dynamic.helpers.DeploymentHelper.
> distributedDeploy(DeploymentHelper.java:827)
> >> at
> >> com.intellica.evam.engine.dynamic.DeploymentWorker.
> handleDeploymentEvent(DeploymentWorker.java:83)
> >> at
> >> com.intellica.evam.engine.dynamic.DeploymentWorker.run(
> DeploymentWorker.java:62)
> >> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to
> >> finish operation (too many remaps): 32
> >> at
> >> org.apache.ignite.internal.processors.datastreamer.
> DataStreamerImpl$5.apply(DataStreamerImpl.java:863)
> >> at
> >> org.apache.ignite.internal.processors.datastreamer.
> DataStreamerImpl$5.apply(DataStreamerImpl.java:828)
> >> at
> >> org.apache.ignite.internal.util.future.GridFutureAdapter$
> ArrayListener.apply(GridFutureAdapter.java:456)
> >> at
> >> org.apache.ignite.internal.util.future.GridFutureAdapter$
> ArrayListener.apply(GridFutureAdapter.java:439)
> >> at
> >> org.apache.ignite.internal.util.future.GridFutureAdapter.
> notifyListener(GridFutureAdapter.java:271)
> >> at
> >> org.apache.ignite.internal.util.future.GridFutureAdapter.
> notifyListeners(GridFutureAdapter.java:259)
> >> at
> >> org.apache.ignite.internal.util.future.GridFutureAdapter.
> onDone(GridFutureAdapter.java:389)
> >> at
> >> org.apache.ignite.internal.util.future.GridFutureAdapter.
> onDone(GridFutureAdapter.java:355)
> >> at
> >> org.apache.ignite.internal.processors.datastreamer.
> DataStreamerImpl$Buffer.onResponse(DataStreamerImpl.java:1789)
> >> at
> >> org.apache.ignite.internal.processors.datastreamer.
> DataStreamerImpl$3.onMessage(DataStreamerImpl.java:335)
> >> at
> >> org.apache.ignite.internal.managers.communication.
> GridIoManager.invokeListener(GridIoManager.java:1215)
> >> at
> >> org.apache.ignite.internal.managers.communication.GridIoManager.
> processRegularMessage0(GridIoManager.java:843)
> >> at
> >> org.apache.ignite.internal.managers.communication.
> GridIoManager.access$2100(GridIoManager.java:108)
> >> at
> >> org.apache.ignite.internal.managers.communication.GridIoManager$6.run(
> GridIoManager.java:783)
> >> at
> >> java.util.concurrent.ThreadPoolExecutor.runWorker(
> ThreadPoolExecutor.java:1145)
> >> at

Re: Run Ignite on a separate Yarn Queue instead of default queue

[vdpyatkov]

Hi,

I have found the issue[1].
Unfortunately it were not resolved.

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



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/Run-Ignite-on-a-separate-Yarn-Queue-instead-of-default-queue-tp12046p12155.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: IgniteCacheProxy connection failure in REPLICATAED mode

[Andrey Mashenkov]

Hi Rick,

Looks weird. Cache operation on replicated cache on server node should not
failed when other node leaved.
Would you please attach logs?

Ignite 2.0 ETA should be release on next week.
But seems, it may delays for 1-2 weeks as there is neither node freeze
happened nor vote started.



On Fri, Apr 21, 2017 at 12:10 PM, rick_tem  wrote:

> Hi Andrey,
>
> Thanks for you response.  Still seems to be problematic.  See below.  Any
> idea when 2.0 will be available?  Recall I had one Ignite as a client in
> Jboss and two Ignite servers.  What I've done is force the Jboss into a
> server, and start one other Ignite instance (two Ignite server nodes, 0
> clients).  Now when I kill the Ignite node, I did get some exceptions in
> the
> Jboss console and at least once I had some remove cache operations fail.  I
> don't believe this should happen in replicated mode and assume this is the
> same bug.  So to get around that, I catch any exception around the
> cache.remove(key) and retry, but since, I haven't been able to reproduce
> it.
> I'll try to see if I can write a test case for it.  Regardless, whether
> client or server, I think we shouldn't expect failures in replicated mode
> with the below config, correct?  Oracle Coherence doesn't fail when you
> take
> down a node in replicated mode.
>
> Thanks,
> Rick
>
> 
>  value="MyCache" />
>  value="REPLICATED" />
>  value="ONHEAP_TIERED" />
>
>  value="#{10 * 1024L * 1024L * 1024L}"
> />
> 
>
>  class="org.apache.ignite.cache.eviction.lru.LruEvictionPolicy">
>
>  name="maxSize" value="100" />
> 
> 
>  value="TRANSACTIONAL" />
>  />
>  name="writeSynchronizationMode"
> value="FULL_SYNC" />
>  value="true" />
> 
> 
> 
>
>
> C:\java\GitHub\ignite1.9\ignite-1.9\modules [ignite-1.9 ≡ +20 ~14 -0 !]>
> git
> apply --verbose --check 4473.patch
> Checking patch
> modules/core/src/main/java/org/apache/ignite/internal/
> IgniteNeedReconnectException.java...
> error: while searching for:
>
> error: patch failed:
> modules/core/src/main/java/org/apache/ignite/internal/
> IgniteNeedReconnectException.java:0
> error:
> modules/core/src/main/java/org/apache/ignite/internal/
> IgniteNeedReconnectException.java:
> patch does not apply
> Checking patch
> modules/core/src/main/java/org/apache/ignite/spi/
> discovery/tcp/TcpDiscoverySpi.java...
> error: while searching for:
> return ignite().configuration().getSslContextFactory() != null;
> }
>
> /**
>  * FOR TEST ONLY!!!
>  */
>
> error: patch failed:
> modules/core/src/main/java/org/apache/ignite/spi/
> discovery/tcp/TcpDiscoverySpi.java:1933
> error:
> modules/core/src/main/java/org/apache/ignite/spi/
> discovery/tcp/TcpDiscoverySpi.java:
> patch does not apply
> Checking patch
> modules/core/src/test/java/org/apache/ignite/testsuites/
> IgniteClientReconnectTestSuite.java...
> error: while searching for:
> import org.apache.ignite.internal.IgniteClientReconnectServicesTest;
> import org.apache.ignite.internal.IgniteClientReconnectStopTest;
> import org.apache.ignite.internal.IgniteClientReconnectStreamerTest;
>
> /**
>  *
>
> error: patch failed:
> modules/core/src/test/java/org/apache/ignite/testsuites/
> IgniteClientReconnectTestSuite.java:29
> error:
> modules/core/src/test/java/org/apache/ignite/testsuites/
> IgniteClientReconnectTestSuite.java:
> patch does not apply
> Checking patch
> modules/core/src/main/java/org/apache/ignite/internal/IgniteKernal.java...
> error: while searching for:
> /** Periodic starvation check interval. */
> private static final long PERIODIC_STARVATION_CHECK_FREQ = 1000 * 30;
>
> /** */
> @GridToStringExclude
> private GridKernalContextImpl ctx;
>
> error: patch failed:
> modules/core/src/main/java/org/apache/ignite/internal/
> IgniteKernal.java:253
> error:
> modules/core/src/main/java/org/apache/ignite/internal/IgniteKernal.java:
> patch does not apply
> Checking patch
> modules/core/src/main/java/org/apache/ignite/spi/
> discovery/tcp/ServerImpl.java...
> error: while searching for:
> throw new UnsupportedOperationException();
> }
>
> /** {@inheritDoc} */
> @Override protected IgniteSpiThread workerThread() {
> return msgWorker;
>
> error: patch failed:
> modules/core/src/main/java/org/apache/ignite/spi/
> discovery/tcp/ServerImpl.java:1589
> error:

Re: How to do write-behind caching?

[Dieds]

A library of tutorials would be just the think for an “Apache Ignite 
University” section. I page of tutorials, how-to’s, videos and local event 
listings. We need one of those on this site. 
Tom







> On Apr 21, 2017, at 2:23 AM, Ricky Nauvaldy Ruliputra [via Apache Ignite 
> Users]  wrote:
> 
> Hello, can you provide a tutorial for write-behind caching? (similar to the 
> one on this page 
> https://dzone.com/articles/apache-ignite-how-to-read-data-from-persistent-sto 
> 
>  but for write-behind). My configuration is the same as in the example 
> provided in that page above (MySQL database), with the transaction process is 
> based on CacheTransactionExample.java provided in Ignite Examples, but this 
> time I'm trying to learn how to do write-behind. I've already succeed in 
> doing write through, but when I add the write behind configuration, it just 
> won't write. What response should I expect when I use write behind? Will it 
> wait for 5 seconds before it writes (e.g. using 
> setWriteBehindFlushFrequency(5000) and setWriteBehindFlushSize(0))?
> 
> Thanks for any help that you can provide.
> 
> 
> If you reply to this email, your message will be added to the discussion 
> below:
> http://apache-ignite-users.70518.x6.nabble.com/How-to-do-write-behind-caching-tp12138.html
>  
> 
> To unsubscribe from Apache Ignite Users, click here 
> .
> NAML 
> 




--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/How-to-do-write-behind-caching-tp12138p12153.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: What is the difference between starting a node using Java application, and manual starting?

[blasteralfred]

Thanks @dkarachentsev .  I got it 



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/What-is-the-difference-between-starting-a-node-using-Java-application-and-manual-starting-tp12143p12152.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Failing DataStreamer beacuse of minor version change

[Alper Tekinalp]

Hi,

So how should I handle that exception? Should I just ignore it? Is
there a way I can know when the data streamer successfully deliver
after getting that error? I just want to know if data
loading/rebalancing finished succesfully.

On Fri, Apr 21, 2017 at 2:10 PM, Evgenii Zhuravlev
 wrote:
> Hi,
>
> Minor topology version changes when you creating or removing caches and at
> late affinity.
>
> Yes, you see this error in log because minor topoly was changed  while
> datastreamer was running, but you didn't lose any data.
>
> According to javadoc:
>
>>Note that there is no guarantee that data will be delivered after this
>> concrete attempt (e.g., it can fail when topology is changing), but it won't
>> be lost anyway.
>
> Evgenii
>
>
> 2017-04-21 13:24 GMT+03:00 Alper Tekinalp :
>>
>> Hi.
>>
>> First of all what is minor topology version and when does it chage?
>>
>> Below we got an error while loading data with data streamer:
>>
>> 18/Apr/2017 13:50:45   INFO   34391455 [exchange-worker-#31%null%]
>> org.apache.ignite.internal.processors.cache.GridCacheProcessor(L:475) -
>> Started cache [name=RECORD_CACHE_XX, mode=PARTITIONED]
>> ..
>> 18/Apr/2017 13:50:49   ERROR  34394884 [DeploymentWorker-0]
>> com.intellica.evam.engine.dynamic.helpers.DeploymentHelper(L:359) - Scenario
>> data could not be preloaded in distributed deployment for scenario [XX].
>> javax.cache.CacheException: class
>> org.apache.ignite.IgniteCheckedException: Failed to finish operation (too
>> many remaps): 32
>> at
>> org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1465)
>> at
>> org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl.close(DataStreamerImpl.java:1160)
>> at
>> org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl.close(DataStreamerImpl.java:1244)
>> at
>> com.intellica.evam.engine.db.dao.ScenarioRecordDao.preloadScenarioRecords(ScenarioRecordDao.java:134)
>> at
>> com.intellica.evam.engine.dynamic.helpers.cache.PreloadHelper.preloadScenarioRecordData(PreloadHelper.java:58)
>> at
>> com.intellica.evam.engine.dynamic.helpers.cache.PreloadHelper.preloadScenarioData(PreloadHelper.java:24)
>> at
>> com.intellica.evam.engine.dynamic.helpers.DeploymentHelper.distributedDeploy(DeploymentHelper.java:827)
>> at
>> com.intellica.evam.engine.dynamic.DeploymentWorker.handleDeploymentEvent(DeploymentWorker.java:83)
>> at
>> com.intellica.evam.engine.dynamic.DeploymentWorker.run(DeploymentWorker.java:62)
>> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to
>> finish operation (too many remaps): 32
>> at
>> org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl$5.apply(DataStreamerImpl.java:863)
>> at
>> org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl$5.apply(DataStreamerImpl.java:828)
>> at
>> org.apache.ignite.internal.util.future.GridFutureAdapter$ArrayListener.apply(GridFutureAdapter.java:456)
>> at
>> org.apache.ignite.internal.util.future.GridFutureAdapter$ArrayListener.apply(GridFutureAdapter.java:439)
>> at
>> org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:271)
>> at
>> org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListeners(GridFutureAdapter.java:259)
>> at
>> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:389)
>> at
>> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:355)
>> at
>> org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl$Buffer.onResponse(DataStreamerImpl.java:1789)
>> at
>> org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl$3.onMessage(DataStreamerImpl.java:335)
>> at
>> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1215)
>> at
>> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:843)
>> at
>> org.apache.ignite.internal.managers.communication.GridIoManager.access$2100(GridIoManager.java:108)
>> at
>> org.apache.ignite.internal.managers.communication.GridIoManager$6.run(GridIoManager.java:783)
>> 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.IgniteCheckedException: DataStreamer
>> request failed [node=6fe302a3-f353-4235-af5a-3708bf240750]
>> at
>> org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl$Buffer.onResponse(DataStreamerImpl.java:1777)
>> ... 8 more
>> Caused by: class org.apache.ignite.IgniteCheckedException: DataStreamer
>> will retry data transfer at stable topology [reqTop=AffinityTopologyVersion
>> [topVer=11, 

Re: What is the difference between starting a node using Java application, and manual starting?

[dkarachentsev]

Hi,

If under manually started you mean using ignite.sh(.bat) script, then there
actually is no difference, because at the end it calls the same
Ignition.start() method (Spring configured app as well). But with
programmatic starting you can run more than one node in single JVM. This may
be useful in tests.

Thanks!
-Dmitry.



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/What-is-the-difference-between-starting-a-node-using-Java-application-and-manual-starting-tp12143p12150.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: With same load Ignite is not able to respond after enabling SSL

[Ankit Singhai]

igniteClient.gz
  
server1.gz
  
server2.gz
  
server3.gz
  



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/With-same-load-Ignite-is-not-able-to-respond-after-enabling-SSL-tp12146p12149.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Exceptions while running Closure with task count > 1000

[Cathode]

Sorry for the late reply.
Can't share full original project, but i create the simple one that can
fully reproduce this exception.
https://www.dropbox.com/s/lcf7q168qbkaxpy/igniteIntegrationTest.zip?dl=0

2017-04-17 16:41 GMT+03:00 vdpyatkov [via Apache Ignite Users] <
ml-node+s70518n11997...@n6.nabble.com>:

> Hi,
>
> Could you try to exclude p2p class loader 
> (IgniteConfiguration#setPeerClassLoadingEnabled
> to false), putting jar (with closure implementation) on each node and
> retry?
>
> Is looks like a some race, but I could not reproduce without full working
> example.
> If it will be easy, please, can you provide whole example?
>
> --
> If you reply to this email, your message will be added to the discussion
> below:
> http://apache-ignite-users.70518.x6.nabble.com/Exceptions-while-running-
> Closure-with-task-count-1000-tp11989p11997.html
> To unsubscribe from Exceptions while running Closure with task count >
> 1000, click here
> 
> .
> NAML
> 
>



-- 
Faithfully yours,
Yevgeniy Klymenko




--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/Exceptions-while-running-Closure-with-task-count-1000-tp11989p12148.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Ignite client deployed on Tomcat is not able to make secure connection with standalone Ignite Server

[Ankit Singhai]

Hi Val,
It was resolved there was certificate error.

Thanks



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/Ignite-client-deployed-on-Tomcat-is-not-able-to-make-secure-connection-with-standalone-Ignite-Server-tp11928p12147.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

With same load Ignite is not able to respond after enabling SSL

[Ankit Singhai]

Hi All,
We have 3 servers and 10 clients in topology, wherein all use-cases are on
Ignite Cache. Load is round 40K cache operations / min i.e. Create, Read,
Update and Delete but after enabling SSL we are getting below exceptions
(which was working earlier with out SSL).


[07:25:15] (err) Failed to execute compound future reducer:
GridNearGetFuture [tx=null, ver=GridCacheVersion [topVer=104236831,
time=1492773516157, order=1492771941620, nodeOrder=23],
innerFuts=[[node=292ba740-8376-4ecc-a836-31e222be7c9e, loc=false,
done=true]], super=GridCompoundIdentityFuture [super=GridCompoundFuture
[rdc=Map reducer: {}, initFlag=0, lsnrCalls=0, done=false, cancelled=false,
err=null, futs=[trueclass 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=292ba740-8376-4ecc-a836-31e222be7c9e, addrs=[10.179.29.136],
sockAddrs=[in1s5xraai002.ivycomptech.co.in/10.179.29.136:47500],
discPort=47500, order=1, intOrder=1, lastExchangeTime=1492771286410,
loc=false, ver=1.8.0#20161205-sha1:9ca40dbe, isClient=false],
topic=TOPIC_CACHE, msg=GridNearGetRequest
[futId=a382d109b51-0e611836-1099-4aef-8fc5-4db1230b4a99,
miniId=b382d109b51-0e611836-1099-4aef-8fc5-4db1230b4a99,
ver=GridCacheVersion [topVer=104236831, time=1492773516157,
order=1492771941620, nodeOrder=23], keyMap=null, reload=false,
readThrough=true, skipVals=false, topVer=AffinityTopologyVersion [topVer=25,
minorTopVer=4], subjId=ccc10d0d-3e3f-41e0-8d24-0ab2272cc8f9, taskNameHash=0,
accessTtl=8640], policy=2]
at
org.apache.ignite.internal.managers.communication.GridIoManager.send(GridIoManager.java:1153)
at
org.apache.ignite.internal.managers.communication.GridIoManager.send(GridIoManager.java:1217)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.send(GridCacheIoManager.java:910)
at
org.apache.ignite.internal.processors.cache.distributed.near.GridNearGetFuture.map(GridNearGetFuture.java:384)
at
org.apache.ignite.internal.processors.cache.distributed.near.GridNearGetFuture.init(GridNearGetFuture.java:162)
at
org.apache.ignite.internal.processors.cache.distributed.near.GridNearCacheAdapter.loadAsync(GridNearCacheAdapter.java:272)
at
org.apache.ignite.internal.processors.cache.distributed.near.GridNearAtomicCache.getAllAsync(GridNearAtomicCache.java:417)
at
org.apache.ignite.internal.processors.cache.GridCacheAdapter.getAsync(GridCacheAdapter.java:1737)
at
org.apache.ignite.internal.processors.cache.GridCacheAdapter.get(GridCacheAdapter.java:4800)
at
org.apache.ignite.internal.processors.cache.GridCacheAdapter.get(GridCacheAdapter.java:4783)
at
org.apache.ignite.internal.processors.cache.GridCacheAdapter.get(GridCacheAdapter.java:1395)
at
org.apache.ignite.internal.processors.cache.IgniteCacheProxy.get(IgniteCacheProxy.java:1118)
at
com.pg.partner.loginservice.cache.PartnerTokenCacheManager.getPartnerToken(PartnerTokenCacheManager.java:62)
at
com.pg.partner.loginservice.impl.PartnerLoginServiceImpl.generatePartnerToken(PartnerLoginServiceImpl.java:185)
at sun.reflect.GeneratedMethodAccessor67.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
com.partygaming.serviceregistry.SRRemoteInvocation.invoke(SRRemoteInvocation.java:189)
at
com.partygaming.serviceregistry.resolver.AbstractServiceResolver.executeOnService(AbstractServiceResolver.java:1259)
at
com.partygaming.serviceregistry.exportimport.RemoteServiceRegistryImpl.execute(RemoteServiceRegistryImpl.java:17)
at sun.reflect.GeneratedMethodAccessor66.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:322)
at sun.rmi.transport.Transport$1.run(Transport.java:177)
at sun.rmi.transport.Transport$1.run(Transport.java:174)
at java.security.AccessController.doPrivileged(Native Method)
at sun.rmi.transport.Transport.serviceCall(Transport.java:173)
at
sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:556)
at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:811)
at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:670)
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:744)
Caused by: class org.apache.ignite.spi.IgniteSpiException: Failed to send
message to remote node: TcpDiscoveryNode

Re: Error while running query against Ignite Server Node

[Evgenii Zhuravlev]

 Alper,

Did you lose any data or you just got the same error in log?
You could get the same error when minor version of topology was changed
during DataStreamer's flushing

Evgneii

2017-04-18 16:29 GMT+03:00 Alper Tekinalp :

> Hi Nikolai,
>
> By saying:
>
> > This exception means that in during data streaming, topology was changed.
>
> Do you mean major topology or minor topology? And also what is minor
> topology? We have encountered same issue without no change in topology
> version no new nodes added or left but with different minorTopVer.
>
> On Mon, Apr 3, 2017 at 5:39 PM, Nikolai Tikhonov 
> wrote:
>
>> Hi,
>>
>> It's looks that you have long gc pause in your application. Did you see
>> in logs any message related with changing topology (node fail, node left,
>> node join and etc)? Could you enable gc logs and check it (for example
>> -Xloggc:./gc.log -XX:+PrintGCDetails -verbose:gc)?
>>
>> On Sun, Apr 2, 2017 at 1:36 PM, rishi007bansod 
>> wrote:
>>
>>> Hi,
>>> I am running 3 instances of ignite per machine(total 3 machines). Data is
>>> inserted in partitioned cache continuously and I am running query against
>>> this cache. After query I am getting above error. Is there any way I can
>>> make topology stable before querying data? For example, how can I query
>>> data
>>> up to certain  snapshot of cache when data is continuously getting added
>>> and
>>> I am querying data to avoid this error(As this error only occurs during
>>> run
>>> time query against data i.e. when cache is getting populated and not when
>>> cache is completely loaded)
>>>
>>> Thanks.
>>>
>>>
>>>
>>> --
>>> View this message in context: http://apache-ignite-users.705
>>> 18.x6.nabble.com/Error-while-running-query-against-Ignite-Se
>>> rver-Node-tp11030p11643.html
>>> Sent from the Apache Ignite Users mailing list archive at Nabble.com.
>>>
>>
>>
>
>
> --
> Alper Tekinalp
>
> Software Developer
> Evam Streaming Analytics
>
> Atatürk Mah. Turgut Özal Bulv.
> Gardenya 5 Plaza K:6 Ataşehir
> 34758 İSTANBUL
>
> Tel:  +90 216 455 01 53 Fax: +90 216 455 01 54
> www.evam.com.tr
> 
>

Re: Failing DataStreamer beacuse of minor version change

[Evgenii Zhuravlev]

Hi,

Minor topology version changes when you creating or removing caches and at
late affinity.

Yes, you see this error in log because minor topoly was changed  while
datastreamer was running, but you didn't lose any data.

According to javadoc
:


>Note that there is no guarantee that data will be delivered after this
concrete attempt (e.g., it can fail when topology is changing), but it
won't be lost anyway.

Evgenii


2017-04-21 13:24 GMT+03:00 Alper Tekinalp :

> Hi.
>
> First of all what is minor topology version and when does it chage?
>
> Below we got an error while loading data with data streamer:
>
> 18/Apr/2017 13:50:45   INFO   34391455 [exchange-worker-#31%null%]
> org.apache.ignite.internal.processors.cache.GridCacheProcessor(L:475) -
> Started cache [name=RECORD_CACHE_XX, mode=PARTITIONED]
> ..
> 18/Apr/2017 13:50:49   ERROR  34394884 [DeploymentWorker-0]
> com.intellica.evam.engine.dynamic.helpers.DeploymentHelper(L:359) -
> Scenario data could not be preloaded in distributed deployment for scenario
> [XX].
> javax.cache.CacheException: class org.apache.ignite.IgniteCheckedException:
> Failed to finish operation (too many remaps): 32
> at org.apache.ignite.internal.processors.cache.GridCacheUtils.
> convertToCacheException(GridCacheUtils.java:1465)
> at org.apache.ignite.internal.processors.datastreamer.
> DataStreamerImpl.close(DataStreamerImpl.java:1160)
> at org.apache.ignite.internal.processors.datastreamer.
> DataStreamerImpl.close(DataStreamerImpl.java:1244)
> at com.intellica.evam.engine.db.dao.ScenarioRecordDao.
> preloadScenarioRecords(ScenarioRecordDao.java:134)
> at com.intellica.evam.engine.dynamic.helpers.cache.PreloadHelper.
> preloadScenarioRecordData(PreloadHelper.java:58)
> at com.intellica.evam.engine.dynamic.helpers.cache.PreloadHelper.
> preloadScenarioData(PreloadHelper.java:24)
> at com.intellica.evam.engine.dynamic.helpers.DeploymentHelper.
> distributedDeploy(DeploymentHelper.java:827)
> at com.intellica.evam.engine.dynamic.DeploymentWorker.
> handleDeploymentEvent(DeploymentWorker.java:83)
> at com.intellica.evam.engine.dynamic.DeploymentWorker.run(
> DeploymentWorker.java:62)
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to
> finish operation (too many remaps): 32
> at org.apache.ignite.internal.processors.datastreamer.
> DataStreamerImpl$5.apply(DataStreamerImpl.java:863)
> at org.apache.ignite.internal.processors.datastreamer.
> DataStreamerImpl$5.apply(DataStreamerImpl.java:828)
> at org.apache.ignite.internal.util.future.GridFutureAdapter$
> ArrayListener.apply(GridFutureAdapter.java:456)
> at org.apache.ignite.internal.util.future.GridFutureAdapter$
> ArrayListener.apply(GridFutureAdapter.java:439)
> at org.apache.ignite.internal.util.future.GridFutureAdapter.
> notifyListener(GridFutureAdapter.java:271)
> at org.apache.ignite.internal.util.future.GridFutureAdapter.
> notifyListeners(GridFutureAdapter.java:259)
> at org.apache.ignite.internal.util.future.GridFutureAdapter.
> onDone(GridFutureAdapter.java:389)
> at org.apache.ignite.internal.util.future.GridFutureAdapter.
> onDone(GridFutureAdapter.java:355)
> at org.apache.ignite.internal.processors.datastreamer.
> DataStreamerImpl$Buffer.onResponse(DataStreamerImpl.java:1789)
> at org.apache.ignite.internal.processors.datastreamer.
> DataStreamerImpl$3.onMessage(DataStreamerImpl.java:335)
> at org.apache.ignite.internal.managers.communication.
> GridIoManager.invokeListener(GridIoManager.java:1215)
> at org.apache.ignite.internal.managers.communication.GridIoManager.
> processRegularMessage0(GridIoManager.java:843)
> at org.apache.ignite.internal.managers.communication.
> GridIoManager.access$2100(GridIoManager.java:108)
> at org.apache.ignite.internal.managers.communication.
> GridIoManager$6.run(GridIoManager.java:783)
> 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.IgniteCheckedException: DataStreamer
> request failed [node=6fe302a3-f353-4235-af5a-3708bf240750]
> at org.apache.ignite.internal.processors.datastreamer.
> DataStreamerImpl$Buffer.onResponse(DataStreamerImpl.java:1777)
> ... 8 more
> Caused by: class org.apache.ignite.IgniteCheckedException: DataStreamer
> will retry data transfer at stable topology [reqTop=AffinityTopologyVersion
> [topVer=11, minorTopVer=14], topVer=AffinityTopologyVersion [topVer=11,
> minorTopVer=15], node=remote]
> at org.apache.ignite.internal.processors.datastreamer.
> DataStreamProcessor.localUpdate(DataStreamProcessor.java:339)
> at org.apache.ignite.internal.processors.datastreamer.
> 

What is the difference between starting a node using Java application, and manual starting?

[blasteralfred]

Hi,

I am completely new ti Ignite and am working around examples. I made a java
application, which uses ignition method to start node. Also, I know that
server can be manually started. What is the difference between these two and
why / in which all situations, should i use them?

Thanks in advance..



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/What-is-the-difference-between-starting-a-node-using-Java-application-and-manual-starting-tp12143.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Failing DataStreamer beacuse of minor version change

[Alper Tekinalp]

Hi.

First of all what is minor topology version and when does it chage?

Below we got an error while loading data with data streamer:

18/Apr/2017 13:50:45   INFO   34391455 [exchange-worker-#31%null%]
org.apache.ignite.internal.processors.cache.GridCacheProcessor(L:475) -
Started cache [name=RECORD_CACHE_XX, mode=PARTITIONED]
..
18/Apr/2017 13:50:49   ERROR  34394884 [DeploymentWorker-0]
com.intellica.evam.engine.dynamic.helpers.DeploymentHelper(L:359) -
Scenario data could not be preloaded in distributed deployment for scenario
[XX].
javax.cache.CacheException: class org.apache.ignite.IgniteCheckedException:
Failed to finish operation (too many remaps): 32
at
org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1465)
at
org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl.close(DataStreamerImpl.java:1160)
at
org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl.close(DataStreamerImpl.java:1244)
at
com.intellica.evam.engine.db.dao.ScenarioRecordDao.preloadScenarioRecords(ScenarioRecordDao.java:134)
at
com.intellica.evam.engine.dynamic.helpers.cache.PreloadHelper.preloadScenarioRecordData(PreloadHelper.java:58)
at
com.intellica.evam.engine.dynamic.helpers.cache.PreloadHelper.preloadScenarioData(PreloadHelper.java:24)
at
com.intellica.evam.engine.dynamic.helpers.DeploymentHelper.distributedDeploy(DeploymentHelper.java:827)
at
com.intellica.evam.engine.dynamic.DeploymentWorker.handleDeploymentEvent(DeploymentWorker.java:83)
at
com.intellica.evam.engine.dynamic.DeploymentWorker.run(DeploymentWorker.java:62)
Caused by: class org.apache.ignite.IgniteCheckedException: Failed to finish
operation (too many remaps): 32
at
org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl$5.apply(DataStreamerImpl.java:863)
at
org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl$5.apply(DataStreamerImpl.java:828)
at
org.apache.ignite.internal.util.future.GridFutureAdapter$ArrayListener.apply(GridFutureAdapter.java:456)
at
org.apache.ignite.internal.util.future.GridFutureAdapter$ArrayListener.apply(GridFutureAdapter.java:439)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:271)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListeners(GridFutureAdapter.java:259)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:389)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:355)
at
org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl$Buffer.onResponse(DataStreamerImpl.java:1789)
at
org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl$3.onMessage(DataStreamerImpl.java:335)
at
org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1215)
at
org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:843)
at
org.apache.ignite.internal.managers.communication.GridIoManager.access$2100(GridIoManager.java:108)
at
org.apache.ignite.internal.managers.communication.GridIoManager$6.run(GridIoManager.java:783)
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.IgniteCheckedException: DataStreamer
request failed [node=6fe302a3-f353-4235-af5a-3708bf240750]
at
org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl$Buffer.onResponse(DataStreamerImpl.java:1777)
... 8 more
Caused by: class org.apache.ignite.IgniteCheckedException: DataStreamer
will retry data transfer at stable topology [reqTop=AffinityTopologyVersion
[topVer=11, minorTopVer=14], topVer=AffinityTopologyVersion [topVer=11,
minorTopVer=15], node=remote]
at
org.apache.ignite.internal.processors.datastreamer.DataStreamProcessor.localUpdate(DataStreamProcessor.java:339)
at
org.apache.ignite.internal.processors.datastreamer.DataStreamProcessor.processRequest(DataStreamProcessor.java:297)
at
org.apache.ignite.internal.processors.datastreamer.DataStreamProcessor.access$000(DataStreamProcessor.java:56)
at
org.apache.ignite.internal.processors.datastreamer.DataStreamProcessor$1.onMessage(DataStreamProcessor.java:86)
... 7 more
18/Apr/2017 13:50:49   INFO   34394950 [exchange-worker-#31%null%]
org.apache.ignite.internal.processors.cache.GridCacheProcessor(L:475) -
Started cache [name=FEC_XX, mode=PARTITIONED]


I guess the reason seems that when one of the server nodes loads data
through data streamer to cache RECORD_CACHE_XX, other server creates cache
FEC_XX. Bacause cache creation increases the minor topology version.

Is my understanding true?
If it is what is the reason?

-- 
Alper Tekinalp

Re: Input data is no significant change in multi-threading

[Andrey Mashenkov]

Hi Woo,

DataStreamer is designed to fill cache with maximum throughput. By default,
streamer will not rewrite cache data, until allowOverwite option is set.

Why you need to input same set of data? Why do you expected data input time
will change significantly with 2 programs compared to 1 if data set is put
twice?
Or I missed smth?

Anyway, if you do not get a speed up but you sure you should, then a
bottleneck have to be found at first.

On Fri, Apr 21, 2017 at 5:02 AM, woo charles 
wrote:

> If the data is buffered in client side, the bottleneck should be also in
> client side.
> If I use 2 programs to input same set data, it should be a significant
> change in data input time.
> Is it right?
>
> 2017-04-21 6:46 GMT+08:00 Dmitriy Setrakyan :
>
>>
>> On Wed, Apr 19, 2017 at 10:16 PM, woo charles 
>> wrote:
>>
>>> When I call addData() in streamer. this data will send & buffer in
>>> server node. is that correct?
>>> If I correct, this data will buffer in random server node or only the
>>> one it directly connected?
>>>
>>
>> addData() will buffer the data on the client side. As a matter of fact,
>> there are multiple buffers on the client side, which each buffer associated
>> with some server node.
>>
>> Ignite will never send the data to a random node. The data is always sent
>> exactly to the node where it will be cached.
>>
>> D.
>>
>
>


-- 
Best regards,
Andrey V. Mashenkov

Re: IgniteCacheProxy connection failure in REPLICATAED mode

[rick_tem]

Hi Andrey,

Thanks for you response.  Still seems to be problematic.  See below.  Any
idea when 2.0 will be available?  Recall I had one Ignite as a client in
Jboss and two Ignite servers.  What I've done is force the Jboss into a
server, and start one other Ignite instance (two Ignite server nodes, 0
clients).  Now when I kill the Ignite node, I did get some exceptions in the
Jboss console and at least once I had some remove cache operations fail.  I
don't believe this should happen in replicated mode and assume this is the
same bug.  So to get around that, I catch any exception around the
cache.remove(key) and retry, but since, I haven't been able to reproduce it. 
I'll try to see if I can write a test case for it.  Regardless, whether
client or server, I think we shouldn't expect failures in replicated mode
with the below config, correct?  Oracle Coherence doesn't fail when you take
down a node in replicated mode.

Thanks,
Rick























C:\java\GitHub\ignite1.9\ignite-1.9\modules [ignite-1.9 ≡ +20 ~14 -0 !]> git
apply --verbose --check 4473.patch
Checking patch
modules/core/src/main/java/org/apache/ignite/internal/IgniteNeedReconnectException.java...
error: while searching for:

error: patch failed:
modules/core/src/main/java/org/apache/ignite/internal/IgniteNeedReconnectException.java:0
error:
modules/core/src/main/java/org/apache/ignite/internal/IgniteNeedReconnectException.java:
patch does not apply
Checking patch
modules/core/src/main/java/org/apache/ignite/spi/discovery/tcp/TcpDiscoverySpi.java...
error: while searching for:
return ignite().configuration().getSslContextFactory() != null;
}

/**
 * FOR TEST ONLY!!!
 */

error: patch failed:
modules/core/src/main/java/org/apache/ignite/spi/discovery/tcp/TcpDiscoverySpi.java:1933
error:
modules/core/src/main/java/org/apache/ignite/spi/discovery/tcp/TcpDiscoverySpi.java:
patch does not apply
Checking patch
modules/core/src/test/java/org/apache/ignite/testsuites/IgniteClientReconnectTestSuite.java...
error: while searching for:
import org.apache.ignite.internal.IgniteClientReconnectServicesTest;
import org.apache.ignite.internal.IgniteClientReconnectStopTest;
import org.apache.ignite.internal.IgniteClientReconnectStreamerTest;

/**
 *

error: patch failed:
modules/core/src/test/java/org/apache/ignite/testsuites/IgniteClientReconnectTestSuite.java:29
error:
modules/core/src/test/java/org/apache/ignite/testsuites/IgniteClientReconnectTestSuite.java:
patch does not apply
Checking patch
modules/core/src/main/java/org/apache/ignite/internal/IgniteKernal.java...
error: while searching for:
/** Periodic starvation check interval. */
private static final long PERIODIC_STARVATION_CHECK_FREQ = 1000 * 30;

/** */
@GridToStringExclude
private GridKernalContextImpl ctx;

error: patch failed:
modules/core/src/main/java/org/apache/ignite/internal/IgniteKernal.java:253
error:
modules/core/src/main/java/org/apache/ignite/internal/IgniteKernal.java:
patch does not apply
Checking patch
modules/core/src/main/java/org/apache/ignite/spi/discovery/tcp/ServerImpl.java...
error: while searching for:
throw new UnsupportedOperationException();
}

/** {@inheritDoc} */
@Override protected IgniteSpiThread workerThread() {
return msgWorker;

error: patch failed:
modules/core/src/main/java/org/apache/ignite/spi/discovery/tcp/ServerImpl.java:1589
error:
modules/core/src/main/java/org/apache/ignite/spi/discovery/tcp/ServerImpl.java:
patch does not apply
Checking patch
modules/core/src/test/java/org/apache/ignite/internal/IgniteClientReconnectCacheTest.java...
error: while searching for:
try {
   
Ignition.start(optimize(getConfiguration(getTestGridName(SRV_CNT;

fail();

return false;
}
catch (IgniteClientDisconnectedException e) {
log.info("Expected start error: " + e);

error: patch failed:
modules/core/src/test/java/org/apache/ignite/internal/IgniteClientReconnectCacheTest.java:700
error:
modules/core/src/test/java/org/apache/ignite/internal/IgniteClientReconnectCacheTest.java: