[JBoss JIRA] (ISPN-4296) Restore predefined cache limitation for Hot Rod servers
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-4296?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño commented on ISPN-4296:
----------------------------------------
Just updated the JIRA to add a missing link to the consistent hash function differences between two caches. The [javadoc for SyncConsistentHashFactory|https://github.com/infinispan/infinispan/blob/m...] contains a very good explanation on how two identical caches, with the same topologies, can end up having different consistent hashes.
> Restore predefined cache limitation for Hot Rod servers
> -------------------------------------------------------
>
> Key: ISPN-4296
> URL: https://issues.jboss.org/browse/ISPN-4296
> Project: Infinispan
> Issue Type: Enhancement
> Components: Remote Protocols
> Affects Versions: 7.0.0.Alpha3
> Reporter: Galder Zamarreño
> Assignee: Galder Zamarreño
> Fix For: 7.0.0.Beta1
>
>
> Even after asymmetric cluster support was implemented, each node still does not know which other nodes contain which caches. The coordinator of the cluster knows, but no one else. This is because the aim has never really been to have different nodes containing different caches, but more about making sure that caches can be started lazily. With this in mind, the limitation in ISPN-833 will be reinstated.
> Being able to work only with predefined caches also simplifies a solution for ISPN-3530 because we can safely assume that all servers contain the defined caches. Each cache might have a different consistent hash (see dev list discussion on why this can easily happen - http://lists.jboss.org/pipermail/infinispan-dev/2014-April/014870.html) but at least knowing that the nodes that have it is the same makes it easier to come up with a solution.
> Finally, restoring the limitation avoids other can of worms such as the edge cases discovered by Jakub in ISPN-4212.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
10 years, 5 months
[JBoss JIRA] (ISPN-4296) Restore predefined cache limitation for Hot Rod servers
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-4296?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño updated ISPN-4296:
-----------------------------------
Description:
Even after asymmetric cluster support was implemented, each node still does not know which other nodes contain which caches. The coordinator of the cluster knows, but no one else. This is because the aim has never really been to have different nodes containing different caches, but more about making sure that caches can be started lazily. With this in mind, the limitation in ISPN-833 will be reinstated.
Being able to work only with predefined caches also simplifies a solution for ISPN-3530 because we can safely assume that all servers contain the defined caches. Each cache might have a different consistent hash (see dev list discussion on why this can easily happen - http://lists.jboss.org/pipermail/infinispan-dev/2014-April/014870.html) but at least knowing that the nodes that have it is the same makes it easier to come up with a solution.
Finally, restoring the limitation avoids other can of worms such as the edge cases discovered by Jakub in ISPN-4212.
was:
Even after asymmetric cluster support was implemented, each node still does not know which other nodes contain which caches. The coordinator of the cluster knows, but no one else. This is because the aim has never really been to have different nodes containing different caches, but more about making sure that caches can be started lazily. With this in mind, the limitation in ISPN-833 will be reinstated.
Being able to work only with predefined caches also simplifies a solution for ISPN-3530 because we can safely assume that all servers contain the defined caches. Each cache might have a different consistent hash (see dev list discussion on why this can easily happen - ) but at least knowing that the nodes that have it is the same makes it easier to come up with a solution.
Finally, restoring the limitation avoids other can of worms such as the edge cases discovered by Jakub in ISPN-4212.
> Restore predefined cache limitation for Hot Rod servers
> -------------------------------------------------------
>
> Key: ISPN-4296
> URL: https://issues.jboss.org/browse/ISPN-4296
> Project: Infinispan
> Issue Type: Enhancement
> Components: Remote Protocols
> Affects Versions: 7.0.0.Alpha3
> Reporter: Galder Zamarreño
> Assignee: Galder Zamarreño
> Fix For: 7.0.0.Beta1
>
>
> Even after asymmetric cluster support was implemented, each node still does not know which other nodes contain which caches. The coordinator of the cluster knows, but no one else. This is because the aim has never really been to have different nodes containing different caches, but more about making sure that caches can be started lazily. With this in mind, the limitation in ISPN-833 will be reinstated.
> Being able to work only with predefined caches also simplifies a solution for ISPN-3530 because we can safely assume that all servers contain the defined caches. Each cache might have a different consistent hash (see dev list discussion on why this can easily happen - http://lists.jboss.org/pipermail/infinispan-dev/2014-April/014870.html) but at least knowing that the nodes that have it is the same makes it easier to come up with a solution.
> Finally, restoring the limitation avoids other can of worms such as the edge cases discovered by Jakub in ISPN-4212.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
10 years, 5 months
[JBoss JIRA] (ISPN-4299) Authentication configuration builder requires CallbackHandle also when subject it set
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-4299?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration updated ISPN-4299:
------------------------------------------
Bugzilla Update: Perform
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1099055
> Authentication configuration builder requires CallbackHandle also when subject it set
> -------------------------------------------------------------------------------------
>
> Key: ISPN-4299
> URL: https://issues.jboss.org/browse/ISPN-4299
> Project: Infinispan
> Issue Type: Bug
> Components: Server
> Reporter: Vojtech Juranek
> Assignee: Mircea Markus
> Priority: Minor
>
> Authentication configuration builder allows to setup direcly subject under which action are performed. In this case there's no need for any additional authentication. However authentication configuration builder requires {{CallbackHandler}} also in this case and without it it fails with
> {noformat}
> org.infinispan.commons.CacheConfigurationException: ISPN004030: Cannot enable authentication without specifying a Callback Handler
> at org.infinispan.client.hotrod.configuration.AuthenticationConfigurationBuilder.validate(AuthenticationConfigurationBuilder.java:86)
> at org.infinispan.client.hotrod.configuration.SecurityConfigurationBuilder.validate(SecurityConfigurationBuilder.java:43)
> at org.infinispan.client.hotrod.configuration.ConfigurationBuilder.validate(ConfigurationBuilder.java:280)
> at org.infinispan.client.hotrod.configuration.ConfigurationBuilder.build(ConfigurationBuilder.java:314)
> at org.infinispan.client.hotrod.configuration.ConfigurationBuilder.build(ConfigurationBuilder.java:309)
> at org.infinispan.server.test.client.hotrod.security.HotRodSaslAuthTestBase.getRemoteCacheManagerConfig(HotRodSaslAuthTestBase.java:104)
> {noformat}
--
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 RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-4298?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration updated ISPN-4298:
------------------------------------------
Bugzilla Update: Perform
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1099054
> 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: Tristan Tarrant
>
> 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-4299) Authentication configuration builder requires CallbackHandle also when subject it set
by Vojtech Juranek (JIRA)
[ https://issues.jboss.org/browse/ISPN-4299?page=com.atlassian.jira.plugin.... ]
Vojtech Juranek updated ISPN-4299:
----------------------------------
Priority: Minor (was: Major)
> Authentication configuration builder requires CallbackHandle also when subject it set
> -------------------------------------------------------------------------------------
>
> Key: ISPN-4299
> URL: https://issues.jboss.org/browse/ISPN-4299
> Project: Infinispan
> Issue Type: Bug
> Components: Server
> Reporter: Vojtech Juranek
> Assignee: Mircea Markus
> Priority: Minor
>
> Authentication configuration builder allows to setup direcly subject under which action are performed. In this case there's no need for any additional authentication. However authentication configuration builder requires {{CallbackHandler}} also in this case and without it it fails with
> {noformat}
> org.infinispan.commons.CacheConfigurationException: ISPN004030: Cannot enable authentication without specifying a Callback Handler
> at org.infinispan.client.hotrod.configuration.AuthenticationConfigurationBuilder.validate(AuthenticationConfigurationBuilder.java:86)
> at org.infinispan.client.hotrod.configuration.SecurityConfigurationBuilder.validate(SecurityConfigurationBuilder.java:43)
> at org.infinispan.client.hotrod.configuration.ConfigurationBuilder.validate(ConfigurationBuilder.java:280)
> at org.infinispan.client.hotrod.configuration.ConfigurationBuilder.build(ConfigurationBuilder.java:314)
> at org.infinispan.client.hotrod.configuration.ConfigurationBuilder.build(ConfigurationBuilder.java:309)
> at org.infinispan.server.test.client.hotrod.security.HotRodSaslAuthTestBase.getRemoteCacheManagerConfig(HotRodSaslAuthTestBase.java:104)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
10 years, 5 months
[JBoss JIRA] (ISPN-4212) Unable to get entries from newly started non-defined caches
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-4212?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño edited comment on ISPN-4212 at 5/19/14 7:27 AM:
-----------------------------------------------------------------
Jakub/Martin, we will be reinstating the limitation of talking only to predefined caches. Details can be found in ISPN-4296. Putting back the limit should fix this issue.
was (Author: galder.zamarreno):
Jakub/Martin, we will be reinstating the limitation of talking only to predefined caches. Details can be found in ISPN-4296. Putting back the limit should this issue.
> Unable to get entries from newly started non-defined caches
> -----------------------------------------------------------
>
> Key: ISPN-4212
> URL: https://issues.jboss.org/browse/ISPN-4212
> Project: Infinispan
> Issue Type: Bug
> Components: Remote Protocols, Server
> Affects Versions: 7.0.0.Alpha3
> Reporter: Jakub Markos
> Assignee: Galder Zamarreño
> Fix For: 7.0.0.Beta1
>
>
> If you use hotrod to put entries into a cache which is not defined in standalone.xml, it will be started:
> {code}
> 15:35:50,676 INFO [org.jboss.as.clustering.infinispan] (HotRodServerWorker-1) JBAS010281: Started nonDefinedCache cache from local container
> {code}
> but when you try to retrieve the entry back, you'll get null.
> {code}
> RemoteCacheManager rcm = new RemoteCacheManager(new ConfigurationBuilder().addServer().host("localhost").port(11222).build());
> RemoteCache<String, String> cache = rcm.getCache("nonDefinedCache");
> cache.put("key", "value");
> cache.get("key"); // returns null
> {code}
> Happens in the current server snapshot.
> A while back you'd get this
> {code}
> WARN: ISPN004005: Error received from the server: org.infinispan.server.hotrod.CacheNotFoundException: Cache with name 'nonDefinedCache' not found amongst the configured caches
> {code}
> So it seems we're somewhere in the middle now (not throwing exception, but also not working). The documentation here is also wrong https://github.com/infinispan/infinispan/blob/master/client/hotrod-client... .
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
10 years, 5 months
[JBoss JIRA] (ISPN-4212) Unable to get entries from newly started non-defined caches
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-4212?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño updated ISPN-4212:
-----------------------------------
Fix Version/s: 7.0.0.Beta1
> Unable to get entries from newly started non-defined caches
> -----------------------------------------------------------
>
> Key: ISPN-4212
> URL: https://issues.jboss.org/browse/ISPN-4212
> Project: Infinispan
> Issue Type: Bug
> Components: Remote Protocols, Server
> Affects Versions: 7.0.0.Alpha3
> Reporter: Jakub Markos
> Assignee: Galder Zamarreño
> Fix For: 7.0.0.Beta1
>
>
> If you use hotrod to put entries into a cache which is not defined in standalone.xml, it will be started:
> {code}
> 15:35:50,676 INFO [org.jboss.as.clustering.infinispan] (HotRodServerWorker-1) JBAS010281: Started nonDefinedCache cache from local container
> {code}
> but when you try to retrieve the entry back, you'll get null.
> {code}
> RemoteCacheManager rcm = new RemoteCacheManager(new ConfigurationBuilder().addServer().host("localhost").port(11222).build());
> RemoteCache<String, String> cache = rcm.getCache("nonDefinedCache");
> cache.put("key", "value");
> cache.get("key"); // returns null
> {code}
> Happens in the current server snapshot.
> A while back you'd get this
> {code}
> WARN: ISPN004005: Error received from the server: org.infinispan.server.hotrod.CacheNotFoundException: Cache with name 'nonDefinedCache' not found amongst the configured caches
> {code}
> So it seems we're somewhere in the middle now (not throwing exception, but also not working). The documentation here is also wrong https://github.com/infinispan/infinispan/blob/master/client/hotrod-client... .
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
10 years, 5 months
[JBoss JIRA] (ISPN-4212) Unable to get entries from newly started non-defined caches
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-4212?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño updated ISPN-4212:
-----------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/infinispan/infinispan/pull/2564
> Unable to get entries from newly started non-defined caches
> -----------------------------------------------------------
>
> Key: ISPN-4212
> URL: https://issues.jboss.org/browse/ISPN-4212
> Project: Infinispan
> Issue Type: Bug
> Components: Remote Protocols, Server
> Affects Versions: 7.0.0.Alpha3
> Reporter: Jakub Markos
> Assignee: Galder Zamarreño
>
> If you use hotrod to put entries into a cache which is not defined in standalone.xml, it will be started:
> {code}
> 15:35:50,676 INFO [org.jboss.as.clustering.infinispan] (HotRodServerWorker-1) JBAS010281: Started nonDefinedCache cache from local container
> {code}
> but when you try to retrieve the entry back, you'll get null.
> {code}
> RemoteCacheManager rcm = new RemoteCacheManager(new ConfigurationBuilder().addServer().host("localhost").port(11222).build());
> RemoteCache<String, String> cache = rcm.getCache("nonDefinedCache");
> cache.put("key", "value");
> cache.get("key"); // returns null
> {code}
> Happens in the current server snapshot.
> A while back you'd get this
> {code}
> WARN: ISPN004005: Error received from the server: org.infinispan.server.hotrod.CacheNotFoundException: Cache with name 'nonDefinedCache' not found amongst the configured caches
> {code}
> So it seems we're somewhere in the middle now (not throwing exception, but also not working). The documentation here is also wrong https://github.com/infinispan/infinispan/blob/master/client/hotrod-client... .
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
10 years, 5 months
[JBoss JIRA] (ISPN-4299) Authentication configuration builder requires CallbackHandle also when subject it set
by Vojtech Juranek (JIRA)
Vojtech Juranek created ISPN-4299:
-------------------------------------
Summary: Authentication configuration builder requires CallbackHandle also when subject it set
Key: ISPN-4299
URL: https://issues.jboss.org/browse/ISPN-4299
Project: Infinispan
Issue Type: Bug
Components: Server
Reporter: Vojtech Juranek
Assignee: Mircea Markus
Authentication configuration builder allows to setup direcly subject under which action are performed. In this case there's no need for any additional authentication. However authentication configuration builder requires {{CallbackHandler}} also in this case and without it it fails with
{noformat}
org.infinispan.commons.CacheConfigurationException: ISPN004030: Cannot enable authentication without specifying a Callback Handler
at org.infinispan.client.hotrod.configuration.AuthenticationConfigurationBuilder.validate(AuthenticationConfigurationBuilder.java:86)
at org.infinispan.client.hotrod.configuration.SecurityConfigurationBuilder.validate(SecurityConfigurationBuilder.java:43)
at org.infinispan.client.hotrod.configuration.ConfigurationBuilder.validate(ConfigurationBuilder.java:280)
at org.infinispan.client.hotrod.configuration.ConfigurationBuilder.build(ConfigurationBuilder.java:314)
at org.infinispan.client.hotrod.configuration.ConfigurationBuilder.build(ConfigurationBuilder.java:309)
at org.infinispan.server.test.client.hotrod.security.HotRodSaslAuthTestBase.getRemoteCacheManagerConfig(HotRodSaslAuthTestBase.java:104)
{noformat}
--
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 Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-4298?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant reassigned ISPN-4298:
-------------------------------------
Assignee: Tristan Tarrant (was: Mircea Markus)
> 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: Tristan Tarrant
>
> 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