Problem importing Metadata Sharing Packages when running Core 2.1.x

In preparation for upgrading to OpenMRS Core 2.1.x we have been doing lots of regression testing and have been having failures when trying to import MDS packages. One error we are seeing is the following:

throw new UnsupportedOperationException("Can't write to a readonly object");

This appears to be happening when trying to save a ConceptDatatype, and looking further I see the following setting in the ConceptDatatype hibernate mapping file:

Not sure what the intent was here, but it looks like if we do want to make ConceptDatatype truly immutable we need to set mutable=false:

Thoug we may just want to set the cache type to “read-write”?

Thoughts @rafal?

Thanks! Mark

Also, I’m really getting stuck on this error if anyone has any ideas:

org.openmrs.module.metadatasharing.task.TaskException: Task failed
	at org.openmrs.module.metadatasharing.task.Task.log(
	at org.openmrs.module.metadatasharing.task.TaskEngine$
	at java.util.concurrent.ThreadPoolExecutor.runWorker(
	at java.util.concurrent.ThreadPoolExecutor$
Caused by: org.openmrs.module.metadatasharing.task.TaskException: Task failed
	... 4 more
Caused by: org.springframework.transaction.UnexpectedRollbackException: Transaction rolled back because it has been marked as rollback-only
	at org.springframework.transaction.interceptor.TransactionAspectSupport.commitTransactionAfterReturning(
	at org.springframework.transaction.interceptor.TransactionAspectSupport.invokeWithinTransaction(
	at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(
	at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(
	at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(
	at com.sun.proxy.$Proxy292.executeTask(Unknown Source)
	at org.openmrs.module.metadatasharing.task.TaskEngine$
	... 3 more

I saw another post about this here Rollback in Metadata Sharing but I’ve yet been able to get a more useful error message like was mentioned in that post.

Any ideas of how/where to set a breakpoint to figure out what’s triggering a rollback? I’ve tried some of suggested breakpoints in posts like the one below, but nothing so far:

Take care, Mark

Could be a transaction time-out. Is there a parameter in the application server that allows to define the transaction time-out? I face this problem often with JBoss and Websphere, with long transactions.

I think we need to add mutable=false. Did you have a chance to test, if it fixes the issue? Since openmrs-core 1.9.x+ we no longer have service methods to add or update concept datatypes and we consider them immutable.

In MDS we have a check preventing calling save on ConceptDatatype, but I’m guessing it happens with a flush on some other objects…

Regarding the transaction rollback only issue I’d try setting a breakpoint in HibernateTransactionManager.HibernateTransactionObject#setRollbackOnly and look at the call stack to find an actual exception. Is there any way I can reproduce it on my machine?

1 Like

@raff I tested the the other way, setting it to read-write, but I’ll test setting mutable to false to see what happens… I was a little confused which would be correct because as you said although there is no longer a service method for saving concept datatypes there’s still a DAO method (though I don’t think it was used?). I should we ticket this for removal

I tried setting breakpoint on setRollbackOnly but there seemed to be a few different transaction managers classes and none of them seemed to pick anything up… I’ll try the one you suggested again in case i missed it.

I’ll also attach one of the failing packages… when I try to import it on a 2.1.3-SNAPSHOT instance it fails… assumedly it will for you as well, but if it doesn’t that’s a good data point as well…

Thanks! I will be exploring more today and will let you know what I find. Next thing I was thinking enabling verbose Hibernate logging and perhaps even see if there’s anything in the mysql logs.

(Actually, it looks like it won’t let me attach a zip… I’ll open a ticket…)

Take care, Mark

One thing I did discover… one of the failing datasets had 13 concepts, so I tried creating the package with only 1 of the concepts and that works… I continued to add the concepts 1 by 1 and it worked every time… so I’m guessing it’s as issue with flushing two new concepts at the same time, perhaps because of some conflict in the dependent objects? Just annoying that I’ve been yet to trace what the underlying cause is.

Take care, Mark

@raff added a breakpoint at that setRollback worked! Seems to be some thing when trying to reference a conference reference term, looking into it now…

Hey @mogoodrich I stumbled upon the exact same error while attempting to load either of:

  • (see here), or
  • (attached by you on TRUNK-5326, see here)

My original goal was actually to load the first one, but I tried the second one as well since it was provided by you on the ticket. Just to see if I could reproduce the problem and its resolution. And the error came up anyway.

I’m doing this on Platform 2.1.3 with

  • metadatasharing 1.4.0-SNAPSHOT (built off this commit from @raff)
  • metadatamapping 1.3.4
  • legacyui 1.4.0
  • owa 1.9.0
  • 2.22.0

Any idea?

I guess my questions is rather, how do you guys at PIH load successfully the first package in practise?

1 Like

@mogoodrich, actually I misread that:

I did a quick test of this and it didn’t seem to fix the issue… it’s possible I missed something though. I have a bunch of updates I need to get out so I’m putting it aside for now but will plan to test again later.

@raff’s commit didn’t fix the issue for you (I initially thought it did.)

Ok so as per the thread the most likely problem is that concept sources should be created beforehand. I’m looking in that direction now…