[JBoss JIRA] (ISPN-4298) HotRod kerberos auth doesn't see the ticket when creating RemoteCachManager
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-4298?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-4298:
----------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/infinispan/infinispan/pull/2566
> HotRod kerberos auth doesn't see the ticket when creating RemoteCachManager
> ---------------------------------------------------------------------------
>
> Key: ISPN-4298
> URL: https://issues.jboss.org/browse/ISPN-4298
> Project: Infinispan
> Issue Type: Bug
> Components: Server
> Reporter: Vojtech Juranek
> Assignee: Mircea Markus
>
> When HR client obtains initial GSSAPI challenge (usually when creating {{RemoteCachManager}}), it fails with
> {noformat}
> 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)
> at org.infinispan.client.hotrod.impl.transport.tcp.SaslTransportObjectFactory.makeObject(SaslTransportObjectFactory.java:67)
> at org.infinispan.client.hotrod.impl.transport.tcp.SaslTransportObjectFactory.makeObject(SaslTransportObjectFactory.java:25)
> at org.apache.commons.pool.impl.GenericKeyedObjectPool.borrowObject(GenericKeyedObjectPool.java:1220)
> at org.infinispan.client.hotrod.impl.transport.tcp.TcpTransportFactory.borrowTransportFromPool(TcpTransportFactory.java:306)
> ... 109 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)
> at sun.security.jgss.krb5.Krb5MechFactory.getCredentialElement(Krb5MechFactory.java:121)
> at sun.security.jgss.krb5.Krb5MechFactory.getMechanismContext(Krb5MechFactory.java:187)
> at sun.security.jgss.GSSManagerImpl.getMechanismContext(GSSManagerImpl.java:223)
> at sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:212)
> at sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:179)
> at com.sun.security.sasl.gsskerb.GssKrb5Client.evaluateChallenge(GssKrb5Client.java:193)
> ... 113 more
> {noformat}
> When the code is wrapped by {{PrivilegedExceptionAction}}, e.g.
> {code}
> final Configuration config = getRemoteCacheManagerConfig(subj);
> Subject.doAs(subj, new PrivilegedExceptionAction<Void>() {
> public Void run() throws Exception {
> remoteCacheManager = new RemoteCacheManager(config, true);
> return null;
> }
> });
> {code}
> everything works fine
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
10 years, 5 months
[JBoss JIRA] (ISPN-4298) HotRod kerberos auth doesn't see the ticket when creating RemoteCachManager
by Vojtech Juranek (JIRA)
Vojtech Juranek created ISPN-4298:
-------------------------------------
Summary: HotRod kerberos auth doesn't see the ticket when creating RemoteCachManager
Key: ISPN-4298
URL: https://issues.jboss.org/browse/ISPN-4298
Project: Infinispan
Issue Type: Bug
Components: Server
Reporter: Vojtech Juranek
Assignee: Mircea Markus
When HR client obtains initial GSSAPI challenge (usually when creating {{RemoteCachManager}}), it fails with
{noformat}
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)
at org.infinispan.client.hotrod.impl.transport.tcp.SaslTransportObjectFactory.makeObject(SaslTransportObjectFactory.java:67)
at org.infinispan.client.hotrod.impl.transport.tcp.SaslTransportObjectFactory.makeObject(SaslTransportObjectFactory.java:25)
at org.apache.commons.pool.impl.GenericKeyedObjectPool.borrowObject(GenericKeyedObjectPool.java:1220)
at org.infinispan.client.hotrod.impl.transport.tcp.TcpTransportFactory.borrowTransportFromPool(TcpTransportFactory.java:306)
... 109 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)
at sun.security.jgss.krb5.Krb5MechFactory.getCredentialElement(Krb5MechFactory.java:121)
at sun.security.jgss.krb5.Krb5MechFactory.getMechanismContext(Krb5MechFactory.java:187)
at sun.security.jgss.GSSManagerImpl.getMechanismContext(GSSManagerImpl.java:223)
at sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:212)
at sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:179)
at com.sun.security.sasl.gsskerb.GssKrb5Client.evaluateChallenge(GssKrb5Client.java:193)
... 113 more
{noformat}
When the code is wrapped by {{PrivilegedExceptionAction}}, e.g.
{code}
final Configuration config = getRemoteCacheManagerConfig(subj);
Subject.doAs(subj, new PrivilegedExceptionAction<Void>() {
public Void run() throws Exception {
remoteCacheManager = new RemoteCacheManager(config, true);
return null;
}
});
{code}
everything works fine
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
10 years, 5 months
[JBoss JIRA] (ISPN-4160) Do not allow the state transfer chunk size to be <= 0
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-4160?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-4160:
-----------------------------------------------
Alan Field <afield(a)redhat.com> changed the Status of [bug 1096466|https://bugzilla.redhat.com/show_bug.cgi?id=1096466] from ON_QA to VERIFIED
> Do not allow the state transfer chunk size to be <= 0
> -----------------------------------------------------
>
> Key: ISPN-4160
> URL: https://issues.jboss.org/browse/ISPN-4160
> Project: Infinispan
> Issue Type: Task
> Components: Configuration, State Transfer
> Affects Versions: 7.0.0.Alpha1
> Reporter: Dan Berindei
> Assignee: Vladimir Blagojevic
> Fix For: 7.0.0.Alpha4
>
>
> The state transfer chunk size is used in other places as well, and the case of {{chunkSize <= 0}} has to be handled everywhere independently. StateTransferConfigurationBuilder should validate that {{chunkSize > 0}}, so that users of the chunk size setting don't need a default value.
> The users will still be able to force state transfer to transfer everything at once with {{chunkSize == Integer.MAX_VALUE}}.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
10 years, 5 months
[JBoss JIRA] (ISPN-4240) Migrate one intermediate key/value per maxCollectorSize threshold
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-4240?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-4240:
-----------------------------------------------
Alan Field <afield(a)redhat.com> changed the Status of [bug 1096467|https://bugzilla.redhat.com/show_bug.cgi?id=1096467] from ON_QA to VERIFIED
> Migrate one intermediate key/value per maxCollectorSize threshold
> -----------------------------------------------------------------
>
> Key: ISPN-4240
> URL: https://issues.jboss.org/browse/ISPN-4240
> Project: Infinispan
> Issue Type: Enhancement
> Components: Distributed Execution and Map/Reduce
> Reporter: Vladimir Blagojevic
> Assignee: Vladimir Blagojevic
> Fix For: 7.0.0.Alpha4
>
>
> When we hit the maxCollectorSize threshold, we remove all the values from the collector and we start transferring them into the intermediary cache. But the other mapper threads keep working, and event with large collector sizes, it's very likely that the collector will be full again before we finished sending the previous batch. So we could end up with a lot of threads trying to insert maxCollectorSize values in the intermediary cache in parallel, and a lot more intermediary values in memory on each mapper node than the user would expect.
> In order to alleviate this observed phenomena Dan proposed an idea to keep the maxCollectorSize threshold, but to only move a single key at a time from the collector to the intermediary cache when the threshold is hit (the least recently used one). That way, the other keys would have time to collect more values (or just run the combiner a few more times).
> This way we still transfer some intermediate keys/values during map/combine phase rather than all at once at the end of that phase thus alleviating possibility of OOM. At the end of map/combine phase all remaining keys/values are of course transferred. Application users can fine tune their requirements and a specific use case using maxCollectorSize threshold.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
10 years, 5 months
[JBoss JIRA] (ISPN-4297) Digest HR auth tests fails, unable to find container
by Vojtech Juranek (JIRA)
[ https://issues.jboss.org/browse/ISPN-4297?page=com.atlassian.jira.plugin.... ]
Vojtech Juranek commented on ISPN-4297:
---------------------------------------
After discussion with dberindei on IRC, having separate profile is fine - speed up CI job and all tests can be run as a nightly build.
> Digest HR auth tests fails, unable to find container
> ----------------------------------------------------
>
> Key: ISPN-4297
> URL: https://issues.jboss.org/browse/ISPN-4297
> Project: Infinispan
> Issue Type: Bug
> Components: Server
> Reporter: Vojtech Juranek
> Assignee: Vojtech Juranek
>
> Fails with
> {noformat}
> java.lang.IllegalArgumentException: Cannot find specified object in InfinispanContext, type: org.infinispan.arquillian.core.RemoteInfinispanServer, qualifier: container1
> {noformat}
> Instead of creating new profile, configure the test to be able to run with default profile.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
10 years, 5 months
[JBoss JIRA] (ISPN-4297) Digest HR auth tests fails, unable to find container
by Vojtech Juranek (JIRA)
Vojtech Juranek created ISPN-4297:
-------------------------------------
Summary: Digest HR auth tests fails, unable to find container
Key: ISPN-4297
URL: https://issues.jboss.org/browse/ISPN-4297
Project: Infinispan
Issue Type: Bug
Components: Server
Reporter: Vojtech Juranek
Assignee: Vojtech Juranek
Fails with
{noformat}
java.lang.IllegalArgumentException: Cannot find specified object in InfinispanContext, type: org.infinispan.arquillian.core.RemoteInfinispanServer, qualifier: container1
{noformat}
Instead of creating new profile, configure the test to be able to run with default profile.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
10 years, 5 months