My Ehcache(2.10.4) has been utilising heap memory a lot by default, what is the procedure to configure off-heap memory on the same?
EHCache Config of the same:
<defaultCache
maxElementsInMemory="8000"
maxElementsOnDisk="10000"
eternal="false"
timeToIdleSeconds="3600"
timeToLiveSeconds="3600"
overflowToDisk="true"
diskPersistent="false"
diskExpiryThreadIntervalSeconds="120"
memoryStoreEvictionPolicy="LRU"
/>
Is there something that needs to be done for configuring off-heap memory.
Ehcache 2.x offers offheap support only as a commercial feature.
However Ehcache 3.x offers it as part of the open source version.
Related
For my application I have a combination of a REST service; and a web site. Both of which are within the same web app.
To secure both I added this security domain to my standalone.xml. (MyAuthClass is a basic authentication extension that reaches out to a third party system for authentication)
<subsystem xmlns="urn:jboss:domain:security:1.2">
<security-domains>
<security-domain name="my-authentication" cache-type="infinispan">
<authentication>
<login-module code="com.myAuthClass.Impl" flag="required"/>
</authentication>
</security-domain>
<security-domain name="other" cache-type="default">
...
I was using cache-type="default" but then I adapted to infinispan, so I can set a life span. As I understand it I set up a special cache like so.
<subsystem xmlns="urn:jboss:domain:infinispan:2.0">
<cache-container name="security" default-cache="auth-cache" module="org.wildfly.clustering.web.infinispan" aliases="standard-security-cache">
<local-cache name="auth-cache" batching="true">
<expiration lifespan="10000"/>
</local-cache>
</cache-container>
The behavior I am now getting is frustrating. When I use a REST test tool, like Poster, I see a 10 second expiration on the principal I have stored. However, when I visit the website and browse around and hit those same REST endpoints, I don't see any timeout.
I am fairly new to this configuration effort and so I think I am just missing something, or my browser is doing some tricky keep alive I don't know about.
Has anyone seen this behavior and knows the solution to enforcing a timeout in the browser when using infinispan and a basic auth extension?
I solved this almost immediately after writing this question...
Also in the Standalone.xml there is a cache container which the web site is using. Cleverly named web
<cache-container name="web" default-cache="passivation" module="org.wildfly.clustering.web.infinispan"> ...
What I ended up doing was setting the cache expiration on this as well and now I seem to get the expected behaviors. I left the expiration in the security context as well, because that is what is driving the REST timeouts when someone is just using our services.
Final Web Cache configuration:
<cache-container name="web" default-cache="passivation" module="org.wildfly.clustering.web.infinispan">
<local-cache name="passivation" batching="true">
<expiration lifespan="10000"/>
<file-store passivation="true" purge="false"/>
</local-cache>
<local-cache name="persistent" batching="true">
<expiration lifespan="10000"/>
<file-store passivation="false" purge="false"/>
</local-cache>
</cache-container>
In order to program against the JPA 2.1 API, I would like to use eclipseLink, rather than the default OpenJPA JPA provider. How can this be achieved in the WAS 8.5 Liberty profile?
I tried with not using the jpa-2.0 feature and setting up a shared library which is referenced by my webapp, but with no success.
Here's my server.xml:
<server description="new server">
<!-- Enable features -->
<featureManager>
<feature>jsp-2.2</feature>
<feature>localConnector-1.0</feature>
</featureManager>
<httpEndpoint host="localhost" httpPort="9080" httpsPort="9443"
id="defaultHttpEndpoint" />
<applicationMonitor updateTrigger="mbean" />
<webApplication id="System" location="System.war" name="System">
<classloader commonLibraryRef="mysql" />
<classloader commonLibraryRef="eclipseLink" />
</webApplication>
<library id="mysql" name="mysql-jdbc-driver">
<fileset dir="C:\Users\jacomac\.m2\repository\mysql\mysql-connector-java\5.1.26" includes="*.jar"/>
</library>
<library id="eclipseLink" name="eclipse-jpa-impl">
<fileset dir="C:\Users\jacomac\.m2\repository\org\eclipse\persistence\eclipselink\2.5.2-M1" includes="*.jar"/>
<fileset dir="C:\Users\jacomac\.m2\repository\org\eclipse\persistence\javax.persistence\2.1.0" includes="*.jar"/>
<fileset dir="C:\Users\jacomac\.m2\repository\org\eclipse\persistence\commonj.sdo\2.1.1" includes="*.jar"/>
</library>
</server>
This is the error I get:
java.lang.NoClassDefFoundError: javax/persistence/Persistence
An addition: I know it works if I supply the eclipseLink libraries in my webapp, but I would like to use it as a shared resource across multiple webapps.
Liberty 8.5.5.x only seems to support JPA 2.0 even if EclipseLink supports JPA 2.1.
To have Liberty use EclipseLink, in a shared library, you need to set a "parentLast" classloader. My example use an ear but you can also set a classloader for a war.
You should only include eclipselink.jar and let Liberty use its own implementation of javax.persistence.
server.xml:
<fileset dir="${shared.resource.dir}/EclipseLinkLibs" id="EclipseLinkFileset" includes="eclipselink.jar"/>
<library filesetRef="EclipseLinkFileset" id="EclipseLinkLib"/>
<enterpriseApplication id="myEAR" location="myEAR.ear" name="myEAR">
<classloader delegation="parentLast" commonLibraryRef="EclipseLinkLib"/>
</enterpriseApplication>
You also need to set EclipseLink as the provider in persistence.xml:
<provider>org.eclipse.persistence.jpa.PersistenceProvider</provider>
Depending on your EclipseLink version and use of JTA you may also have to consider this bug and use the suggested workaround:
WebSphereTransactionController does not handle JTA on WebSphere 8.5
As of WebSphere Liberty 8.5.5.6 EE7 support was introduced, which includes JPA 2.1 support. With JPA 2.1 feature (jpa-2.1), we changed the default JPA Provider to Eclipselink 2.6.
OpenJPA is still available, and is the default JPA Provider, with the jpa-2.0 feature, which itself is forward compatible with the other EE7 features to support those who do not want to move their JPA-enabled applications off of OpenJPA and do not need to take advantage of the capabilities added by JPA 2.1.
Bear in mind that only one JPA feature can be enabled at one time, so using jpa-2.0 with EE7 features requires enabling individual features rather than using the EE7 convenience feature.
I've spend the last days trying to locate the cause of some new problem during development that raised a few days ago... and I've not found it yet. But I've found a workaround. But let's start with the problem itself.
We are using JBoss EAP 6.1.0.GA (AS 7.2.0.Final-redhat-8) as our application server for a quite large enterprise project. The JPA layer is handled by Hibernate Core {4.2.0.Final-redhat-1} using oracle.jdbc.OracleDriver (Version 11.2) connecting Oracle 11.2.0.3.0.
A few weeks ago everything worked as expected and we had no database related problems. We were using the following datasource:
<datasource jta="true" jndi-name="java:/myDS" pool-name="myDS" enabled="true" use-java-context="true" use-ccm="true">
<connection-url>jdbc:oracle:thin:#192.168.0.93:1521:DEV</connection-url>
<driver>oracle</driver>
<transaction-isolation>TRANSACTION_READ_COMMITTED</transaction-isolation>
<pool>
<min-pool-size>1</min-pool-size>
<max-pool-size>20</max-pool-size>
<prefill>true</prefill>
<use-strict-min>false</use-strict-min>
<flush-strategy>FailingConnectionOnly</flush-strategy>
</pool>
<security>
<user-name>MY_DB</user-name>
<password>pass</password>
</security>
</datasource>
Most of the time we had 5-10 open connections with 1-3 in use (single development environment)... the pool held that level and worked just fine.
But with some unknown changes to our code that pool stopped working... didn't release it connections anymore... even did not re-use them at all! It took a few simple requests to fill the pool up to the maximum of 20 connections and JPA refused any new database queries.
We've spend several days to find the relevant changes to our code... without success!
Today I've discovered a workaround. We changes persistence.xml a little bit:
<persistence-unit name="myPU">
<provider>org.hibernate.ejb.HibernatePersistence</provider>
<jta-data-source>java:/myDS</jta-data-source>
<properties>
<property name="jboss.entity.manager.factory.jndi.name" value="java:/myDSMF" />
<property name="hibernate.dialect" value="org.hibernate.dialect.Oracle10gDialect" />
<property name="hibernate.transaction.manager_lookup_class" value="org.hibernate.transaction.JBossTransactionManagerLookup" />
<property name="hibernate.default_batch_fetch_size" value="1000" />
<property name="hibernate.jdbc.batch_size" value="0" />
<property name="hibernate.connection.release_mode" value="after_statement" />
<!-- <property name="hibernate.connection.release_mode" value="after_transaction" /> -->
<property name="hibernate.connection.SetBigStringTryClob" value="true" />
</properties>
</persistence-unit>
Changing hibernate.connection.release_mode from after_transaction to after_statement did the trick. But that setting has never been touched before. Now connections are released as expected and the pooling is usable again.
I don't get why after_transaction doesn't work anymore... because changes are committed. We see all these things in the database. And committing a transaction should end it - doesn't it?
Although I've found that simple workaround I'd really get to know the problem. I've no good feeling to delay that knowledge until production time. So any feedback is very well appreciated! Thanks!
You are using JTA . So after_transaction mode in never recommended for JTA transactions.
Here is the document from JBOSS site.
after_transaction - says to use
ConnectionReleaseMode.AFTER_TRANSACTION. This setting should not be
used in JTA environments. Also note that with
ConnectionReleaseMode.AFTER_TRANSACTION, if a session is considered to
be in auto-commit mode connections will be released as if the release
mode were AFTER_STATEMENT.
so you should either use auto or after_statement explicitly, to aggressively release the connection.
References
Connection Release Modes.
My #Cacheable with Spring and ehcache doesn't work, no datas are put on the cache.
When the application calls the cacheable method getFolProfile, the database is always call rather than the cache.
Can you, please, say me what is wrong in my code.
My root-context.xml:
<cache:annotation-driven proxy-target-class="true"/>
<bean id="ehcache" class="org.springframework.cache.ehcache.EhCacheManagerFactoryBean" p:configLocation="classpath:/cache/ehcache.xml" />
<bean id="cacheManager" class="org.springframework.cache.ehcache.EhCacheCacheManager" p:cacheManager-ref="ehcache"/>
My Service :
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.cache.annotation.Cacheable;
import org.springframework.stereotype.Service;
#Service
public class FolManager {
#Autowired
FolDao folDao;
#Cacheable(value = "oneCache", key = "#email")
public FolProfileForm getFolProfile(String email) {
return folDao.retrieveByLogin(email);
}
}
My ehcache.xml:
<?xml version="1.0" encoding="UTF-8"?>
<ehcache xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="http://ehcache.org/ehcache.xsd">
<diskStore path="c:/tmp" />
<defaultCache maxElementsInMemory="10000" eternal="false" timeToIdleSeconds="120"
timeToLiveSeconds="120" overflowToDisk="true" diskSpoolBufferSizeMB="30" maxElementsOnDisk="10000000"
diskPersistent="false" diskExpiryThreadIntervalSeconds="120" memoryStoreEvictionPolicy="LRU" />
<cache name="oneCache" maxElementsInMemory="100000" maxElementsOnDisk="10000000" eternal="true" diskPersistent="true"
overflowToDisk="true" diskSpoolBufferSizeMB="20" memoryStoreEvictionPolicy="LFU" />
</ehcache>
Thanks for your help
Michel
It looks like you're defining caching in the service layer. At http://docs.spring.io/spring/docs/current/spring-framework-reference/html/cache.html, it is specifically noted as follows:
Note
<cache:annotation-driven/> only looks for #Cacheable/#CacheEvict on
beans in the same application context it is defined in. This means
that, if you put <cache:annotation-driven/> in a WebApplicationContext
for a DispatcherServlet, it only checks for #Cacheable/#CacheEvict
beans in your controllers, and not your services. See Section 16.2,
“The DispatcherServlet” for more information.
Add this
<cache:annotation-driven cache-manager="cacheManager" />
You have to tell Spring where cache-manager is.
When proxy-target-class attribute is set to true, class-based proxies are created. CGLIB will be used to create the proxy for a given target object. Make sur that you have CGLIB in your dependencies.
If you have the choice, prefer JDK dynamic proxies by setting proxy-target-class attribute to false and by implementing at least one interface on your class.
Please check your ehCache logs for exceptions like the following:
java.io.NotSerializableException: com.googlecode.ehcache.annotations.RefreshableCacheEntry
You use disk persistent cache (diskPersistent=true), so you have to check that your FolProfileForm object is Serializable.
From the ehCache documentation:
Only data that is Serializable can be placed in the DiskStore. Writes to and from the disk use ObjectInputStream and the Java serialization mechanism. Any non-serializable data overflowing to the disk store is removed and a NotSerializableException is thrown.
It could be the case that your data aren't placed to your cache (filesystem), so it tries to get it from the method invocation again and again.
You can use memory store cache where you can save even not serializable data.
I have upgraded my application to Spring 3.1 and all the jars have been adequately updated. But when I try to use #Cacheable for a method in one of my controllers, URL mapping for all the methods of that controller breaks. On checking the log files I found that the URL mapping for all the methods of that controller were never detected. I am pretty sure that my cache configurations are fine.
Can anyone give me some clue as what I might be doing wrong.
ehcache.xml
<?xml version="1.0" encoding="UTF-8"?>
<ehcache>
<defaultCache
eternal="false"
maxElementsInMemory="2"
overflowToDisk="false"
diskPersistent="false"
timeToLiveSeconds="300"
memoryStoreEvictionPolicy="LRU" />
<cache name="Backlog"
eternal="false"
maxElementsInMemory="2"
overflowToDisk="false"
diskPersistent="false"
timeToLiveSeconds="300"
memoryStoreEvictionPolicy="LRU" />
</ehcache>
configuration:
<bean id="cacheManager" class="org.springframework.cache.ehcache.EhCacheCacheManager">
<property name="cacheManager">
<ref bean="ehcache" />
</property>
</bean>
<bean id="ehcache" class="org.springframework.cache.ehcache.EhCacheManagerFactoryBean" p:configLocation="/WEB-INF/spring-configuration/ehcache.xml" />
code snippet:
#RequestMapping("/*/backlog")
#Cacheable(value = "Backlog")
public ModelAndView getBackLog(){
//sth here
}
Thanks for the help.
Whilst #mana has explained how to fix this, this is why adding #Cacheable breaks your code. A recent blog post explains this in more detail and is well worth a read.
By default Spring creates JDK dynamic proxies to achieve the caching behaviour, this requires that the class being proxied implements an interface which declares all the methods you wish to expose on your #Cacheable class. It is worth noting that you don't have to implement any interfaces if you configure Spring to use CGLIB based proxies.
You haven't supplied any specific errors but often you get a method not found exception in this scenario. Spring tries to invoke the getBackLog() method on the proxy and there isn't one.
You shouldn't cache the controller method itself but the resource hungry method that will be called to create the backlog. Have a look at this similar question. What #Cachable does is to create a key value map for your function parameters and the related return value. In your case this would be a ModelAndView object.
If you really need server side web page caching maybe use this Apache Cache Module.
you should be injecting your service class into the controller and caching the methods on the service class