when I use JPA2 + Hibernate 4.3 + Infinispan 6.0 and call
entitymanager.getEntityManagerFactory().getCache().evictAll()
the caches are NOT cleared.
If I invoke the clear command via JMX on a certain cache it works.
My config is empty:
http://www.infinispan.org/schemas/infinispan-config-6.0.xsd"
xmlns="urn:infinispan:config:6.0">
What is the problem here?
Thank you
Eviction is DISABLED by default in 6.0. If you want to use this feature, you have to configure it.
See: http://infinispan.org/docs/6.0.x/user_guide/user_guide.html#_more_defaults
By default when no eviction element is specified, no eviction takes place.
Related
i upgraded my spring boot application to master pom 2.4 version and using cloud configs with the property enabled spring.cloud.bootstrap.enabled = true, I have db password encrypted in cloud properties so by the time i use the db properties i don't have my encryption framework available, so eventually my application failing with invalid username and password .."i have my own encryption service "
i am looking to see load the cloud config properties after i have my encryption service available, but the spring.cloud.bootstrap.enabled makes it load first on application startup, before i upgrade to master pom, i was not using spring.cloud.bootstrap.enabled so i didn't had any issue, with adding the property the order of loading changed, so i am running into an issue. Any help will be greatly appreciated. Thanks
so by the time i use the db properties i don't have my encryption
framework available
Use #DependsOn annotation in the bean that uses the db properties to depend on the encryption framework.
This thing bugs me for sometime now - I've been googling the web and literally nothing on something obvious such as keeping a Solr core persistent on 5.2.1
Each time I restart the service "sudo service solr restart" my cores are getting lost, although the data can still be found in: /var/solr/data.
The persistence flag is no longer supported in 5.x - so what is the alternative ?
Any help would be much appreciated !
I've run into an issue with a non-persistent core as well. Make sure to check the solr log (/var/solr/logs, in my case) for startup details:
ERROR - 2016-04-05 05:05:49.547; [ ]
org.apache.solr.common.SolrException;
null:org.apache.solr.common.SolrException:
Found multiple cores with the name [somecore],
with instancedirs
[/var/solr/data/somecore/] and [/var/solr/data/gettingstarted/]
The gettingstarted core (a sample created on solr installation) had the same core name set in its core.properties.
Deleting the gettingstarted directory resolved this issue.
Solr uses core discovery now, so the persistent flag isn't needed. Any core available in the data dir should be loaded automagically. You might still need the solr.xml file, although it should be enough to just have an empty <solr> element.
The content within the core directory (conf, data, core.properties) should also be present.
I am curious how should I force jboss 7.1.1 to use Apaches Log4j 2 instead of org.jboss.as.logging, because I would like to do some performance comparison of log4j2 and jboss.as.logging (I have given up on log4j because it seems to have similar performance as jboss.as.logging).
Log4j2 Official website: http://logging.apache.org/log4j/2.x/
I suppose I need to create a new module for the log4j2 library in jboss modules.
Then what? Do I need any changes in standalone.xml? Any changes for jboss-deployment-structure.xml?
How can I tell jboss where to search for the log4j2 library?
Thanks for any suggestions. I am a bit stuck here.
JBoss Logging is just a logging facade similar to slf4j. JBoss AS 7 uses JBoss Log Manager for it's log manager.
Without changing some code you and removing the logging subsystem you cannot use another log manager like log4j2 for the server wide log manager. You'd have to make some changes here and remove the STDIO stuff. It's probably not worth the effort TBH.
JBoss Log Manager is fairly fast. You could try using an async-handler to see if that helps performance at all. It probably won't make a significant difference though if you're just using a standard console-handler and file-handler of some sort.
Some ruff measuring results between JBoss Default Logging and Log4J 2 (by configuring it native and therefore skipping the LogManager), by logging with 10 Threads at the same time:
JBoss Default Log Async Rolling File Appender -> 200.000 Logs/minute
Log4j 2 ASync File Appender -> 5.000.000 Logs/minute
These are really only ruff results, the second case uses a different logger and does not use the Log Manager, these things must be measured independently ... maybe I will do that too. Nevertheless, the bottom line is that default logging is damn slow.
I'm using neo4j in a glassfish server through a modified version of Alex Smirnov neo4j JCA connector.
My version is available here : https://github.com/Riduidel/neo4j-connector
I'm using this connector with neo4j 1.8.
As a consequence, when i want to use it, i first install the connector in my Glassfish application server, then use this connector in applications wishing to connect to.
It works OK when using it with fresh stores.
But, when using it with stores created with previous version, I encounter weird bugs.
Typically, I got today the following stack
javax.resource.spi.ResourceAllocationException: Error in allocating a connection. Cause: Failed to transition org.neo4j.kernel.InternalAbstractGraphDatabase$DefaultKernelExtensionLoader#3bbd53b1 from NONE to STOPPED
...
...
.../* JCA internal exception stack */
...
...
Caused by: com.sun.appserv.connectors.internal.api.PoolingException: Failed to transition org.neo4j.kernel.InternalAbstractGraphDatabase$DefaultKernelExtensionLoader#494b584c from NONE to STOPPED
at com.sun.enterprise.resource.pool.ConnectionPool.createSingleResource(ConnectionPool.java:924)
at com.sun.enterprise.resource.pool.ConnectionPool.createResource(ConnectionPool.java:1185)
at com.sun.enterprise.resource.pool.datastructure.RWLockDataStructure.addResource(RWLockDataStructure.java:98)
... 66 more
Caused by: org.neo4j.kernel.lifecycle.LifecycleException: Failed to transition org.neo4j.kernel.InternalAbstractGraphDatabase$DefaultKernelExtensionLoader#494b584c from NONE to STOPPED
at org.neo4j.kernel.lifecycle.LifeSupport$LifecycleInstance.init(LifeSupport.java:388)
at org.neo4j.kernel.lifecycle.LifeSupport.init(LifeSupport.java:82)
at org.neo4j.kernel.lifecycle.LifeSupport.start(LifeSupport.java:116)
at org.neo4j.kernel.InternalAbstractGraphDatabase.run(InternalAbstractGraphDatabase.java:227)
at org.neo4j.kernel.EmbeddedGraphDatabase.<init>(EmbeddedGraphDatabase.java:79)
at org.neo4j.kernel.EmbeddedGraphDatabase.<init>(EmbeddedGraphDatabase.java:70)
at com.netoprise.neo4j.AbstractNeo4jManagedConnectionFactory.createDatabase(AbstractNeo4jManagedConnectionFactory.java:165)
at com.netoprise.neo4j.AbstractNeo4jManagedConnectionFactory.createDatabase(AbstractNeo4jManagedConnectionFactory.java:127)
at com.netoprise.neo4j.Neo4jManagedConnectionFactory.createManagedConnection(Neo4jManagedConnectionFactory.java:163)
at com.sun.enterprise.resource.allocator.ConnectorAllocator.createResource(ConnectorAllocator.java:160)
at com.sun.enterprise.resource.pool.ConnectionPool.createSingleResource(ConnectionPool.java:907)
... 68 more
Caused by: java.lang.AssertionError
at org.neo4j.index.impl.lucene.LuceneDataSource.cleanWriteLocks(LuceneDataSource.java:265)
at org.neo4j.index.impl.lucene.LuceneDataSource.cleanWriteLocks(LuceneDataSource.java:260)
at org.neo4j.index.impl.lucene.LuceneDataSource.cleanWriteLocks(LuceneDataSource.java:260)
at org.neo4j.index.impl.lucene.LuceneDataSource.cleanWriteLocks(LuceneDataSource.java:260)
at org.neo4j.index.impl.lucene.LuceneDataSource.<init>(LuceneDataSource.java:185)
at org.neo4j.index.lucene.LuceneIndexProvider.load(LuceneIndexProvider.java:72)
at org.neo4j.kernel.InternalAbstractGraphDatabase$DefaultKernelExtensionLoader.loadIndexImplementations(InternalAbstractGraphDatabase.java:1171)
at org.neo4j.kernel.InternalAbstractGraphDatabase$DefaultKernelExtensionLoader.init(InternalAbstractGraphDatabase.java:1143)
at org.neo4j.kernel.lifecycle.LifeSupport$LifecycleInstance.init(LifeSupport.java:382)
... 78 more
A fast inspection reveals that this exception is linked to an undeletable "write.lock" file. My write.lock file can't be deleted because I guess migration is not over.
How can I make sure the migration is done before using it without migrating it outside of Glassfish ?
Is there a way to ahve exclusive store migrations in that context ? And if so, how ?
And is it the solution for my problem ?
EDIT 1 Added exception message.
EDIT 2 All this only happen when loaded graph was previously used with a Neo4j 1.5 and now with a Neo4j 1.8 connector. when graph is created by connector, absolutely no error happens.
EDIT 3 Strangely enough, this happens as long as there is no debugger plugged into that code : as soon as I try to debug it, the issue stop appearing. Which make me thinking there may be a migration cleanup mechanism that remvoe the write lock once migration is done, and this cleanup is not performed when using my neo4j JCA connector. Is it a valid observation ?
I am not too familiar with the JCA connector, but to be sure, I would just write a very small migration java class that opens the database, lets it migrate and shut down. Then try it again with the JCA connector?
After further investigations, truth revealed to not be in multiple calls to the EmbeddedGraphDatabase constructor, but instead to multiple identicail IndexProvider being loaded.
I use neo4j embedded in an open-source JCA connector.
In this connector, the org.neo4j.kernel.Service class is replaced by a custom one which contains a workaround regarding service loading for JBoss non shared libraries.
Unfortunatly, in our context, this workaround implies loading twice the index provider :
once using the EAR classloader
once using the Glassfish library classloader.
Why ?
Because, as our neo4j instance is using for application data AND for authentication, neo4j connector jar is put in ${domain}/lib. As a consequence, due to Classloader delegation in application server, the EAR classloader delegates to the Glassfish library classloader, and find this way the LuceneIndexProvider. Then, the Glassfish library classloader is directly used to load the same LuceneIndexProvider class.
This concludes by us having two LuceneIndexProvider objects, both trying to migrate the lucene index. Which lead to the AssertionError as the write.lock file created by the first object should be deleted by the second one, which can't do that.
I've then changed slightly that very specific class to use JBoss workaround only when default loading mechanism do not return any class (seee commit here). This small change worked like a charm, so I think you can considered this issue as fixed.
I am testing the tomcat7 clickstack for our application which has some config parameters set using the built in Config features of Cloudbees. The tomcat7 clickstack does not find them, but the standard tomcat6 container does. I have double checked them and reset them through the cloudbees sdk and they are there and correct, but are coming back as null for tomcat7.
The switch to clickstacks requires us to refactor how the servlet container gets configured so that the injection points such as cloudbees-web.xml and jvm system properties behave consistently across all the servlet container clickstacks.
Some of that refactoring has been committed but some of the work is still in my backlog... Assuming none of the other bees steal that task from my backlog before I get to it ;-)
IF I recall correctly, the parameters should be available as environment variables (sub optimal I know, but all containers should be giving this as a consistent UX for all clickstacks, eg both non-java based and java-based) and may be already available as system properties (again sub optimal, but the java container refactoring should be giving this as a consistent UX for all java based clickstacks). The consistent java servlet UX has not been committed yet but should be available soon.