[JBoss JIRA] (ISPN-2906) SyncCacheListenerTest.testSyncTxRepl failing randomly
by Adrian Nistor (JIRA)
[ https://issues.jboss.org/browse/ISPN-2906?page=com.atlassian.jira.plugin.... ]
Adrian Nistor updated ISPN-2906:
--------------------------------
Attachment: SyncCacheListenerTest_age_is_null.log
Failed again with 'java.lang.AssertionError: "age" obtained from cache2 must be non-null'. New trace log attached.
> SyncCacheListenerTest.testSyncTxRepl failing randomly
> -----------------------------------------------------
>
> Key: ISPN-2906
> URL: https://issues.jboss.org/browse/ISPN-2906
> Project: Infinispan
> Issue Type: Bug
> Components: Listeners, Transactions
> Reporter: Galder Zamarreño
> Assignee: Mircea Markus
> Labels: testsuite_stability
> Fix For: 5.3.0.Beta1
>
> Attachments: SyncCacheListenerTest_age_is_null.log, testSyncTxRepl-0.log
>
>
> {code}testSyncTxRepl(org.infinispan.replication.SyncCacheListenerTest) Time elapsed: 0.04 sec <<< FAILURE!
> java.lang.AssertionError: "age" obtained from cache2 must be non-null
> at org.testng.AssertJUnit.fail(AssertJUnit.java:59)
> at org.testng.AssertJUnit.assertTrue(AssertJUnit.java:24)
> at org.testng.AssertJUnit.assertNotNull(AssertJUnit.java:267)
> at org.infinispan.replication.SyncCacheListenerTest.testSyncTxRepl(SyncCacheListenerTest.java:99)
> 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:601)
> 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$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:722){code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 2 months
[JBoss JIRA] (ISPN-2814) RpcManager doesn't return values properly
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-2814?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-2814:
-------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> RpcManager doesn't return values properly
> -----------------------------------------
>
> Key: ISPN-2814
> URL: https://issues.jboss.org/browse/ISPN-2814
> Project: Infinispan
> Issue Type: Bug
> Components: RPC
> Affects Versions: 5.1.5.FINAL
> Reporter: William Burns
> Assignee: Adrian Nistor
> Fix For: 5.3.0.Final, 5.2.3.Final
>
> Attachments: RpcManagerCustomCommandTest.java
>
>
> We currently use some custom commands with Infinispan. We have since moved over to wanting to use a custom command with a return value for the response.
> We have tried using the various methods on the RpcManager and have found a few issues.
> 1. Map<Address, Response> invokeRemotely(Collection<Address> recipients, ReplicableCommand rpc, boolean sync, boolean usePriorityQueue) throws RpcException;
> This method always returns a null for cluster responses. This is a simple issue that can be solved with the following diff
> {code}
> diff --git a/core/src/main/java/org/infinispan/commands/remote/SingleRpcCommand.
> index bf369bc..79bc02e 100644
> --- a/core/src/main/java/org/infinispan/commands/remote/SingleRpcCommand.java
> +++ b/core/src/main/java/org/infinispan/commands/remote/SingleRpcCommand.java
> @@ -107,6 +107,6 @@ public ReplicableCommand getCommand() {
>
> @Override
> public boolean isReturnValueExpected() {
> - return false;
> + return command.isReturnValueExpected();
> }
> }
> {code}
> The SingleRpcCommand wraps the given command always forcing the return value expectation to be false.
> 2. Map<Address, Response> invokeRemotely(Collection<Address> recipients, ReplicableCommand rpcCommand, ResponseMode mode, long timeout);
> This method doesn't wrap the return value in a Response thus causing a ClassCastException when the client node gets the response back. I haven't looked into detail with this one yet.
> If needed I can send a sample project that shows the behavior.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 2 months
[JBoss JIRA] (ISPN-2976) Log4J dependencies in codebase to be cleaned up
by Adrian Nistor (JIRA)
[ https://issues.jboss.org/browse/ISPN-2976?page=com.atlassian.jira.plugin.... ]
Adrian Nistor commented on ISPN-2976:
-------------------------------------
log4j 1.x also has some concurrency bugs like this one https://issues.apache.org/bugzilla/show_bug.cgi?id=50213 that leads to hanged test suites very often. It wold be good to move away from it.
> Log4J dependencies in codebase to be cleaned up
> -----------------------------------------------
>
> Key: ISPN-2976
> URL: https://issues.jboss.org/browse/ISPN-2976
> Project: Infinispan
> Issue Type: Task
> Affects Versions: 5.2.5.Final
> Reporter: Manik Surtani
> Assignee: Mircea Markus
> Fix For: 5.3.0.Beta1, 5.3.0.Final
>
>
> When attempting to move to Log4J 2.0, I've noticed a number of hard deps on log4j classes.
> {{SampleConfigFilesCorrectnessTest}} - this class makes use of a custom appender to analyse what a user is being warned of when a config file is parsed. Why are we using Log4J for this? Our own logging interface should be mocked and messages captured directly.
> {{RehashStressTest}} and {{NucleotideCache}} - seems like a bug, I presume the author intended to use {{org.infinispan.logging.Log}}.
> {{CompressedFileAppender}} and {{ThreadNameFilter}}- can this be written in a way that works with Log4J 1.x as well as 2.x? Or have the SPIs changed that much?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 2 months
[JBoss JIRA] (ISPN-907) SSL access to Hot Rod
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-907?page=com.atlassian.jira.plugin.s... ]
Dan Berindei updated ISPN-907:
------------------------------
Status: Resolved (was: Pull Request Sent)
Fix Version/s: 5.3.0.Beta1
Resolution: Done
> SSL access to Hot Rod
> ---------------------
>
> Key: ISPN-907
> URL: https://issues.jboss.org/browse/ISPN-907
> Project: Infinispan
> Issue Type: Feature Request
> Components: Remote protocols
> Reporter: Galder Zamarreño
> Assignee: Tristan Tarrant
> Labels: hotrod, ssl
> Fix For: 5.3.0.Beta1, 5.3.0.Final
>
> Attachments: ssl.patch, SSLEngineFactory.scala, SSLTest.java
>
>
> Investigate and integrate Adrian's patch for Hot Rod server so that it can accessed via SSL.
> Email from Adrian:
> "While I remember heres a patch to add ssl for infinispan clients.
> I did it a couple of weeks ago, but I dont know when Ill have time
> to finish it off/polish it. It was based on head a few weeks ago,
> but I dont remember which version. :-(
> The horrible part is the way I had to modify all the parameter lists.
> It could really do with passing some config object instead.
> I dont know how to make "git diff" include new uncommitted files so Ive attached them
> seperately.
> See the test for how to use it, but it is basically set the config properties
> (with the relevant infinispan package prefixes)
> use_ssl=true
> key_store_file_name=jks file containing our key
> key_store_password=secret
> trust_store_file_name=jks file containing public keys we trust for authentication
> trust_store_password=another-secret
> Optionally you can get the server to authenticate the client as well
> need_client_auth=true
> which means the server will need a trust store.
> I've also left it so if you dont set the properties it will use the default implementations.
> But this doesnt work out of the box unless you enable the "anon" alogorithms on
> the server, they aren't enabled by default. Those dont authenticate, they just encrypt the traffic.
> The main thing left to do would be change the test to get maven to generate the
> key/trust store in a well defined place in "target".
> Other comments:
> * The code on the serrver will also work for other protocols as well, e.g. memcached
> if the client supports ssl
> * The ssl context construction is pretty similar in the client/server
> and could probably be shared if I knew where to put shared stuff in the codebase. :-)
> * There is some commented out bits where I think the client/server should really
> be adding socket timeouts. Otherwise network drops/splits could cause the connection
> to hang forever. There should at least be a connection timeout on the socket construction,
> if you dont want to implement a full blown ping to continually test the connection rather
> than just ping on start - which doesnt run until after the connection timeout is needed.
> * I had to modify the system property handling so you can have a default of "null".
> I only did this for Strings, might not be relevant for others?
> * Why doesnt the client side do system property replacement like the server?
>
> * Theres a lot of places in the code doing
> InputStream is = openStream();
> useIt(is);
> but never close the stream. While this is probably ok in infinispans use cases
> it is not good practice to leave files open for the gc to close - that could take a while
> to happen and you are hogging system resources.
> Either useIt() should close the stream or the code should be
> InputStream is = openStream();
> try {
> useIt(is);
> }
> finally {
> is.close();
> }
> Feel free to post whatever parts of this message you like in the infinispan forum. :-)"
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 2 months
[JBoss JIRA] (ISPN-2609) Infinispan SpringCache throws java.lang.NullPointerException: Null values are not supported!
by Adrian Nistor (JIRA)
[ https://issues.jboss.org/browse/ISPN-2609?page=com.atlassian.jira.plugin.... ]
Adrian Nistor updated ISPN-2609:
--------------------------------
Status: Resolved (was: Pull Request Sent)
Assignee: Olaf Bergner (was: Mircea Markus)
Fix Version/s: 5.3.0.Beta1
Resolution: Done
Integrated in master. Thanks!
> Infinispan SpringCache throws java.lang.NullPointerException: Null values are not supported!
> --------------------------------------------------------------------------------------------
>
> Key: ISPN-2609
> URL: https://issues.jboss.org/browse/ISPN-2609
> Project: Infinispan
> Issue Type: Bug
> Components: Spring integration
> Affects Versions: 5.1.6.FINAL
> Reporter: Roland Csupor
> Assignee: Olaf Bergner
> Fix For: 5.3.0.Beta1, 5.3.0.Final
>
>
> I trying to use Infinispan as Spring cache, but if my function returns null, I got an exception, cause Spring tries to cache this result value:
> {noformat}
> Caused by: java.lang.NullPointerException: Null values are not supported!
> at org.infinispan.CacheImpl.assertKeyValueNotNull(CacheImpl.java:203) ~[infinispan-core-5.1.6.FINAL.jar:5.1.6.FINAL]
> at org.infinispan.CacheImpl.put(CacheImpl.java:699) ~[infinispan-core-5.1.6.FINAL.jar:5.1.6.FINAL]
> at org.infinispan.CacheImpl.put(CacheImpl.java:694) ~[infinispan-core-5.1.6.FINAL.jar:5.1.6.FINAL]
> at org.infinispan.CacheSupport.put(CacheSupport.java:53) ~[infinispan-core-5.1.6.FINAL.jar:5.1.6.FINAL]
> at org.infinispan.spring.provider.SpringCache.put(SpringCache.java:83) ~[infinispan-spring-5.1.6.FINAL.jar:5.1.6.FINAL]
> at org.springframework.cache.interceptor.CacheAspectSupport.update(CacheAspectSupport.java:390) ~[spring-context-3.1.2.RELEASE.jar:3.1.2.RELEASE]
> at org.springframework.cache.interceptor.CacheAspectSupport.execute(CacheAspectSupport.java:218) ~[spring-context-3.1.2.RELEASE.jar:3.1.2.RELEASE]
> at org.springframework.cache.interceptor.CacheInterceptor.invoke(CacheInterceptor.java:66) ~[spring-context-3.1.2.RELEASE.jar:3.1.2.RELEASE]
> {noformat}
> Did I misconfigured something?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 2 months
[JBoss JIRA] (ISPN-2609) Infinispan SpringCache throws java.lang.NullPointerException: Null values are not supported!
by Adrian Nistor (JIRA)
[ https://issues.jboss.org/browse/ISPN-2609?page=com.atlassian.jira.plugin.... ]
Adrian Nistor updated ISPN-2609:
--------------------------------
Status: Pull Request Sent (was: Reopened)
Git Pull Request: https://github.com/infinispan/infinispan/pull/1724
> Infinispan SpringCache throws java.lang.NullPointerException: Null values are not supported!
> --------------------------------------------------------------------------------------------
>
> Key: ISPN-2609
> URL: https://issues.jboss.org/browse/ISPN-2609
> Project: Infinispan
> Issue Type: Bug
> Components: Spring integration
> Affects Versions: 5.1.6.FINAL
> Reporter: Roland Csupor
> Assignee: Mircea Markus
> Fix For: 5.3.0.Final
>
>
> I trying to use Infinispan as Spring cache, but if my function returns null, I got an exception, cause Spring tries to cache this result value:
> {noformat}
> Caused by: java.lang.NullPointerException: Null values are not supported!
> at org.infinispan.CacheImpl.assertKeyValueNotNull(CacheImpl.java:203) ~[infinispan-core-5.1.6.FINAL.jar:5.1.6.FINAL]
> at org.infinispan.CacheImpl.put(CacheImpl.java:699) ~[infinispan-core-5.1.6.FINAL.jar:5.1.6.FINAL]
> at org.infinispan.CacheImpl.put(CacheImpl.java:694) ~[infinispan-core-5.1.6.FINAL.jar:5.1.6.FINAL]
> at org.infinispan.CacheSupport.put(CacheSupport.java:53) ~[infinispan-core-5.1.6.FINAL.jar:5.1.6.FINAL]
> at org.infinispan.spring.provider.SpringCache.put(SpringCache.java:83) ~[infinispan-spring-5.1.6.FINAL.jar:5.1.6.FINAL]
> at org.springframework.cache.interceptor.CacheAspectSupport.update(CacheAspectSupport.java:390) ~[spring-context-3.1.2.RELEASE.jar:3.1.2.RELEASE]
> at org.springframework.cache.interceptor.CacheAspectSupport.execute(CacheAspectSupport.java:218) ~[spring-context-3.1.2.RELEASE.jar:3.1.2.RELEASE]
> at org.springframework.cache.interceptor.CacheInterceptor.invoke(CacheInterceptor.java:66) ~[spring-context-3.1.2.RELEASE.jar:3.1.2.RELEASE]
> {noformat}
> Did I misconfigured something?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 2 months