[JBoss JIRA] (ISPN-4283) Unable to setup SASL auth properties
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-4283?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-4283:
-----------------------------------------------
Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 1097283|https://bugzilla.redhat.com/show_bug.cgi?id=1097283] from NEW to MODIFIED
> Unable to setup SASL auth properties
> ------------------------------------
>
> Key: ISPN-4283
> URL: https://issues.jboss.org/browse/ISPN-4283
> Project: Infinispan
> Issue Type: Bug
> Components: Server
> Reporter: Vojtech Juranek
> Assignee: Tristan Tarrant
> Fix For: 7.0.0.Beta1
>
>
> It seems that it's not possible to setup SASL auth properies. This is needed e.g. in case of DIGEST-MD5 authentication - {{org.jboss.sasl.digest.DigestMD5Server}}, which handles this auth., expects that properties contain {{com.sun.security.sasl.digest.realm}}, otherwise default to server name as realm name. However, it seems that proprties passed to {{DigestMD5Server}} are always {{null}}. Therefore it's not possible to refer any security realm named other than server name (e.g. standard {{ApplicationRealm}}).
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
10 years, 5 months
[JBoss JIRA] (ISPN-4284) HotRod digest-md5 auth provides wrong callback
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-4284?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-4284:
-----------------------------------------------
Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 1097310|https://bugzilla.redhat.com/show_bug.cgi?id=1097310] from NEW to MODIFIED
> HotRod digest-md5 auth provides wrong callback
> ----------------------------------------------
>
> Key: ISPN-4284
> URL: https://issues.jboss.org/browse/ISPN-4284
> Project: Infinispan
> Issue Type: Bug
> Components: Server
> Reporter: Vojtech Juranek
> Assignee: Tristan Tarrant
> Fix For: 7.0.0.Beta1
>
>
> HotRod DIGEST-MD5 auth fails with
> {noformat}
> ERROR [org.infinispan.server.hotrod.HotRodDecoder] (HotRodServerWorker-12) ISPN005009: Unexpected error before any request parameters read: io.netty.handler.codec.DecoderException: or
> g.infinispan.server.hotrod.HotRodException: javax.security.sasl.SaslException: DIGEST-MD5: Cannot perform callback to acquire password [Caused by javax.security.auth.callback.UnsupportedCallbackException]
> at io.netty.handler.codec.ReplayingDecoder.callDecode(ReplayingDecoder.java:417) [netty-all-4.0.18.Final.jar:4.0.18.Final]
> at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:141) [netty-all-4.0.18.Final.jar:4.0.18.Final]
> at org.infinispan.server.core.AbstractProtocolDecoder.channelRead(AbstractProtocolDecoder.scala:470) [infinispan.jar:7.0.0-SNAPSHOT]
> at io.netty.channel.DefaultChannelHandlerContext.invokeChannelRead(DefaultChannelHandlerContext.java:341) [netty-all-4.0.18.Final.jar:4.0.18.Final]
> at io.netty.channel.DefaultChannelHandlerContext.fireChannelRead(DefaultChannelHandlerContext.java:327) [netty-all-4.0.18.Final.jar:4.0.18.Final]
> at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:785) [netty-all-4.0.18.Final.jar:4.0.18.Final]
> at io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:116) [netty-all-4.0.18.Final.jar:4.0.18.Final]
> at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:494) [netty-all-4.0.18.Final.jar:4.0.18.Final]
> at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:461) [netty-all-4.0.18.Final.jar:4.0.18.Final]
> at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:378) [netty-all-4.0.18.Final.jar:4.0.18.Final]
> at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:350) [netty-all-4.0.18.Final.jar:4.0.18.Final]
> at io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:116) [netty-all-4.0.18.Final.jar:4.0.18.Final]
> at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
> Caused by: org.infinispan.server.hotrod.HotRodException: javax.security.sasl.SaslException: DIGEST-MD5: Cannot perform call16:23:08,225 WARN [Codec20] (main) ISPN004005: Error received from the server: io.net
> ty.handler.codec.DecoderException: org.infinispan.server.hotrod.HotRodException: javax.security.sasl.SaslException: DIGEST-MD5: Cannot perform callback to acquire password [Caused by javax.security.auth.callba
> ck.UnsupportedCallbackException]
> back to acquire password [Caused by javax.security.auth.callback.UnsupportedCallbackException]
> at org.infinispan.server.hotrod.HotRodDecoder.createServerException(HotRodDecoder.scala:193) [infinispan.jar:7.0.0-SNAPSHOT]
> at org.infinispan.server.core.AbstractProtocolDecoder.secureDecodeDispatch(AbstractProtocolDecoder.scala:117) [infinispan.jar:7.0.0-SNAPSHOT]
> at org.infinispan.server.core.AbstractProtocolDecoder.decode(AbstractProtocolDecoder.scala:58) [infinispan.jar:7.0.0-SNAPSHOT]
> at io.netty.handler.codec.ReplayingDecoder.callDecode(ReplayingDecoder.java:362) [netty-all-4.0.18.Final.jar:4.0.18.Final]
> ... 12 more
> Caused by: javax.security.sasl.SaslException: DIGEST-MD5: Cannot perform callback to acquire password [Caused by javax.security.auth.callback.UnsupportedCallbackException]
> at org.jboss.sasl.digest.DigestMD5Server.validateClientResponse(DigestMD5Server.java:600) [jboss-sasl-1.0.3.Final.jar:1.0.3.Final]
> at org.jboss.sasl.digest.DigestMD5Server.evaluateResponse(DigestMD5Server.java:253) [jboss-sasl-1.0.3.Final.jar:1.0.3.Final]
> at org.infinispan.server.hotrod.Decoder2x$.customReadHeader(Decoder2x.scala:214) [infinispan.jar:7.0.0-SNAPSHOT]
> at org.infinispan.server.hotrod.HotRodDecoder.customDecodeHeader(HotRodDecoder.scala:139) [infinispan.jar:7.0.0-SNAPSHOT]
> at org.infinispan.server.core.AbstractProtocolDecoder.decodeHeader(AbstractProtocolDecoder.scala:147) [infinispan.jar:7.0.0-SNAPSHOT]
> at org.infinispan.server.core.AbstractProtocolDecoder.secureDecodeDispatch(AbstractProtocolDecoder.scala:95) [infinispan.jar:7.0.0-SNAPSHOT]
> ... 14 more
> Caused by: javax.security.auth.callback.UnsupportedCallbackException
> at org.jboss.as.domain.management.security.PropertiesCallbackHandler.handle(PropertiesCallbackHandler.java:164) [jboss-as-domain-management-7.2.0.Final.jar:7.2.0.Final]
> at org.jboss.as.domain.management.security.SecurityRealmService$1.handle(SecurityRealmService.java:168) [jboss-as-domain-management-7.2.0.Final.jar:7.2.0.Final]
> at org.infinispan.server.endpoint.subsystem.EndpointServerAuthenticationProvider$RealmAuthorizingCallbackHandler.handle(EndpointServerAuthenticationProvider.java:74) [infinispan-server-endpoints-7.0.0-
> SNAPSHOT.jar:7.0.0-SNAPSHOT]
> at org.jboss.sasl.digest.DigestMD5Server.validateClientResponse(DigestMD5Server.java:594) [jboss-sasl-1.0.3.Final.jar:1.0.3.Final]
> ... 19 more
> {noformat}
> Instead of {{DigestHashCallback}} is provided {{PasswordCallback}} whichi results into above {{UnsupportedCallbackException}} if password is not stored in plain on server.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
10 years, 5 months
[JBoss JIRA] (ISPN-2103) Concurrent access after removal of an AtomicMap should NOT result in an IllegalStateException when accessed by other threads
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/ISPN-2103?page=com.atlassian.jira.plugin.... ]
Radoslav Husar updated ISPN-2103:
---------------------------------
Bugzilla Update: (was: Perform)
> Concurrent access after removal of an AtomicMap should NOT result in an IllegalStateException when accessed by other threads
> ----------------------------------------------------------------------------------------------------------------------------
>
> Key: ISPN-2103
> URL: https://issues.jboss.org/browse/ISPN-2103
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 5.1.5.FINAL
> Reporter: Adrian Nistor
> Assignee: Galder Zamarreño
>
> ISPN-1121 introduces an IllegalStateException that is being thrown from AtomicMap methods once the map handle has become stale (ie. removed from cache). In case of concurrent access, the exception is thrown to all threads not just to the thread that performed the removal. This was fine-ish in older versions of Infinispan before introduction of optimistic and pessimistic locking but it should be reconsidered now because:
> 1. It interferes/overlaps with transaction isolation. We should rely on the selected locking scheme (OL/PL) to detect conflicts between transactions and report the problem accordingly. Especially if the stale map is used just for reading - this should be allowed to work rather than stop it.
> 2. This exception is pretty disruptive and awkward to handle. All methods of an AtomicMap can result in this exception and the current thread has to be prepared for handling it if other threads remove the map. Not much transaction isolation.
> 3. Since the TreeCache is backed by AtomicMap nearly all Tree API can throw this.
> The proposed fix consists of:
> 1. removing AtomicHashMap.removed flag and AtomicHashMap.markRemoved() method.
> 2. revising AtomicHashMapProxy.assertValid() method to check only if the map is null (ie. removed) but no longer use the removed flag.
> 3. revising ReadCommittedEntry.commit() method to no longer call markRemoved() method.
> The consequences of these changes are:
> 1. Any further access to a stale map results in IllegalStateException ONLY in the thread that performed the removal. This thread 'knows' the map is stale so it is fine to punish it. Other threads remain unaffected until lock acquisition or commit is performed (depending on locking model).
> 2. Other threads can continue to use the previously obtained map handle for reads without danger of getting an exception.
> 3. If a write operation is done on the map, the results depend on the locking model:
> 3.1 optimistic locking + write skew check: a WriteSkewException will stop the commit during prepare
> 3.2 optimistic locking, no write skew check: the write is committed and the work of the transaction that removed the map is overwritten. The map is effectively revived.
> 3.3 pessimistic locking: same as 3.2
> Please note 3.2 and 3.3 work the same as for normal values (not atomic maps).
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
10 years, 5 months
[JBoss JIRA] (ISPN-2103) Concurrent access after removal of an AtomicMap should NOT result in an IllegalStateException when accessed by other threads
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-2103?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration updated ISPN-2103:
------------------------------------------
Bugzilla Update: Perform
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=922699
> Concurrent access after removal of an AtomicMap should NOT result in an IllegalStateException when accessed by other threads
> ----------------------------------------------------------------------------------------------------------------------------
>
> Key: ISPN-2103
> URL: https://issues.jboss.org/browse/ISPN-2103
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 5.1.5.FINAL
> Reporter: Adrian Nistor
> Assignee: Galder Zamarreño
>
> ISPN-1121 introduces an IllegalStateException that is being thrown from AtomicMap methods once the map handle has become stale (ie. removed from cache). In case of concurrent access, the exception is thrown to all threads not just to the thread that performed the removal. This was fine-ish in older versions of Infinispan before introduction of optimistic and pessimistic locking but it should be reconsidered now because:
> 1. It interferes/overlaps with transaction isolation. We should rely on the selected locking scheme (OL/PL) to detect conflicts between transactions and report the problem accordingly. Especially if the stale map is used just for reading - this should be allowed to work rather than stop it.
> 2. This exception is pretty disruptive and awkward to handle. All methods of an AtomicMap can result in this exception and the current thread has to be prepared for handling it if other threads remove the map. Not much transaction isolation.
> 3. Since the TreeCache is backed by AtomicMap nearly all Tree API can throw this.
> The proposed fix consists of:
> 1. removing AtomicHashMap.removed flag and AtomicHashMap.markRemoved() method.
> 2. revising AtomicHashMapProxy.assertValid() method to check only if the map is null (ie. removed) but no longer use the removed flag.
> 3. revising ReadCommittedEntry.commit() method to no longer call markRemoved() method.
> The consequences of these changes are:
> 1. Any further access to a stale map results in IllegalStateException ONLY in the thread that performed the removal. This thread 'knows' the map is stale so it is fine to punish it. Other threads remain unaffected until lock acquisition or commit is performed (depending on locking model).
> 2. Other threads can continue to use the previously obtained map handle for reads without danger of getting an exception.
> 3. If a write operation is done on the map, the results depend on the locking model:
> 3.1 optimistic locking + write skew check: a WriteSkewException will stop the commit during prepare
> 3.2 optimistic locking, no write skew check: the write is committed and the work of the transaction that removed the map is overwritten. The map is effectively revived.
> 3.3 pessimistic locking: same as 3.2
> Please note 3.2 and 3.3 work the same as for normal values (not atomic maps).
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
10 years, 5 months
[JBoss JIRA] (ISPN-4264) Server CLI should be able to manipulate role mapping
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-4264?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-4264:
----------------------------------
Description:
The server CLI should have "grant" and "deny" commands to manipulate the role mapping:
[GRANT|DENY] role TO principal [ON container]?
was:The server CLI should have "allow" and "deny" commands to be able to grant permissions to principals
> Server CLI should be able to manipulate role mapping
> ----------------------------------------------------
>
> Key: ISPN-4264
> URL: https://issues.jboss.org/browse/ISPN-4264
> Project: Infinispan
> Issue Type: Sub-task
> Components: Core, Remote Protocols, Security, Server
> Reporter: Tristan Tarrant
> Assignee: Tristan Tarrant
> Fix For: 7.0.0.Beta1, 7.0.0.Final
>
>
> The server CLI should have "grant" and "deny" commands to manipulate the role mapping:
> [GRANT|DENY] role TO principal [ON container]?
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
10 years, 5 months
[JBoss JIRA] (ISPN-4291) Poor REPL state transfer performance with cache stores
by Dennis Reed (JIRA)
Dennis Reed created ISPN-4291:
---------------------------------
Summary: Poor REPL state transfer performance with cache stores
Key: ISPN-4291
URL: https://issues.jboss.org/browse/ISPN-4291
Project: Infinispan
Issue Type: Bug
Components: State Transfer
Affects Versions: 6.0.2.Final
Reporter: Dennis Reed
Assignee: Dan Berindei
During a state transfer every single key is loaded from the cache store to determine whether it's still owned by the local node.
This is an extremely slow operation, and doesn't even make sense for a REPL cache.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
10 years, 5 months
[JBoss JIRA] (ISPN-4236) RHQ JMX plugin causes Cache/CacheManager to report as not available
by Debbie Steigner (JIRA)
[ https://issues.jboss.org/browse/ISPN-4236?page=com.atlassian.jira.plugin.... ]
Debbie Steigner commented on ISPN-4236:
---------------------------------------
Is there a new RHQ JMX plugin for JON 3.2 that includes this fix?
> RHQ JMX plugin causes Cache/CacheManager to report as not available
> -------------------------------------------------------------------
>
> Key: ISPN-4236
> URL: https://issues.jboss.org/browse/ISPN-4236
> Project: Infinispan
> Issue Type: Bug
> Components: JMX, reporting and management
> Affects Versions: 6.0.2.Final, 7.0.0.Alpha3
> Reporter: William Burns
> Assignee: William Burns
> Labels: 630betablocker
> Fix For: 7.0.0.Alpha4, 7.0.0.Final
>
>
> With the update to use newer RHQ, the CacheManager and Cache sometimes report as being down when using library JMX plugin. It looks like RHQ added some additional checks which just pushes the operation time over the default of 5 seconds. This is to clean up our code a bit to make the availability check for efficient.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
10 years, 5 months
[JBoss JIRA] (ISPN-4129) Add Query, CDI, JCache, LevelDB and REST to the AS modules
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-4129?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo updated ISPN-4129:
------------------------------
Git Pull Request: https://github.com/infinispan/infinispan/pull/2447, https://github.com/infinispan/infinispan/pull/2558 (was: https://github.com/infinispan/infinispan/pull/2447)
> Add Query, CDI, JCache, LevelDB and REST to the AS modules
> ----------------------------------------------------------
>
> Key: ISPN-4129
> URL: https://issues.jboss.org/browse/ISPN-4129
> Project: Infinispan
> Issue Type: Feature Request
> Components: Build process
> Affects Versions: 7.0.0.Alpha1
> Reporter: Tristan Tarrant
> Assignee: Pedro Ruivo
> Fix For: 7.0.0.Beta1, 7.0.0.Final
>
>
> Query, CDI, JCache, LevelDB and REST modules need to be added to the AS modules we ship
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
10 years, 5 months
[JBoss JIRA] (ISPN-4290) jdbcStore oracle select sql with mixed case index name leads to table or view does not exist
by Eric van Lydegraf (JIRA)
Eric van Lydegraf created ISPN-4290:
---------------------------------------
Summary: jdbcStore oracle select sql with mixed case index name leads to table or view does not exist
Key: ISPN-4290
URL: https://issues.jboss.org/browse/ISPN-4290
Project: Infinispan
Issue Type: Bug
Affects Versions: 6.0.2.Final
Reporter: Eric van Lydegraf
Assignee: Mircea Markus
This was discovered when adding JdbcStore to infinispan for hibernate-search lucene integration. The default cache names are mixed case.
e.g.
name="LuceneIndexesMetadata"
This leads to a syntax with select ... "LuceneIndexesMetadata".
In Oracle quotes on a table name mean exact match.
But most tools that will create the table (eg. liquibase, toad) do not put quotes
around the table name and hence is treated as all UPPERCASE in the database.
So then when infinispan tries to load the data, it fails on sql select with table or view does not exist.
The easy fix is to have the quote identifier return blank for oracle in TableManipulation class
line 454-466
{code}
public String getIdentifierQuoteString() {
if(identifierQuoteString == null){
switch (getDatabaseType()) {
case MYSQL:
identifierQuoteString = "`";
break;
default:
identifierQuoteString = "\"";
break;
}
}
return identifierQuoteString;
}
{code}
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
10 years, 5 months