Trying to invoke:
QueryCriteria linearStateCriteria = new QueryCriteria.LinearStateQueryCriteria(null,null,Arrays.asList(externalId),Vault.StateStatus.UNCONSUMED);
connection.getProxy().vaultQueryByCriteria(linearStateCriteria,SomeState.class);
getting exception:
Serialization failed direction="Serialize", type="net.corda.core.node.services.vault.QueryCriteria$LinearStateQueryCriteria", msg="Defined getter for parameter contractStateTypes returns type java.util.Set<java.lang.Class<? extends net.corda.core.contracts.ContractState>> yet underlying type is java.util.Set<java.lang.Class<? extends net.corda.core.contracts.ContractState>>", ClassChain="java.util.List<*> -> net.corda.core.node.services.vault.QueryCriteria$LinearStateQueryCriteria"
Looks like bug in serialization in client rpc. If somebody faced this issue or this is a known bug please advice.
Thanks.
As mention in this question: Corda 4.0 transaction serialization issue
It is not necessarily a serialization issue, rather it is the java.util.Set class not get properly picked up.
It's caused by a bug in certain versions of Guava. As stated in the other question, it is fixed by the later releases.
Related
while upgrading our spring kafka to 2.7.8, we are getting error in the setAckOnError(false) method as it has been deprecated now. Is there any way now to set the acknowledgement for the errors to false? Any other methods that can help me to set it as false for errors acknowledgement?
P.S: I am new to Kafka, any help appreciated!
That property was found to have a (very small) timing hole in that a record could be ack'd before the error handler handles it; if the app dies at that time, the record could be "lost".
It was replaced by a new feature in the error handlers ackAfterHandle; which is true by default - i.e. the record's offset is only committed if the error handler "handles" the error.
Records are now never ack'd if the error handler (such as the SeekToCurrentErrorHandler) throws an exception (after it repositions the partitions).
There is no extra configuration needed any more.
See Spring Kafka AckOnError for more details.
IBM WAS: 8.5.5 Version
On JSP pages have & tags, I receive below error
Error 500: java.lang.Exception: java.lang.VerifyError: JVMVRFY012
stack shape inconsistent; class=com/ibm/_jsp/_desktop,
method=_jspx_meth_c_set_0(Ljavax/servlet/jsp/PageContext;)Z, pc=73;
Type Mismatch, argument 1 in signature
org/apache/jasper/el/ELContextWrapper.:(Ljavax/el/ELContext;Ljavax/el/FunctionMapper;)V
does not match Exception Details:
Location:
com/ibm/_jsp/_desktop._jspx_meth_c_set_0(Ljavax/servlet/jsp/PageContext;)Z
#73: JBinvokespecial Reason: Type
'org/apache/jasper/runtime/ProtectedFunctionMapper' (current frame,
stack[8]) is not assignable to 'javax/el/FunctionMapper'
Current Frame: bci: #73 flags: { } locals: { 'com/ibm/_jsp/_desktop',
'javax/servlet/jsp/PageContext', 'javax/servlet/jsp/JspWriter',
'org/apache/taglibs/standard/tag/rt/core/SetTag' } stack: {
'org/apache/taglibs/standard/tag/rt/core/SetTag', 'uninitialized',
'uninitialized', 'java/lang/String', 'javax/el/ExpressionFactory',
'uninitialized', 'uninitialized', 'javax/el/ELContext',
'org/apache/jasper/runtime/ProtectedFunctionMapper' } Stackmap Table:
append_frame(#128,Object[#127],Object[#231],integer)
On reading https://www.ibm.com/support/pages/ibm-java-linux-howto-resolving-javalangverifyerror-jvmvrfy012-stack-shape-inconsistent, understand that the reason could be
code is compiled against a different library than the one being used at runtime
a class tries to extend a class declared as final
a method tries to override a super method that is declared as final
a wrong argument is passed to a method
It does look to be #4 - but the same code works in Tomcat and does not work in IBM WAS and am unsure why WAS is passing an incorrect argument. Any suggestions on how we can resolve this issue?
You may want to explore Servlet/JSP version compatibility.
WAS: 8.5.5 reference
Servlet 3.0
JSP 2.2
If you happen to be using Spring Boot:
2.2.x and 2.1.x require Servlet 3.1+
2.0.x supports Servlet 3.0
This looks like a cross-linkage between the javax.el library in your application and the version packaged in the server. When using PARENT_LAST, any Java EE APIs you include in the application are loaded twice, once from the server and once from the application (because the application loader doesn't delegate that load to its parents). Depending on the other classes/packages in play, you can have an instance in which a class ends up directly referencing one instance of the class and indirectly (through some other reference) referencing the other instance, and the JVM will throw a VerifyError in that scenario.
The easiest answer: If you are not 200% sure you NEED the version of the javax.el classes in the app, remove them, and this specific error should be impossible. If you are definitely dependent on that version, then it becomes trickier, as it might require adding additional stuff to the application (to avoid picking stuff up from the server), or it may be that this specific library simply can't be safely overridden with PARENT_LAST loading. That analysis would require a deeper look at the error stack and possibly a dive into detail trace of the class loading.
Having recently upgraded to Corda 4.0 we are now seeing a serialization exception when trying to create transactions:
[ERROR] 10:09:49,500 [Mock network] amqp.SerializationOutput. -
Serialization failed direction="Serialize",
type="net.corda.core.transactions.TraversableTransaction",
msg="Defined getter for parameter commands returns type
java.util.List> yet underlying
type is java.util.List>",
ClassChain="net.corda.core.transactions.TraversableTransaction"
{actor_id=Only For Testing, actor_owning_identity=O=Supplier 1,
L=London, C=GB, actor_store_id=TEST, fiber-id=10000001,
flow-id=e61b7da7-6826-4410-9414-1c03bebbc3fe,
invocation_id=58c5f5ff-09f8-4bfa-bbe5-cf6b0ef47d06,
invocation_timestamp=2019-03-28T10:09:46.205Z, origin=Only For
Testing, session_id=58c5f5ff-09f8-4bfa-bbe5-cf6b0ef47d06,
session_timestamp=2019-03-28T10:09:46.205Z, thread-id=400}
Any ideas what causes this?
Anytime you see an error message of this form on Corda 4:
Defined getter for parameter [parameter name] returns type [type] yet
underlying type is [exactly the same type]
It's caused by a bug in certain versions of Guava.
Corda 4 uses Guava version 25.1-jre. However, if your node loads another version of Guava (e.g. 21.0) that overrides Corda's version of Java, you will see this error.
A fix is planned for Corda 4.1.
I faced this issue as well after upgrade to 4.0. My flows returned transaction as output and I've got TraversableTransaction serialization exception. I didn't solved it. I've created flow response DTO with all appropriated data, trxId etc...
Example:
SignedTransaction signedTransaction = subFlow(new FinalityFlow(signedTx, session));
response.setTrxId(signedTransaction.getId().toString());
return response;
I am facing an issue in my deployment where I am using a completable future to do asynchronous task in tomcat servlet (version 8.5.23).
I am aware that my following question could not say much about the implementation details but unfortunately I could not come up with a simple example to recreate the issue. Please pardon me for that. I hope that some experts in the field can give me high level advice or suggestion which I could further look into it.
It’s a follow up of my previous question Do the task asynchronously but reply first.
What I would like to do was “whenever I receive a request from the client then I have to start a task which may take an hour. Therefore I have immediately reply to the user that ‘the task has started’ before the task finishes.
I initially used AsyncContext.start() to do this but what I found that AsyncContext won’t return the response to the client until it calls the onComplete(AsyncEvent event).
Therefore I replaced AsyncContext.start() with CompletableFuture.runAsync(Runnable). It initially appeared to me that it’s doing the correct job but later I found out that it’s giving me an issue.
In my task I was using com.caucho.hessian.client.HessianProxyFactory.create(Class api, String urlName) to create proxy class of backend interface but
after using the completable future then a runtime occurs which says the java.lang.RuntimeException: java.lang.IllegalArgumentException: interface MyInterface is not visible from class loader.
I will be grateful if, somebody can throw some light into the issue
I found out a solution for my issue. It seems to work now but I do not know whether it would it create a new issue. I basically ensured that the async task used the same class loader.
ClassLoader cl = Thread.currentThread().getContextClassLoader();
CompletableFuture.runAsync(() -> {
try {
Thread.currentThread().setContextClassLoader(cl);
.......
I am getting this error during serialization:
RangeError: Error #2006: The supplied
index is out of bounds.
The error occurs in AbstractMessage.as when it attempts to read input of timestamp.
After that my fault handler gets this error:
faultCode:Server.Acknowledge.Failed
faultString:'Didn't receive an
acknowledge message' faultDetail:'Was
expecting
mx.messaging.messages.AcknowledgeMessage,
but received null'
It appears to be happening as a result of an ArrayCollection coming back from the server.
Is it necessary to create custom classes to handle serialization of ArrayCollections with custom objects as shown here?
I've also followed the serialization recommendations here with no luck.
Thanks for your help!
The solution was correcting a mistake in writeExternal on the Java side. I was being very careful about the order of serialization but was writing an int as an object using writeObject. This will cause errors in completely unrelated code on the client side after it tries to readInt.
I just experienced this error myself, and it turns out it is caused by the Flash Builder Network monitor being enabled!! FB 4.0.1 this is.
I was going nuts for not finding the reason, so sharing it here for your peace of mind.