Re: java.lang.IllegalArgumentException: Can not set final

Hi Ilya, I don't think the errors are caused by the binary objects, but by having custom objects in the EntryProcessor. Checkout the attached FragmentAssignToScannerEntryProcessor.java. Instead of injecting the BinaryFragmentConverter into FragmentAssignToScannerEntryProcessor, I moved all the

Re: java.lang.IllegalArgumentException: Can not set final

Thanks for the responses. Ilya - I did try your suggestion: removing the final modifier, deleting the constructor and only using getters and setters. I even went as far as to make the fields public. All these changes resulted in the an IllegalArgumentException. If it helps, I was able to write

Re: java.lang.IllegalArgumentException: Can not set final

Hmm pasting the stack trace into the page didn't work. Here it is as an attachment..: stackTrace.txt -- Sent from: http://apache-ignite-users.70518.x6.nabble.com/

java.lang.IllegalArgumentException: Can not set final

FragmentAssignToScannerEntryProcessor.java BinaryFragmentConverter.java I am running 2 server nodes

Re: ClassNotFoundException when remotely calling cache.withKeepBinary().get(key)

Ilya, Apologies for the slow response.. You are right - this fixed my issue. Thanks, Steve -- Sent from: http://apache-ignite-users.70518.x6.nabble.com/

ClassNotFoundException when remotely calling cache.withKeepBinary().get(key)

(Full logs and test class should be attached at the bottom..) I am running ver. 2.5.0 in client/server mode and am calling ignite.compute().call(..) on an IgniteCallable. Server node does not have any of my code on its classpath, but peer class loading it set to true on both the server and the

Re: Upgrade from 2.1.0 to 2.4.0 resulting in error within transaction block

>From my reading of the javadoc of org.apache.ignite.IgniteCache, only methods that are inherited from javax.cache.Cache are transactional. So, get(..) and put(..) are transactional, but query(..) is not.. >From the javadoc...: Transactions Cache API supports transactions. You can group and set

Re: Upgrade from 2.1.0 to 2.4.0 resulting in error within transaction block

Another update.. I changed the code (shown at the beginning of this thread) that deletes records from: SqlFieldsQuery sqlQuery = new SqlFieldsQuery("delete from EngineFragment where " + criteria()); fragmentCache.query(sqlQuery.setArgs(criteria.getArgs())); to: _fragmentCache.remove(id);

Re: Upgrade from 2.1.0 to 2.4.0 resulting in error within transaction block

I neglected to say that I also removed Spring's ChainedTransactionManager and used SpringTransactionManager in the annotation, which also resulted in the same stack trace.. @Transactional("igniteTxMgr") // code that deletes from cache... // Here is how the transaction manager is wired up..

Upgrade from 2.1.0 to 2.4.0 resulting in error within transaction block

Code works in Ignite 2.1.0. Upgrading to 2.4.0 produces the stack trace below. The delete statement that is causing the error is: SqlFieldsQuery sqlQuery = new SqlFieldsQuery("delete from EngineFragment where " + criteria()); fragmentCache.query(sqlQuery.setArgs(criteria.getArgs())); The code

Re: SpringTransactionManager and ChainedTransactionManager

In actuality I rewrote the tests and removed the AbstractTransactionalJUnit4SpringContextTests super class and the transactions worked. I also rewrote the the test as an integration test on a tomcat server and confirmed that the transaction managers worked. I did see the same javadoc comments

SpringTransactionManager and ChainedTransactionManager

Hello, I am using SpringTransactionManager & HibernateTransactionManager in a Spring ChainedTransactionManager in order to rollback all database and cache updates in the event of there being any failures in either transaction manager. I am finding that rollbacks in HibernateTransactionManager do

Re: Grid freezing

I figured this out at long last... The root cause of the problem was the Scan object's toString method: @Override public String toString() { return ReflectionToStringBuilder.reflectionToString(this); } It used the apache common-lang's RefelectionToStringBuilder and this jar

Re: Grid freezing

The WARNING message above is not consistently showing up in the logs. Nodes are not going down either. What I have found is that running 1 server and 2 clients does NOT freeze, even under heavy loads. But having 2 ignite servers does freeze up. Two servers are unsuccessful either on separate

Re: Grid freezing

Here is an additional log message that suggests that rolling back the transaction is not working. I do not know why the isolation level in this log is marked as READ_COMMITTED. All transactions are configured to be Optimistic and Serializable..: 2017-10-26 10:49:12,524 ERROR [dna-scan-engine

Re: Grid freezing

One thing that I see in the logs looks to me like a NullPointerException on attempting to commit an optimistic/serializable transaction. My reading of this excpetion is that an optimistic lock conflict is correctly detected in prepare0 but that eventually the code incorrectly attempts to return

Re: Grid freezing

log_1.txt log_2.txt log_3.txt I don't see any nodes shutting down until 9

Re: Grid freezing

No - this is what the invocation looks like: DequeuePortionsCallable job = new DequeuePortionsCallable(ignitePortionDequeuer); DequeuedPortionResponse response = _ignite.compute().call(job); -- Sent from: http://apache-ignite-users.70518.x6.nabble.com/

Re: Grid freezing

I added a transaction timeout of 1 millis and a transation size of 100 (transaction is Optimistic and Serializable)... I see no TransactionTimeoutExceptions, just the following: CacheException: class org.apache.ignite.IgniteInterruptedException: Got interrupted while waiting for future to

Re: Grid freezing

Thanks Evgenii, I'll add that catch block and see if it sheds any light on the issue. The client's transaction configuration is set to Optimistic and Serializable and the transaction within the try with resources block is explicitly set to Optimistic and Serializable, which should preclude

Re: Grid freezing

IgnitePortionDequeuer.java top.visor Hi Evgenii, See the attached top command and java file.. -- Sent from:

Grid freezing

threaddump.tdump I am using Ignite v2.1 and my code using Optimistic/Serializable transactions and is locking up. When it does, there are a lot of `WARNING: Found long running transaction` and `WARNING: Found long