[JBoss JIRA] (ISPN-3689) Preloading fails with JdbcBinaryCacheStore on DB2
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-3689?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-3689:
-----------------------------------------------
mark yarborough <myarboro(a)redhat.com> changed the Status of [bug 1087209|https://bugzilla.redhat.com/show_bug.cgi?id=1087209] from VERIFIED to CLOSED
> Preloading fails with JdbcBinaryCacheStore on DB2
> --------------------------------------------------
>
> Key: ISPN-3689
> URL: https://issues.jboss.org/browse/ISPN-3689
> Project: Infinispan
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Loaders and Stores
> Affects Versions: 5.2.7.Final, 6.0.0.CR1
> Environment: DB2 9.7.5
> Reporter: Nicolas Filotto
> Assignee: Mircea Markus
> Fix For: 7.0.0.Alpha4, 5.2.9.Final
>
>
> I use the {{JdbcBinaryCacheStore}} with preloading enabled, when I test it on DB2 I get an exception of type:
> {code}
> 06.11.2013 16:27:51 *ERROR* [main] DataManipulationHelper: ISPN008007: SQL error while fetching all StoredEntries (DataManipulationHelper.java, line 253)
> com.ibm.db2.jcc.am.SqlSyntaxErrorException: DB2 SQL Error: SQLCODE=-104, SQLSTATE=42601, SQLERRMC=?;r_quota" FETCH FIRST;<space>, DRIVER=4.13.80
> at com.ibm.db2.jcc.am.id.a(id.java:677)
> at com.ibm.db2.jcc.am.id.a(id.java:60)
> at com.ibm.db2.jcc.am.id.a(id.java:127)
> at com.ibm.db2.jcc.am.fo.c(fo.java:2653)
> at com.ibm.db2.jcc.am.fo.d(fo.java:2641)
> at com.ibm.db2.jcc.am.fo.a(fo.java:2090)
> at com.ibm.db2.jcc.am.go.a(go.java:7639)
> at com.ibm.db2.jcc.t4.cb.h(cb.java:141)
> at com.ibm.db2.jcc.t4.cb.b(cb.java:41)
> at com.ibm.db2.jcc.t4.q.a(q.java:32)
> at com.ibm.db2.jcc.t4.sb.i(sb.java:135)
> at com.ibm.db2.jcc.am.fo.ib(fo.java:2059)
> at com.ibm.db2.jcc.am.go.sc(go.java:3555)
> at com.ibm.db2.jcc.am.go.b(go.java:4344)
> at com.ibm.db2.jcc.am.go.fc(go.java:741)
> at com.ibm.db2.jcc.am.go.executeQuery(go.java:711)
> at org.apache.commons.dbcp.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:96)
> at org.apache.commons.dbcp.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:96)
> at org.infinispan.loaders.jdbc.DataManipulationHelper.loadSome(DataManipulationHelper.java:245)
> at org.infinispan.loaders.jdbc.binary.JdbcBinaryCacheStore.loadLockSafe(JdbcBinaryCacheStore.java:312)
> at org.infinispan.loaders.LockSupportCacheStore.load(LockSupportCacheStore.java:167)
> at org.infinispan.loaders.CacheLoaderManagerImpl.loadState(CacheLoaderManagerImpl.java:285)
> at org.infinispan.loaders.CacheLoaderManagerImpl.preload(CacheLoaderManagerImpl.java:238)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.infinispan.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:203)
> at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:886)
> at org.infinispan.factories.AbstractComponentRegistry.invokeStartMethods(AbstractComponentRegistry.java:657)
> at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:646)
> at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:549)
> at org.infinispan.factories.ComponentRegistry.start(ComponentRegistry.java:217)
> at org.infinispan.CacheImpl.start(CacheImpl.java:582)
> at org.infinispan.manager.DefaultCacheManager.wireAndStartCache(DefaultCacheManager.java:686)
> at org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:649)
> at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:545)
> {code}
> I looks like you cannot use a parameter to set your query limit in case of DB2 9.7.5 at least
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
9 years, 10 months
[JBoss JIRA] (ISPN-3680) Inconsistent way to use the column id in the JdbcBinaryCacheStore
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-3680?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-3680:
-----------------------------------------------
mark yarborough <myarboro(a)redhat.com> changed the Status of [bug 1087205|https://bugzilla.redhat.com/show_bug.cgi?id=1087205] from VERIFIED to CLOSED
> Inconsistent way to use the column id in the JdbcBinaryCacheStore
> -----------------------------------------------------------------
>
> Key: ISPN-3680
> URL: https://issues.jboss.org/browse/ISPN-3680
> Project: Infinispan
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Loaders and Stores
> Affects Versions: 5.2.7.Final, 5.3.0.Final, 6.0.0.CR1
> Reporter: Nicolas Filotto
> Assignee: Mircea Markus
> Fix For: 7.0.0.Alpha4, 5.2.9.Final
>
>
> I met some issues with (at least) H2 and JdbcBinaryCacheStore that prevent to modify a value in the cache store which is quite annoying. After a deeper look, I realized that it was due to the method {{JdbcBinaryCacheStore.loadBucket(Integer keyHashCode)}} that uses {{setInt}} instead of {{setString}} like in updateBucket and insertBucket to set the id as parameter to the query. With HSQLDB and MySQL, it works normally but with H2, the result of the query is always empty so it always tries to add a new entry which of course fails because of the integrity constraint on the primary key (aka the id).
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
9 years, 10 months
[JBoss JIRA] (ISPN-4451) Missing ACCESS right
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-4451?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant commented on ISPN-4451:
---------------------------------------
I'm going to check about the LIFECYCLE permission on starting a cache, and maybe add a check for any permission on the getCache() (i.e. anything greater than NONE)
> Missing ACCESS right
> --------------------
>
> Key: ISPN-4451
> URL: https://issues.jboss.org/browse/ISPN-4451
> Project: Infinispan
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Security
> Reporter: Vojtech Juranek
> Assignee: Tristan Tarrant
>
> When security is turned on ({{cacheConfig.security().authorization().enable()}}), any user can obtain/create a cache, even unauthorized users. This should be allowed only for users with right {{ACCESS}}. This right is actually not present in {{AuthorizationPermission}}.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
9 years, 10 months
[JBoss JIRA] (ISPN-4454) HR client SASL MD5 against LDAP fails
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-4454?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant commented on ISPN-4454:
---------------------------------------
Using LDAP with DIGEST-MD5 requires WFLY-1217 to be fixed.
> HR client SASL MD5 against LDAP fails
> -------------------------------------
>
> Key: ISPN-4454
> URL: https://issues.jboss.org/browse/ISPN-4454
> Project: Infinispan
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Security
> Reporter: Vojtech Juranek
> Assignee: Tristan Tarrant
>
> When trying to authenticate HotRod client against LDAP using SASL DIGEST-MD5 auth, it fails with:
> {noformat}
> 31m18:21:40,265 ERROR [org.infinispan.server.hotrod.HotRodDecoder] (HotRodServerWorker-7-1) ISPN005009: Unexpected error before any request parameters read: io.netty.handler.codec.DecoderException: org.infinispan.server.hotrod.HotRodException: java.lang.IllegalStateException: JBAS015259: No CallbackHandler available for mechanism DIGEST in realm ApplicationRealm
> at io.netty.handler.codec.ReplayingDecoder.callDecode(ReplayingDecoder.java:417) [netty-all-4.0.20.Final.jar:4.0.20.Final]
> at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:149) [netty-all-4.0.20.Final.jar:4.0.20.Final]
> at org.infinispan.server.core.AbstractProtocolDecoder.channelRead(AbstractProtocolDecoder.scala:471) [infinispan.jar:7.0.0-SNAPSHOT]
> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:332) [netty-all-4.0.20.Final.jar:4.0.20.Final]
> at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:318) [netty-all-4.0.20.Final.jar:4.0.20.Final]
> at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:787) [netty-all-4.0.20.Final.jar:4.0.20.Final]
> at io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:125) [netty-all-4.0.20.Final.jar:4.0.20.Final]
> at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:507) [netty-all-4.0.20.Final.jar:4.0.20.Final]
> at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:464) [netty-all-4.0.20.Final.jar:4.0.20.Final]
> at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:378) [netty-all-4.0.20.Final.jar:4.0.20.Final]
> at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:350) [netty-all-4.0.20.Final.jar:4.0.20.Final]
> at io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:116) [netty-all-4.0.20.Final.jar:4.0.20.Final]
> at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
> Caused by: org.infinispan.server.hotrod.HotRodException: java.lang.IllegalStateException: JBAS015259: No CallbackHandler available for mechanism DIGEST in realm ApplicationRealm
> at org.infinispan.server.hotrod.HotRodDecoder.createServerException(HotRodDecoder.scala:204) [infinispan.jar:7.0.0-SNAPSHOT]
> at org.infinispan.server.core.AbstractProtocolDecoder.secureDecodeDispatch(AbstractProtocolDecoder.scala:118) [infinispan.jar:7.0.0-SNAPSHOT]
> at org.infinispan.server.core.AbstractProtocolDecoder.decode(AbstractProtocolDecoder.scala:59) [infinispan.jar:7.0.0-SNAPSHOT]
> at io.netty.handler.codec.ReplayingDecoder.callDecode(ReplayingDecoder.java:362) [netty-all-4.0.20.Final.jar:4.0.20.Final]
> ... 12 more
> Caused by: java.lang.IllegalStateException: JBAS015259: No CallbackHandler available for mechanism DIGEST in realm ApplicationRealm
> at org.jboss.as.domain.management.security.SecurityRealmService.getCallbackHandlerService(SecurityRealmService.java:231) [wildfly-domain-management-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.as.domain.management.security.SecurityRealmService.getMechanismConfig(SecurityRealmService.java:128) [wildfly-domain-management-8.1.0.Final.jar:8.1.0.Final]
> at org.infinispan.server.endpoint.subsystem.EndpointServerAuthenticationProvider.getCallbackHandler(EndpointServerAuthenticationProvider.java:54) [infinispan-server-endpoints-7.0.0-SNAPSHOT.jar:7.0.0-SNAPSHOT]
> at org.infinispan.server.hotrod.Decoder2x$.customReadHeader(Decoder2x.scala:208) [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
> {noformat}
> When running same test, but using login/passwd store in properties file, everything works. Serve LDAP config:
> {noformat}
> <security-realms>
> <security-realm name="ApplicationRealm">
> <authentication>
> <ldap connection="ldap_connection" recursive="true" base-dn="ou=People,dc=infinispan,dc=org">
> <username-filter attribute="uid" />
> </ldap>
> </authentication>
> <authorization>
> <properties path="application-roles.properties" relative-to="jboss.server.config.dir"/>
> </authorization>
> </security-realm>
> </security-realms>
> <outbound-connections>
> <ldap name="ldap_connection" url="ldap://localhost:10389"/>
> </outbound-connections>
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
9 years, 10 months
[JBoss JIRA] (ISPN-4455) Provide ability to block/notify on RPC readiness on node startup
by Mikhail Dobrinin (JIRA)
[ https://issues.jboss.org/browse/ISPN-4455?page=com.atlassian.jira.plugin.... ]
Mikhail Dobrinin updated ISPN-4455:
-----------------------------------
Summary: Provide ability to block/notify on RPC readiness on node startup (was: Provide ability to block/notify on cache readiness on node startup)
> Provide ability to block/notify on RPC readiness on node startup
> ----------------------------------------------------------------
>
> Key: ISPN-4455
> URL: https://issues.jboss.org/browse/ISPN-4455
> Project: Infinispan
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Affects Versions: 6.0.0.Final
> Reporter: Mikhail Dobrinin
> Assignee: Mircea Markus
> Priority: Minor
>
> Currently, when a node joins the cluster, the members will receive a ViewChanged event. However, this does not mean you can act on it in all ways. For example, you cannot send an RPC command to the new member. If you do then he will respond with {{CacheNotFoundResponse}} because his ComponentRegistry is not set up with the cache yet. It would be helpful if there were some way to know when someone joined *and* they are fully functional.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
9 years, 10 months
[JBoss JIRA] (ISPN-4455) Provide ability to block/notify on cache readiness on node startup
by Mikhail Dobrinin (JIRA)
Mikhail Dobrinin created ISPN-4455:
--------------------------------------
Summary: Provide ability to block/notify on cache readiness on node startup
Key: ISPN-4455
URL: https://issues.jboss.org/browse/ISPN-4455
Project: Infinispan
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Affects Versions: 6.0.0.Final
Reporter: Mikhail Dobrinin
Assignee: Mircea Markus
Priority: Minor
Currently, when a node joins the cluster, the members will receive a ViewChanged event. However, this does not mean you can act on it in all ways. For example, you cannot send an RPC command to the new member. If you do then he will respond with {{CacheNotFoundResponse}} because his ComponentRegistry is not set up with the cache yet. It would be helpful if there were some way to know when someone joined *and* they are fully functional.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
9 years, 10 months
[JBoss JIRA] (ISPN-4435) CacheNotifierImplInitialTransferDistTest test instability part 2
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-4435?page=com.atlassian.jira.plugin.... ]
William Burns updated ISPN-4435:
--------------------------------
Status: Pull Request Sent (was: Coding In Progress)
Git Pull Request: https://github.com/infinispan/infinispan/pull/2679
> CacheNotifierImplInitialTransferDistTest test instability part 2
> ----------------------------------------------------------------
>
> Key: ISPN-4435
> URL: https://issues.jboss.org/browse/ISPN-4435
> Project: Infinispan
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Test Suite - Core
> Reporter: William Burns
> Assignee: William Burns
> Fix For: 7.0.0.Alpha5
>
>
> Some of the tests even with the more recent fixes can fail with the following exception:
> {code}
> java.lang.AssertionError: expected [11] but found [9]
> at org.testng.Assert.fail(Assert.java:94)
> at org.testng.Assert.failNotEquals(Assert.java:494)
> at org.testng.Assert.assertEquals(Assert.java:123)
> at org.testng.Assert.assertEquals(Assert.java:370)
> at org.testng.Assert.assertEquals(Assert.java:380)
> at org.infinispan.notifications.cachelistener.CacheNotifierImplInitialTransferDistTest.testIterationBeganAndSegmentNotComplete(CacheNotifierImplInitialTransferDistTest.java:514)
> at org.infinispan.notifications.cachelistener.CacheNotifierImplInitialTransferDistTest.testRemoveAfterIterationBeganAndSegmentNotCompleteValueOwnerClustered(CacheNotifierImplInitialTransferDistTest.java:660)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:80)
> at org.testng.internal.Invoker.invokeMethod(Invoker.java:714)
> at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:901)
> at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1231)
> at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127)
> at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111)
> at org.testng.TestRunner.privateRun(TestRunner.java:767)
> at org.testng.TestRunner.run(TestRunner.java:617)
> at org.testng.SuiteRunner.runTest(SuiteRunner.java:334)
> at org.testng.SuiteRunner.access$000(SuiteRunner.java:37)
> at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:368)
> at org.testng.internal.thread.ThreadUtil$2.call(ThreadUtil.java:64)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:724)
> {code}
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
9 years, 10 months