[JBoss JIRA] (ISPN-3838) L1 entry added by ST when already invalidated
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-3838?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-3838:
-----------------------------------------------
Dave Stahl <dstahl(a)redhat.com> changed the Status of [bug 1043434|https://bugzilla.redhat.com/show_bug.cgi?id=1043434] from VERIFIED to CLOSED
> L1 entry added by ST when already invalidated
> ---------------------------------------------
>
> Key: ISPN-3838
> URL: https://issues.jboss.org/browse/ISPN-3838
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 6.0.0.Final
> Reporter: Radim Vansa
> Assignee: William Burns
> Priority: Critical
> Labels: 620
> Fix For: 7.0.0.Alpha4, 7.0.0.Final
>
>
> Non-transactional cache with L1 enabled. Node A is losing ownership of an entry, the entry is not removed during ST but is going to L1.
> 1. ST builds the invalidation command, EntryWrapping interceptor starts committing all the entries
> 2. Write on primary owner (B) occurs
> 3. A gets the InvalidateL1Command, removes the ImmortalCacheEntry from data container (as it does not own the entry anymore)
> 4. The ST invalidation command commits the MortalCacheEntry with old value, storing it into the data container.
> Result: Outdated value is in L1 cache.
> As the entry is not locked during the ST, it can be committed as MortalCacheEntry only if it was not changed (removed and possibly then cached again with different value).
> (I understand that this wouldn't be easy to implement as the check is not to be executed in perform, but during the actual commit - and atomically in the container.)
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months
[JBoss JIRA] (ISPN-4409) LevelDBCacheStoreIT fails to initialise with com.arjuna.ats.arjuna.exceptions.FatalError
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-4409?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-4409:
-----------------------------------------------
Dave Stahl <dstahl(a)redhat.com> changed the Status of [bug 1108089|https://bugzilla.redhat.com/show_bug.cgi?id=1108089] from VERIFIED to CLOSED
> LevelDBCacheStoreIT fails to initialise with com.arjuna.ats.arjuna.exceptions.FatalError
> ----------------------------------------------------------------------------------------
>
> Key: ISPN-4409
> URL: https://issues.jboss.org/browse/ISPN-4409
> Project: Infinispan
> Issue Type: Bug
> Components: Test Suite - Server
> Reporter: Galder Zamarreño
> Assignee: Galder Zamarreño
> Fix For: 7.0.0.Alpha5
>
>
> The LevelDBCacheStoreIT fails to start with an error resulting from initialising the server side cache marshaller. The way the cache manager is created is not correct. You might as well just use the same marshaller as for the client.
> Even if you really need a cache's marshaller, you should get it via an injected cache rather than initialising a cache from scratch.
> {code}com.arjuna.ats.arjuna.exceptions.FatalError: null
> at com.arjuna.ats.internal.jts.ORBManager.getPOA(ORBManager.java:96)
> at com.arjuna.ats.internal.jts.OTSImpleManager.<clinit>(OTSImpleManager.java:300)
> at com.arjuna.ats.internal.jta.transaction.jts.TransactionImple.getTransaction(TransactionImple.java:1146)
> at com.arjuna.ats.internal.jta.transaction.jts.TransactionManagerImple.getTransaction(TransactionManagerImple.java:69)
> at org.infinispan.cache.impl.CacheImpl.getOngoingTransaction(CacheImpl.java:1414)
> at org.infinispan.cache.impl.CacheImpl.getInvocationContextForRead(CacheImpl.java:592)
> at org.infinispan.cache.impl.CacheImpl.keySet(CacheImpl.java:474)
> at org.infinispan.cache.impl.CacheImpl.keySet(CacheImpl.java:469)
> at org.infinispan.registry.impl.ClusterRegistryImpl.keys(ClusterRegistryImpl.java:81)
> at org.infinispan.query.remote.ProtobufMetadataManager.ensureInit(ProtobufMetadataManager.java:67)
> at org.infinispan.query.remote.ProtobufMetadataManager.getSerializationContext(ProtobufMetadataManager.java:132)
> at org.infinispan.query.remote.LifecycleManager.cacheStarting(LifecycleManager.java:114)
> at org.infinispan.factories.ComponentRegistry.notifyCacheStarting(ComponentRegistry.java:228)
> at org.infinispan.factories.ComponentRegistry.start(ComponentRegistry.java:214)
> at org.infinispan.cache.impl.CacheImpl.start(CacheImpl.java:699)
> at org.infinispan.manager.DefaultCacheManager.wireAndStartCache(DefaultCacheManager.java:573)
> at org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:528)
> at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:408)
> at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:381)
> at org.infinispan.server.test.cs.leveldb.LevelDBCacheStoreIT.getServerMarshaller(LevelDBCacheStoreIT.java:190)
> at org.infinispan.server.test.cs.leveldb.LevelDBCacheStoreIT.<clinit>(LevelDBCacheStoreIT.java:67)
> « Hide stacktrace{code}
> The fix gets past this particular error but it still shows this afterwards:
> {code}Caused by: javax.management.InstanceNotFoundException: jboss.infinispan:type=Server,name=HotRod,component=Transport{code}
> Tristan is working on this...
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months
[JBoss JIRA] (ISPN-4366) RHQ JMX plugin provides unstable availability check with extensive deployments
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-4366?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-4366:
-----------------------------------------------
Dave Stahl <dstahl(a)redhat.com> changed the Status of [bug 1105680|https://bugzilla.redhat.com/show_bug.cgi?id=1105680] from VERIFIED to CLOSED
> RHQ JMX plugin provides unstable availability check with extensive deployments
> ------------------------------------------------------------------------------
>
> Key: ISPN-4366
> URL: https://issues.jboss.org/browse/ISPN-4366
> Project: Infinispan
> Issue Type: Bug
> Components: JMX, reporting and management
> Affects Versions: 7.0.0.Alpha4
> Reporter: Tomas Sykora
> Assignee: William Burns
> Labels: 63gablocker, rhq
>
> Availability check was greatly improved by changes introduced in https://issues.jboss.org/browse/ISPN-4236 and https://issues.jboss.org/browse/ISPN-4235.
> This works pretty well in case of one deployment of an embedded application on one application server, which is monitored by an agent.
> However, when we try to monitor more deployments by the same agent (app servers, switched ports, each one with its own deployment), the process of availability checking is unstable.
> Cache managers / caches... are reported repeatedly UP and DOWN, UP and DOWN. See linked bugzilla with attached screenshots depicting this issue.
> I suspect higher number of MBeans to cause this problem.
> When we deploy on 2 servers, one of them for example was able to stabilize availability check after 2 hours and then, it stays UP.
> During deployment in 2xdomain mode = 4 servers, availability check "is skipping, jumping" UP, DOWN, UP, DOWN... etc. again, see screenshots in BZ.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months
[JBoss JIRA] (ISPN-4354) Unable to use custom keys/values with clustered caches in OSGi
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-4354?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-4354:
-----------------------------------------------
Dave Stahl <dstahl(a)redhat.com> changed the Status of [bug 1105157|https://bugzilla.redhat.com/show_bug.cgi?id=1105157] from VERIFIED to CLOSED
> Unable to use custom keys/values with clustered caches in OSGi
> --------------------------------------------------------------
>
> Key: ISPN-4354
> URL: https://issues.jboss.org/browse/ISPN-4354
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 7.0.0.Alpha4
> Reporter: Martin Gencur
> Assignee: Ion Savin
> Priority: Critical
> Labels: 630
> Attachments: custom-objects-stacktrace.txt, CustomObjectsReplicatedCacheTest.java
>
>
> JGroups cannot find custom classes that are used as keys or values. The stacktrace looks like this:
> {code}
> Caused by: java.lang.ClassNotFoundException: org.infinispan.it.osgi.tx.CustomObjectsReplicatedCacheTest$Person not found by org.jgroups [61]
> at org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1460)
> at org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:72)
> at org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1843)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:356)
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:266)
> at org.jboss.marshalling.AbstractClassResolver.loadClass(AbstractClassResolver.java:131)
> at org.jboss.marshalling.AbstractClassResolver.resolveClass(AbstractClassResolver.java:112)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadClassDescriptor(RiverUnmarshaller.java:943)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1239)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:272)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209)
> at org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:41)
> at org.infinispan.container.entries.ImmortalCacheEntry$Externalizer.readObject(ImmortalCacheEntry.java:152)
> at org.infinispan.container.entries.ImmortalCacheEntry$Externalizer.readObject(ImmortalCacheEntry.java:142)
> at org.infinispan.marshall.core.ExternalizerTable$ExternalizerAdapter.readObject(ExternalizerTable.java:406)
> at org.infinispan.marshall.core.ExternalizerTable.readObject(ExternalizerTable.java:213)
> at org.infinispan.marshall.core.JBossMarshaller$ExternalizerTableProxy.readObject(JBossMarshaller.java:148)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:351)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209)
> at org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:41)
> at org.infinispan.marshall.exts.ListExternalizer.readObject(ListExternalizer.java:62)
> at org.infinispan.marshall.exts.ListExternalizer.readObject(ListExternalizer.java:26)
> at org.infinispan.marshall.core.ExternalizerTable$ExternalizerAdapter.readObject(ExternalizerTable.java:406)
> at org.infinispan.marshall.core.ExternalizerTable.readObject(ExternalizerTable.java:213)
> at org.infinispan.marshall.core.JBossMarshaller$ExternalizerTableProxy.readObject(JBossMarshaller.java:148)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:351)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209)
> at org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:41)
> at org.infinispan.statetransfer.StateChunk$Externalizer.readObject(StateChunk.java:88)
> at org.infinispan.statetransfer.StateChunk$Externalizer.readObject(StateChunk.java:65)
> at org.infinispan.marshall.core.ExternalizerTable$ExternalizerAdapter.readObject(ExternalizerTable.java:406)
> at org.infinispan.marshall.core.ExternalizerTable.readObject(ExternalizerTable.java:213)
> at org.infinispan.marshall.core.JBossMarshaller$ExternalizerTableProxy.readObject(JBossMarshaller.java:148)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:351)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209)
> at org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:41)
> at org.infinispan.marshall.exts.ListExternalizer.readObject(ListExternalizer.java:62)
> at org.infinispan.marshall.exts.ListExternalizer.readObject(ListExternalizer.java:26)
> at org.infinispan.marshall.core.ExternalizerTable$ExternalizerAdapter.readObject(ExternalizerTable.java:406)
> at org.infinispan.marshall.core.ExternalizerTable.readObject(ExternalizerTable.java:213)
> at org.infinispan.marshall.core.JBossMarshaller$ExternalizerTableProxy.readObject(JBossMarshaller.java:148)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:351)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209)
> at org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:41)
> at org.infinispan.marshall.exts.ReplicableCommandExternalizer.readParameters(ReplicableCommandExternalizer.java:100)
> at org.infinispan.marshall.exts.CacheRpcCommandExternalizer.readObject(CacheRpcCommandExternalizer.java:153)
> at org.infinispan.marshall.exts.CacheRpcCommandExternalizer.readObject(CacheRpcCommandExternalizer.java:64)
> at org.infinispan.marshall.core.ExternalizerTable$ExternalizerAdapter.readObject(ExternalizerTable.java:406)
> at org.infinispan.marshall.core.ExternalizerTable.readObject(ExternalizerTable.java:213)
> at org.infinispan.marshall.core.JBossMarshaller$ExternalizerTableProxy.readObject(JBossMarshaller.java:148)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:351)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209)
> at org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:41)
> at org.infinispan.commons.marshall.jboss.AbstractJBossMarshaller.objectFromObjectStream(AbstractJBossMarshaller.java:135)
> at org.infinispan.marshall.core.VersionAwareMarshaller.objectFromByteBuffer(VersionAwareMarshaller.java:101)
> at org.infinispan.commons.marshall.AbstractDelegatingMarshaller.objectFromByteBuffer(AbstractDelegatingMarshaller.java:80)
> at org.infinispan.remoting.transport.jgroups.MarshallerAdapter.objectFromBuffer(MarshallerAdapter.java:28)
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.handle(CommandAwareRpcDispatcher.java:204)
> ... 24 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months
[JBoss JIRA] (ISPN-4669) Loading LDAP roles fails when some principal hasn't LDAP record
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-4669?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-4669:
-----------------------------------------------
Dave Stahl <dstahl(a)redhat.com> changed the Status of [bug 1134085|https://bugzilla.redhat.com/show_bug.cgi?id=1134085] from VERIFIED to CLOSED
> Loading LDAP roles fails when some principal hasn't LDAP record
> ---------------------------------------------------------------
>
> Key: ISPN-4669
> URL: https://issues.jboss.org/browse/ISPN-4669
> Project: Infinispan
> Issue Type: Bug
> Components: Server
> Reporter: Vojtech Juranek
> Assignee: Tristan Tarrant
> Fix For: 7.0.0.Beta2, 7.0.0.Final
>
>
> In server mode, when loading the roles from LDAP (e.g. scenario GSSAPI authentization and authorization is delegate to LDAP), it fails with following exception when some principal (typically {{InetAddressPrincipal}}) hasn't a record in LDAP:
> {noformat}
> Caused by: java.lang.SecurityException: JDGS010022: Cannot retrieve authorization information for user admin(a)INFINISPAN.ORG
> at org.infinispan.server.endpoint.subsystem.EndpointServerAuthenticationProvider$GSSAPIEndpointAuthorizingCallbackHandler.getSubjectUserInfo(EndpointServerAuthenticationProvider.java:96) [infinispan-server-endpoints-7.0.0-SNAPSHOT.
> jar:7.0.0-SNAPSHOT]
> at org.infinispan.server.hotrod.Decoder2x$.customReadHeader(Decoder2x.scala:238) [infinispan.jar:7.0.0-SNAPSHOT]
> at org.infinispan.server.hotrod.HotRodDecoder.customDecodeHeader(HotRodDecoder.scala:152) [infinispan.jar:7.0.0-SNAPSHOT]
> at org.infinispan.server.core.AbstractProtocolDecoder.decodeHeader(AbstractProtocolDecoder.scala:148) [infinispan.jar:7.0.0-SNAPSHOT]
> at org.infinispan.server.core.AbstractProtocolDecoder.secureDecodeDispatch(AbstractProtocolDecoder.scala:96) [infinispan.jar:7.0.0-SNAPSHOT]
> ... 14 more
> Caused by: java.io.IOException: javax.naming.NamingException: JBAS015231: User '127.0.0.1' not found in directory.
> at org.jboss.as.domain.management.security.LdapSubjectSupplementalService$LdapSubjectSupplemental.supplementSubject(LdapSubjectSupplementalService.java:171) [wildfly-domain-management-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.as.domain.management.security.SecurityRealmService$1.createSubjectUserInfo(SecurityRealmService.java:200) [wildfly-domain-management-8.1.0.Final.jar:8.1.0.Final]
> at org.infinispan.server.endpoint.subsystem.EndpointServerAuthenticationProvider$GSSAPIEndpointAuthorizingCallbackHandler.getSubjectUserInfo(EndpointServerAuthenticationProvider.java:94) [infinispan-server-endpoints-7.0.0-SNAPSHOT.jar:7.0.0-SNAPSHOT]
> ... 18 more
> Caused by: javax.naming.NamingException: JBAS015231: User '127.0.0.1' not found in directory.
> at org.jboss.as.domain.management.security.LdapUserSearcherFactory$LdapUserSearcherImpl.search(LdapUserSearcherFactory.java:130) [wildfly-domain-management-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.as.domain.management.security.LdapUserSearcherFactory$LdapUserSearcherImpl.search(LdapUserSearcherFactory.java:67) [wildfly-domain-management-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.as.domain.management.security.LdapCacheService$NoCacheCache.search(LdapCacheService.java:223) [wildfly-domain-management-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.as.domain.management.security.LdapSubjectSupplementalService$LdapSubjectSupplemental.loadGroups(LdapSubjectSupplementalService.java:184) [wildfly-domain-management-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.as.domain.management.security.LdapSubjectSupplementalService$LdapSubjectSupplemental.supplementSubject(LdapSubjectSupplementalService.java:163) [wildfly-domain-management-8.1.0.Final.jar:8.1.0.Final]
> ... 20 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months