[JBoss JIRA] Created: (ISPN-512) Avoid throwing an IOException on a buffer switch caused by Lucene's seek()
by Sanne Grinovero (JIRA)
Avoid throwing an IOException on a buffer switch caused by Lucene's seek()
--------------------------------------------------------------------------
Key: ISPN-512
URL: https://jira.jboss.org/browse/ISPN-512
Project: Infinispan
Issue Type: Bug
Components: Lucene Directory
Affects Versions: 4.1.0.BETA2, 4.1.0.BETA1, 4.1.0.ALPHA3, 4.1.0.ALPHA2, 4.1.0.ALPHA1, 4.0.0.Final, 4.0.0.CR4, 4.0.0.CR3, 4.0.0.CR2, 4.0.0.CR1
Reporter: Sanne Grinovero
Assignee: Sanne Grinovero
Fix For: 4.1.0.CR1
Examining Lucene's sourcecode it appears that skipping to an unexisting buffer should throw an IOException *unless* it's being caused by a seek(position) having a too position value. We currently always throw such an exception when asked for a buffer which can't be found.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 4 months
[JBoss JIRA] Created: (ISPN-731) make state transfer and tx log draining serial
by Mircea Markus (JIRA)
make state transfer and tx log draining serial
----------------------------------------------
Key: ISPN-731
URL: https://jira.jboss.org/browse/ISPN-731
Project: Infinispan
Issue Type: Bug
Affects Versions: 4.1.0.Final
Reporter: Mircea Markus
Assignee: Manik Surtani
Priority: Critical
Fix For: 4.2.0.BETA1, 4.2.0.Final
{A,B,C, D}, num owners= 2. A's state is {(k,v)} and a transactions is prepared with {(k, otherValue)} on A.
B crashes.
two things happen with A's state:
1. on C an thread pulls state from A
2. A sends transaction state to C on another thread
Whit the right timing:
- 2 executes first (tx log is drained)
- tx commits - this applies the changes on C as well
- 1 executes last
Data ends up inconsistent:
A's states is {(k, otherValue)} while C's state is {(k,v)}
State transfer and tx log needs to be sequential (not parallel). The easy way to achieve this is to only do push, i.e. A sends the state and then drains tx log.
This can be reproduce by running ConcurrentNonOverlappingLeaveTest.testTransactional (fails aprox 1/5)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 4 months
[JBoss JIRA] Updated: (ISPN-60) make cache XA compliant
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-60?page=com.atlassian.jira.plugin.sy... ]
Galder Zamarreño updated ISPN-60:
---------------------------------
Fix Version/s: (was: 5.0.0.Final)
(was: 5.0.0.BETA1)
> make cache XA compliant
> -----------------------
>
> Key: ISPN-60
> URL: https://issues.jboss.org/browse/ISPN-60
> Project: Infinispan
> Issue Type: Feature Request
> Components: Transactions
> Reporter: Mircea Markus
> Assignee: Mircea Markus
> Labels: transaction, xa
>
> This should be implemented in order to bring failure-recovery capabilities to cache. Failure example:
> Let's say that we have 3 nodes, A B and C. A starts tx, does a put ("k","v") then commits tx. During commit following happen:
> 1) prepare is broadcasted
> B prepares and holds locks
> C prepares and holds locks
> 2) A sees B and C voted okay,so triggers a commit:
> - B receives the commit msg and applies changes (for good!)
> - A does not manage to send the message to C *in the given timeout*. At this point, the RPC call returns and A rollbacks, also C will rollback after a while (tx timeout). But B will have the changes applied, and this will result in an atomicity being violated.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 4 months