[JBoss JIRA] (ISPN-3589) StackOverflow in InternalMetadataImpl.Externalizer
by Divya Mehra (JIRA)
[ https://issues.jboss.org/browse/ISPN-3589?page=com.atlassian.jira.plugin.... ]
Divya Mehra updated ISPN-3589:
------------------------------
Labels: 620 (was: jdg620_dm jdg62GAblocker)
> StackOverflow in InternalMetadataImpl.Externalizer
> --------------------------------------------------
>
> Key: ISPN-3589
> URL: https://issues.jboss.org/browse/ISPN-3589
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 6.0.0.CR1
> Reporter: Pedro Ruivo
> Assignee: Mircea Markus
> Labels: 620
>
> the implementation delegates to another metadata some methods. The result is a chain of InternalMetadataImpl as you can see in:
> {code}
> metadata=InternalMetadataImpl{actual=InternalMetadataImpl{actual=InternalMetadataImpl{actual=Inte
> rnalMetadataImpl{actual=InternalMetadataImpl{actual=InternalMetadataImpl{actual=InternalMetadataImpl{actual=InternalMetadataImpl{actual=InternalMetadataImpl{actual=InternalMetadataImpl
> {actual=InternalMetadataImpl{actual=InternalMetadataImpl{actual=InternalMetadataImpl{actual=InternalMetadataImpl{actual=InternalMetadataImpl{actual=InternalMetadataImpl{actual=Internal
> MetadataImpl{actual=InternalMetadataImpl{actual=InternalMetadataImpl{actual=InternalMetadataImpl{actual=InternalMetadataImpl{actual=InternalMetadataImpl{actual=InternalMetadataImpl{act
> ual=InternalMetadataImpl [....]
> {code}
--
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
10 years, 5 months
[JBoss JIRA] (ISPN-3473) CDI Cache interceptor tests are failing while running in Tomcat container
by Divya Mehra (JIRA)
[ https://issues.jboss.org/browse/ISPN-3473?page=com.atlassian.jira.plugin.... ]
Divya Mehra updated ISPN-3473:
------------------------------
Labels: 620 (was: jdg620_dm jdg62GAblocker)
> CDI Cache interceptor tests are failing while running in Tomcat container
> -------------------------------------------------------------------------
>
> Key: ISPN-3473
> URL: https://issues.jboss.org/browse/ISPN-3473
> Project: Infinispan
> Issue Type: Bug
> Components: CDI integration
> Affects Versions: 6.0.0.Alpha3
> Reporter: Anna Manukyan
> Assignee: Mircea Markus
> Labels: 620
>
> There is a problem with Infinispan CDI interceptors under the Tomcat container.
> While running the infinispan/cdi-extension module's tests under the tomcat container, the following 2 related issues appear:
> 1) When the beans.xml contains the definition for the interceptors, as given below:
> {code}
> <beans xmlns="http://java.sun.com/xml/ns/javaee"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/beans_1_0.xsd">
> <interceptors>
> <class>org.infinispan.jcache.annotation.CacheResultInterceptor</class>
> <class>org.infinispan.jcache.annotation.CachePutInterceptor</class>
> <class>org.infinispan.jcache.annotation.CacheRemoveEntryInterceptor</class>
> <class>org.infinispan.jcache.annotation.CacheRemoveAllInterceptor</class>
> </interceptors>
> <alternatives>
> <class>org.infinispan.cdi.InjectedCacheResolver</class>
> </alternatives>
> </beans>
> {code}
> Then while the deployment on the container, the following exception is thrown:
> {code}
> org.jboss.weld.exceptions.DeploymentException: WELD-001416 Enabled interceptor class [<class>org.infinispan.jcache.annotation.CacheResultInterceptor</class> in jar:file:/home/anna.manukyan/.jenkins/jobs/invm-tomcat/workspace/tomcat-server/jboss-ews-2.0/tomcat7/webapps/test/WEB-INF/lib/infinispan-jcache.jar!/META-INF/beans.xml@7, <class>org.infinispan.jcache.annotation.CachePutInterceptor</class> in jar:file:/home/anna.manukyan/.jenkins/jobs/invm-tomcat/workspace/tomcat-server/jboss-ews-2.0/tomcat7/webapps/test/WEB-INF/lib/infinispan-jcache.jar!/META-INF/beans.xml@8, <class>org.infinispan.jcache.annotation.CacheRemoveEntryInterceptor</class> in jar:file:/home/anna.manukyan/.jenkins/jobs/invm-tomcat/workspace/tomcat-server/jboss-ews-2.0/tomcat7/webapps/test/WEB-INF/lib/infinispan-jcache.jar!/META-INF/beans.xml@9, <class>org.infinispan.jcache.annotation.CacheRemoveAllInterceptor</class> in jar:file:/home/anna.manukyan/.jenkins/jobs/invm-tomcat/workspace/tomcat-server/jboss-ews-2.0/tomcat7/webapps/test/WEB-INF/lib/infinispan-jcache.jar!/META-INF/beans.xml@10, <class>org.infinispan.jcache.annotation.CacheResultInterceptor</class> in jndi:/localhost/test/WEB-INF/beans.xml@29, <class>org.infinispan.jcache.annotation.CachePutInterceptor</class> in jndi:/localhost/test/WEB-INF/beans.xml@30, <class>org.infinispan.jcache.annotation.CacheRemoveEntryInterceptor</class> in jndi:/localhost/test/WEB-INF/beans.xml@31, <class>org.infinispan.jcache.annotation.CacheRemoveAllInterceptor</class> in jndi:/localhost/test/WEB-INF/beans.xml@32] specified twice
> at org.jboss.weld.manager.Enabled.createMetadataMap(Enabled.java:123)
> at org.jboss.weld.manager.Enabled.<init>(Enabled.java:96)
> at org.jboss.weld.manager.Enabled.of(Enabled.java:79)
> at org.jboss.weld.bootstrap.BeanDeployment.<init>(BeanDeployment.java:114)
> at org.jboss.weld.bootstrap.WeldBootstrap$DeploymentVisitor.visit(WeldBootstrap.java:183)
> at org.jboss.weld.bootstrap.WeldBootstrap$DeploymentVisitor.visit(WeldBootstrap.java:152)
> at org.jboss.weld.bootstrap.WeldBootstrap.startContainer(WeldBootstrap.java:283)
> at org.jboss.weld.environment.servlet.Listener.contextInitialized(Listener.java:151)
> at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4791)
> at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5285)
> at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
> at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:901)
> at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:877)
> at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:618)
> at org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:963)
> at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:537)
> at org.apache.catalina.startup.HostConfig.check(HostConfig.java:1468)
> at sun.reflect.GeneratedMethodAccessor27.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at org.apache.tomcat.util.modeler.BaseModelMBean.invoke(BaseModelMBean.java:301)
> at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819)
> at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:791)
> at org.apache.catalina.manager.ManagerServlet.check(ManagerServlet.java:1444)
> at org.apache.catalina.manager.ManagerServlet.deploy(ManagerServlet.java:677)
> at org.apache.catalina.manager.ManagerServlet.doPut(ManagerServlet.java:435)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:644)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
> at org.apache.catalina.filters.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:108)
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
> at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222)
> at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123)
> at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:581)
> at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:168)
> at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99)
> at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:929)
> at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
> at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407)
> at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1002)
> at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:585)
> at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:312)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:722)
> {code}
> If there is no need declare the interceptors in the beans.xml (as far as I know it is necessary), then please let me know and ignore this case.
> 2) When the interceptors declaration is commented, then the interceptors doesn't work properly. So all tests located under the package org.infinispan.cdi.test.interceptor.* are failing with assertion errors.
> Please note that this behaviour is noticed for infinispan 6.0.0.Alpha3. It is not tried for the earlier versions.
--
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
10 years, 5 months
[JBoss JIRA] (ISPN-3599) CommitCommand with replayed PrepareCommand executes rollback and then commit
by Divya Mehra (JIRA)
[ https://issues.jboss.org/browse/ISPN-3599?page=com.atlassian.jira.plugin.... ]
Divya Mehra updated ISPN-3599:
------------------------------
Labels: 620 (was: jdg62GAblocker)
> CommitCommand with replayed PrepareCommand executes rollback and then commit
> ----------------------------------------------------------------------------
>
> Key: ISPN-3599
> URL: https://issues.jboss.org/browse/ISPN-3599
> Project: Infinispan
> Issue Type: Bug
> Components: State transfer, Transactions
> Affects Versions: 6.0.0.CR1
> Reporter: Radim Vansa
> Assignee: Pedro Ruivo
> Priority: Critical
> Labels: 620
> Fix For: 6.0.0.CR2, 6.0.0.Final
>
>
> During state-transfer in tx cache, the node can receive {{CommitCommand}} from other node. After the node gets transaction data for affected segments, it creates the transaction with {{missingLookedUpEntries=true}} and the {{CommitCommand}} can be executed.
> In this command's {{perform(...)}} the transaction is *first* marked as completed, then it enters the interceptor chain. There, the {{PrepareCommand}} is created in {{StateTransferInterceptor.visitCommitCommand}} but after this is processed the {{TxInterceptor}} finds out that the transaction is already completed and executes {{RollbackCommand}}, clearing locks etc.
> Nevertheless, {{StateTransferInterceptor}} executes the initial {{CommitCommand}} afterwards. I suspect that this may be executed without the locks held.
> Anyway, it is not correct to execute both commit and rollback on the same transaction.
--
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
10 years, 5 months
[JBoss JIRA] (ISPN-3354) Multiple events on the local node with Infinispan 5.3.0-final
by Divya Mehra (JIRA)
[ https://issues.jboss.org/browse/ISPN-3354?page=com.atlassian.jira.plugin.... ]
Divya Mehra updated ISPN-3354:
------------------------------
Labels: 620 (was: jdg620_dm jdg62GAblocker)
> Multiple events on the local node with Infinispan 5.3.0-final
> -------------------------------------------------------------
>
> Key: ISPN-3354
> URL: https://issues.jboss.org/browse/ISPN-3354
> Project: Infinispan
> Issue Type: Bug
> Components: Listeners
> Affects Versions: 5.3.0.Final
> Reporter: Luca Zenti
> Assignee: Mircea Markus
> Labels: 620
> Attachments: TestInfinispanDuplicatedEvents.java
>
>
> After upgrading to Infinispan 5.3.0-final I found a strange "intermittent" problem in my application. Digging a bit deeper, I found out it is due to CacheEntry events raised twice for some keys on the local node (the node where the cache operation is invoked).
> I was able to reproduce the problem and I wrote the attached test case.
> The problem happens regardless of the cluster mode, but only with non-transactional caches. I think this is due to the fact that with transactional caches the events are raised on commit.
> Also, my application used to work with an interceptor rather than an event listener, so I actually found the problem when I saw my interceptor being occasionally executed 3 times with 2 nodes.
> I'm not sure whether the command and the chain of interceptor is really meant to be executed twice on the local node, but the consequent behaviour on the events sounds like a bug.
--
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
10 years, 5 months
[JBoss JIRA] (ISPN-3601) REST cache store has problems with modules and finding classes
by Divya Mehra (JIRA)
[ https://issues.jboss.org/browse/ISPN-3601?page=com.atlassian.jira.plugin.... ]
Divya Mehra updated ISPN-3601:
------------------------------
Labels: 620 (was: jdg62GAblocker)
> REST cache store has problems with modules and finding classes
> --------------------------------------------------------------
>
> Key: ISPN-3601
> URL: https://issues.jboss.org/browse/ISPN-3601
> Project: Infinispan
> Issue Type: Bug
> Components: Server
> Affects Versions: 6.0.0.Alpha4
> Reporter: William Burns
> Assignee: William Burns
> Labels: 620
> Fix For: 6.0.0.Final
>
>
> Found in DR4 as the first release which contains Infinispan 6.0.0.Aplha4 and therefore REST Cache Store + possibility of REST Rolling Upgrades.
> I've experienced problems with starting JDG node using standalone-rest-rolling-upgrade.xml example configuration (for target node).
> Please see report in attachment.
> You can find 2 console outputs of jdg server. The second one is after some changes in modules.xml (in rest cachestore module).
> Details are shown and described in that file.
--
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
10 years, 5 months
[JBoss JIRA] (ISPN-3315) Retry remote get after topology change if all the targets are no longer owners
by Divya Mehra (JIRA)
[ https://issues.jboss.org/browse/ISPN-3315?page=com.atlassian.jira.plugin.... ]
Divya Mehra updated ISPN-3315:
------------------------------
Labels: 620 (was: jdg620_dm jdg62GAblocker)
> Retry remote get after topology change if all the targets are no longer owners
> ------------------------------------------------------------------------------
>
> Key: ISPN-3315
> URL: https://issues.jboss.org/browse/ISPN-3315
> Project: Infinispan
> Issue Type: Bug
> Components: State transfer
> Affects Versions: 5.3.0.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Critical
> Labels: 620
>
> It's possible for a remote get to reach its intended targets only after they are no longer owners, and they don't have the key anymore. If that happens, instead of returning a {{null}} value, the originator should retry on the new owners (possibly in a loop).
> Note that this is different from all the owners leaving the cluster at the same time: in that case retrying on the new owners wouldn't make a difference, because data would be lost anyway.
--
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
10 years, 5 months
[JBoss JIRA] (ISPN-3659) Cache stop should clear thread-local ExtendedRiverMarshaller or their instance caches
by Divya Mehra (JIRA)
[ https://issues.jboss.org/browse/ISPN-3659?page=com.atlassian.jira.plugin.... ]
Divya Mehra updated ISPN-3659:
------------------------------
Labels: 620 (was: jdg620_dm jdg62GAblocker)
> Cache stop should clear thread-local ExtendedRiverMarshaller or their instance caches
> -------------------------------------------------------------------------------------
>
> Key: ISPN-3659
> URL: https://issues.jboss.org/browse/ISPN-3659
> Project: Infinispan
> Issue Type: Bug
> Components: Marshalling
> Affects Versions: 5.3.0.Final, 6.0.0.CR1
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Labels: 620
> Fix For: 6.1.0.Final
>
>
> The fix for ISPN-2372 was incomplete. We now clear the references from the thread-local marshallers to the cache itself, so it can be garbage-collected, but we don't clear the marshallers or their instance caches. If the cache values' object graph is very large, the cached marshallers will use up a lot of memory that could be garbage-collected (assuming the cache was indeed restarted and only one cache instance is running now).
--
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
10 years, 5 months
[JBoss JIRA] (ISPN-3556) When LockControlCommand fails on an owner, the rollback command is not sent
by Divya Mehra (JIRA)
[ https://issues.jboss.org/browse/ISPN-3556?page=com.atlassian.jira.plugin.... ]
Divya Mehra updated ISPN-3556:
------------------------------
Labels: 620 (was: jdg620_dm jdg62GAblocker)
> When LockControlCommand fails on an owner, the rollback command is not sent
> ---------------------------------------------------------------------------
>
> Key: ISPN-3556
> URL: https://issues.jboss.org/browse/ISPN-3556
> Project: Infinispan
> Issue Type: Bug
> Components: Locking and Concurrency
> Affects Versions: 5.2.7.Final, 5.3.0.Final, 6.0.0.Beta1
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Critical
> Labels: 620
>
> If a transaction starts with a {{lock()}} operation and the lock fails on one of the owners (e.g. because of a {{SuspectException}}), the rollback command should still be sent to all the live owners.
> However, because a locked key is only registered in the {{affectedKeys}} collection after a successful lock operation (in {{PessimisticLockingInterceptor.acquireRemoteIfNeeded()}}, the rollback command is not sent to any owners.
> This is in a pessimistic cache. However, looking at the {{OptimisticLockingInterceptor.acquireAllLocks()}} code I think I see a similar problem: it's possible that a key is locked, but the write skew check fails and the key is not added to the {{affectedKeys}} collection. We should always register the key first and attempt to lock it after.
--
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
10 years, 5 months