[JBoss JIRA] (ISPN-1965) Some entries not available during view change
by Michal Linhard (JIRA)
Michal Linhard created ISPN-1965:
------------------------------------
Summary: Some entries not available during view change
Key: ISPN-1965
URL: https://issues.jboss.org/browse/ISPN-1965
Project: Infinispan
Issue Type: Bug
Affects Versions: 5.1.3.FINAL
Reporter: Michal Linhard
Assignee: Manik Surtani
In the 4 node, dist mode, num-owners=2, elasticity test
http://www.qa.jboss.com/~mlinhard/hyperion/run44-elas-dist/
there is a cca 90 sec period of time where clients get null responses to GET
requests on entries that should exist in the cache.
first occurence:
hyperion1139.log 05:31:01,202 286.409
last occurence:
hyperion1135.log 05:32:45,441 390.648
total occurence count: (in all 19 driver nodes)
152241
(this doesn't mean it happens for 152K keys, because each key is retried after
erroneous attempt)
data doesn't seem to be lost, because these errors cease after a while and
number of entries returns back to normal (see cache_entries.csv)
this happens approximately in the period between node0001 is killed and cluster
{node0002 - node0004} is formed (and shortly after).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 5 months
[JBoss JIRA] (ISPN-2081) Transaction leak caused by reordering between prepare and commit
by Mircea Markus (JIRA)
Mircea Markus created ISPN-2081:
-----------------------------------
Summary: Transaction leak caused by reordering between prepare and commit
Key: ISPN-2081
URL: https://issues.jboss.org/browse/ISPN-2081
Project: Infinispan
Issue Type: Bug
Components: Transactions
Affects Versions: 5.1.5.FINAL
Reporter: Mircea Markus
Assignee: Mircea Markus
Fix For: 5.2.0.ALPHA1, 5.2.0.FINAL
Attachments: RollbackNotSentBeforePrepareTest.java
There's no ordering between the prepare and commit/rollback messages, as the later are sent OOB.
With this in mind, the following transaction leak might happen:
Tx1 send prepare on nodes {A,B}
1. the message reaches A and timeouts but hasn't yet been processed on B
2. The transaction originator reacts immediately to the timeout received from A without waiting the response from B and sends a rollback request
3. The rollback request is processed on A and B
4. The initial prepare is then processed on B
At this point we have an orphan transaction prepare on B.
Whilst this is not causing any inconsistencies, it keeps keys locked indefinitely and is a memory leak.
The solution would be to wait at 2 for all the prepare messages *before* sending the rollback.
Attached is a unit test to reproduce the issue.
Related mailing list thread: http://infinispan.markmail.org/search/#query:%20list%3Aorg.jboss.lists.in...
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 5 months
[JBoss JIRA] (ISPN-2187) Pre-Invocation flag PUT_FOR_EXTERNAL_READ throws exception
by Anna Manukyan (JIRA)
Anna Manukyan created ISPN-2187:
-----------------------------------
Summary: Pre-Invocation flag PUT_FOR_EXTERNAL_READ throws exception
Key: ISPN-2187
URL: https://issues.jboss.org/browse/ISPN-2187
Project: Infinispan
Issue Type: Bug
Components: Core API
Reporter: Anna Manukyan
Assignee: Manik Surtani
Hi,
While writing tests for Infinispan Flag.PUT_FOR_EXTERNAL_READ the following issue has been found.
In documentation it is said:
PUT_FOR_EXTERNAL_READ
Flags the invocation as a Cache.putForExternalRead(Object, Object) call, as opposed to a regular Map.put(Object, Object).
And the documentation for Cache.putForExternalRead(Object, Object) says:
void putForExternalRead(K key,
V value)
...................
Errors and exceptions are 'silent' - logged at a much lower level than normal, and this method does not throw exceptions
The issue is the following:
when trying to perform operation using PUT_FOR_EXTERNAL_READ flag, the exception is thrown, it is not 'silent'.
cache1.getAdvancedCache().withFlags(Flag.PUT_FOR_EXTERNAL_READ).put(key, value);
The test is the following:
public void testExceptionSuppression() throws Exception {
Cache cache1 = cache(0, "replSync");
Cache cache2 = cache(1, "replSync");
Transport mockTransport = mock(Transport.class);
RpcManagerImpl rpcManager = (RpcManagerImpl) TestingUtil.extractComponent(cache1, RpcManager.class);
Transport originalTransport = TestingUtil.extractComponent(cache1, Transport.class);
try {
Address mockAddress1 = mock(Address.class);
Address mockAddress2 = mock(Address.class);
List<Address> memberList = new ArrayList<Address>(2);
memberList.add(mockAddress1);
memberList.add(mockAddress2);
rpcManager.setTransport(mockTransport);
when(mockTransport.getMembers()).thenReturn(memberList);
when(mockTransport.getViewId()).thenReturn(originalTransport.getViewId());
when(mockTransport.invokeRemotely(anyAddresses(), (CacheRpcCommand) anyObject(), anyResponseMode(),
anyLong(), anyBoolean(), (ResponseFilter) anyObject()))
.thenThrow(new RuntimeException("Barf!"));
try {
cache1.put(key, value);
fail("Should have barfed");
}
catch (RuntimeException re) {
}
// clean up any indeterminate state left over
try {
cache1.remove(key);
fail("Should have barfed");
}
catch (RuntimeException re) {
}
assertNull("Should have cleaned up", cache1.get(key));
// should not barf
cache1.putForExternalRead(key, value);
/** ------------------- Testing the same feature with Flag.PUT_FOR_EXTERNAL_READ **/
try {
cache1.remove(key);
fail("Should have barfed");
}
catch (RuntimeException re) {
}
cache1.getAdvancedCache().withFlags(Flag.PUT_FOR_EXTERNAL_READ).put(key, value);
}
finally {
if (rpcManager != null) rpcManager.setTransport(originalTransport);
}
}
Best regards,
Anna.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 5 months
[JBoss JIRA] (ISPN-2302) New JdbcCacheStoreConfigurationBuilder should support existing ConnectionFactoryConfig
by Thomas Fromm (JIRA)
Thomas Fromm created ISPN-2302:
----------------------------------
Summary: New JdbcCacheStoreConfigurationBuilder should support existing ConnectionFactoryConfig
Key: ISPN-2302
URL: https://issues.jboss.org/browse/ISPN-2302
Project: Infinispan
Issue Type: Feature Request
Components: Configuration
Affects Versions: 5.2.0.Alpha3
Reporter: Thomas Fromm
Assignee: Mircea Markus
I've the situation the I need to reuse existing ConnectionFactoryConfigs.
Maybe implement ConnectionFactoryConfigurationBuilder with method read(ConnectionFactoryConfig template). Then extend JdbcCacheStoreConfigurationBuilder and add connectionFactory()?
--
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, 5 months
[JBoss JIRA] (ISPN-2335) MultiHotRodServersTest not works with ConfigurationBuilder API
by Thomas Fromm (JIRA)
Thomas Fromm created ISPN-2335:
----------------------------------
Summary: MultiHotRodServersTest not works with ConfigurationBuilder API
Key: ISPN-2335
URL: https://issues.jboss.org/browse/ISPN-2335
Project: Infinispan
Issue Type: Bug
Components: Test Suite
Affects Versions: 5.2.0.Alpha4
Reporter: Thomas Fromm
Assignee: Tristan Tarrant
Attachments: trace-infinispan.log
I tried to use ConfigurationBuilder API with addClusterEnabledCacheManager inside MultiHotRodServersTest.addHotRodServer.
Unfortunality it works on with the old Configuration object, with the Builder the test fails. I tried to find any relevant difference inside configuration, but wasn't successful :-(
So I use a LegacyConfigurationAdaptor to create old config.
Attachmed I've traces from the failing tests and from the working one. Maybe it helps.
--
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, 5 months