[JBoss JIRA] (ISPN-3582) Server does not expose MBean for registering server-side serialization context
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-3582?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-3582:
-----------------------------------------------
Martin Gencur <mgencur(a)redhat.com> changed the Status of [bug 1015412|https://bugzilla.redhat.com/show_bug.cgi?id=1015412] from ASSIGNED to ON_QA
> Server does not expose MBean for registering server-side serialization context
> ------------------------------------------------------------------------------
>
> Key: ISPN-3582
> URL: https://issues.jboss.org/browse/ISPN-3582
> Project: Infinispan
> Issue Type: Bug
> Components: Querying, Server
> Affects Versions: 6.0.0.Beta2
> Reporter: Martin Gencur
> Assignee: Tristan Tarrant
> Priority: Critical
> Labels: jdg62GAblocker
> Fix For: 6.0.0.CR1
>
>
> There should be the following MBean available when starting ISPN server:
> {code}
> jboss.infinispan:type=RemoteQuery,name="{cacheManagerName}",component=ProtobufMetadataManager
> {code}
> However, this MBean is not exposed and so the server-side serialization context cannot be configured.
> More information about the MBean and its usage can be found in HotRodQueryTest . In infinispan itself (non-server) the JMX domain would be different but in the server it should be jboss.infinispan
> I'll attach a test for server-side.
--
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, 3 months
[JBoss JIRA] (ISPN-3592) Regression in Lucene Directory: NPE during SegmentInfos.getLastCommitGeneration
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-3592?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-3592:
-----------------------------------------------
Martin Gencur <mgencur(a)redhat.com> made a comment on [bug 1018097|https://bugzilla.redhat.com/show_bug.cgi?id=1018097]
See description in linked JIRA
> Regression in Lucene Directory: NPE during SegmentInfos.getLastCommitGeneration
> -------------------------------------------------------------------------------
>
> Key: ISPN-3592
> URL: https://issues.jboss.org/browse/ISPN-3592
> Project: Infinispan
> Issue Type: Bug
> Components: Lucene Directory
> Affects Versions: 6.0.0.CR1
> Reporter: Sanne Grinovero
> Assignee: Sanne Grinovero
> Priority: Blocker
> Fix For: 6.0.0.Final
>
>
> The problem is a very recent regression, so relative to 6.0.0.CR1 only.
> {noformat}
> java.lang.NullPointerException
> at org.apache.lucene.index.SegmentInfos.getLastCommitGeneration(SegmentInfos.java:160)
> at org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:605)
> at org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:554)
> at org.apache.lucene.index.SegmentInfos.read(SegmentInfos.java:359)
> at org.apache.lucene.index.SegmentInfos.readCurrentVersion(SegmentInfos.java:483)
> at org.apache.lucene.index.DirectoryReader.isCurrent(DirectoryReader.java:891)
> at org.apache.lucene.index.DirectoryReader.doOpenNoWriter(DirectoryReader.java:455)
> at org.apache.lucene.index.DirectoryReader.doOpenIfChanged(DirectoryReader.java:434)
> at org.apache.lucene.index.DirectoryReader.doOpenIfChanged(DirectoryReader.java:375)
> at org.apache.lucene.index.IndexReader.openIfChanged(IndexReader.java:508)
> at org.apache.lucene.index.IndexReader.reopen(IndexReader.java:695)
> at org.infinispan.lucene.profiling.LuceneReaderThread.refreshIndexReader(LuceneReaderThread.java:58)
> {noformat}
--
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, 3 months
[JBoss JIRA] (ISPN-3592) Regression in Lucene Directory: NPE during SegmentInfos.getLastCommitGeneration
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-3592?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-3592:
-----------------------------------------------
Martin Gencur <mgencur(a)redhat.com> changed the Status of [bug 1018097|https://bugzilla.redhat.com/show_bug.cgi?id=1018097] from NEW to POST
> Regression in Lucene Directory: NPE during SegmentInfos.getLastCommitGeneration
> -------------------------------------------------------------------------------
>
> Key: ISPN-3592
> URL: https://issues.jboss.org/browse/ISPN-3592
> Project: Infinispan
> Issue Type: Bug
> Components: Lucene Directory
> Affects Versions: 6.0.0.CR1
> Reporter: Sanne Grinovero
> Assignee: Sanne Grinovero
> Priority: Blocker
> Fix For: 6.0.0.Final
>
>
> The problem is a very recent regression, so relative to 6.0.0.CR1 only.
> {noformat}
> java.lang.NullPointerException
> at org.apache.lucene.index.SegmentInfos.getLastCommitGeneration(SegmentInfos.java:160)
> at org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:605)
> at org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:554)
> at org.apache.lucene.index.SegmentInfos.read(SegmentInfos.java:359)
> at org.apache.lucene.index.SegmentInfos.readCurrentVersion(SegmentInfos.java:483)
> at org.apache.lucene.index.DirectoryReader.isCurrent(DirectoryReader.java:891)
> at org.apache.lucene.index.DirectoryReader.doOpenNoWriter(DirectoryReader.java:455)
> at org.apache.lucene.index.DirectoryReader.doOpenIfChanged(DirectoryReader.java:434)
> at org.apache.lucene.index.DirectoryReader.doOpenIfChanged(DirectoryReader.java:375)
> at org.apache.lucene.index.IndexReader.openIfChanged(IndexReader.java:508)
> at org.apache.lucene.index.IndexReader.reopen(IndexReader.java:695)
> at org.infinispan.lucene.profiling.LuceneReaderThread.refreshIndexReader(LuceneReaderThread.java:58)
> {noformat}
--
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, 3 months
[JBoss JIRA] (ISPN-3592) Regression in Lucene Directory: NPE during SegmentInfos.getLastCommitGeneration
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-3592?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration updated ISPN-3592:
------------------------------------------
Bugzilla Update: Perform
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1018097
> Regression in Lucene Directory: NPE during SegmentInfos.getLastCommitGeneration
> -------------------------------------------------------------------------------
>
> Key: ISPN-3592
> URL: https://issues.jboss.org/browse/ISPN-3592
> Project: Infinispan
> Issue Type: Bug
> Components: Lucene Directory
> Affects Versions: 6.0.0.CR1
> Reporter: Sanne Grinovero
> Assignee: Sanne Grinovero
> Priority: Blocker
> Fix For: 6.0.0.Final
>
>
> The problem is a very recent regression, so relative to 6.0.0.CR1 only.
> {noformat}
> java.lang.NullPointerException
> at org.apache.lucene.index.SegmentInfos.getLastCommitGeneration(SegmentInfos.java:160)
> at org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:605)
> at org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:554)
> at org.apache.lucene.index.SegmentInfos.read(SegmentInfos.java:359)
> at org.apache.lucene.index.SegmentInfos.readCurrentVersion(SegmentInfos.java:483)
> at org.apache.lucene.index.DirectoryReader.isCurrent(DirectoryReader.java:891)
> at org.apache.lucene.index.DirectoryReader.doOpenNoWriter(DirectoryReader.java:455)
> at org.apache.lucene.index.DirectoryReader.doOpenIfChanged(DirectoryReader.java:434)
> at org.apache.lucene.index.DirectoryReader.doOpenIfChanged(DirectoryReader.java:375)
> at org.apache.lucene.index.IndexReader.openIfChanged(IndexReader.java:508)
> at org.apache.lucene.index.IndexReader.reopen(IndexReader.java:695)
> at org.infinispan.lucene.profiling.LuceneReaderThread.refreshIndexReader(LuceneReaderThread.java:58)
> {noformat}
--
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, 3 months
[JBoss JIRA] (ISPN-3600) ignorePreviousValue should not be set on non-origin nodes
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-3600?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-3600:
-----------------------------------------------
Radim Vansa <rvansa(a)redhat.com> changed the Status of [bug 1016104|https://bugzilla.redhat.com/show_bug.cgi?id=1016104] from ON_QA to VERIFIED
> ignorePreviousValue should not be set on non-origin nodes
> ---------------------------------------------------------
>
> Key: ISPN-3600
> URL: https://issues.jboss.org/browse/ISPN-3600
> Project: Infinispan
> Issue Type: Bug
> Components: State transfer, Transactions
> Affects Versions: 6.0.0.CR1
> Reporter: Radim Vansa
> Assignee: Pedro Ruivo
> Priority: Critical
> Labels: jdg62blocker
> Fix For: 6.0.0.Final
>
>
> In {{TxDistributionInterceptor.visit(Replace|Remove)Command}} the ignorePreviousValue flag is set to false on nodes which are not executing the transaction. Usually this does not matter, but when some other node requests transactions from this node (during ST), the Remove and Replace commands are sent with this flag set to false, which results in skipping their execution.
> Note: the overall behaviour with ignoring the command when this flag is false and origin is not local seems to me as abusing it - the semantics of the command is far from obvious. When the non-origin node receives the exact command that is executed on the original node (without ignorePreviousValue set to true), it simply ignores it.
--
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, 3 months
[JBoss JIRA] (ISPN-3603) Conditional command is committed on originator when it fails on primary owner
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-3603?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-3603:
-----------------------------------------------
Martin Gencur <mgencur(a)redhat.com> changed the Status of [bug 1016499|https://bugzilla.redhat.com/show_bug.cgi?id=1016499] from NEW to POST
> Conditional command is committed on originator when it fails on primary owner
> -----------------------------------------------------------------------------
>
> Key: ISPN-3603
> URL: https://issues.jboss.org/browse/ISPN-3603
> Project: Infinispan
> Issue Type: Bug
> Components: Distributed Cache
> Affects Versions: 6.0.0.CR1
> Reporter: Radim Vansa
> Assignee: Pedro Ruivo
> Priority: Critical
> Labels: jdg62blocker
> Fix For: 6.0.0.CR2, 6.0.0.Final
>
>
> In non-tx cache, when conditional command (e.g. ReplaceCommand) fails on primary owner because the old value is not equal to current value, the NonTxDistributionInterceptor.visitReplaceCommand returns false but the entry is committed in EntryWrappingInterceptor anyway.
> Speaking about EntryWrappingInterceptor.invokeNextAndApplyChanges: NonTxDistributionInterceptor does not mark the command as unsuccessful if it fails on the primary owner, therefore, checking for command.isSuccessful() in order to retry the command upon topology change may seem insufficient.
--
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, 3 months
[JBoss JIRA] (ISPN-3443) WriteCommand may be ignored during state transfer
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-3443?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-3443:
-----------------------------------------------
Martin Gencur <mgencur(a)redhat.com> changed the Status of [bug 1001634|https://bugzilla.redhat.com/show_bug.cgi?id=1001634] from ON_QA to ASSIGNED
> WriteCommand may be ignored during state transfer
> -------------------------------------------------
>
> Key: ISPN-3443
> URL: https://issues.jboss.org/browse/ISPN-3443
> Project: Infinispan
> Issue Type: Bug
> Components: Locking and Concurrency, State transfer
> Affects Versions: 6.0.0.Alpha3
> Reporter: Radim Vansa
> Assignee: Dan Berindei
> Priority: Blocker
> Labels: jdg62blocker
> Fix For: 6.0.0.CR1
>
>
> Distributed sync non-tx cache.
> Situation:
> 1) A node is joining the cluster, requesting some segment
> 2) RemoveCommand is sent to backup owner with ignorePreviousValue=true
> 3) It looks up the entry and finds null
> 4) State transfer invokes the PutKeyValueCommand and sets the value for removed entry (updateKeys has not the key yet)
> 5) RemoveCommand adds its key to updateKeys set, but it does not remove the value as it is already null (in its context)
> Result: the value is removed on primary but on backup this is still present
--
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, 3 months
[JBoss JIRA] (ISPN-3540) Persisting new entity with cached blind-side @OneToMany CMR field fails on transaction flush to ARJUNA016082.
by Jari Juslin (JIRA)
[ https://issues.jboss.org/browse/ISPN-3540?page=com.atlassian.jira.plugin.... ]
Jari Juslin commented on ISPN-3540:
-----------------------------------
Further testing: This bug manifests only if the caching mode is FULL_XA. With NONE or NON_XA the code works.
> Persisting new entity with cached blind-side @OneToMany CMR field fails on transaction flush to ARJUNA016082.
> -------------------------------------------------------------------------------------------------------------
>
> Key: ISPN-3540
> URL: https://issues.jboss.org/browse/ISPN-3540
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 5.2.1.Final, 6.0.0.CR1
> Environment: 64-bit Ubuntu 13.04, JBoss 7.2.0.Final, Hibernate 4.2.4.
> Reporter: Jari Juslin
> Assignee: Galder Zamarreño
> Attachments: infinispan_bug_repro.zip, infinispan_bug_repro2.zip
>
>
> I have two entity beans, both transactionally cached and then n:m relationship between them. The one side maps the CMR relationship as a Set and sets it to be transactionally cached.
> Now when I create a new object on the one side, so that the Set containing the other side is empty, the transaction fails during the flush stage with the following message:
> WARN [org.infinispan.transaction.TransactionTable] (http-/0.0.0.0:8080-1:) ISPN000101: Failed synchronization registration: java.lang.IllegalStateException: ARJUNA016082: Synchronizations are not allowed! Transaction status isActionStatus.RUNNING
> If I leave the Set field null, it works.
> The beans:
> @Entity()
> @Table(name="k3_run")
> @Cache(usage=CacheConcurrencyStrategy.TRANSACTIONAL)
> public class Run implements Serializable {
> private Integer id;
> private Set<Restriction> restrictions = new HashSet<>();
>
> @Id
> @GeneratedValue(strategy=GenerationType.IDENTITY)
> @Column(name = "id")
> public Integer getId() {
> return id;
> }
> public void setId(Integer id) {
> this.id = id;
> }
> @OneToMany
> @JoinColumn(name="run_fk")
> @Cache(usage=CacheConcurrencyStrategy.TRANSACTIONAL)
> public Set<Restriction> getRestrictions() {
> return restrictions;
> }
> public void setRestrictions(Set<Restriction> restrictions) {
> this.restrictions = restrictions;
> }
> }
> @Entity
> @Table(name="k3_restriction")
> @Cache(usage=CacheConcurrencyStrategy.TRANSACTIONAL)
> public class Restriction {
> private Integer id;
>
> @Id
> @GeneratedValue(strategy=GenerationType.IDENTITY)
> @Column(name = "id")
> public Integer getId() {
> return id;
> }
> public void setId(Integer id) {
> this.id = id;
> }
> }
> The RESTeasy service doing the creation:
> @Stateless
> @LocalBean
> @Path("/bug_repro")
> @TransactionAttribute(TransactionAttributeType.REQUIRED)
> public class RunRest {
> @PersistenceContext(unitName = "persistence_context")
> protected EntityManager entityManager;
> @POST
> @TransactionAttribute(TransactionAttributeType.REQUIRED)
> public String createRun() {
> final Run run = new Run();
> entityManager.persist(run);
> return "New run created with ID " + run.getId();
> }
> }
> This curl command used to invoke it:
> curl -H 'Content-Type: application/xml; charset=UTF-8' -X POST http://localhost:8080/infinispan_bug_reproduction/bug_repro
> The persistence.xml:
> <?xml version="1.0" encoding="UTF-8"?>
> <persistence xmlns="http://java.sun.com/xml/ns/persistence"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xsi:schemaLocation="http://java.sun.com/xml/ns/persistence http://java.sun.com/xml/ns/persistence/persistence_2_0.xsd"
> version="2.0">
> <persistence-unit name="persistence_context" transaction-type="JTA">
> <provider>org.hibernate.ejb.HibernatePersistence</provider>
> <jta-data-source>java:/OperationalDS</jta-data-source>
> <properties>
> <property name="hibernate.hbm2ddl.auto" value="validate"/>
> <property name="hibernate.cache.use_second_level_cache" value="true"/>
> <property name="hibernate.cache.use_query_cache" value="true"/>
> </properties>
> </persistence-unit>
> </persistence>
> The datasource definition:
> <xa-datasource jndi-name="java:/OperationalDS" pool-name="MpkDemoUsDS" enabled="true">
> <xa-datasource-property name="ServerName">
> localhost
> </xa-datasource-property>
> <xa-datasource-property name="DatabaseName">
> production
> </xa-datasource-property>
> <driver>mysql</driver>
> <security>
> <user-name>k3</user-name>
> <password>********</password>
> </security>
> <validation>
> <check-valid-connection-sql>/* ping */ SELECT 1</check-valid-connection-sql>
> <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.mysql.MySQLExceptionSorter"/>
> </validation>
> </xa-datasource>
> The stacktrace:
> 17:08:50,159 WARN [org.infinispan.transaction.TransactionTable] (http-/0.0.0.0:8080-1:) ISPN000101: Failed synchronization registration: java.lang.IllegalStateException: ARJUNA016082: Synchronizations are not allowed! Transaction status isActionStatus.RUNNING
> at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.registerSynchronizationImple(TransactionImple.java:374)
> at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.registerSynchronization(TransactionImple.java:351)
> at org.infinispan.transaction.TransactionTable.enlist(TransactionTable.java:214)
> at org.infinispan.interceptors.TxInterceptor.enlist(TxInterceptor.java:271)
> at org.infinispan.interceptors.TxInterceptor.enlistWriteAndInvokeNext(TxInterceptor.java:245)
> at org.infinispan.interceptors.TxInterceptor.visitRemoveCommand(TxInterceptor.java:201)
> at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:72)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
> at org.infinispan.interceptors.CacheMgmtInterceptor.visitRemoveCommand(CacheMgmtInterceptor.java:137)
> at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:72)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:128)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:92)
> at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:67)
> at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:72)
> at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:343)
> at org.infinispan.CacheImpl.executeCommandAndCommitIfNeeded(CacheImpl.java:1162)
> at org.infinispan.CacheImpl.removeInternal(CacheImpl.java:308)
> at org.infinispan.CacheImpl.remove(CacheImpl.java:302)
> at org.infinispan.DecoratedCache.remove(DecoratedCache.java:325)
> at org.infinispan.AbstractDelegatingCache.remove(AbstractDelegatingCache.java:313)
> at org.hibernate.cache.infinispan.access.TransactionalAccessDelegate.remove(TransactionalAccessDelegate.java:152) [hibernate-infinispan-4.2.4.Final.jar:4.2.4.Final]
> at org.hibernate.cache.infinispan.collection.TransactionalAccess.remove(TransactionalAccess.java:48) [hibernate-infinispan-4.2.4.Final.jar:4.2.4.Final]
> at org.hibernate.action.internal.CollectionAction.evict(CollectionAction.java:152) [hibernate-core-4.2.4.Final.jar:4.2.4.Final]
> at org.hibernate.action.internal.CollectionRecreateAction.execute(CollectionRecreateAction.java:64) [hibernate-core-4.2.4.Final.jar:4.2.4.Final]
> at org.hibernate.engine.spi.ActionQueue.execute(ActionQueue.java:377) [hibernate-core-4.2.4.Final.jar:4.2.4.Final]
> at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:369) [hibernate-core-4.2.4.Final.jar:4.2.4.Final]
> at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:292) [hibernate-core-4.2.4.Final.jar:4.2.4.Final]
> at org.hibernate.event.internal.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:339) [hibernate-core-4.2.4.Final.jar:4.2.4.Final]
> at org.hibernate.event.internal.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:52) [hibernate-core-4.2.4.Final.jar:4.2.4.Final]
> at org.hibernate.internal.SessionImpl.flush(SessionImpl.java:1234) [hibernate-core-4.2.4.Final.jar:4.2.4.Final]
> at org.hibernate.internal.SessionImpl.managedFlush(SessionImpl.java:404) [hibernate-core-4.2.4.Final.jar:4.2.4.Final]
> at org.hibernate.engine.transaction.synchronization.internal.SynchronizationCallbackCoordinatorImpl.beforeCompletion(SynchronizationCallbackCoordinatorImpl.java:113) [hibernate-core-4.2.4.Final.jar:4.2.4.Final]
> at org.hibernate.engine.transaction.synchronization.internal.RegisteredSynchronization.beforeCompletion(RegisteredSynchronization.java:53) [hibernate-core-4.2.4.Final.jar:4.2.4.Final]
> at com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.beforeCompletion(SynchronizationImple.java:76)
> at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.beforeCompletion(TwoPhaseCoordinator.java:273)
> at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:93)
> at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:162)
> at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1165)
> at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:126)
> at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:75)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.endTransaction(CMTTxInterceptor.java:91) [jboss-as-ejb3-7.2.0.Final.jar:7.2.0.Final]
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:252) [jboss-as-ejb3-7.2.0.Final.jar:7.2.0.Final]
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:315) [jboss-as-ejb3-7.2.0.Final.jar:7.2.0.Final]
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:214) [jboss-as-ejb3-7.2.0.Final.jar:7.2.0.Final]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) [jboss-as-ejb3-7.2.0.Final.jar:7.2.0.Final]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) [jboss-as-ejb3-7.2.0.Final.jar:7.2.0.Final]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:59) [jboss-as-ejb3-7.2.0.Final.jar:7.2.0.Final]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50) [jboss-as-ee-7.2.0.Final.jar:7.2.0.Final]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54) [jboss-as-ejb3-7.2.0.Final.jar:7.2.0.Final]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> at org.jboss.as.ee.component.TCCLInterceptor.processInvocation(TCCLInterceptor.java:45) [jboss-as-ee-7.2.0.Final.jar:7.2.0.Final]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:165) [jboss-as-ee-7.2.0.Final.jar:7.2.0.Final]
> at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:182) [jboss-as-ee-7.2.0.Final.jar:7.2.0.Final]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:72) [jboss-as-ee-7.2.0.Final.jar:7.2.0.Final]
> at com.ecolane.mpk.rest.RunRest$$$view2.createRun(Unknown Source) [classes:]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_40]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_40]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_40]
> at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_40]
> at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:167) [resteasy-jaxrs-2.3.5.Final.jar:]
> at org.jboss.resteasy.core.ResourceMethod.invokeOnTarget(ResourceMethod.java:257) [resteasy-jaxrs-2.3.5.Final.jar:]
> at org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:222) [resteasy-jaxrs-2.3.5.Final.jar:]
> at org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:211) [resteasy-jaxrs-2.3.5.Final.jar:]
> at org.jboss.resteasy.core.SynchronousDispatcher.getResponse(SynchronousDispatcher.java:542) [resteasy-jaxrs-2.3.5.Final.jar:]
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:524) [resteasy-jaxrs-2.3.5.Final.jar:]
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:126) [resteasy-jaxrs-2.3.5.Final.jar:]
> at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:208) [resteasy-jaxrs-2.3.5.Final.jar:]
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:55) [resteasy-jaxrs-2.3.5.Final.jar:]
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:50) [resteasy-jaxrs-2.3.5.Final.jar:]
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:847) [jboss-servlet-api_3.0_spec-1.0.2.Final.jar:1.0.2.Final]
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:295) [jbossweb-7.2.0.Final.jar:7.2.0.Final]
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) [jbossweb-7.2.0.Final.jar:7.2.0.Final]
> at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230) [jbossweb-7.2.0.Final.jar:7.2.0.Final]
> at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:149) [jbossweb-7.2.0.Final.jar:7.2.0.Final]
> at org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:50) [jboss-as-jpa-7.2.0.Final.jar:7.2.0.Final]
> at org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:50) [jboss-as-jpa-7.2.0.Final.jar:7.2.0.Final]
> at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:169) [jboss-as-web-7.2.0.Final.jar:7.2.0.Final]
> at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:145) [jbossweb-7.2.0.Final.jar:7.2.0.Final]
> at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:97) [jbossweb-7.2.0.Final.jar:7.2.0.Final]
> at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:102) [jbossweb-7.2.0.Final.jar:7.2.0.Final]
> at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:336) [jbossweb-7.2.0.Final.jar:7.2.0.Final]
> at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:856) [jbossweb-7.2.0.Final.jar:7.2.0.Final]
> at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:653) [jbossweb-7.2.0.Final.jar:7.2.0.Final]
> at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:920) [jbossweb-7.2.0.Final.jar:7.2.0.Final]
> at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40]
--
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, 3 months
[JBoss JIRA] (ISPN-3364) Tests from org.infinispan.atomic package fail with AssertionError
by Vitalii Chepeliuk (JIRA)
[ https://issues.jboss.org/browse/ISPN-3364?page=com.atlassian.jira.plugin.... ]
Vitalii Chepeliuk commented on ISPN-3364:
-----------------------------------------
Hi Will! You can still see it here. I run it with ER2, you can see it in matrix under IBM and JDK7, this tests fail every time
https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/JDG/view/FUNC/job/e...
> Tests from org.infinispan.atomic package fail with AssertionError
> -----------------------------------------------------------------
>
> Key: ISPN-3364
> URL: https://issues.jboss.org/browse/ISPN-3364
> Project: Infinispan
> Issue Type: Bug
> Components: Core API
> Affects Versions: 6.0.0.Alpha1
> Environment: RHEL5_x86, RHEL5_x86_64, RHEL6_x86, RHEL5_x86_64 with IBM JDK7
> Reporter: Vitalii Chepeliuk
> Assignee: William Burns
> Labels: jdg62GAblocker, testsuite_stability
> Attachments: LocalDeltaAwarePassivationTest.log.zip, ReplDeltaAwarePassivationTest.log.zip
>
>
> Following tests fail from org.infinispan.atomic package
> org.infinispan.atomic.LocalDeltaAwarePassivationTest.testAtomicMap
> org.infinispan.atomic.LocalDeltaAwarePassivationTest.testDeltaAware
> org.infinispan.atomic.LocalDeltaAwarePassivationTest.testFineGrainedAtomicMap
> org.infinispan.atomic.ReplDeltaAwarePassivationTest.testAtomicMap
> org.infinispan.atomic.ReplDeltaAwarePassivationTest.testAtomicMap2
> org.infinispan.atomic.ReplDeltaAwarePassivationTest.testDeltaAware
> org.infinispan.atomic.ReplDeltaAwarePassivationTest.testDeltaAware2
> org.infinispan.atomic.ReplDeltaAwarePassivationTest.testFineGrainedAtomicMap
> org.infinispan.atomic.ReplDeltaAwarePassivationTest.testFineGrainedAtomicMap2
> Add link on jenkins job https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/JDG/view/FUNC/job/e...
--
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, 3 months
[JBoss JIRA] (ISPN-3617) Inconsistent L1 in non-tx distributed cache
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-3617?page=com.atlassian.jira.plugin.... ]
Work on ISPN-3617 started by William Burns.
> Inconsistent L1 in non-tx distributed cache
> -------------------------------------------
>
> Key: ISPN-3617
> URL: https://issues.jboss.org/browse/ISPN-3617
> Project: Infinispan
> Issue Type: Bug
> Components: Distributed Cache
> Affects Versions: 6.0.0.CR1
> Reporter: Radim Vansa
> Assignee: William Burns
>
> When the change is replicated to backup owner, it sends the InvalidateL1Command to backup owners before committing the entry in EntryWrappingInterceptor (it performs the WriteCommand in parallel with sending the invalidation commmand, but then it waits until the invalidation request gets acked. If a GET is executed between the invalidation and committing the entry, the response contains outdated result and the L1 will not be invalidated until next write operation.
--
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, 3 months