Welcome to the new Gigaspaces XAP forum. To recover your account, please follow these instructions.

Ask Your Question

invalid fifo order


I have an class that we have annotated with fifoSupport = FifoSupport.ALL and we are seeing this exception in a non-deterministic manner. My question is, what can cause two objects of the same class to have an invalid fifo order if GS behind the scenes is determining the fifo order? Put another way, I am asking if can someone explain how this can happen than I might be able to figure out what we are doing to cause it. This is happening on readMultiple followed by a loop that does a takeById per item found in the readMultiple (it is checking if a condition exists prior to doing the take).



java.lang.RuntimeException: invalid fifo order 2 equal entries from same class uid1=-153217946^72^18846058^0^0 uid2=-153217946^72^18846057^0^0; Caused by: java.lang.RuntimeException: invalid fifo order 2 equal entries from same class uid1=-153217946^72^18846058^0^0 uid2=-153217946^72^18846057^0^0 at com.j_spaces.core.FifoEntriesComparator.compare(FifoEntriesComparator.java:31) at com.j_spaces.core.FifoEntriesComparator.compare(FifoEntriesComparator.java:19) at java.util.TreeMap.put(TreeMap.java:545) at com.j_spaces.core.server.processor.Processor.handleLockedFifoEntriesOnXtnEnd(Processor.java:1951) at com.gigaspaces.internal.server.space.SpaceEngine.prepare(SpaceEngine.java:3363) at com.gigaspaces.internal.server.space.SpaceEngine.prepareAndCommit(SpaceEngine.java:3458) at com.gigaspaces.internal.server.space.SpaceImpl.prepareAndCommitImpl(SpaceImpl.java:2685) at com.gigaspaces.internal.server.space.operations.PrepareAndCommitTransactionSpaceOperation.execute(PrepareAndCommitTransactionSpaceOperation.java:26) at com.gigaspaces.internal.server.space.operations.PrepareAndCommitTransactionSpaceOperation.execute(PrepareAndCommitTransactionSpaceOperation.java:18) at com.gigaspaces.internal.server.space.operations.SpaceOperationsExecutor.executeOperation(SpaceOperationsExecutor.java:78) at com.gigaspaces.internal.server.space.SpaceImpl.executeOperation(SpaceImpl.java:1826) at com.gigaspaces.internal.lrmi.stubs.LRMISpaceImpl.executeOperation(LRMISpaceImpl.java:850) at com.gigaspaces.internal.remoting.routing.embedded.EmbeddedRemoteOperationRouter.executeImpl(EmbeddedRemoteOperationRouter.java:75) at com.gigaspaces.internal.remoting.routing.embedded.EmbeddedRemoteOperationRouter.execute(EmbeddedRemoteOperationRouter.java:60) at com.gigaspaces.internal.client.spaceproxy.router.SpaceProxyRouter.execute(SpaceProxyRouter.java:232) at com.sun.jini.mahalo.PrepareAndCommitJob.commitAndPreparePartitionWithEnabledFailover(PrepareAndCommitJob.java:331) at com.sun.jini.mahalo.TxnManagerTransaction.prepareAndCommitPartitionWithEnabledFailover(TxnManagerTransaction.java:1254) at com.sun.jini.mahalo.TxnManagerTransaction.lightPrepareAndCommit(TxnManagerTransaction.java:1218) at com.sun.jini.mahalo.TxnManagerTransaction.commitImpl(TxnManagerTransaction.java:775) at com.sun.jini.mahalo.TxnManagerTransaction.commit(TxnManagerTransaction.java:703) at com.sun.jini.mahalo.TxnManagerImpl.commit_impl(TxnManagerImpl.java:1170) at com.sun.jini.mahalo.TxnManagerImpl.commit(TxnManagerImpl.java:1140) at com.sun.jini.mahalo.TxnMgrProxy.commit(TxnMgrProxy.java:184) at net.jini.core.transaction.server.ServerTransaction.commit(ServerTransaction.java:193)

asked 2017-01-05 14:35:38 -0500

rich gravatar image
edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted


We've never seen this before; do you have a reproduction?



answered 2017-01-05 14:39:37 -0500

jb gravatar image
edit flag offensive delete link more


Hi John,

I wish I did. I was hoping someone could point me into the right direction to be able to reproduce this more deterministically. If you have any ideas/suggestions to try I am listening.



rich gravatar imagerich ( 2017-01-05 15:14:17 -0500 )edit

One other bit of fact. We only see this error after we bounce the space and then try to delete the objects. So start of the day, the system is empty and we can delete, reload, delete, reload, delete, reload all day long without any incident. However it seems once we bounce the system in the middle of all this and objects are then reloaded at startup, we get this exception. So if GS is keeping track of the insert order, I understand how it would work in real time during the day as we delete and reload. However when restarting by loading data from a database, how does it determine fifo order?



rich gravatar imagerich ( 2017-01-05 15:46:05 -0500 )edit


Please open a support case for this. As for reproduction and analysis, is it possible that you have uncommitted transactions when you restart?

jb gravatar imagejb ( 2017-01-09 10:11:36 -0500 )edit

Hi John,

I will open a support case, but let me see if I can better understand what is happening so I can give you guys some understanding. Right now, I have added some more logging to see what is going on. What we discovered Friday is we do have transactions that are timing out. I added some indexing on objects to see if that can address some of the timeouts.

I will keep you posted.



rich gravatar imagerich ( 2017-01-09 10:15:51 -0500 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower


Asked: 2017-01-05 14:35:38 -0500

Seen: 389 times

Last updated: Jan 05 '17