I had to copy some existing beans and their remote interfaces within an existing working application. Now whenever I call one of the methods, I get the following exception:
java.lang.IllegalStateException: EJBCLIENT000032: Cannot retry a request which hasn't previously been completed
at org.jboss.ejb.client.EJBClientInvocationContext.retryRequest(EJBClientInvocationContext.java:203)
at org.jboss.ejb.client.EJBInvocationHandler.sendRequestWithPossibleRetries(EJBInvocationHandler.java:256)
at org.jboss.ejb.client.EJBInvocationHandler.sendRequestWithPossibleRetries(EJBInvocationHandler.java:265)
at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:198)
at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:181)
at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:144)
at com.sun.proxy.$Proxy27.createRawSTRProfiles(Unknown Source)
at org.acme.project.CreateSomethingRunnable.run(CreateSomethingRunnable.java:76)
at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:121)
The same bean works for other method calls. There is no other exception on neither client nor server side, a breakpoint inside the server method in question is never called. I have no idea how to debug, and Google is oblivous to this error message. We are using WildFly 8.1.0.Final.
Can anybody help shed light on this issue? Thanks.
The root exception for us was a ClassNotFoundError because an entirely unrelated JAR inside the EAR had the wrong version number.
Double-check everything. We dismantled the value that was sent (setting all fields to null). When that worked, we set the fields to objects again one by one, checking the classes in question for Serializable (because sometimes a missing Serializable causes similar exceptions).
In short, ensure that all classes going over the wire implement the Serializable interface.
Related
Firstly i would like to apologize if i could not find anything about what i would like to describe that really solved my problems. This does not mean that i fully searched in the site. Although i have been spending too much time (days). I am also new on here (in the sense that i never wrote/replied to SO users). And i am sorry for my possible english errors.
I have to say i am new to Java EE.
I am working on WildFly 14, using MySQL.
I am now focusing on a JPA problem.
I have a uniqueness constraint. I am doing tests and while performing the uniqueness violation test, from the data source level i get a MySQLIntegrityConstraintViolationException, and that's ok. I have the problem in that the persist() method does not let me catch the exception (i even put Throwable in the clause, but nothing..). I strongly, strictly, need to catch that, in order to manage a crucial procedure (that, indirectly contains the call to .remove()) in my work's code.
By the way, trying to write that exception, the system does not show me the window of the suggested classes/annotations/etc, suggesting me just to create the class "MySQLIntegrityConstraintViolationException". Doesn't working on WildFly, using MySQL, suffice, for having the suggestions?
Not finding the solution, i decided to change: instead of using persist(), i decided to use .createNativeQuery() in which i put as parameter a String describing an insertion in the db. It seems working. Indeed it works (signals uniqueness violation (ok!), does not execute the TRY block code (ok!) and goes into CATCH block (ok!)). But, again, the exception/error is not clear.
Also, when in the code i enter the piece of code that is in charge of managing the catching and then executing what's inside (and i have a .remove(), inside), it raises the exception:
"Transaction is required to perform this operation (either use a transaction or extended persistence context)" --> this referring to my entityManager.remove() execution..
Now i cannot understand.. should not JPA/JTA manage automatically the transactions?
Moreover, trying, later, to put entityManager.getTransaction().begin() (and commit()), it gives me the problem of having tried to manage manually transactions when instead i couldn't.. seems an endless loop..
[edit]: i am working in CMT context, so i am allowed to work with just EntityManager and EntityManagerFactory. I have tried with entityManager.getTransaction().begin() and entityManager.getTransaction().commit() and it hasn't worked.
[edit']: .getTransaction (EntityTransaction object) cannot be used in CMT context, for this reason that didn't work.
[edit'']: i have solved the transaction issue, by means of the transaction management suited for the CMT context: JTA + CMT requires us to manage the transactions with a TRY-CATCH-FINALLY block, in whose TRY body it is needed to put the operation we want to perform on the database and in whose FINALLY body it is needed to put the EntityManager object closing (em.close()). Though, as explained above, i have used em.createNativeQuery(), that, when failing, throws catchable (catchable in my app) exceptions; i would really need to do a roll-back (usage of .createNativeQuery() is temporary) in my work code and use the .persist() method, so i need to know what to do in order to be able to catch that MySQLIntegrityConstraintViolationException.
Thanks so much!
IT SEEMS i have solved the problem.
Rolling back to the use of .persist() (so, discarding createNativeQuery()), putting em.flush() JUST AFTER em.persist(my_entity_object) has helped me, in that, once the uniqueness constraint is violated (see above), the raised exception is now catchable. With the catchable exception, I can now do as described at the beginning of the post.
WARNING: I remind you of the fact that i am new to JavaEE-JPA-JTA. I have been "lucky" because, since my lack of knowledge, i put that instruction (em.flush()) by taking a guess (i don't know how i could think of that). Hence, I would not be able to explain the behaviour; I would appreciate, though, any explanation of what could have happen, of how and when the method flush() is used, and so on and so forth..
Thanks!
I was looking at scala.util.control.NonFatal. I can't find the source, but I believe it is something like this.
They are declaring LinkageError as Fatal ...
Tomcat (at least last few years I used it) always returned 500 on catch Throwable, rather than crashing on certain kinds of errors. So do many other systems that make a best effort to always return something to the client.
So, my end question is when would you use NonFatal instead of making a best-effort attempt to provide some response?
As an example, now Futures in Twitter's Future library end up not resolving on NoSuchMethodError so my Future no longer resolves as failed with a Throwable but instead throw up the stack (differently from RuntimeException). In fact, in the open source Finagle stack, a NoSuchMethodError will cause the client socket connection to close on the client with no 500 http error back to customer. Customer then thinks 'hmm, network issue maybe ... why did my socket close'
So far, it has caused me nothing but issues and I admit to be a little frustrated, but need to be open to more use cases. For years, KISS and treating every Throwable in the catchall as non fatal has worked, but NonFatal is implying there are use-cases where we should do something different.
The source code of NonFatal is linked from the API docs.
Fatal errors are those from which your system or the JVM will most likely not recover correctly, so catching those errors is not a good idea.
The sub-classes of LinkageError are: ClassCircularityError, ClassFormatError, ExceptionInInitializerError, IncompatibleClassChangeError, NoClassDefFoundError, UnsatisfiedLinkError, VerifyError. These all occur when your class path is broken, there are invalid or binary incompatible class files. It's safe to assume that your entire system is broken if these happen at runtime.
To answer the question: You should "let it crash". Always use a NonFatal pattern match when you need a catch-all clause. It will also do you the favour and handle control-flow related exceptions correctly (e.g. NonLocalReturnControl).
Note that unlike the old source you link to, StackOverflowError is not non-fatal any longer, the decision was revised in Scala 2.11 as per SI-7999.
For the last two years we've been developing a web based application with ASP.NET MVC 3, NHibernate (v. 3.3.1.4000) and PostgreSql for back-end database, therefore using the Npgsql driver (v. 2.0.12.0). The system has been in successful exploitation on 4 different client servers and has never produced the error I encountered on a new server we setup recently. The exception has occurred only once, upon the initial population with data, and prevented some business entities from being stored to the DB. I really must make sure that in the future the error is properly handled, if not at all possible to be avoided, but am at a loss how. Searching the site and the internet in general for this or similar errors has produced no information. Has any of you encountered this problem or have an idea how to fix it? Thanks :)
Here's the error:
System.NotSupportedException: This stream does not support seek operations.
at System.Net.Sockets.NetworkStream.Seek(Int64 offset, SeekOrigin origin)
at System.IO.BufferedStream.FlushRead()
at System.IO.BufferedStream.WriteByte(Byte value)
at Npgsql.NpgsqlSync.WriteToStream(Stream outputStream)
at Npgsql.NpgsqlReadyState.SyncEnum(NpgsqlConnector context)
at Npgsql.NpgsqlState.Sync(NpgsqlConnector context)
at Npgsql.ForwardsOnlyDataReader.GetNextResponseObject()
at Npgsql.ForwardsOnlyDataReader.GetNextRowDescription()
at Npgsql.ForwardsOnlyDataReader.NextResult()
at Npgsql.ForwardsOnlyDataReader..ctor(IEnumerable`1 dataEnumeration, CommandBehavior behavior, NpgsqlCommand command, NotificationThreadBlock threadBlock, Boolean synchOnReadError)
at Npgsql.NpgsqlCommand.GetReader(CommandBehavior cb)
at Npgsql.NpgsqlCommand.ExecuteNonQuery()
at NHibernate.AdoNet.AbstractBatcher.ExecuteNonQuery(IDbCommand cmd)
at NHibernate.AdoNet.NonBatchingBatcher.AddToBatch(IExpectation expectation)
at NHibernate.Persister.Entity.AbstractEntityPersister.Insert(Object id, Object[] fields, Boolean[] notNull, Int32 j, SqlCommandInfo sql, Object obj, ISessionImplementor session)
at NHibernate.Persister.Entity.AbstractEntityPersister.Insert(Object id, Object[] fields, Object obj, ISessionImplementor session)
at NHibernate.Action.EntityInsertAction.Execute()
at NHibernate.Engine.ActionQueue.Execute(IExecutable executable)
at NHibernate.Engine.ActionQueue.ExecuteActions(IList list)
at NHibernate.Engine.ActionQueue.ExecuteActions()
at NHibernate.Event.Default.AbstractFlushingEventListener.PerformExecutions(IEventSource session)
at NHibernate.Event.Default.DefaultFlushEventListener.OnFlush(FlushEvent event)
at NHibernate.Impl.SessionImpl.Flush()
at NHibernate.Transaction.AdoTransaction.Commit()
Since the stack trace originates from NHibernate.Transaction.AdoTransaction.Commit, that means this error was probably logged by NHibernate itself. Your application must do its own logging so that you can have...
details for errors that occur outside of NHibernate
better context for errors that bubble up from NHibernate, like the one you've encountered
See "log all unhandled application errors" and "exception handling should never hide issues" for help on implementing this type of logging.
Without more information about the code that generated this error, this will be nearly impossible to fix. Fixing the logging and exception handling code needs to be one of the top priorities when working with a new code base in order to actually have a fighting chance to fix bugs and improve the code.
This seems to be a bug inside Npgsql.
According to the stacktrace (and checking Npgsql code: https://github.com/npgsql/Npgsql/blob/master/src/Npgsql/NpgsqlDataReader.cs#L1163), when an error occurs inside the GetNextResponseObject(), Npgsql sends a Sync message to server to reset the conversation to a consistent state. The problem is that when this error occurs, some data may have been left in the stream and when Npgsql tries to write to it, the buffered stream checks if there is data yet and, while flushing the data, tries to call seek which isn't supported by a network stream ( over which the buffered stream is created ).
A possible fix for this bug is to flush the buffered stream from any possible data left before writing to it.
I'll create a pull request with this change.
The biggest problem is that this type or error is very rare, as you noticed. This error occurred only once for you. I'll need to investigate more what have caused the exception to be thrown in the first place.
I hope it helps.
The most popular desicion for handling exceptions in rest service and return the error message to client - as i understand - is to catch WebApplicationException or MappableContainerException. But they are extending RuntimeExceprion (I don't understand why). As I know we should avoid handling RuntimeExceptions.
I need to handle such exceptions as "The entity with such name already exsists". I'm sure it is not a runtime exception.
Any other ways? I'm researching now Wrappers. May be you could excplain me the best way to solve my problem?
The way that I handle this is to have my own exception hierarchy, and to build a separate ExceptionMapper which handles this hierarchy. That allows me to pass back whatever information I need to (in my case a JSON-formatted response) in a standardized way.
I would still have an ExceptionMapper for WebApplicationException, otherwise the end user might receive some nasty looking responses. And if you want to be extra-safe then you can also put one in for Exception that picks up anything else you might have missed (the exceptions go to the most specific exception mapper for them, so putting one in for Exception doesn't affect them).
In GWT application I have RPC interface. Some methods works fine (i.e. RemoeServiceServlet configured fine), but when I try to invoke another method, it always fails with onFailure() method. Ajax call also don't occur (I can see it using FireBug, also on server side method invocation don't occur), but another methods of this service performs Ajax calls as well.
When I try to log error using e.getMessage() I get "undefined" message. Also I tried to wrap RPC calling code using try-catch - no error message.
Can this issue be related with GWT-RPC Serialization?
EDIT: Opera Dragonfly showed error on following method inside generated JavaScript (compiled with PRETTY mode):
function $check(this$static, typeSignature){
if (isNull($get_3(this$static.methodMapNative, typeSignature))) {
Unhandled Object: undefined
throw new SerializationException_1(typeSignature);
}
}
with error message
Unhandled Object: undefined
I would guess that you have a Serialization issue, remember that Java Serialization is not the same as GWT Serialization.
There is often no meaningful error message on Serialization errors when using RPC.
must have 0-ary constructor
final fields are inherently transient (ie. do NOT use final fields in classes intended to be serialized)
collections (ex List and Set) must be annotated with #gwt.typeArgs. #gwt.typeArgs is a JavaDoc annotation, thus it must be wrapped in a JavaDoc comment
ex.: /** #gwt.typeArgs */
For more details see:
GWT Serialization
Another thing to try:
When running GWT from the eclipse-plugin, a folder in the eclipse project is created (I belive its called gwt-unitCache). Sometimes my own GWT projects get ill and output strange exceptions, I can solve this by deleting the folder and run the project again.