Using
JBoss 7.1.0 EAP
Infinispan 8.2.8.Final-redhat-1
Is it possible to use passivation and memory based evictions with infinispan?
When I try to use this configuration:
ConfigurationBuilder config = new ConfigurationBuilder();
config.clustering().cacheMode(CacheMode.DIST_SYNC);
config.eviction()
.type(EvictionType.MEMORY)
.size(heapAllocationForCache);
config.persistence().passivation(true)
.addSingleFileStore()
.location("/path/to/cache-dir")
.purgeOnStartup(true);
When I try this configuration I get this error:
2019-10-30 11:28:59 INFO [] EvictionConfigurationBuilder:114 - ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
Here is the validation logic:
if (!strategy.isEnabled()) {
if (maxEntries > 0) {
strategy(EvictionStrategy.LIRS);
log.debugf("Max entries configured (%d) without eviction strategy. Eviction strategy overriden to %s", maxEntries, strategy);
} else if (getBuilder().persistence().passivation() && strategy != EvictionStrategy.MANUAL) {
log.passivationWithoutEviction(); // <--------- this line is where the warning comes from
}
}
Can you not use memory based eviction with Passivation? Or is this a bug with the validation on Infinispan 8.2.x?
Note we cannot set
strategy(EvictionStrategy.LRU) etc because of this code:
https://github.com/infinispan/infinispan/blob/8.2.11.Final/core/src/main/java/org/infinispan/configuration/cache/EvictionConfigurationBuilder.java
if (strategy.isEnabled() && maxEntries <= 0)
throw new CacheConfigurationException("Eviction maxEntries value cannot be less than or equal to zero if eviction is enabled");
As you use EAP the I would not use the Infinispan bits inside of EAP as this are not meant to be used for application cache - also you can not update the version as this is not supported.
Best approach is to use RHDG as a supported product or (if you can't) use the latest Infinispan version to have a full feature set and the latest fixes.
Also with 9.x yuo can use off-heap memory which provide often a better performance.
See this post for more details Unable to use Infinispan embedded cachemanager on JBoss EAP 7.2
You should be able to. The problem though is that in 8.2 the default strategy is NONE [1]. Setting the strategy to LIRS or LRU should fix your issue. Newer versions of Infinispan this setting is no longer required unless you want to set it to MANUAL eviction strategy.
config.eviction()
.type(EvictionType.MEMORY)
.strategy(EvictionStrategy.LRU)
.size(heapAllocationForCache);
[1] https://github.com/infinispan/infinispan/blob/8.2.x/core/src/main/java/org/infinispan/configuration/cache/EvictionConfiguration.java#L19
Related
Product name: Open Liberty
Product version: 20.0.0.7
Product edition: Open
is it possible to implement persistent ejbtimers on filesystem based default derby DB, using embedded.derby.DB
I installed derby in /tmp/derby, configured server.xml with the following, i don't see any file being created under /tmp when I start the OpenLiberty JVM, what am I missing in this approach?
<feature>ejbPersistentTimer-3.2</feature>
<library id="DerbyLib">
<fileset dir="/tmp/derby/lib" includes="derby.jar"/>
</library>
<dataSource id="DefaultDerbyDatasource" jndiName="jdbc/defaultDatasource" statementCacheSize="10" transactional="false">
<jdbcDriver libraryRef="DerbyLib"/>
<properties.derby.embedded createDatabase="create" databaseName="/tmp/sample.ejbtimer.db" shutdownDatabase="false"/>
<containerAuthData user="user1" password="derbyuser" />
</dataSource>
Check this book - http://www.redbooks.ibm.com/abstracts/sg248076.html?Open
In chapter "5.2.4 Developing applications using timers" you should find all stuff needed.
UPDATE based on comment:
If you look to the book and to the log it shows:
[INFO ] CNTR4000I: The ITSOTimerApp.war EJB module in the ITSOTimerApp
application is starting.
[INFO ] CNTR0167I: The server is binding the com.ibm.itso.timers.TimerBean
interface of the TimerBean enterprise bean in the ITSOTimerApp.war module of
the ITSOTimerApp application. The binding location is:
java:global/ITSOTimerApp/TimerBean!com.ibm.itso.timers.TimerBean
[INFO ] DSRA8203I: Database product name : Apache Derby
[INFO ] DSRA8204I: Database product version : 10.8.2.3 - (1212722)
[INFO ] DSRA8205I: JDBC driver name : Apache Derby Embedded JDBC Driver
[INFO ] DSRA8206I: JDBC driver version : 10.8.2.3 - (1212722)
[INFO ] CNTR0219I: The server created 1 persistent automatic timer or timers
and 0 non-persistent automatic timer or timers for the ITSOTimerApp.war module.
TimerBean initialized
It creates db 'as needed' so if you dont have any persistent timers beans, the service will not be started nor db created.
Liberty in general follows lazy model and doesn't start unneeded services.
So create sample application and then your DB will be created. There is no need to create database nor connection to database when no one is requesting for it.
In general, it is not advisable to use Derby Embedded database for persistent EJB timers due to limitations of Derby Embedded that all connections use the same class loader (implying the same JVM as well). This means you cannot leverage the failover capability (missedTaskThreshold setting) or even have multiple servers connected to the database at all. If you decide to use a Derby Embedded database, it means that you are limiting yourself to a single server. You can decide for yourself if that is acceptable based on what your needs are.
In the case of the example configuration you gave, it doesn't work because the EJB persistent timers feature in Liberty has no way of knowing that you dataSource, "DefaultDerbyDatasource" with jndiName "jdbc/defaultDatasource" is the data source that it ought to use. Also, it is incorrect to specify transactional="false" on the data source that you want EJB persistent timers to use because EJB persistent timers are transactional in nature.
I assume that what you are intending to do is configure the Java EE default data source and expecting EJB persistent timers to use it. That approach will work, except that you'll need to configure the Java EE default data source, you need to specify the id as "DefaultDataSource".
Here is an example that switches your configured data source to the Java EE default data source and removes the transactional="false" config,
<library id="DerbyLib">
<fileset dir="/tmp/derby/lib" includes="derby.jar"/>
</library>
<dataSource id="DefaultDataSource" jndiName="jdbc/defaultDatasource" statementCacheSize="10">
<jdbcDriver libraryRef="DerbyLib"/>
<properties.derby.embedded createDatabase="create" databaseName="/tmp/sample.ejbtimer.db" shutdownDatabase="false"/>
<containerAuthData user="user1" password="derbyuser" />
</dataSource>
By default, the EJB persistent timers feature should create database tables once the application runs and the EJB module is used.
However, you may be able to verify the configuration prior to that point by running the ddlgen utility (after correcting the configuration as above)
https://www.ibm.com/docs/en/was-liberty/base?topic=line-running-ddlgen-utility
which gives you the opportunity to see the DDL that it will use and optionally to run it manually (which is useful if you turned off automatic table creation via
<databaseStore id="defaultDatabaseStore" createTables="false"/> )
My tech stack
EclipseLink 2.6.3, JPA 2.0, IBM Websphere 8.5.5.8 and JTA enabled
Currently in my project I have enabled SHARED_CACHE mode and have below cache settings on all my non read only entities and CacheType is SOFT_WEAK
#Cacheable
#Cache(
alwaysRefresh=true,
refreshOnlyIfNewer=true,
coordinationType=CacheCoordinationType.SEND_NEW_OBJECTS_WITH_CHANGES,
expiry=3600000 //changed according to entity
)
I have also configured JMS cache coordination as my app is hosted on clustered environment.
My question is are my cache settings are inline with EclipseLink best practices in accordance with cache coordination in place?
Should I need to change anything apart from what mentioned above ?
UPDATE:
Now I have an issue with this cache coordination settings i.e CacheCoordinationType.SEND_NEW_OBJECTS_WITH_CHANGES,it enters into deadlock mode and ends up locking threads and my server crashes.Not sure what's happening here. I've debugged source code and it shows it acquires locks on thread & cache of the object to merge the changes but that should be happening in minimal time.Why is it taking 10mins for the locks to release?
Any help would be appreciated.
Below is the error I'm facing in my QA/Prod env.
[14/09/17 13:37:16:015 BST] 000003d4 SystemOut O [EL Finer]: 2017-09-14 13:37:16.014--ServerSession(772764452)--Thread(Thread[SIBJMSRAThreadPool : 7,5,main])--
Potential deadlock encountered while thread: SIBJMSRAThreadPool : 7 attempted to lock object of class: class com.jlr.vista.business.order.model.event.StatusUpdateEvent with id: 324,836,575, entering deadlock avoidance algorithm. This is a notice only.
[14/09/17 13:47:16:015 BST] 000003d4 SystemOut O [EL Severe]: 2017-09-14 13:47:16.015--ServerSession(772764452)--Thread(Thread[SIBJMSRAThreadPool : 7,5,main])--MAX TIME 600 seconds EXCEEDED FOR WRITELOCKMANAGER WAIT. Waiting on Entity type: com.business.model.event.UpdateEvent with pk: 324,836,575 currently locked by thread: SIBJMSRAThreadPool : 1 with the following trace:
atsun.misc.Unsafe.park(Native Method)
atjava.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:237)
atjava.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2187)
atcom.ibm.ws.util.BoundedBuffer$GetQueueLock.await(BoundedBuffer.java:286)
atcom.ibm.ws.util.BoundedBuffer.waitGet_(BoundedBuffer.java:425)
atcom.ibm.ws.util.BoundedBuffer.take(BoundedBuffer.java:823)
atcom.ibm.ws.util.ThreadPool.getTask(ThreadPool.java:1059)
atcom.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:1916)
(There is no English translation for this message.)
NOTE: My application is very large and have almost 150+ entities which are writable.
We are running on 32bit windows and since upgrading from 1.4.1 to 2.2.2, we are seeing the following memory in stdout (numbers not exact):
INFO: Database 'BLAH' uses 770MB/912MB of DISKCACHE memory, while Heap is not completely used (usedHeap=123MB maxHeap=512MB). To improve performance set maxHeap to 124MB and DISKCACHE to 1296MB
With 32bit, we can only set a max of Xmx + storage.diskCache.bufferSize ~= 1.4gb without getting OOM or performance issues. Any combination of different sizes of either of these two configurable variables results in a variant of the above message.
Is there a way to suppress the above profiler/memory checker messages?
You can disable the profiler with:
java ... -Dprofiler.enabled=false ...
Set that configuration in your server.sh or in the last section of config/orientdb-server-config.xml file.
I have installed libaio on ubuntu, and running HornetQ embedded, with programmatic config, I am doing this to use AIO on journal, but I see on startup, it's not getting AIO, always using NIO. Any way to determine why it would be failing?
Configuration configuration = new ConfigurationImpl();
boolean supportsAIO = AIOSequentialFileFactory.isSupported();
if (supportsAIO) {
configuration.setJournalType(JournalType.ASYNCIO);
log.info("** using AIO **");
} else {
configuration.setJournalType(JournalType.NIO);
log.info("** using NIO **");
}
You have to define -Djava.library.path=PathToYourBinaries
and you should have these files at PathToYourBinaries:
libHornetQAIO32.so
libHornetQAIO64.so
if you still can't load it then it will be a matter of recompiling the natives at your system, but most likely you just need to define java.library.path.
I am currently trying to replace Hypersonic with MS-SQL 2008 R2 in JBoss AS 5.1.0GA.
I have followed the instructions in the JBoss Server Configuration Guide, however the server fails to load with this error:
2013-09-26 17:06:04,479 WARN [org.jboss.resource.adapter.jms.inflow.JmsActivation] (WorkManager(2)-3) Failure in jms activation org.jboss.resource.adapter.jms.inflow.JmsActivationSpec#8bb1eb(ra=org.jboss.resource.adapter.jms.JmsResourceAdapter#c54851 destination=queue/iam/im/jms/queue/wpUtilQueue destinationType=javax.jms.Queue tx=true durable=false reconnect=10 provider=DefaultJMSProvider user=null maxMessages=1 minSession=1 maxSession=15 keepAlive=30000 useDLQ=true DLQHandler=org.jboss.resource.adapter.jms.inflow.dlq.GenericDLQHandler DLQJndiName=queue/DLQ DLQUser=null DLQMaxResent=10)
javax.naming.NameNotFoundException: DLQ not bound
(I left out the stack trace for brevity; it isn't important.)
I have checked, and DLQ is defined in destinations-service.xml
I'm not sure where to proceed from here; every response I can find on Google seems to suggest that defining the queue in destinations-service.xml has solved the issue for almost everyone.
Any help would be appreciated.
It turns out that the instructions in the Configuration Guide aren't 100% complete. The issue was that a ChannelFactory was referenced in the mssql-persistence-service.xml; however, this environment is not clustered, and so there were no ChannelFactory objects defined.
Removing the reference to the ChannelFactory was sufficient to resolve the issue.