In openJPA 2.4, if I set :
<property name="openjpa.QueryCache" value="true"/>
but DO NOT SET openjpa.RemoteCommitProvider property, I get the following error :
org.apache.openjpa.util.UserException: You have attempted to use a RemoteCommitListener without also specifying a RemoteCommitProvider. In order to use a remote commit listener, you must configure a remote commit provider to use through the openjpa.RemoteCommitProvider configuration property.
This configuration used to work in openJPA 1.X
Does anyone know if QueryCache absolutely requires a openjpa.RemoteCommitProvider or does this look like a bug in openJPA ?
The documentation mentions that openjpa.RemoteCommitProvider is required for openjpa.DataCache but it doesn't mention that for openjpa.QueryCache
I think the problem you've encountered is an oddity of a configuration problem. From what I can tell, you must have the QueryCache enabled, but not the DataCache.? If that is not true, please ignore the rest of my post.
From what I recall when you enable openjpa.DataCache the runtime automatically configures a RemoteCommitProvider for you. The RCP is required when using the DataCache/QueryCache. In your case if you only have the QueryCache enabled, the RCP doesn't get auto configured.
I'm still scratching my head why you are configuring the QueryCache without the DataCache? This is a very odd use case as with this setup it is very unlikely that you'll ever have a cache hit and you're paying the price of a cache that isn't helping you.
Related
Each version has so different information that it is difficult to use.
I am using Spring Boot EhCache version 3.10.
Without a special Java configuration file, only the expiration time is entered in the xml file and then used.
Cache synchronization is required. So I found TerraCotta, but I can't quite figure out how to use it.
I checked the guide, but didn't understand which of these to use where and how.
I have received the TerraCotta server file, and I have run it, but please tell me how to configure SpringBoot to synchronize it.
I have this property into Spring Boot application:
server:
connection-timeout: 12000
I get warning:
Deprecated Each server behaves differently. Use server specific properties instead.
Gradle: org.springframework.boot:spring-boot-autoconfigure:2.6.8 (spring-boot-autoconfigure-2.6.8.jar)
is there some better configuration property that I can use?
I don't even know why you receive a deprecated warning.
According to the documentation from Spring Boot version 2.3 and onwards this property is removed not deprecated any more.
As you can read here, there are some other properties which you can use instead depending on the server that runs your spring boot application.
server.tomcat.connection-timeout should be used if you have tomcat as running server.
server.netty.connection-timeout should be used if netty is used.
server.jetty.connection-idle-timeout should be used if jetty is used
Basically each server has it's own implementation, so you must read your server's documentation to see what it allows and how this behaves. There might be slight differences from how one server behaves and how it interprets connection-timeout and how another server behave and interprets a similar configuration.
This is I think the reason that Spring decides to move to server specific configuration on property connection-timeout instead of a general property and also a very important reason was that some servers may not even have this configuration available to them. So then you have a general property configured in your spring boot application which the server that runs the application can't even respect.
Therefore you now have specific properties for specific servers and now you can be sure upfront whether this configuration is available in your server and you can also read the server documentation to understand exactly what the behavior will be.
Although this setting is being deprecated, we still can use the timeout function.
According to official document, we can use #Transactional(timeout = 1) to do the track in the controller
https://www.baeldung.com/spring-rest-timeout
Before the log4j shell issue happened last month I was using 'org.springframework.boot:spring-boot-starter-logging:1.5.22.RELEASE' which has internal dependencies on
ch.qos.logback:logback-classic:1.1.11 and ch.qos.logback:logback-core:1.1.11 jars respectively.
After that log4j shell issue occurred I had upgraded both the jars to version ch.qos.logback:logback-classic:1.2.3 and ch.qos.logback:logback-core:1.2.3 with gradle v3.5 which works fine. Now when I am trying to upgrade jars to logback-classic:1.2.10 and logback-core:1.2.10, this stops me while running the application stating below error:
org.gradle.tooling.BuildException: Could not execute build using Gradle distribution 'https://services.gradle.org/distributions/gradle-3.5-all.zip'.
Do I need to move to higher version of Grails or Gradle 3.5 have any issue with upgrade. Please any hint or guidance is most welcome.
From https://logback.qos.ch/news.html
We note that the vulnerability mentioned in CVE-2021-42550 requires
write access to logback's configuration file as a prerequisite. Please
understand that log4Shell and CVE-2021-42550 are of different severity
levels. In response to CVE-2021-42550 (aka LOGBACK-1591) we have
decided to make the following steps. 1) Hardened logback's JNDI lookup
mechanism to only honor requests in the java: namespace. All other
types of requests are ignored. Many thanks to Michael Osipov for
suggesting this change and providing the relvant PR. 2) SMTPAppender
was hardened. 3) Temporarily removed DB support for security reasons.
4) Removed Groovy configuration support. As logging is so
pervasive and configuration with Groovy is probably too powerful, this
feature is unlikely to be reinstated for security reasons. We note
that the aforementioned vulnerability requires write access to
logback's configuration file as a prerequisite. Please understand that
log4Shell/CVE-2021-44228 and CVE-2021-42550 are of different severity
levels. A successul RCE attack with CVE-2021-42550 requires all of the
following conditions to be met: write access to logback.xml use of
versions < 1.2.9 reloading of poisoned configuration data, which
implies application restart or scan="true" set prior to attack As an
additional extra precaution, in addition to upgrading to logback
version 1.2.9, we also recommend users to set their logback
configuration files as read-only
For now no support for grails so v1.2.9 onwards logback is not supported for now.
I am looking at externalizing certain configuration parameters for ehcache in our Grails application and I am running into something not working that the documentation claims ought to.
Likely there is something I am missing.
I am using the grails ehcache plugin version 1.0.1 with Grails 2.4.0 and grails cache plugin 1.1.7. I am using hibernate plugin 3.6.10.16.
Here's what I have in my CacheConfig.groovy configuration...
...
cacheManagerPeerProviderFactory {
peerDiscovery 'automatic'
factoryType 'rmi'
multicastGroupAddress '${ehcacheMulticastGroupAddress}'
multicastGroupPort '${ehcacheMulticastGroupPort}'
timeToLive 'site'
}
I've turned on debug-level logging so I can see what XML it generates. Here's the relevant snippet:
<cacheManagerPeerProviderFactory class='net.sf.ehcache.distribution.RMICacheManagerPeerProviderFactory'
properties="peerDiscovery=automatic,multicastGroupAddress=${ehcacheMulticastGroupAddress},multicastGroupPort=${ehcacheMulticastGroupPort},timeToLive=32"
propertySeparator=','
/>
The grails ehcache plugin documentation has the following note, which I was hoping to "prove out"...
(note that ${ehcacheMulticastGroupAddress} and ${ehcacheMulticastGroupPort} are an Ehcache feature that lets you use system property names as variables to be resolved at runtime)
Great. Except that it doesn't work when I start the application. It fails to create CacheManagerPeerProvider due to the following
...
Caused by UnknownHostException: ${ehcacheMulticastGroupAddress}
->> 901 | lookupAllHostAddr in java.net.InetAddress$1
...
I have a myApplication-config.groovy file living in an accessible area that I point to when assigning a value to grails.config.locations in Config.groovy. But I am not sure it is making any effort to really interpolate that value at all.
I tried double quotes but they were a bad idea as well -- at the time of interpreting CacheConfig.groovy it doesn't see the configuration I put into myApplication-config.groovy. I do know it reads that file in successfully at some point because I successfully use it to drive some Quartz job logic, so the placement of that config file is probably not the issue.
The answer is that I need to set SYSTEM PROPERTIES for ehcache to find. Using Grails configuration files such as myApplication-config.groovy is completely incorrect.
The CacheConfig.groovy file is correct, as is the XML it generates. So the question becomes, how do the properties it looks for get set correctly in the first place?
I am deploying to Tomcat. For Tomcat, setting system properties makes the most sense in a setenv.bat file (or setenv.sh on *nix).
I created setenv.bat, put the following into it
set CATALINA_OPTS=%CATALINA_OPTS% -DehcacheMulticastGroupAddress=230.0.0.1 -DehcacheMulticastGroupPort=4446 -DehcachePeerListenerPort=40001
...And it worked. Ehcache was able to find the system properties and start everything appropriately.
tl;dr: system properties != grails application config
I've got a website build with Spring and jpa (by hibernate). I've got a bug and I don't know how to identify the line where the bug appears.
I can't debug it on my ide because it's a live version (all runs fine in local).
I've got log which says:
o
rg.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)#012#011
at org.springframework.aop.framework.Cglib2AopProxy$DynamicAdvisedInterceptor.intercept(Cglib2AopProxy.java:625)#012#011
at com.mycompany.server.rpc.UserService$$EnhancerByCGLIB$$64ed2d4f.createAccount(<generated>)#012#011
at com.mycompany.server.rpc.ServiceRPCImpl.createAccount(ServiceRPCImpl.java:309)
My problem is the third line. As the UserService object is handled by Spring, it becomes a proxy and I can't know the line of the bug.
Do you know how to solve the problem ?
Thanks
Is it possible for you to change from cglib to jdk proxy? (Spring AOP proxy reference)
Basically: if you access your beans as interfaces, you can use jdk proxies (spring default mechanism), thereby leaving the underlying object intact and gaining access to line numbers in stack traces.
I would say that not being able to reproduce this locally is a significant restraint. I would try to set up your local environment or a test server to reproduce the problem, using JMeter or other load test software to simulate load of concurrent user accesses. Once this is done, your tweak/compile/test cycle becomes a lot shorter, and you can make experimental changes without fear of disrupting service on your production server. It may seem like a lot of effort, but the work will pay dividends not just for this bug, but for bugs you may encounter in future.
It sounds like it could be a threading bug, especially since spring by default uses singleton scope. With that in mind, look into creating multithreaded integration tests for the service that is failing. Once you have reproduced the bug through load testing, you can verify that it's a threading bug by making your main service method synchronized, preventing concurrent use. If the bug disappears, it is most likely a concurrency bug.
As to finding the line of the bug - there is no line to look for since the code is generated. The best you can do is to add defensive checks in all beans that are being used in the advice around the UserService. (E.g. check for null values due to missing injections.) The init-method attribute on beans is useful for performing checks that the bean has been fully constructed and all required collaborators have been set.
If you cannot reproduce the issue in local environment, then may be it is environment / network related issue. I would first recreate the issue in test environment ( which is closer to production environment and not just own local machine ) to debug the bug.
You may also use Fiddler to debug network related issues for a live version.