[JBoss JIRA] (ISPN-2377) Forwarded transactions not being completed on new owner
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-2377?page=com.atlassian.jira.plugin.... ]
Mircea Markus resolved ISPN-2377.
---------------------------------
Resolution: Duplicate Issue
Duplicate of ISPN-2382.
> Forwarded transactions not being completed on new owner
> -------------------------------------------------------
>
> Key: ISPN-2377
> URL: https://issues.jboss.org/browse/ISPN-2377
> Project: Infinispan
> Issue Type: Bug
> Components: State transfer
> Affects Versions: 5.2.0.Beta1
> Reporter: Erik Salter
> Assignee: Mircea Markus
>
> On a view change, transactions that are forwarded to a new node aren't necessarily completed on their new owner if they have only acquired local locks and have no modifications, which is the case with an aggregate lock.
> Here's an example:
> Node 1 started the following transaction: GlobalTransaction:<east-dg01-49896(east)>:9927
> It was forwarded to Node 3:
> 2012-10-09 08:48:51,021 TRACE [org.infinispan.transaction.TransactionTable] (OOB-16,erm-cluster,east-dg03-49466(east)) Created and registered remote transaction RemoteTransaction{modifications=[], lookedUpEntries={}, lockedKeys=null, backupKeyLocks=null, missingLookedUpEntries=false, markForRollback=false, tx=GlobalTransaction:<east-dg01-49896(east)>:9927:local}
> Then it was completed on the originating node, but due to there being no modifications (and no remote locks acquired), the tx completion method is never forwarded to the new owner.
> Consequently, the new node will never allow a lock to this key, due to this tx being in the table and other locks waiting on it to complete.
> 2012-10-09 08:48:51,285 TRACE [org.infinispan.transaction.AbstractCacheTransaction] (OOB-20,erm-cluster,east-dg03-49466(east)) Transaction gtx=GlobalTransaction:<east-dg01-49896(east)>:9927:local potentially locks key ServiceGroupKey[edgeDeviceId=2,serviceGroupNo=201]? true
> ...
> Could not acquire lock on ServiceGroupKey[edgeDeviceId=2,serviceGroupNo=201] on behalf of transaction GlobalTransaction:<east-dg01-49896(east)>:10177:remote. Lock is being held by null
> There are two ways I can think of to fix this. One is to not transmit txs that don't have modifications or backup locks and just keep them local. The other is to add a flag to LocalTransaction to let it know it was transmitted to a new node so the tx completion message is sent.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 6 months
[JBoss JIRA] (ISPN-2377) Forwarded transactions not being completed on new owner
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-2377?page=com.atlassian.jira.plugin.... ]
Mircea Markus commented on ISPN-2377:
-------------------------------------
I think this is a duplicate of ISPN-2383.
> Forwarded transactions not being completed on new owner
> -------------------------------------------------------
>
> Key: ISPN-2377
> URL: https://issues.jboss.org/browse/ISPN-2377
> Project: Infinispan
> Issue Type: Bug
> Components: State transfer
> Affects Versions: 5.2.0.Beta1
> Reporter: Erik Salter
> Assignee: Mircea Markus
>
> On a view change, transactions that are forwarded to a new node aren't necessarily completed on their new owner if they have only acquired local locks and have no modifications, which is the case with an aggregate lock.
> Here's an example:
> Node 1 started the following transaction: GlobalTransaction:<east-dg01-49896(east)>:9927
> It was forwarded to Node 3:
> 2012-10-09 08:48:51,021 TRACE [org.infinispan.transaction.TransactionTable] (OOB-16,erm-cluster,east-dg03-49466(east)) Created and registered remote transaction RemoteTransaction{modifications=[], lookedUpEntries={}, lockedKeys=null, backupKeyLocks=null, missingLookedUpEntries=false, markForRollback=false, tx=GlobalTransaction:<east-dg01-49896(east)>:9927:local}
> Then it was completed on the originating node, but due to there being no modifications (and no remote locks acquired), the tx completion method is never forwarded to the new owner.
> Consequently, the new node will never allow a lock to this key, due to this tx being in the table and other locks waiting on it to complete.
> 2012-10-09 08:48:51,285 TRACE [org.infinispan.transaction.AbstractCacheTransaction] (OOB-20,erm-cluster,east-dg03-49466(east)) Transaction gtx=GlobalTransaction:<east-dg01-49896(east)>:9927:local potentially locks key ServiceGroupKey[edgeDeviceId=2,serviceGroupNo=201]? true
> ...
> Could not acquire lock on ServiceGroupKey[edgeDeviceId=2,serviceGroupNo=201] on behalf of transaction GlobalTransaction:<east-dg01-49896(east)>:10177:remote. Lock is being held by null
> There are two ways I can think of to fix this. One is to not transmit txs that don't have modifications or backup locks and just keep them local. The other is to add a flag to LocalTransaction to let it know it was transmitted to a new node so the tx completion message is sent.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 6 months
[JBoss JIRA] (ISPN-2377) Forwarded transactions not being completed on new owner
by Erik Salter (JIRA)
[ https://issues.jboss.org/browse/ISPN-2377?page=com.atlassian.jira.plugin.... ]
Erik Salter updated ISPN-2377:
------------------------------
Summary: Forwarded transactions not being completed on new owner (was: Forwarded transactions not being invoked on new owner)
> Forwarded transactions not being completed on new owner
> -------------------------------------------------------
>
> Key: ISPN-2377
> URL: https://issues.jboss.org/browse/ISPN-2377
> Project: Infinispan
> Issue Type: Bug
> Components: State transfer
> Affects Versions: 5.2.0.Beta1
> Reporter: Erik Salter
> Assignee: Mircea Markus
>
> On a view change, transactions that are forwarded to a new node aren't necessarily completed on their new owner if they have only acquired local locks and have no modifications, which is the case with an aggregate lock.
> Here's an example:
> Node 1 started the following transaction: GlobalTransaction:<east-dg01-49896(east)>:9927
> It was forwarded to Node 3:
> 2012-10-09 08:48:51,021 TRACE [org.infinispan.transaction.TransactionTable] (OOB-16,erm-cluster,east-dg03-49466(east)) Created and registered remote transaction RemoteTransaction{modifications=[], lookedUpEntries={}, lockedKeys=null, backupKeyLocks=null, missingLookedUpEntries=false, markForRollback=false, tx=GlobalTransaction:<east-dg01-49896(east)>:9927:local}
> Then it was completed on the originating node, but due to there being no modifications (and no remote locks acquired), the tx completion method is never forwarded to the new owner.
> Consequently, the new node will never allow a lock to this key, due to this tx being in the table and other locks waiting on it to complete.
> 2012-10-09 08:48:51,285 TRACE [org.infinispan.transaction.AbstractCacheTransaction] (OOB-20,erm-cluster,east-dg03-49466(east)) Transaction gtx=GlobalTransaction:<east-dg01-49896(east)>:9927:local potentially locks key ServiceGroupKey[edgeDeviceId=2,serviceGroupNo=201]? true
> ...
> Could not acquire lock on ServiceGroupKey[edgeDeviceId=2,serviceGroupNo=201] on behalf of transaction GlobalTransaction:<east-dg01-49896(east)>:10177:remote. Lock is being held by null
> There are two ways I can think of to fix this. One is to not transmit txs that don't have modifications or backup locks and just keep them local. The other is to add a flag to LocalTransaction to let it know it was transmitted to a new node so the tx completion message is sent.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 6 months
[JBoss JIRA] (ISPN-2377) Forwarded transactions not being invoked on new owner
by Erik Salter (JIRA)
[ https://issues.jboss.org/browse/ISPN-2377?page=com.atlassian.jira.plugin.... ]
Erik Salter commented on ISPN-2377:
-----------------------------------
This looks like it's also broken in the general case, since the tx notification message has no affected keys to look up the addresses to send the completion message.
> Forwarded transactions not being invoked on new owner
> -----------------------------------------------------
>
> Key: ISPN-2377
> URL: https://issues.jboss.org/browse/ISPN-2377
> Project: Infinispan
> Issue Type: Bug
> Components: State transfer
> Affects Versions: 5.2.0.Beta1
> Reporter: Erik Salter
> Assignee: Mircea Markus
>
> On a view change, transactions that are forwarded to a new node aren't necessarily completed on their new owner if they have only acquired local locks and have no modifications, which is the case with an aggregate lock.
> Here's an example:
> Node 1 started the following transaction: GlobalTransaction:<east-dg01-49896(east)>:9927
> It was forwarded to Node 3:
> 2012-10-09 08:48:51,021 TRACE [org.infinispan.transaction.TransactionTable] (OOB-16,erm-cluster,east-dg03-49466(east)) Created and registered remote transaction RemoteTransaction{modifications=[], lookedUpEntries={}, lockedKeys=null, backupKeyLocks=null, missingLookedUpEntries=false, markForRollback=false, tx=GlobalTransaction:<east-dg01-49896(east)>:9927:local}
> Then it was completed on the originating node, but due to there being no modifications (and no remote locks acquired), the tx completion method is never forwarded to the new owner.
> Consequently, the new node will never allow a lock to this key, due to this tx being in the table and other locks waiting on it to complete.
> 2012-10-09 08:48:51,285 TRACE [org.infinispan.transaction.AbstractCacheTransaction] (OOB-20,erm-cluster,east-dg03-49466(east)) Transaction gtx=GlobalTransaction:<east-dg01-49896(east)>:9927:local potentially locks key ServiceGroupKey[edgeDeviceId=2,serviceGroupNo=201]? true
> ...
> Could not acquire lock on ServiceGroupKey[edgeDeviceId=2,serviceGroupNo=201] on behalf of transaction GlobalTransaction:<east-dg01-49896(east)>:10177:remote. Lock is being held by null
> There are two ways I can think of to fix this. One is to not transmit txs that don't have modifications or backup locks and just keep them local. The other is to add a flag to LocalTransaction to let it know it was transmitted to a new node so the tx completion message is sent.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 6 months
[JBoss JIRA] (ISPN-2326) c3p0 not part of the release
by Thomas Fromm (JIRA)
Thomas Fromm created ISPN-2326:
----------------------------------
Summary: c3p0 not part of the release
Key: ISPN-2326
URL: https://issues.jboss.org/browse/ISPN-2326
Project: Infinispan
Issue Type: Feature Request
Components: Build process
Affects Versions: 5.2.0.Alpha4
Reporter: Thomas Fromm
Assignee: Mircea Markus
According infinispan-5.2.0.Alpha4-all/modules/cachestores/jdbc/runtime-classpath.txt c3p0 lib should be part of the release.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 6 months
[JBoss JIRA] (ISPN-2374) Add ability to Build a EDS VDB via APIe
by Van Halbert (JIRA)
[ https://issues.jboss.org/browse/ISPN-2374?page=com.atlassian.jira.plugin.... ]
Van Halbert moved PRODMGT-252 to ISPN-2374:
-------------------------------------------
Project: Infinispan (was: Product Management)
Key: ISPN-2374 (was: PRODMGT-252)
Workflow: GIT Pull Request workflow (was: JBoss Platforms RFE Workflow v2)
Component/s: Core API
(was: Enterprise SOA Platform (SOA-P))
> Add ability to Build a EDS VDB via APIe
> ---------------------------------------
>
> Key: ISPN-2374
> URL: https://issues.jboss.org/browse/ISPN-2374
> Project: Infinispan
> Issue Type: Feature Request
> Components: Core API
> Reporter: Debbie Steigner
> Assignee: Ken Johnson
>
> Ability to build a VDB pro-grammatically via an API
> The need is to build the VDB during their build process, so would like to pull XMI's into the build process, then bind them together into a VDB for release. This way the build process can choose which version of the XMI files to bundle together into the VDB. Also an addition to this, it would be (almost necessary) great to be able to define what goes into the VDB (roles, translators to use, translator overrides etc) in a file that we can provide to the API, and also that we can check in to our source control.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 6 months
[JBoss JIRA] (ISPN-2374) Add ability to Build a EDS VDB via APIe
by Van Halbert (JIRA)
[ https://issues.jboss.org/browse/ISPN-2374?page=com.atlassian.jira.plugin.... ]
Van Halbert reassigned ISPN-2374:
---------------------------------
Assignee: Steven Hawkins (was: Ken Johnson)
> Add ability to Build a EDS VDB via APIe
> ---------------------------------------
>
> Key: ISPN-2374
> URL: https://issues.jboss.org/browse/ISPN-2374
> Project: Infinispan
> Issue Type: Feature Request
> Components: Core API
> Reporter: Debbie Steigner
> Assignee: Steven Hawkins
>
> Ability to build a VDB pro-grammatically via an API
> The need is to build the VDB during their build process, so would like to pull XMI's into the build process, then bind them together into a VDB for release. This way the build process can choose which version of the XMI files to bundle together into the VDB. Also an addition to this, it would be (almost necessary) great to be able to define what goes into the VDB (roles, translators to use, translator overrides etc) in a file that we can provide to the API, and also that we can check in to our source control.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 6 months
[JBoss JIRA] (ISPN-2355) Flag for local affine key at put
by Thomas Fromm (JIRA)
Thomas Fromm created ISPN-2355:
----------------------------------
Summary: Flag for local affine key at put
Key: ISPN-2355
URL: https://issues.jboss.org/browse/ISPN-2355
Project: Infinispan
Issue Type: Feature Request
Components: Distributed Cache
Affects Versions: 5.2.0.Alpha4
Reporter: Thomas Fromm
Assignee: Mircea Markus
Problem:
I store data based upon a known key (I can't use key generator) in the distributed cache. Shortly after storing the data will be read/deleted.
In case store is used, the data are only held on 2 nodes which migh not be the same node, where its created and needed next.
What I need is some kind of withFlags(Flag.LOCAL_AFFINE).put(...) to make sure, that at least the local node gets owner.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 6 months
[JBoss JIRA] (ISPN-2341) event.isPre has a counter intuitive behaviour
by Mircea Markus (JIRA)
Mircea Markus created ISPN-2341:
-----------------------------------
Summary: event.isPre has a counter intuitive behaviour
Key: ISPN-2341
URL: https://issues.jboss.org/browse/ISPN-2341
Project: Infinispan
Issue Type: Feature Request
Components: Listeners
Affects Versions: 5.1.7.Final
Reporter: Mircea Markus
Assignee: Mircea Markus
Fix For: 6.0.0.Final
When the listener is notified with (event.isPre == false), the change that triggered the event is not visible to the user[1] as the notification happens before exiting the EntryWrappingInterceptor.
For all types of notifications, when event.isPre==false, the modification should be visible into the cache. OTHO when event.isPre == true the modification shouldn't be visible.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 6 months
[JBoss JIRA] (ISPN-2336) Allow endpoints to be configured as read-only
by Tristan Tarrant (JIRA)
Tristan Tarrant created ISPN-2336:
-------------------------------------
Summary: Allow endpoints to be configured as read-only
Key: ISPN-2336
URL: https://issues.jboss.org/browse/ISPN-2336
Project: Infinispan
Issue Type: Feature Request
Components: Cache Server
Reporter: Tristan Tarrant
Assignee: Galder Zamarreño
Priority: Minor
It would be nice to configure endpoints to be read-only. This can be done reasonably easily with REST by disabling certain methods, but a common method would be welcome
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 6 months