April 2013 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-907) SSL access to Hot Rod

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-907?page=com.atlassian.jira.plugin.s... ] Tristan Tarrant updated ISPN-907: --------------------------------- Fix Version/s: 5.3.0.Final (was: 6.0.0.Final) > 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.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, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2924) Update ConcurrentHashMapV8 and dependant classes

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-2924?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-2924: ----------------------------------- Description: Update with latest changes in http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/jsr166e/ > Update ConcurrentHashMapV8 and dependant classes > ------------------------------------------------ > > Key: ISPN-2924 > URL: https://issues.jboss.org/browse/ISPN-2924 > Project: Infinispan > Issue Type: Enhancement > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Fix For: 5.3.0.Final > > > Update with latest changes in http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/jsr166e/ -- 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, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2756) Enabling/disabling RpcManager statistics via JMX doesn't work

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-2756?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-2756: ----------------------------------------------- Richard Janík <rjanik(a)redhat.com> changed the Status of [bug 908700|https://bugzilla.redhat.com/show_bug.cgi?id=908700] from NEW to VERIFIED > Enabling/disabling RpcManager statistics via JMX doesn't work > ------------------------------------------------------------- > > Key: ISPN-2756 > URL: https://issues.jboss.org/browse/ISPN-2756 > Project: Infinispan > Issue Type: Bug > Components: JMX, reporting and management > Affects Versions: 5.2.0.CR2 > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 5.2.0.Final > > > The test RpcManagerMBeanTest.testEnableJmxStats tries to write to the "StatisticsEnabled" attribute but fails. The operation doesn't throw an exception, but it does log this WARN message: > {noformat} > 10:43:42,079 WARN (testng-RpcManagerMBeanTest:) [ResourceDMBean] ISPN000043: Exception while writing value for attribute statisticsEnabled > java.lang.NullPointerException > at org.infinispan.jmx.ResourceDMBean$InvokableSetterBasedMBeanAttributeInfo.invoke(ResourceDMBean.java:391) > at org.infinispan.jmx.ResourceDMBean.setNamedAttribute(ResourceDMBean.java:325) > at org.infinispan.jmx.ResourceDMBean.setAttribute(ResourceDMBean.java:212) > at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.setAttribute(DefaultMBeanServerInterceptor.java:746) > at com.sun.jmx.mbeanserver.JmxMBeanServer.setAttribute(JmxMBeanServer.java:729) > at org.infinispan.jmx.RpcManagerMBeanTest.testEnableJmxStats(RpcManagerMBeanTest.java:134) > {noformat} > Because statistics are still enabled, the test then fails with an assertion error: > {noformat} > 10:43:42,464 ERROR (testng-RpcManagerMBeanTest:) [UnitTestTestNGListener] Test testEnableJmxStats(org.infinispan.jmx.RpcManagerMBeanTest) failed. > java.lang.AssertionError: expected [-1] but found [1] > 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:165) > at org.infinispan.jmx.RpcManagerMBeanTest.testEnableJmxStats(RpcManagerMBeanTest.java:138) > {noformat} -- 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, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2756) Enabling/disabling RpcManager statistics via JMX doesn't work

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-2756?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-2756: ----------------------------------------------- Richard Janík <rjanik(a)redhat.com> made a comment on [bug 908700|https://bugzilla.redhat.com/show_bug.cgi?id=908700] Haven't seen this for a long time. Verified. > Enabling/disabling RpcManager statistics via JMX doesn't work > ------------------------------------------------------------- > > Key: ISPN-2756 > URL: https://issues.jboss.org/browse/ISPN-2756 > Project: Infinispan > Issue Type: Bug > Components: JMX, reporting and management > Affects Versions: 5.2.0.CR2 > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 5.2.0.Final > > > The test RpcManagerMBeanTest.testEnableJmxStats tries to write to the "StatisticsEnabled" attribute but fails. The operation doesn't throw an exception, but it does log this WARN message: > {noformat} > 10:43:42,079 WARN (testng-RpcManagerMBeanTest:) [ResourceDMBean] ISPN000043: Exception while writing value for attribute statisticsEnabled > java.lang.NullPointerException > at org.infinispan.jmx.ResourceDMBean$InvokableSetterBasedMBeanAttributeInfo.invoke(ResourceDMBean.java:391) > at org.infinispan.jmx.ResourceDMBean.setNamedAttribute(ResourceDMBean.java:325) > at org.infinispan.jmx.ResourceDMBean.setAttribute(ResourceDMBean.java:212) > at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.setAttribute(DefaultMBeanServerInterceptor.java:746) > at com.sun.jmx.mbeanserver.JmxMBeanServer.setAttribute(JmxMBeanServer.java:729) > at org.infinispan.jmx.RpcManagerMBeanTest.testEnableJmxStats(RpcManagerMBeanTest.java:134) > {noformat} > Because statistics are still enabled, the test then fails with an assertion error: > {noformat} > 10:43:42,464 ERROR (testng-RpcManagerMBeanTest:) [UnitTestTestNGListener] Test testEnableJmxStats(org.infinispan.jmx.RpcManagerMBeanTest) failed. > java.lang.AssertionError: expected [-1] but found [1] > 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:165) > at org.infinispan.jmx.RpcManagerMBeanTest.testEnableJmxStats(RpcManagerMBeanTest.java:138) > {noformat} -- 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, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2990) L1ManagerImpl doesn't reliably invalidate with async caches

by Sebastian Tusk (JIRA)

Sebastian Tusk created ISPN-2990: ------------------------------------ Summary: L1ManagerImpl doesn't reliably invalidate with async caches Key: ISPN-2990 URL: https://issues.jboss.org/browse/ISPN-2990 Project: Infinispan Issue Type: Bug Components: Distributed Cache Affects Versions: 5.2.1.Final Reporter: Sebastian Tusk Assignee: Mircea Markus B is owner of k,v1 A has k,v1 in L1 1. TX: A puts k,v2 2. TX: A sends async PrepareCommand k,v2 to B (one-phase-commit) 3. TX: A removes k,v1 from L1 4. A putForExternalRead k,v1 and has it in L1 again 5. TX: B executes PrepareCommand k,v2 but doesn't send invalidation to origin Result: A has k,v1 and B has k,v2 Solution: For async caches send invalidation to origin too. The problem is that the owner updates the cache entry asynchronously. This gives the origin of the transaction time to request the entry. Here an outdated version is received and placed in L1. The owner never invalidates the entry and as result the cache is inconsistent. -- 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, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2989) View rollback never unlocks stateTransferLock

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-2989?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated ISPN-2989: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=947614 > View rollback never unlocks stateTransferLock > --------------------------------------------- > > Key: ISPN-2989 > URL: https://issues.jboss.org/browse/ISPN-2989 > Project: Infinispan > Issue Type: Bug > Components: State transfer > Affects Versions: 5.1.7.Final > Reporter: Dennis Reed > Assignee: Mircea Markus > > When a new cache view prepare fails and is rolled back (for example due to a TimeoutException), the state transfer lock is never released, causing all future operations to fail with a StateTransferInProgressException timeout. -- 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, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2989) View rollback never unlocks stateTransferLock

by Dennis Reed (JIRA)

[ https://issues.jboss.org/browse/ISPN-2989?page=com.atlassian.jira.plugin.... ] Dennis Reed commented on ISPN-2989: ----------------------------------- Note: this code no longer exists in 5.2+ after NBST implementation. > View rollback never unlocks stateTransferLock > --------------------------------------------- > > Key: ISPN-2989 > URL: https://issues.jboss.org/browse/ISPN-2989 > Project: Infinispan > Issue Type: Bug > Components: State transfer > Affects Versions: 5.1.7.Final > Reporter: Dennis Reed > Assignee: Mircea Markus > > When a new cache view prepare fails and is rolled back (for example due to a TimeoutException), the state transfer lock is never released, causing all future operations to fail with a StateTransferInProgressException timeout. -- 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, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2989) View rollback never unlocks stateTransferLock

by Dennis Reed (JIRA)

[ https://issues.jboss.org/browse/ISPN-2989?page=com.atlassian.jira.plugin.... ] Dennis Reed commented on ISPN-2989: ----------------------------------- StateTransferLock#blockNewTransactions is called on a prepare from: CacheViewsManagerImpl#handlePrepareView -> BaseStateTransferManagerImpl#prepareView -> BaseStateTransferTask#performStateTransfer -> *#doPerformStateTransfer StateTransferLock#unblockNewTransactions is called on a commit from: CacheViewsManagerImpl#handleCommitView -> BaseStateTransferManagerImpl#postInstallView unblockNewTransactions is never called during a rollback! It looks like BaseStateTransferManagerImpl#rollbackView should unblock it. (just copy the unblock code from postInstallView). > View rollback never unlocks stateTransferLock > --------------------------------------------- > > Key: ISPN-2989 > URL: https://issues.jboss.org/browse/ISPN-2989 > Project: Infinispan > Issue Type: Bug > Components: State transfer > Affects Versions: 5.1.7.Final > Reporter: Dennis Reed > Assignee: Mircea Markus > > When a new cache view prepare fails and is rolled back (for example due to a TimeoutException), the state transfer lock is never released, causing all future operations to fail with a StateTransferInProgressException timeout. -- 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, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2989) View rollback never unlocks stateTransferLock

by Dennis Reed (JIRA)

Dennis Reed created ISPN-2989: --------------------------------- Summary: View rollback never unlocks stateTransferLock Key: ISPN-2989 URL: https://issues.jboss.org/browse/ISPN-2989 Project: Infinispan Issue Type: Bug Components: State transfer Affects Versions: 5.1.7.Final Reporter: Dennis Reed Assignee: Mircea Markus When a new cache view prepare fails and is rolled back (for example due to a TimeoutException), the state transfer lock is never released, causing all future operations to fail with a StateTransferInProgressException timeout. -- 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, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2987) Fix for ISPN-2808: BaseRpcCommand should provide an implementation of the new method

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-2987?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-2987: ------------------------------ Status: Pull Request Sent (was: Coding In Progress) Git Pull Request: https://github.com/infinispan/infinispan/pull/1744 > Fix for ISPN-2808: BaseRpcCommand should provide an implementation of the new method > ------------------------------------------------------------------------------------ > > Key: ISPN-2987 > URL: https://issues.jboss.org/browse/ISPN-2987 > Project: Infinispan > Issue Type: Bug > Components: RPC > Affects Versions: 5.3.0.Alpha1 > Reporter: Pedro Ruivo > Assignee: Pedro Ruivo > Priority: Blocker > Fix For: 5.3.0.Alpha1 > > > It has broken the integration with other projects -- 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, 9 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues April 2013