Working with Spring Data Rest continues. Moving to 2.4.0 gave me more of the behavior I want, however now I am getting a strange intermittent exception.
About. . . 2/3 of the time when I reload or deploy my application, every SDR endpoint with data throws a 500, and gives the following:
GET /api/departments
--------------------
HTTP Status 500 - Could not write content: org.springframework.data.rest.webmvc.json.PersistentEntityJackson2Module$ProjectionResourceContentSerializer
cannot be cast to com.fasterxml.jackson.databind.ser.impl.UnwrappingBeanSerializer
(through reference chain:
org.springframework.hateoas.PagedResources["_embedded"]
->java.util.UnmodifiableMap["departments"]
->java.util.ArrayList[0]
->org.springframework.data.rest.webmvc.json.ProjectionResource["content"]);
nested exception is com.fasterxml.jackson.databind.JsonMappingException:
org.springframework.data.rest.webmvc.json.PersistentEntityJackson2Module$ProjectionResourceContentSerializer
cannot be cast to com.fasterxml.jackson.databind.ser.impl.UnwrappingBeanSerializer
(through reference chain:
org.springframework.hateoas.PagedResources["_embedded"]
->java.util.UnmodifiableMap["departments"]
->java.util.ArrayList[0]
->org.springframework.data.rest.webmvc.json.ProjectionResource["content"])
(Full error report available: http://pastebin.com/xzzXkFiR )
Like I said, this does not occur every time I reload/deploy the app, but if it is occuring it's completely stuck, and a reload is the only way to fix it. Very odd behavior, wondering if anyone has any insight.
Issue does not occur if I roll back to Spring Data Rest 2.3.2
Thanks for the help, and please let me know what other relevant information I can provide.
SDR: 2.4.1
SFW: 4.2.1
SDJPA: 1.9.0
Some further testing
Issue also occurs with latest (2.5.0 SNAPSHOT).
I can observe the same issue after updating to Spring Data Rest 2.4.0. The issue is not deterministically reproducible. I do not have any statistics so far, but it occurs less frequently after updating Jackson dependencies from 2.4.0 to 2.6.0. Sometimes it still pops up, but then a reload is sufficient in my case. A minimal example would help to dive deeper into it.
Bugs in jackson-databind library. Upgrade to release train Gosling-SR3 once released.
See https://jira.spring.io/browse/DATAREST-716 and https://jira.spring.io/browse/DATAREST-743
Related
Getting this error while hitting PUT and POST API's. Tried multiple solutions but no luck. Can you please Help me with it.
nested exception is org.springframework.transaction.CannotCreateTransactionException: Could not open JPA EntityManager for transaction; nested exception is java.lang.NoSuchMethodError: org.springframework.orm.jpa.JpaTransactionManager$JpaTransactionObject.setReadOnly(Z)V] with root cause
java.lang.NoSuchMethodError: org.springframework.orm.jpa.JpaTransactionManager$JpaTransactionObject.setReadOnly(Z)V
at org.springframework.orm.jpa.JpaTransactionManager.doBegin(JpaTransactionManager.java:405) ~[spring-orm-5.2.3.RELEASE.jar:5.2.3.RELEASE]
This issue is basically because of version mis-match. It mostly occurs when you update your spring version. When the updated spring version does not match with your other versions like spring-orm, spring-jdbc, etc, this issue occurs. In my case there were two jars present for spring-jdbc(one was provided by spring started and other was externally added.) please check and try to use the latest version(you can get the version of jar's here ) or the one which was used by many people and has no vulnerability. If the latest one is not working, then please check with the other one. you have to find out which one is suitable for your spring version based on trial and error method only.
We've been working on an application that uses Tomcat 8 throught connection pool. We control Optimistic exceptions with #Version field, and we control transactions with Entitymanagers isolated by ThreadLocal.
However, the application triggers a concurrency exception sometimes with hangs other processes and requieres to restart the server.
The exception is always like this:
Caused by: Exception [EclipseLink-2004] (Eclipse Persistence Services - 2.6.4.v20160829-44060b6):
org.eclipse.persistence.exceptions.ConcurrencyException
Exception Description: A signal was attempted before wait() on ConcurrencyManager. This normally means that an attempt was made to commit or rollback a transaction before it was started, or to rollback a transaction twice.
at org.eclipse.persistence.exceptions.ConcurrencyException.signalAttemptedBeforeWait(ConcurrencyException.java:84)
at org.eclipse.persistence.internal.helper.ConcurrencyManager.releaseReadLock(ConcurrencyManager.java:468)
at org.eclipse.persistence.internal.identitymaps.CacheKey.releaseReadLock(CacheKey.java:475)
We've been trying to solve this problem or find any specific information about this error with no result. We even followed instructions in https://wiki.eclipse.org/EclipseLink/FAQ/JPA#How_to_diagnose_and_resolve_hangs_and_deadlocks.3F.
Disabling cache seems to solve the problem, but we cannt afford to not use cache due to performance needs.
Any help would be appreciated.
Thanks
Finally, after six months of headaches, I managed to solve the problem.
The general error was EclipseLink-2004. If you check Eclipselink error reference:
Eclipse link error reference page, it says "Verify transactions in the application".
I've been using a application managed Entity Managers. To control that transactions were single-thread I used this ManagerHelper class:
EntityManagerHelper
The problem was that I was putting a managed object inside a Session attribute. I don't really understand the process inside, but somehow it created new transactions outside the main transaction if it was used to query. Moving the object to Request attributes solved the problem.
I hope this helps to someone in the future.
Best regards
I am using the latest version of Bitnami Apache solr and the issue that I am facing is after adding a SolrCore every time services or server got restart the attached SolrCore collection got detached, and the interface shows like there was never been any SolrCore attached before.
But the strange thing is when I am attaching the SolrCore again the solr interface shows a error message "another core is already defined there" and once I refresh the page its like nothing happen everything fine.
enter image description here
This mean core exist on the back end but some reference is removed because of the services restart.
So I need to know why this happening? why core is getting detached after the services restarted? And how can I fix this issue?
Reference link of a solr version I am using:
https://bitnami.com/stack/solr/installer
I bet it is a SoftReference linked inside a Service, which is lost, causing these trouble.
I think you should look for a UnitedService which starts and stop together, keeping an united work in the same Context.
You could start/stop all your webserver and Solr instances together, at the same time, with a batch script. And you can look at how the SoftReferences are working inside Solr manual and which usual problems they are facing with.
Good luck!
I have an interesting problem regarding json web token. The moment I add this dependency to maven pom, my unit tests for Spring Rest Controller throw gibberish, like
ResultActions results = mockMvc.perform(post("/customers/" + customerId + "/orders")
.contentType(MediaType.APPLICATION_JSON).content(new Gson().toJson(order)));
is expected to give 200, but gives 400. What I've noticed upon investigating the issue is that the problem happens only for tests that test POST/PUT (transactional HTTP requests I guess I could call them). I've tried excluding dependency from testing using information in this link, but to no avail. I'm not sure what other information to provide, because I really don't have the faintest idea as to what is causing this issue.
I've solved this issue. The problem was dependency conflict. JJWT depends on Jackson and I've already been using GSON for my Jsons. Those two conflicted in a weird way. I've solved the issue by changing JJWT to another JWT lib.
My application is throwing this error:
Error : An error occurred trying to instantiate an instance of the API adapter "org.datanucleus.api.jdo.JDOAdapter"
(perhaps you dont have the requisite datanucleus-api-XXX jar in the CLASSPATH?) :
{1}
org.datanucleus.exceptions.NucleusUserException: Error :
An error occurred trying to instantiate an instance of the API adapter "org.datanucleus.api.jdo.JDOAdapter" (perhaps you dont have the requisite datanucleus-api-XXX jar in the CLASSPATH?) :
{1}
...
at org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582)
Although my application do have datanucleus-api-jdo-3.0.0-release.jar
What could be the reason if not missing jars?
EDIT:
This is what have been suggested to fix this issue:
This is a sporadic error that happens from time to time on any
persistable class, but moreso on ones that are used a lot in parallel.
It happens in JDO and JPA, and it seems as though the local datastore
locks a particular table / entity group and forgets to release it;
thus causing all subsequent calls to ds operations to fail. I
generally don't have to restart eclipse; just stopping then starting
the server tends to fix the problem, if not, a full refresh/clean
build will do the trick.
However, I have already restarted my GAE server and re-run my application still getting the same error.
Here is the complete POM.xml
Here is the complete stack trace.
Use latest versions. Include all dependencies (jdo-api, datanucleus-api-jdo). Read docs for what needs to be in the CLASSPATH (enhanced versions of your classes, for example).