[JBoss JIRA] (ISPN-2806) Add a more efficient FileCacheStore implementation
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-2806?page=com.atlassian.jira.plugin.... ]
Dan Berindei commented on ISPN-2806:
------------------------------------
Regarding ISPN-517, asynchronous I/O won't necessarily bring a big benefit for us, as we already have a separate mechanism for asynchronous cache stores. But it might be cheaper to write directly to disk, bypassing the kernel buffers, than to write and then do a separate fsync.
> Add a more efficient FileCacheStore implementation
> --------------------------------------------------
>
> Key: ISPN-2806
> URL: https://issues.jboss.org/browse/ISPN-2806
> Project: Infinispan
> Issue Type: Feature Request
> Components: Loaders and Stores
> Reporter: Mircea Markus
> Assignee: Dan Berindei
> Priority: Critical
> Fix For: 5.3.0.Final
>
>
> Based on the feedback we got from community/users Infinispan needs a more efficient FileCacheStore implementation. See the [design document|https://community.jboss.org/wiki/FileCacheStoreRedesign] that contains several suggestion of implementing it. It would be nice to also have a benchmark written in order to evaluate the performance between various implementation suggestion.
--
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 Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-907?page=com.atlassian.jira.plugin.s... ]
Tristan Tarrant updated ISPN-907:
---------------------------------
Status: Pull Request Sent (was: Coding In Progress)
Git Pull Request: https://github.com/infinispan/infinispan/pull/1762
> 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, 2 months
[JBoss JIRA] (ISPN-3010) Cache GET operation retrieves a Class instance instead of expected type
by Sanne Grinovero (JIRA)
Sanne Grinovero created ISPN-3010:
-------------------------------------
Summary: Cache GET operation retrieves a Class instance instead of expected type
Key: ISPN-3010
URL: https://issues.jboss.org/browse/ISPN-3010
Project: Infinispan
Issue Type: Bug
Affects Versions: 5.2.5.Final
Reporter: Sanne Grinovero
Assignee: Mircea Markus
http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/hibernate-search-mast...
{quote}
Error Message
HSEARCH000103: Unable to initialize IndexManager emails
Stacktrace
org.hibernate.search.SearchException: HSEARCH000103: Unable to initialize IndexManager emails
at org.hibernate.search.indexes.impl.IndexManagerHolder.createIndexManager(IndexManagerHolder.java:230)
at org.hibernate.search.indexes.impl.IndexManagerHolder.buildEntityIndexBinding(IndexManagerHolder.java:102)
at org.hibernate.search.spi.SearchFactoryBuilder.initDocumentBuilders(SearchFactoryBuilder.java:414)
at org.hibernate.search.spi.SearchFactoryBuilder.buildNewSearchFactory(SearchFactoryBuilder.java:222)
at org.hibernate.search.spi.SearchFactoryBuilder.buildSearchFactory(SearchFactoryBuilder.java:146)
at org.hibernate.search.event.impl.FullTextIndexEventListener.initialize(FullTextIndexEventListener.java:130)
at org.hibernate.search.hcore.impl.HibernateSearchIntegrator.integrate(HibernateSearchIntegrator.java:83)
at org.hibernate.internal.SessionFactoryImpl.<init>(SessionFactoryImpl.java:303)
at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1750)
at org.hibernate.search.test.util.FullTextSessionBuilder.build(FullTextSessionBuilder.java:182)
at org.hibernate.search.infinispan.StoredIndexTest.startNode(StoredIndexTest.java:121)
at org.hibernate.search.infinispan.StoredIndexTest.testRestartingNode(StoredIndexTest.java:53)
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.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
at org.junit.runners.BlockJUnit4ClassRunner.runNotIgnored(BlockJUnit4ClassRunner.java:79)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:71)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:49)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184)
at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:236)
at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:134)
at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:113)
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.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:103)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:74)
Caused by: java.lang.ClassCastException: java.lang.Class cannot be cast to [B
at org.infinispan.lucene.SingleChunkIndexInput.<init>(SingleChunkIndexInput.java:49)
at org.infinispan.lucene.InfinispanDirectory.openInput(InfinispanDirectory.java:290)
at org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:620)
at org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:554)
at org.apache.lucene.index.SegmentInfos.read(SegmentInfos.java:359)
at org.apache.lucene.index.IndexReader.indexExists(IndexReader.java:1099)
at org.hibernate.search.store.impl.DirectoryProviderHelper.initializeIndexIfNeeded(DirectoryProviderHelper.java:155)
at org.hibernate.search.infinispan.impl.InfinispanDirectoryProvider.start(InfinispanDirectoryProvider.java:103)
at org.hibernate.search.indexes.impl.DirectoryBasedIndexManager.initialize(DirectoryBasedIndexManager.java:104)
at org.hibernate.search.indexes.impl.IndexManagerHolder.createIndexManager(IndexManagerHolder.java:227)
... 42 more
{quote}
--
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-3010) Cache GET operation retrieves a Class instance instead of expected type
by Sanne Grinovero (JIRA)
[ https://issues.jboss.org/browse/ISPN-3010?page=com.atlassian.jira.plugin.... ]
Sanne Grinovero commented on ISPN-3010:
---------------------------------------
Note the failing test is running on Windows.
> Cache GET operation retrieves a Class instance instead of expected type
> -----------------------------------------------------------------------
>
> Key: ISPN-3010
> URL: https://issues.jboss.org/browse/ISPN-3010
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 5.2.5.Final
> Reporter: Sanne Grinovero
> Assignee: Mircea Markus
> Labels: stable_embedded_query
>
> http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/hibernate-search-mast...
> {quote}
> Error Message
> HSEARCH000103: Unable to initialize IndexManager emails
> Stacktrace
> org.hibernate.search.SearchException: HSEARCH000103: Unable to initialize IndexManager emails
> at org.hibernate.search.indexes.impl.IndexManagerHolder.createIndexManager(IndexManagerHolder.java:230)
> at org.hibernate.search.indexes.impl.IndexManagerHolder.buildEntityIndexBinding(IndexManagerHolder.java:102)
> at org.hibernate.search.spi.SearchFactoryBuilder.initDocumentBuilders(SearchFactoryBuilder.java:414)
> at org.hibernate.search.spi.SearchFactoryBuilder.buildNewSearchFactory(SearchFactoryBuilder.java:222)
> at org.hibernate.search.spi.SearchFactoryBuilder.buildSearchFactory(SearchFactoryBuilder.java:146)
> at org.hibernate.search.event.impl.FullTextIndexEventListener.initialize(FullTextIndexEventListener.java:130)
> at org.hibernate.search.hcore.impl.HibernateSearchIntegrator.integrate(HibernateSearchIntegrator.java:83)
> at org.hibernate.internal.SessionFactoryImpl.<init>(SessionFactoryImpl.java:303)
> at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1750)
> at org.hibernate.search.test.util.FullTextSessionBuilder.build(FullTextSessionBuilder.java:182)
> at org.hibernate.search.infinispan.StoredIndexTest.startNode(StoredIndexTest.java:121)
> at org.hibernate.search.infinispan.StoredIndexTest.testRestartingNode(StoredIndexTest.java:53)
> 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.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
> at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
> at org.junit.runners.BlockJUnit4ClassRunner.runNotIgnored(BlockJUnit4ClassRunner.java:79)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:71)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:49)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184)
> at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
> at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
> at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:236)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:134)
> at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:113)
> 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.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
> at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
> at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
> at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:103)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:74)
> Caused by: java.lang.ClassCastException: java.lang.Class cannot be cast to [B
> at org.infinispan.lucene.SingleChunkIndexInput.<init>(SingleChunkIndexInput.java:49)
> at org.infinispan.lucene.InfinispanDirectory.openInput(InfinispanDirectory.java:290)
> at org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:620)
> at org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:554)
> at org.apache.lucene.index.SegmentInfos.read(SegmentInfos.java:359)
> at org.apache.lucene.index.IndexReader.indexExists(IndexReader.java:1099)
> at org.hibernate.search.store.impl.DirectoryProviderHelper.initializeIndexIfNeeded(DirectoryProviderHelper.java:155)
> at org.hibernate.search.infinispan.impl.InfinispanDirectoryProvider.start(InfinispanDirectoryProvider.java:103)
> at org.hibernate.search.indexes.impl.DirectoryBasedIndexManager.initialize(DirectoryBasedIndexManager.java:104)
> at org.hibernate.search.indexes.impl.IndexManagerHolder.createIndexManager(IndexManagerHolder.java:227)
> ... 42 more
> {quote}
--
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-2982) CLONE - State transfer does not end because some segments are erroneously reported as unreceived
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-2982?page=com.atlassian.jira.plugin.... ]
Dan Berindei commented on ISPN-2982:
------------------------------------
The "Problems unmarshalling remote command from byte buffer" warning might be related, didn't it have an exception and a stack trace as well? The command that cannot be deserialized might be the {{ClusterTopologyControlCommand(CH_UPDATE)}} that tells the joiner that it has joined successfully.
Note, however, that this exception ({{CacheException: Initial state transfer timed out for cache LuceneIndexesMetadata on PersistentStateTransferQueryDistributedIndexTest-NodeC-6067}}) is a catch-all exception that appears on the node that is trying to join the cluster.
In order for the node to join successfully, all the nodes have to report that they finished receiving state to the coordinator (even if they didn't request any state), and the coordinator then has to tell the joiner that the state transfer is completed. If any of the state transfer steps fails, on any node, the joiner will probably report a state transfer timeout. So in general it's very important to know what the other nodes were doing, in order to find the root problem.
> CLONE - State transfer does not end because some segments are erroneously reported as unreceived
> ------------------------------------------------------------------------------------------------
>
> Key: ISPN-2982
> URL: https://issues.jboss.org/browse/ISPN-2982
> Project: Infinispan
> Issue Type: Bug
> Components: State transfer
> Affects Versions: 5.2.1.Final
> Reporter: Ittay Dror
> Assignee: Adrian Nistor
> Priority: Critical
> Attachments: jgroups.xml
>
>
> Hard to reproduce. I lost the last log where this was visible but still have a stack trace:
> org.infinispan.CacheException: Unable to invoke method public void org.infinispan.statetransfer.StateTransferManagerImpl.waitForInitialStateTransferToComplete() throws java.lang.InterruptedException on object of type StateTransferManagerImpl
> at org.infinispan.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:205)
> at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:879)
> at org.infinispan.factories.AbstractComponentRegistry.invokeStartMethods(AbstractComponentRegistry.java:650)
> at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:639)
> at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:542)
> at org.infinispan.factories.ComponentRegistry.start(ComponentRegistry.java:197)
> at org.infinispan.CacheImpl.start(CacheImpl.java:517)
> at org.infinispan.manager.DefaultCacheManager.wireAndStartCache(DefaultCacheManager.java:689)
> at org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:652)
> at org.infinispan.manager.DefaultCacheManager.access$100(DefaultCacheManager.java:126)
> at org.infinispan.manager.DefaultCacheManager$1.run(DefaultCacheManager.java:574)
> Caused by: org.infinispan.CacheException: Initial state transfer timed out for cache LuceneIndexesMetadata on PersistentStateTransferQueryDistributedIndexTest-NodeC-6067
> at org.infinispan.statetransfer.StateTransferManagerImpl.waitForInitialStateTransferToComplete(StateTransferManagerImpl.java:199)
> at sun.reflect.GeneratedMethodAccessor139.invoke(Unknown Source)
> 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)
> ... 10 more
--
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-3006) Oracle: TableManipulation.tableExists fails, when user has extended permissions
by Thomas Fromm (JIRA)
[ https://issues.jboss.org/browse/ISPN-3006?page=com.atlassian.jira.plugin.... ]
Thomas Fromm edited comment on ISPN-3006 at 4/11/13 11:30 AM:
--------------------------------------------------------------
Honestly I've not tested if using schema prefix within table name prefix already is recognized by the Metadata.getTables. Maybe it simply already works, so in this case I've only to prepend the user name on my side and there is no change required. Let me test it first...
Have tested it, getTables(null, null, "KOSCH.FOOBAR", new String[] {"TABLE"}) does not work.
So I'll change the impl as you said.
was (Author: tfromm):
Honestly I've not tested if using schema prefix within table name prefix already is recognized by the Metadata.getTables. Maybe it simply already works, so in this case I've only to prepend the user name on my side and there is no change required. Let me test it first...
> Oracle: TableManipulation.tableExists fails, when user has extended permissions
> --------------------------------------------------------------------------------
>
> Key: ISPN-3006
> URL: https://issues.jboss.org/browse/ISPN-3006
> Project: Infinispan
> Issue Type: Bug
> Components: Loaders and Stores
> Affects Versions: 5.3.0.Alpha1
> Reporter: Thomas Fromm
> Assignee: Mircea Markus
> Priority: Minor
>
> When an Oracle user has e.g. permissions to visit other schemas, the metaData.getTables returns not only the table matadata of the schema of the current user. So if a table exists in another user it returns true.
> Solution: Since we anyway do not support explicit definition of schema name in configuration, we can use in case of oracle the current user name as schema pattern for getTables(..)
> Other databases has different structures, e.g. in mysql the schema param seems to be ignored. To avoid problems the chance should be limited to oracle at the moment.
--
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