I've seen many incarnations of this same issue but I think I've tried all the fixes - my usage is quite straightforward.
I had been using Ehcache which also didn't work. So, to rule out Ehcache issues and help point to something more fundamental, I moved to SimpleCacheManager and ConcurrentMapCacheFactoryBean.
Here's my config:
<cache:annotation-driven/>
<bean id="cacheManager" class="org.springframework.cache.support.SimpleCacheManager">
<property name="caches">
<set>
<bean class="org.springframework.cache.concurrent.ConcurrentMapCacheFactoryBean" p:name="parentAppIds"/>
</set>
</property>
</bean>
Here's my method:
#Cacheable(value="parentAppIds", key="accountNumber")
public Long findApplicationId(String accountNsc, String accountNumber) throws EMSException {
....
}
This is a method on an interface, who's implementing class is Spring managed #Service("foo")
I tried using 'p0' as is suggested here but to no avail. I have no compilation problems and no errors in my server logs so I'm confident that I have all that is necessary on my classpath; and that Namespaces are all fine, since I'm using STS for that - so I left out pom.xml and spring Namespace declarations to block noise.
I'm using Spring 3.1; Java 1.5 and Websphere 6.1
The symptom is that the method is being visited with the same parameters repeatedly.
Please help - I'm hungry and refuse to go for lunch until I nail this.
note: I have simplified my #Cacheable declaration my actual one is
#Cacheable(value="parentAppIds", key="#p0.concat('-').concat(#p1)")
Neither work.
Thanks.
** Edit - I've ruled out Websphere as being a problem by creating a test rig with
#RunWith(SpringJUnit4ClassRunner.class)
#ContextConfiguration(...)
which mimics what is happening. #Cacheable is simply not working. There must be something blindingly obvious that I am missing. (I've had lunch now)
My issue is resolved. Unfortunately I cannot pinpoint exactly where my issue lay. Certainly, all that is required is that which I have mentioned in my question.
TO fix this, I tidied up my Spring configuration a bit and cleared my browser and application server cache and temp directories. I did a full clean install and cache is now working.
It is possible that I was testing with an earlier version which did not include this important line in the application config:
<cache:annotation-driven/>
I had omitted that at the start. Maybe my adding of that was not picked up until now. Otherwise I am stumped. Thanks for your time.
Did you perhaps change
#Cacheable(value="parentAppIds", key="accountNumber")
to
#Cacheable(value="parentAppIds", key="#accountNumber")
as adding the # that removed one error for me while trying to get caching working.
Related
ClassCastException occurs when I try to scan a large number of keys
using opsForHash.scan() method. I am using Jedis 2.6.2 and I face this
error only when the number of keys to be searched is large(~100,000).
I have read solutions to this problem online and most of them are
suggesting that the problem occurs due to connection pooling.
I am using Spring integration in my project and have set use-pool attribute as true(in JedisConnectionFactory) even though it is the default option.
Since spring is supposed to manage the connections with redis, why am I still having this issue?
Please suggest.
This is the Spring Configuration file I am using :
This is the java code where i am executing scan() :
I had this same problem. After searching a lot on the internet, I found that the problem occurs due to connection pooling problems. As you have mentioned, you have set use-pool to be true in the spring configuration.
I by passed this problem by setting pooling as false. It turned out that I didn't need pooling and after that the problem didn't occur.
You can try this solution if you don't explicitly need pooling.
Here is the code snippet:
<bean id="jedisConnFactory" class="org.springframework.data.redis.connection.jedis.JedisConnectionFactory"
p:hostName="" p:port="6379" p:usePool="false" />
Hope it helps!
Im upgrading from spring-security-oauth2 1.0.5 to 2.0.5, is there any tutorial or good description of the differences to start with this? Im having a lot of issues because I have several customization's and all of them failed because there are a lot of differences and things like AuthorizationRequestHolder doesnt exists anymore and it is not easy to change it for simple AuthorizationRequest objects.
Thanks
The main thing I noticed that changed was the token stores packages where changed so for example:
<bean id="tokenStore" class="org.springframework.security.oauth2.provider.token.InMemoryTokenStore" />
becomes
<bean id="tokenStore" class="org.springframework.security.oauth2.provider.token.store.InMemoryTokenStore" />
Also previously in 1.0.5 I had used the TokenServicesUserApprovalHandler which I could no longer find in any of the packages. I removed the reference to that class and user-approval-handler-ref="userApprovalHandler" I had added to the oauth:authorization server. Mines seems to be working now on 2.0.5, hope this helps.
You could start with
$ git diff 1.0.5.RELEASE 2.0.5.RELEASE -- samples/oauth2
The main differences are the move from XML to #Configuration (which you could optionally skip). There is also a functional change to support approvals in the UI which is also optional. And that leaves the UserApprovalHandler in which you can see the changes in the API and the use of AuthorizationRequest. Other differences will depend on what you customized, but look at the framework extension points that you are using and the default implementations for information on how to migrate them. The main differences (as you noted) are with the AuthorizationRequest which now is much more granular, and the extension points that affect it are OAuth2RequestFactory and OAuth2RequestValidator (both replacing AuthorizationRequestManager).
If you want to trace the history look for "Amanda Anganes" in the log, since she was the main author. Commit 4f577389b3 is the first big change.
Spring 3.2.6
There might be an easy solution for this that I've missed, but I've been scouring the boards for the last couple days, tried a few things and so far nothing - so I thought I'd consult the experts.
My app:
I have 5 JaxWsPortProxyFactoryBean beans configured in my applicationContext.xml that connect to and consume various web services. Everything works fine, very nice!
Problem:
When my app starts there may be 1 or more web services that are either OFF or not accessible. This is fine as my app can run without them; however, is there a way to continue processing other beans in the context after receiving a TimeoutException (or any Exception due to connectivity with the WS)?
I was hoping for a property in JaxWsPortProxyFactoryBean like continueOnError or something similar.
Hope this makes sense.
You can disable the lookup/check of the web service at startup by setting the lookupServiceOnStartup property to false.
<bean id="yourService" class="org.springframework.remoting.jaxws.JaxWsPortProxyFactoryBean">
<property name="lookupServiceOnStartup" value="false" />
// Other properties
</bean>
Advantage your application starts up a bit faster, drawback the first call to the web service might take a little longer.
You can check the javadoc for more information, the lookupServiceOnStartup property is defined on the JaxWsPortClientInterceptor.
Possible solution is to use setLookupServiceOnStartup and set it to false.
http://static.javadoc.io/org.springframework/spring-web/3.2.6.RELEASE/index.html?org/springframework/remoting/jaxws/JaxWsPortClientInterceptor.html
We are having a portlet application which uses Spring 3.1.0.Final and deployed on WAS 6.1.
We have multiple portlets using Spring MVC in past. This is the first portlet with Spring 3. I am using annotations and autowiring in most of the places in the code.
When this application is deployed in server the base heap usage jumped by 25+ MB.
I did profiling using Jprofiler and found that StringHTTPMessageConverter is loading all charsets in memory which occupies around 14 MB of memory (com.ibm.nio.charset.Charset takes up memory)
Since it is a portlet app I have org.springframework.web.portlet.mvc.annotation.Ann otationMethodHandlerAdapter bean explicity defined in my configuration and not org.springframework.web.servlet.mvc.annotation.Ann otationMethodHandlerAdapter
This is what I have tried doing so far
1) Change StringHttpMessageConvertor settings
Defined the following bean in my configuration
<bean class = "org.springframework.web.servlet.mvc.annotation.An notationMethodHandlerAdapter">
<property name = "messageConverters">
<list>
<bean class = "org.springframework.http.converter.StringHttpMess ageConverter">
<property name = "supportedMediaTypes">
<list>
text/plain;charset=UTF-8
</list>
</property>
</bean>
</list>
</property>
No luck with this.
2) I have defined in my config file. As suggested in some posts I also tried the above configuration by commenting out the tag. But no luck.
3) As suggested in some forums I Tried to write BeanPostProcessor but it could not find the StringHttpMessageConverter class.
Do I need to explicitly define org.springframework.web.servlet.mvc.annotation.Ann otationMethodHandlerAdapter in my configuration?
My questions are
1) Is there any way to avoid all charsets loading up in memory?
2) Also Is the 25 MB jump in base heap justifiable ? What is the usual memory foot print of Spring 3.1.0 ?
I am running out of ideas Any help regarding fine tuning the Spring framework would be highly appreciated.
Thanks and Regards
RaviG
Update: Problem Solved, removed tag from the configuration. We are using Portlet MVC Annotation Handler adapters so Servlet MVC Annotation handler Adapters were unnecessary and are not needed at all. The StringHttpMessageConvertor was pulled in by Servlet MVC Annotation Handler tag. The StringHttpMessageConvertor in its constructor has code to pull in the charsets in the memory.
I am working on a Spring MVC application in which I have recently been convinced to revamp my database code. Before I was using very traditional JDBC code that I have been told was very "old school" because of the boilerplate code. I have been making the transition to using JdbcTemplate with Spring.
I have configured a bean like shown below in my applicationContext.xml file.
<bean id="dataSource" class="org.apache.commons.dbcp.BasicDataSource">
<property name="driverClassName" value="com.mysql.jdbc.Driver"/>
<property name="url" value="jdbc:ip-address:port/dbName"/>
<property name="username" value="myUsername"/>
<property name="password" value="mypassword"/>
</bean>
I have run tests just to make sure everything is working and it is.
My question is, I am aware that I am using the Commons DBCP package which uses the
following packages
commons-dbcp package
commons-pool package
Again, I am very inexperienced with this, so I apologize if I am mis referencing something or am explaining something incorrectly.
I have followed what most of the tutorials have said to do and specified a jdbcTemplate and injected the dataSource bean into it, but this doesnt really refer to my question.
What I would really like to know is, am I using ConnectionPooling with this configuration?
If so, is it being done behind the scenes, or do I need to specify to do it somewhere?
I have looked at the documentation at Here which gives the following, but I am not sure exactly how to interpret it.
"here are several Database Connection Pools already available, both within Apache products and elsewhere. This Commons package provides an opportunity to coordinate the efforts required to create and maintain an efficient, feature-rich package under the ASF license.
The commons-dbcp package relies on code in the commons-pool package to provide the underlying object pool mechanisms that it utilizes."
I also looked at the Configuration Page
and based on this page, I would think that I am able to do ConnectionPooling, but may need to specify additional parameters in my dataSource bean.
Can somebody please answer my questions or point me in the right direction?
Yes you are using connection pooling.
here is another thread you might find interesting
http://forum.springsource.org/showthread.php?t=40598
Also most of the links you specified above will provide additional information on parameters that can be set.