Hibernate 4 uses jdbc4, were the signature of method setBinaryStream(int, InputStream, int) was changed to setBinaryStream(int, InputStream, long). C3P0 does not support this new method.
So calling saveOrUpdate(myObjWithBlob) results
java.lang.AbstractMethodError: com.mchange.v2.c3p0.impl.NewProxyPreparedStatement.setBinaryStream(ILjava/io/InputStream;J)V
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.hibernate.engine.jdbc.internal.proxy.AbstractStatementProxyHandler.continueInvocation(AbstractStatementProxyHandler.java:122)
at org.hibernate.engine.jdbc.internal.proxy.AbstractProxyHandler.invoke(AbstractProxyHandler.java:81)
at $Proxy75.setBinaryStream(Unknown Source)
So what can i do now?
1) Do not use c3p0. DHCP, BoneCP or no conntection pool at all. - is not really the option i want.
2) Somehow make hibernate avoid calling this new method? Is ist possible?
3) Switching back to hibernate 3 - is also not really good for me.
please upgrade to c3p0 0.9.2-pre8 (or wait a few days for 0.9.2 final). This issue has been resolved in recent releases of the library.
Update: c3p0-0.9.2 is now a release. it does resolve this issue.
Related
When I try to edit my database connections, I get the "General Error in Dialog" message. Upon clicking details, I get the following:
java.lang.NullPointerException at
org.pentaho.di.ui.core.database.dialog.XulDatabaseDialog.open(XulDatabaseDialog.java:113)
at
org.pentaho.di.ui.core.database.dialog.DatabaseDialog.open(DatabaseDialog.java:61)
at
org.pentaho.di.ui.spoon.delegates.SpoonDBDelegate.editConnection(SpoonDBDelegate.java:96)
at org.pentaho.di.ui.spoon.Spoon.editConnection(Spoon.java:2725) at
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498) at
org.pentaho.ui.xul.impl.AbstractXulDomContainer.invoke(AbstractXulDomContainer.java:313)
at
org.pentaho.ui.xul.impl.AbstractXulComponent.invoke(AbstractXulComponent.java:157)
at
org.pentaho.ui.xul.impl.AbstractXulComponent.invoke(AbstractXulComponent.java:141)
at
org.pentaho.ui.xul.jface.tags.JfaceMenuitem.access$100(JfaceMenuitem.java:43)
at
org.pentaho.ui.xul.jface.tags.JfaceMenuitem$1.run(JfaceMenuitem.java:106)
at org.eclipse.jface.action.Action.runWithEvent(Action.java:498) at
org.eclipse.jface.action.ActionContributionItem.handleWidgetSelection(ActionContributionItem.java:545)
at
org.eclipse.jface.action.ActionContributionItem.access$2(ActionContributionItem.java:490)
at
org.eclipse.jface.action.ActionContributionItem$5.handleEvent(ActionContributionItem.java:402)
at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:89)
at org.eclipse.swt.widgets.Display.sendEvent(Display.java:4385) at
org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1512) at
org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1535) at
org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1520) at
org.eclipse.swt.widgets.Widget.notifyListeners(Widget.java:1324) at
org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:4172)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3789)
at org.pentaho.di.ui.spoon.Spoon.readAndDispatch(Spoon.java:1385) at
org.pentaho.di.ui.spoon.Spoon.waitForDispose(Spoon.java:7968) at
org.pentaho.di.ui.spoon.Spoon.start(Spoon.java:9350) at
org.pentaho.di.ui.spoon.Spoon.main(Spoon.java:711) at
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498) at
org.pentaho.commons.launcher.Launcher.main(Launcher.java:92)
I'm using Java version 8 update 261. I know that PDI requires Java 8 so I don't understand why I'm having this issue. Currently, I have to delete and then create a new database connection for each job, which is really tedious.
How do I resolve this issue? Or is there another way to set my database connections so that I don't have to create a new one for each job?
I don't know about your error message, but to share connections IN YOUR PC you have the option in the View tab:
I have an empty transformation, so all the DB connections shown are the shared ones, if I had a new connection in the transformation it would be also shown but the connection name wouldn't be in bold letters.
Beware, the shared connections information are only available in your PC, and the connection information is copied to the transformation or job, so if you change the information in your shared connection, you need to reopen all the transformations and jobs that use it and save them with the new information.
In the .kettle folder in your user folder there's a shared.xml file with the shared connections information.
We have below code in our project and although it works fine but randomly we get class def not found error at runtime. Our App servers are restarted on each Sunday so sometimes we get this error on any random server instance.
Server restart fix the problem but any clue as why the class loading breaks in between.
I got somewhat similar error in this question and seems the issue is fixed in jdk 9 Transforming lambdas in Java 8
But before I conclude can someone explain it is the same kind of error and why it happens occasionally.
public boolean isAttachmentExpired(final Document_Attachment da) {
return this.bcDocumentScreen.getValidator().getAttachmentsValidator().isAttachmentExpired(da);
}
public boolean isAttachmentWarningShown() {
return CollectionUtils.isNotEmpty(getAttachments()) && getAttachments().stream().anyMatch(this::isAttachmentExpired);
}
public boolean isAttachmentExpired(final Document_Attachment da) {
final Date today = DateHelper.today();
return DateHelper.diffInYears(today, da.getUploaded()) >= 1;
}
Error:-
Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.GeneratedMethodAccessor1913.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.jboss.seam.util.Reflections.invoke(Reflections.java:22)
at org.jboss.seam.intercept.RootInvocationContext.proceed(RootInvocationContext.java:32)
at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:56)
at org.jboss.seam.core.BijectionInterceptor.aroundInvoke(BijectionInterceptor.java:79)
at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
at org.jboss.seam.persistence.ManagedEntityInterceptor.aroundInvoke(ManagedEntityInterceptor.java:48)
at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
at org.jboss.seam.transaction.RollbackInterceptor.aroundInvoke(RollbackInterceptor.java:28)
at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
at org.jboss.seam.core.MethodContextInterceptor.aroundInvoke(MethodContextInterceptor.java:44)
at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
at org.jboss.seam.intercept.RootInterceptor.invoke(RootInterceptor.java:107)
at org.jboss.seam.intercept.JavaBeanInterceptor.interceptInvocation(JavaBeanInterceptor.java:196)
at org.jboss.seam.intercept.JavaBeanInterceptor.invoke(JavaBeanInterceptor.java:114)
at com.XXX.BcdAttachmentsSection_$$_javassist_seam_91.isAttachmentWarningShown(BcdAttachmentsSection_$$_javassist_seam_91.java)
at sun.reflect.GeneratedMethodAccessor1912.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at javax.el.BeanELResolver.getValue(BeanELResolver.java:363)
at com.sun.faces.el.DemuxCompositeELResolver._getValue(DemuxCompositeELResolver.java:176)
at com.sun.faces.el.DemuxCompositeELResolver.getValue(DemuxCompositeELResolver.java:203)
at org.jboss.el.parser.AstPropertySuffix.getValue(AstPropertySuffix.java:53)
at org.jboss.el.parser.AstValue.getValue(AstValue.java:67)
at org.jboss.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:186)
at com.sun.faces.facelets.el.TagValueExpression.getValue(TagValueExpression.java:109)
... 122 more
Caused by: java.lang.NoClassDefFoundError: com/XXX/docsections/BcdAttachmentsSection$$Lambda$75
at com.XXX.BcdAttachmentsSection$$Lambda$75/1736532374.get$Lambda(Unknown Source)
at com.XXXX.isAttachmentWarningShown(BcdAttachmentsSection.java:51)
... 150 more
It’s quite possible that the bug, you have linked does apply, if Instrumentation is involved. Consider this bug, JDK-8027681, “Lambda serialization fails once reflection proxy generation kicks in”, that affected all Reflection operations that are performed more than 16 times (this is a configurable threshold), as the underlying implementation will optimize subsequent calls by generating an accessor class, consisting of bytecode that HotSpot can inline. This bytecode failed to access the anonymous classes generated for lambda expressions in early version of Java 8.
While this bug has been fixed, the described behavior of generating classes after a certain number of invocations still exists, so if an agent attempts to instrument these generated classes, it would fail due to the still existing Instrumentation bug and the dependency to the number of invocations is likely the reason why this only occurs occasionally.
While this bug in the Instrumentation/JVM should be fixed (and will be fixed in the next release), it would also help not trying to instrument these classes. Normally, there should be no reason to instrument these internal helper classes.
I have an Oracle SOA Composite that is generating a BPEL fault in Weblogic 11g. In EnterpriseManager I see the fault and the message:
<bpelFault>
<faultType>0</faultType>
<selectionFailure xmlns="http://schemas.xmlsoap.org/ws/2003/03/business-process/"></selectionFailure>
</bpelFault>
When I drill into the instance I see the following message listed on an assignement:
Error in evaluate expression at line "493". The result is empty for the XPath expression :
"/ns27:UsersCollection/ns27:Users/ns27:id"
I see the following error in the WLS-SOA1-diagnostic.log:
com.oracle.bpel.client.BPELFault: faultName: {{http://schemas.xmlsoap.org/ws/2003/03/business-process/}selectionFailure}
messageType: {{http://schemas.oracle.com/bpel/extension}RuntimeFaultMessage}
at com.collaxa.cube.engine.ext.bpel.common.BPELWMPHelper.evalFromValue(BPELWMPHelper.java:344)
at com.collaxa.cube.engine.ext.bpel.v1.wmp.BPEL1AssignWMP.__executeStatements(BPEL1AssignWMP.java:138)
at com.collaxa.cube.engine.ext.bpel.common.wmp.BaseBPELActivityWMP.perform(BaseBPELActivityWMP.java:166)
at com.collaxa.cube.engine.CubeEngine.performActivity(CubeEngine.java:2687)
at com.collaxa.cube.engine.CubeEngine._handleWorkItem(CubeEngine.java:1190)
at com.collaxa.cube.engine.CubeEngine.handleWorkItem(CubeEngine.java:1093)
at com.collaxa.cube.engine.dispatch.message.instance.PerformMessageHandler.handleLocal(PerformMessageHandler.java:78)
at com.collaxa.cube.engine.dispatch.DispatchHelper.handleLocalMessage(DispatchHelper.java:218)
at com.collaxa.cube.engine.dispatch.DispatchHelper.sendMemory(DispatchHelper.java:297)
at com.collaxa.cube.engine.CubeEngine.endRequest(CubeEngine.java:4609)
at com.collaxa.cube.engine.CubeEngine.endRequest(CubeEngine.java:4541)
at com.collaxa.cube.engine.CubeEngine._createAndInvoke(CubeEngine.java:713)
at com.collaxa.cube.engine.CubeEngine.createAndInvoke(CubeEngine.java:560)
at com.collaxa.cube.engine.ejb.impl.CubeEngineBean.createAndInvoke(CubeEngineBean.java:103)
at com.collaxa.cube.engine.ejb.impl.CubeEngineBean.syncCreateAndInvoke(CubeEngineBean.java:145)
at com.collaxa.cube.engine.ejb.impl.bpel.BPELEngineBean.syncCreateAndInvoke(BPELEngineBean.java:112)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
Has anyone run into this issue before? It seems strange as we only occasionally see this fault and error.
I made a change to the assignment in question here to "ignoreMissingFromData" and deployed it a few weeks ago and it seems to have worked fine ever since.
Thanks,
Tom
I have an application which manipulates the rows of a google spreadsheet. Occasionally, when I call ListEntry.update(), I receive the following stack trace:
Exception in thread "main" java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.eclipse.jdt.internal.jarinjarloader.JarRsrcLoader.main(JarRsrcLoader.java:58)
Caused by: com.google.gdata.util.PreconditionFailedException: Precondition Failed
Mismatch: etags = ["E10QemAgYit7ImA-CEFaShYM"], version = [2ag9hk74om621l]
at com.google.gdata.client.http.HttpGDataRequest.handleErrorResponse(HttpGDataRequest.java:614)
at com.google.gdata.client.http.GoogleGDataRequest.handleErrorResponse(GoogleGDataRequest.java:564)
at com.google.gdata.client.http.HttpGDataRequest.checkResponse(HttpGDataRequest.java:560)
at com.google.gdata.client.http.HttpGDataRequest.execute(HttpGDataRequest.java:538)
at com.google.gdata.client.http.GoogleGDataRequest.execute(GoogleGDataRequest.java:536)
at com.google.gdata.client.Service.update(Service.java:1563)
at com.google.gdata.client.Service.update(Service.java:1530)
at com.google.gdata.client.GoogleService.update(GoogleService.java:597)
at com.google.gdata.data.BaseEntry.update(BaseEntry.java:639)
at feedProcessor.ProcessClientFeed.UpdateRow(ProcessClientFeed.java:466)
at feedProcessor.ProcessClientFeed.updateGoogleSpreadsheet(ProcessClientFeed.java:404)
at feedProcessor.ProcessClientFeed.processFeed(ProcessClientFeed.java:318)
at feedProcessor.ProcessClientFeed.main(ProcessClientFeed.java:61)
... 5 more
Here is the relevant documentation:
https://developers.google.com/gdata/javadoc/com/google/gdata/data/spreadsheet/ListEntry
https://developers.google.com/gdata/javadoc/com/google/gdata/data/BaseEntry#update()
According to these docs, the update() function is not even capable of throwing a PreconditionFailedException, so the docs are essentially useless here. Testing the issue has shown that this exception is thrown when you try to call the update() function on the same row more than once in a session. Exactly what defines a 'session' is still unclear, but if you loop through all your rows more than once, and call update() on each row in each iteration, you will get this error. The only resolution I am aware of is to write your software such that each row (ListEntry) has update() called only once.
The problem is caused by Google Spreadsheet API Resource Versioning mecanism.
To be able to edit the entry no matter what - just use:
entry.setEtag("*")
before update.
And yes, this is not multi-user friendly. Refetch the feed if you need multi-user support.
When developing an application which consumes an external webservice I have generated the sources from the wsdl-url and then created a client:
GeoIPServiceClient service = new GeoIPServiceClient();
GeoIPServiceSoap geoIPClient = service.getGeoIPServiceSoap();
Since the creation of this proxy takes some time I set the client as an attribute in my service class.
But I'm worried that the client isn't thread safe and this webservice is heavily used in the application by concurrent threads (webapp). I can't find any documentation on this.
As a precaution I've started to use an object pool of soap clients instead of a shared one.
Is this an unnecessary precaution? What is the best practice when writing xfire clients?
I suspect some kind of concurrency problem with xfire since I regularly, under high load, get blocked threads and as a result of this the application crashes. Here's a partial thread dump:
"http-xx.xx.xx.xx-80-17" daemon prio=10 tid=0x00007f560d437000 nid=0x66cb waiting for monitor entry [0x00000000412b8000]
java.lang.Thread.State: BLOCKED (on object monitor)
at com.sun.xml.bind.v2.runtime.reflect.opt.Injector.inject(Injector.java:174)
- waiting to lock <0x00007f561d44e1c0> (a com.sun.xml.bind.v2.runtime.reflect.opt.Injector)
at com.sun.xml.bind.v2.runtime.reflect.opt.Injector.inject(Injector.java:85)
at com.sun.xml.bind.v2.runtime.reflect.opt.AccessorInjector.prepare(AccessorInjector.java:87)
at com.sun.xml.bind.v2.runtime.reflect.opt.OptimizedAccessorFactory.get(OptimizedAccessorFactory.java:165)
at com.sun.xml.bind.v2.runtime.reflect.Accessor$FieldReflection.optimize(Accessor.java:253)
at com.sun.xml.bind.v2.runtime.reflect.TransducedAccessor$CompositeTransducedAccessorImpl.<init>(TransducedAccessor.java:231)
at com.sun.xml.bind.v2.runtime.reflect.TransducedAccessor.get(TransducedAccessor.java:173)
at com.sun.xml.bind.v2.runtime.property.SingleElementLeafProperty.<init>(SingleElementLeafProperty.java:83)
at sun.reflect.GeneratedConstructorAccessor165.newInstance(Unknown Source)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at com.sun.xml.bind.v2.runtime.property.PropertyFactory.create(PropertyFactory.java:124)
at com.sun.xml.bind.v2.runtime.ClassBeanInfoImpl.<init>(ClassBeanInfoImpl.java:171)
at com.sun.xml.bind.v2.runtime.JAXBContextImpl.getOrCreate(JAXBContextImpl.java:481)
at com.sun.xml.bind.v2.runtime.JAXBContextImpl.<init>(JAXBContextImpl.java:315)
at com.sun.xml.bind.v2.ContextFactory.createContext(ContextFactory.java:139)
at com.sun.xml.bind.v2.ContextFactory.createContext(ContextFactory.java:117)
at com.sun.xml.bind.v2.ContextFactory.createContext(ContextFactory.java:188)
at sun.reflect.GeneratedMethodAccessor176.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:128)
at javax.xml.bind.ContextFinder.find(ContextFinder.java:277)
at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:372)
at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:337)
at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:244)
at org.codehaus.xfire.jaxb2.JaxbType.getJAXBContext(JaxbType.java:306)
- locked <0x00007f565b3aee60> (a org.codehaus.xfire.jaxb2.JaxbType)
at org.codehaus.xfire.jaxb2.JaxbType.writeObject(JaxbType.java:230)
at org.codehaus.xfire.aegis.AegisBindingProvider.writeParameter(AegisBindingProvider.java:229)
at org.codehaus.xfire.service.binding.AbstractBinding.writeParameter(AbstractBinding.java:273)
at org.codehaus.xfire.service.binding.WrappedBinding.writeMessage(WrappedBinding.java:90)
at org.codehaus.xfire.soap.SoapSerializer.writeMessage(SoapSerializer.java:80)
at org.codehaus.xfire.transport.http.HttpChannel.writeWithoutAttachments(HttpChannel.java:56)
at org.codehaus.xfire.transport.http.OutMessageRequestEntity.writeRequest(OutMessageRequestEntity.java:51)
at org.apache.commons.httpclient.methods.EntityEnclosingMethod.writeRequestBody(EntityEnclosingMethod.java:499)
at org.apache.commons.httpclient.HttpMethodBase.writeRequest(HttpMethodBase.java:2114)
at org.apache.commons.httpclient.HttpMethodBase.execute(HttpMethodBase.java:1096)
at org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(HttpMethodDirector.java:398)
at org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMethodDirector.java:171)
at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:397)
at org.codehaus.xfire.transport.http.CommonsHttpMessageSender.send(CommonsHttpMessageSender.java:369)
at org.codehaus.xfire.transport.http.HttpChannel.sendViaClient(HttpChannel.java:123)
at org.codehaus.xfire.transport.http.HttpChannel.send(HttpChannel.java:48)
at org.codehaus.xfire.handler.OutMessageSender.invoke(OutMessageSender.java:26)
at org.codehaus.xfire.handler.HandlerPipeline.invoke(HandlerPipeline.java:131)
at org.codehaus.xfire.client.Invocation.invoke(Invocation.java:79)
at org.codehaus.xfire.client.Invocation.invoke(Invocation.java:114)
at org.codehaus.xfire.client.Client.invoke(Client.java:336)
at org.codehaus.xfire.client.XFireProxy.handleRequest(XFireProxy.java:77)
at org.codehaus.xfire.client.XFireProxy.invoke(XFireProxy.java:57)
at $Proxy143.getMyMethod(Unknown Source)
The thread dump contains a lot of blocked threads that look like this.
I guess as you get a lot of blocked threads, the client is actually thread-safe as object data is not corrupted :). But I agree it's not handling the concurrency in a good way.
1) One observation is that the final lock seems to be in JAXB implementation and not in XFire. What if you try using different JAXB implementation like JaxMe?
2) Also the method getJAXBContext in JaxbType is synchronised. And most likely because your threads are accessing the same JaxbType instance they may be blocked.
Looking at that method I would actually moved the synchronisation into the method after context presense is checked:
if (context == null) {
synchronized (this) {
...
This will allow for clients that already have JAXBContext initialised to skip expensive synchronisation.
My suggestion is either try fixing the code yourself and make a test or submit a bug to XFire or do both :).
Depends on the version of Xfire you are using, as they have fixed few Thread Safety issues in version 1.2.5. You can check the bug raised at http://jira.codehaus.org/browse/XFIRE-886 , and see more details on the release notes at hxxp://xfire.codehaus.org/XFire+1.2.5+Release+Notes