May 2014 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-4288) JGroups kerberos auth is not able to obtain credentials

by Vojtech Juranek (JIRA)

[ https://issues.jboss.org/browse/ISPN-4288?page=com.atlassian.jira.plugin.... ] Vojtech Juranek resolved ISPN-4288. ----------------------------------- Resolution: Duplicate Issue This is basically a subset of ISPN-4303, so resolving this one as s duplicate. > JGroups kerberos auth is not able to obtain credentials > ------------------------------------------------------- > > Key: ISPN-4288 > URL: https://issues.jboss.org/browse/ISPN-4288 > Project: Infinispan > Issue Type: Bug > Components: Test Suite - Server > Reporter: Vojtech Juranek > Assignee: Mircea Markus > > When trying to use kerberos for authentication between ISPN nodes (which uses JGroups authentication) I get following exception: > {noformat} > Caused by: java.lang.Exception: connecting to channel "clustered" failed > at org.jgroups.JChannel._connect(JChannel.java:564) > at org.jgroups.JChannel.connect(JChannel.java:288) > at org.jgroups.JChannel.connect(JChannel.java:273) > at org.infinispan.remoting.transport.jgroups.JGroupsTransport.startJGroupsChannelIfNeeded(JGroupsTransport.java:198) > ... 27 more > Caused by: java.lang.SecurityException: javax.security.sasl.SaslException: GSS initiate failed [Caused by GSSException: No valid credentials provided (Mechanism level: Failed to find any Kerberos tgt)] > at org.jgroups.protocols.SASL.down(SASL.java:294) > at org.jgroups.protocols.pbcast.STABLE.down(STABLE.java:347) > at org.jgroups.protocols.pbcast.ClientGmsImpl.sendJoinMessage(ClientGmsImpl.java:243) > at org.jgroups.protocols.pbcast.ClientGmsImpl.joinInternal(ClientGmsImpl.java:124) > at org.jgroups.protocols.pbcast.ClientGmsImpl.join(ClientGmsImpl.java:40) > at org.jgroups.protocols.pbcast.GMS.down(GMS.java:1082) > at org.jgroups.protocols.FlowControl.down(FlowControl.java:340) > at org.jgroups.protocols.FlowControl.down(FlowControl.java:340) > at org.jgroups.protocols.FRAG2.down(FRAG2.java:136) > at org.jgroups.protocols.RSVP.down(RSVP.java:142) > at org.jgroups.stack.ProtocolStack.down(ProtocolStack.java:1039) > at org.jgroups.JChannel.down(JChannel.java:785) > at org.jgroups.JChannel._connect(JChannel.java:558) > ... 30 more > Caused by: javax.security.sasl.SaslException: GSS initiate failed [Caused by GSSException: No valid credentials provided (Mechanism level: Failed to find any Kerberos tgt)] > at com.sun.security.sasl.gsskerb.GssKrb5Client.evaluateChallenge(GssKrb5Client.java:212) [rt.jar:1.7.0_45] > at org.jgroups.auth.sasl.SaslClientContext.addHeader(SaslClientContext.java:84) > at org.jgroups.protocols.SASL.down(SASL.java:289) > ... 42 more > Caused by: GSSException: No valid credentials provided (Mechanism level: Failed to find any Kerberos tgt) > at sun.security.jgss.krb5.Krb5InitCredential.getInstance(Krb5InitCredential.java:147) [rt.jar:1.7.0_45] > at sun.security.jgss.krb5.Krb5MechFactory.getCredentialElement(Krb5MechFactory.java:121) [rt.jar:1.7.0_45] > at sun.security.jgss.krb5.Krb5MechFactory.getMechanismContext(Krb5MechFactory.java:187) [rt.jar:1.7.0_45] > at sun.security.jgss.GSSManagerImpl.getMechanismContext(GSSManagerImpl.java:223) [rt.jar:1.7.0_45] > at sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:212) [rt.jar:1.7.0_45] > at sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:179) [rt.jar:1.7.0_45] > at com.sun.security.sasl.gsskerb.GssKrb5Client.evaluateChallenge(GssKrb5Client.java:193) [rt.jar:1.7.0_45] > ... 44 more > {noformat} > The test and setup can be downloaded [here|https://github.com/vjuranek/infinispan/tree/ISPN-4273]. Not completely sure, if it's a bug or some kerberos setup issue, but it failed also in case when I tried to use already running kerberos (not ApacheDS run in within the test). -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-800) Infinispan inside OSGI

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-800?page=com.atlassian.jira.plugin.s... ] Galder Zamarreño updated ISPN-800: ---------------------------------- Git Pull Request: https://github.com/infinispan/infinispan/pull/2497, https://github.com/infinispan/infinispan/pull/2553 (was: https://github.com/infinispan/infinispan/pull/2497) > Infinispan inside OSGI > ---------------------- > > Key: ISPN-800 > URL: https://issues.jboss.org/browse/ISPN-800 > Project: Infinispan > Issue Type: Feature Request > Components: Core > Reporter: Luca Stancapiano > Assignee: Ion Savin > > We need to import infinispan inside a OSGI repository. Tests are made with Felix. > I added the configuration to use infinispan inside a osgi repository. We need to ignore all listed dependencies. With this configuration we can install infinispan-core.jar inside OSGI. Its achievement will be as a base installation here: https://github.com/flashboss/infinispan > I added the Import-Package because you are forced to put manually in Felix all dependencies as jgroups, jboss marshalling, jcip, all apache commons. I've seen infinispan core working by default without all those libraries, so I think the same achievement should be replicated in OSGI. > Inside the Import-Package tag I excluded those libraries so Infinispan core can be started in default mode without errors. If we want use the replication in OSGI, it is enough add manually the other packages (jgroups.jar etc etc) > Actually the core bundle can be installed. But to be used it needs theese projects be installed as osgi bundles: > jboss transaction api 1.0.1.GA > We patched it. There is a new OSGI version here: https://repository.jboss.org/nexus/content/groups/public/org/jboss/spec/j... ) > jgroups 2.10.1.GA > (it's a osgi bundle since the 3.x version) > river 1.2.3.GA > (opened an issue for marshalling 1.4.0 in JBMAR-118 and https://github.com/flashboss/jboss-marshalling/blob/master/river/pom.xml ) > marshalling-api 1.2.3.GA > (opened an issue for marshalling 1.4.0 in JBMAR-118 and https://github.com/flashboss/jboss-marshalling/blob/master/api/pom.xml ) > jboss logging spi 2.0.5.GA > (added a jira issue in JBLOGGING-51 . It could be fixed in the 2.2.0.CR2 version. Fixed in the 3.x version) > rhq plugin annotations 1.4.0.B01 > (opened a feature request in https://bugzilla.redhat.com/show_bug.cgi?id=657754 ) > i18nlog 1.0.9 > (sent a patch in https://sourceforge.net/projects/i18nlog . It could become a OSGI bundle in the 1.0.10 version. Waiting for a response. Fixed in 1.15) > log4j 1.2.16 > (that's ok...it is a osgi bundle ;)) > jcip-annotations 1.0 > (I sent a patch via email to brian(a)briangoetz.com and a post in http://tembrel.blogspot.com. Sent the patch in concurrency-interest(a)cs.oswego.edu too. They responded to me. There is a OSGI version with a different artifact name. I changed the dependency in the pom.xml of the parent project) > We should make sure proper 'Import-Package' property is specified in the MANIFEST.MF so that: > 1- it fails to load obviously when there's any missing bundles that are essential in using the very core functionality of Infinispan. > 2 - it does not fail due to the dependency that is not really essential. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-4304) Speed up execution of OSGi tests

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-4304?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-4304: ----------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 7.0.0.Beta1 Resolution: Done > Speed up execution of OSGi tests > -------------------------------- > > Key: ISPN-4304 > URL: https://issues.jboss.org/browse/ISPN-4304 > Project: Infinispan > Issue Type: Task > Components: Test Suite - Core > Affects Versions: 7.0.0.Alpha4 > Reporter: Martin Gencur > Assignee: Martin Gencur > Fix For: 7.0.0.Beta1 > > > * Start the Karaf container only once and run all the tests instead of starting the container before each test class > * place the OSGi tests into the default Maven profile -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-4315) Automatically enable JDT Annotation Processor support in Eclipse

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-4315?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-4315: ----------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Automatically enable JDT Annotation Processor support in Eclipse > ---------------------------------------------------------------- > > Key: ISPN-4315 > URL: https://issues.jboss.org/browse/ISPN-4315 > Project: Infinispan > Issue Type: Task > Components: Build process > Reporter: Sanne Grinovero > Assignee: Sanne Grinovero > Priority: Trivial > Fix For: 7.0.0.Beta1 > > > This is finally possible to automate in Eclipse Luna using a property in the project to configure the external Me2 plugin. > Kudos to Fred Bricon! > https://github.com/jbosstools/m2e-apt/issues/26 -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-4293) PR for ISPN-4137 causes a performance drop in repl tx mode

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-4293?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-4293: ----------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 7.0.0.Beta1 Resolution: Done > PR for ISPN-4137 causes a performance drop in repl tx mode > ---------------------------------------------------------- > > Key: ISPN-4293 > URL: https://issues.jboss.org/browse/ISPN-4293 > Project: Infinispan > Issue Type: Bug > Reporter: Jakub Markos > Assignee: Dan Berindei > Fix For: 7.0.0.Beta1 > > > See the last graph here for example http://jawa36.mw.lab.eng.brq.redhat.com:8080/repo/reports/metric/saved/te... > Caused by this commit https://github.com/infinispan/infinispan/commit/8be817a193699ce8b59aec8da... -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-4137) Transaction executed multiple times due to forwarded CommitCommand

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-4137?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-4137: ----------------------------------- Fix Version/s: 7.0.0.Beta1 > Transaction executed multiple times due to forwarded CommitCommand > ------------------------------------------------------------------ > > Key: ISPN-4137 > URL: https://issues.jboss.org/browse/ISPN-4137 > Project: Infinispan > Issue Type: Bug > Components: State Transfer, Transactions > Reporter: Radim Vansa > Assignee: Dan Berindei > Priority: Critical > Labels: 630betablocker > Fix For: 7.0.0.Beta1 > > > When the {{StateTransferInterceptor}} forwards a CommitCommand for the new topology, multiple CommitCommands may be broadcast across the cluster. If the command (forwarded already from originator) times out, the transaction may be correctly finished by the first one and the application considers TX as succeeded (useSynchronizations=true), although one more Rollback is sent as well. > Then, again in STI, when the CommitCommand arrives with higher topologyId than the one used for the first TX execution, another artificial Prepare (followed by the commit) is executed - see {{STI.visitCommitCommand}}. > However, this execution may be delayed a lot and originator may have already executed another TX on the same entries. Then, this forwarded Commit will overwrite the already updated entries, causing inconsistency of data. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-4207) Lock container ignores key Equivalence

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4207?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4207: ----------------------------------------------- Martin Gencur <mgencur(a)redhat.com> changed the Status of [bug 1093723|https://bugzilla.redhat.com/show_bug.cgi?id=1093723] from ON_QA to VERIFIED > Lock container ignores key Equivalence > -------------------------------------- > > Key: ISPN-4207 > URL: https://issues.jboss.org/browse/ISPN-4207 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 7.0.0.Alpha3 > Reporter: Pedro Ruivo > Assignee: Pedro Ruivo > Fix For: 7.0.0.Alpha4 > > > AbstractPerEntryLockContainer uses an EquivalentConcurrentHashMapV8 to map keys to lock. It can create issues when the key is a byte array. > edit: the Stripped*LockContainer suffers from the same problem since it uses object.hashCode(). -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-3916) Expiration reaper is not enabled until lifespan or max-idle is set

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-3916?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-3916: ----------------------------------------------- Martin Gencur <mgencur(a)redhat.com> changed the Status of [bug 1083147|https://bugzilla.redhat.com/show_bug.cgi?id=1083147] from ON_QA to VERIFIED > Expiration reaper is not enabled until lifespan or max-idle is set > ------------------------------------------------------------------ > > Key: ISPN-3916 > URL: https://issues.jboss.org/browse/ISPN-3916 > Project: Infinispan > Issue Type: Bug > Components: Server > Affects Versions: 6.0.1.Final > Reporter: Wolf-Dieter Fink > Assignee: Mircea Markus > Labels: 630 > Fix For: 7.0.0.Alpha1, 7.0.0.Final > > > If a cache is added where entities are with and without expiration by external processes it is expected that the reaper purge the data from memory and datastore. > As the reaper is only enabled for the cache if the element > <expiration interval="millis" lifespan="millis" max-idle="millis"/> > has one of the attributes lifespan or max-idle set to a value >0 > The expired entities will not be removed from the memory or datastore. > This is an unexpected behaviour and might end in a memory bottleneck if a server is up for a long time. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-4239) Commands received before the first topology where the local node is a member are not ignored

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4239?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4239: ----------------------------------------------- Radim Vansa <rvansa(a)redhat.com> changed the Status of [bug 1096073|https://bugzilla.redhat.com/show_bug.cgi?id=1096073] from ON_QA to VERIFIED > Commands received before the first topology where the local node is a member are not ignored > -------------------------------------------------------------------------------------------- > > Key: ISPN-4239 > URL: https://issues.jboss.org/browse/ISPN-4239 > Project: Infinispan > Issue Type: Bug > Components: Core, State Transfer > Affects Versions: 6.0.2.Final, 7.0.0.Alpha3 > Reporter: Dan Berindei > Assignee: Dan Berindei > Labels: testsuite_stability > Fix For: 7.0.0.Alpha4, 7.0.0.Final > > > The ISPN-3731 fix was supposed to prevent a joiner from running commands broadcasted by other members before the joiner became a member in the cache topology. > However, the fix was incomplete, and commands received before the joiner became a member were still executed. This is causing failures in {{StateTransferReplicationQueueTest}}, which is issuing a put(k, v) and a remove(k) and expecting the key to be removed. It can happen that the put(k, v) command is executed before the joiner becomes a member, but the remove(k) command is rejected because it came from a topology where the joiner was not a member: > {noformat} > 12:54:41,412 TRACE (testng-StateTransferReplicationQueueTest:nbst-replqueue) [StateTransferManagerImpl] Installing new cache topology CacheTopology{id=3, currentCH=ReplicatedConsistentHash{members=[StateTransferReplicationQueueTest-NodeA-8686], numSegments=1, primaryOwners=[0]}, pendingCH=null} on cache nbst-replqueue > 12:54:41,412 TRACE (testng-StateTransferReplicationQueueTest:nbst-replqueue) [StateTransferLockImpl] Signalling topology 3 is installed > 12:54:41,433 TRACE (Incoming-1,StateTransferReplicationQueueTest-NodeC-12962:) [InboundInvocationHandlerImpl] Calling perform() on MultipleRpcCommand{commands=[..., PrepareCommand {modifications=[PutKeyValueCommand{key=test58, value=org.infinispan.statetransfer.StateTransferReplicationQueueTest$PojoValue@59, flags=null, putIfAbsent=false, valueMatcher=MATCH_ALWAYS, metadata=EmbeddedMetadata{version=null}, successful=true}], onePhaseCommit=true, gtx=GlobalTransaction:<StateTransferReplicationQueueTest-NodeA-8686>:6969:local, cacheName='nbst-replqueue', topologyId=3}], cacheName='nbst-replqueue'} > 12:54:41,439 TRACE (remote-thread-StateTransferReplicationQueueTest-NodeC-p3980-t1:nbst-replqueue) [StateTransferManagerImpl] Installing new cache topology CacheTopology{id=4, currentCH=ReplicatedConsistentHash{members=[StateTransferReplicationQueueTest-NodeA-8686], numSegments=1, primaryOwners=[0]}, pendingCH=ReplicatedConsistentHash{members=[StateTransferReplicationQueueTest-NodeA-8686, StateTransferReplicationQueueTest-NodeC-12962], numSegments=1, primaryOwners=[0]}} on cache nbst-replqueue > 12:54:41,439 TRACE (remote-thread-StateTransferReplicationQueueTest-NodeC-p3980-t1:nbst-replqueue) [StateTransferManagerImpl] This is the first topology in which the local node is a member > 12:54:41,462 TRACE (Incoming-1,StateTransferReplicationQueueTest-NodeC-12962:nbst-replqueue) [ReadCommittedEntry] Updating entry (key=test58 removed=false valid=true changed=true created=true loaded=false value=org.infinispan.statetransfer.StateTransferReplicationQueueTest$PojoValue@59 metadata=EmbeddedMetadata{version=null}, providedMetadata=null) > 12:54:41,491 TRACE (Incoming-1,StateTransferReplicationQueueTest-NodeC-12962:) [CommandAwareRpcDispatcher] Attempting to execute command: MultipleRpcCommand{commands=[PrepareCommand {modifications=[RemoveCommand{key=test58, value=null, flags=null, valueMatcher=MATCH_ALWAYS}], onePhaseCommit=true, gtx=GlobalTransaction:<StateTransferReplicationQueueTest-NodeA-8686>:6970:local, cacheName='nbst-replqueue', topologyId=3}, ...], cacheName='nbst-replqueue'} [sender=StateTransferReplicationQueueTest-NodeA-8686] > 12:54:41,493 TRACE (Incoming-1,StateTransferReplicationQueueTest-NodeC-12962:) [StateTransferLockImpl] Waiting for transaction data for topology 3, current topology is 3 > 12:54:41,493 TRACE (Incoming-1,StateTransferReplicationQueueTest-NodeC-12962:) [InboundInvocationHandlerImpl] Ignoring command sent before the local node was a member (command topology id is 3) > {noformat} -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-4131) Lock acquired forever with delayed PrepareCommand

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4131?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4131: ----------------------------------------------- Radim Vansa <rvansa(a)redhat.com> changed the Status of [bug 1080314|https://bugzilla.redhat.com/show_bug.cgi?id=1080314] from ON_QA to VERIFIED > Lock acquired forever with delayed PrepareCommand > ------------------------------------------------- > > Key: ISPN-4131 > URL: https://issues.jboss.org/browse/ISPN-4131 > Project: Infinispan > Issue Type: Bug > Components: Transactions > Affects Versions: 6.0.2.Final, 7.0.0.Alpha1 > Reporter: Radim Vansa > Assignee: Dan Berindei > Priority: Critical > Labels: 630betablocker > Fix For: 7.0.0.Beta1, 7.0.0.Final > > > Distributed transactional cache: > 1. A sends Prepare to B > 2. B receives Prepare, but due to ongoing ST it is blocked > 3. B replication timeout elapses > 4. B sends Rollback, this does not find the TX as Prepare was not executed yet. The transaction is put into completedTransactions. > 5. Completed transactions timeout elapses. This is by default 15 seconds, way shorter than ST timeout (due to which the Prepare was blocked) > 6. Prepare is executed on B, acquiring lock on K > Nobody will rollback the TX as originator thinks it was already rolled back. > Result: key K will be locked forever, all attempts to update/remove it will fail. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years, 1 month

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues May 2014