We have developed Server-Client application using CORBA.
When client try to make a request to Server, we get below error message.
Jan 14, 2018 10:00:22 AM com.sun.corba.se.impl.transport.SocketOrChannelConnectionImpl writeLock
WARNING: "IOP00410202: (COMM_FAILURE) Connection close: rebind"
org.omg.CORBA.COMM_FAILURE: vmcid: SUN minor code: 202 completed: No
at com.sun.corba.se.impl.logging.ORBUtilSystemException.connectionCloseRebind(Unknown Source)
at com.sun.corba.se.impl.logging.ORBUtilSystemException.connectionCloseRebind(Unknown Source)
at com.sun.corba.se.impl.transport.SocketOrChannelConnectionImpl.writeLock(Unknown Source)
at com.sun.corba.se.impl.encoding.BufferManagerWriteStream.sendFragment(Unknown Source)
at com.sun.corba.se.impl.encoding.BufferManagerWriteStream.sendMessage(Unknown Source)
at com.sun.corba.se.impl.encoding.CDROutputObject.finishSendingMessage(Unknown Source)
at com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.finishSendingRequest(Unknown Source)
at com.sun.corba.se.impl.protocol.CorbaClientRequestDispatcherImpl.marshalingComplete1(Unknown Source)
at com.sun.corba.se.impl.protocol.CorbaClientRequestDispatcherImpl.marshalingComplete(Unknown Source)
at com.sun.corba.se.impl.protocol.CorbaClientDelegateImpl.invoke(Unknown Source)
at org.omg.CORBA.portable.ObjectImpl._invoke(Unknown Source)
What we observed that, whenever client make continuous 5-6 requests, client gets the above error for particular 2-keys. Sometimes first 4 requests work correctly but get the error on last request. Or sometime gets the error on first request then remaining requests work correctly.
I have done enough search on google but did not find the solution.
I hope someone will help me here.
COMM_FAILURE means the underlying connection failed somehow. In your case, you're experiencing a premature close of the connection.
You reported only a warning message. Do you experienced an COMM_FAILURE exception in your code or are you seeing this only in log messages? In my guess this seems only a ORB internal log message and, if I'm right, it's not a problem at all.
In some very simple hello world code you could experience this when you execute the server without a orb.run() in your server, or even you're doing a System.exit while processing the invocation.
In other hand, I recommend you to use http://JacORB.org implementation instead of old and unsupported Sun implementation for CORBA (built-in the Oracle JVM). JacORB is a mature implementation and it's compliant to CORBA 3.0 spec.
Related
I have followed Android quickstart conversations project
I am facing a crash with following details -
com.twilio.conversations.ListenerException: Exception thrown by a listener. Your application might have a problem in listener implementation. Listeners must never throw uncaught exceptions. See 'Caused by:' below for more details.
at java.lang.reflect.Constructor.newInstance0(Native Method)
at java.lang.reflect.Constructor.newInstance(Constructor.java:343)
at com.twilio.conversations.internal.RethrowingForwarder$RethrowingProxy.invoke(RethrowingForwarder.java:123)
at java.lang.reflect.Proxy.invoke(Proxy.java:1006)
at $Proxy10.onSuccess(Unknown Source)
at com.twilio.conversations.internal.CallbackListenerForwarder$1.run(CallbackListenerForwarder.java:34)
at android.os.Handler.handleCallback(Handler.java:883)
at android.os.Handler.dispatchMessage(Handler.java:100)
at android.os.Looper.loop(Looper.java:214)
at android.app.ActivityThread.main(ActivityThread.java:7356)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:492)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:930)
Caused by: java.lang.IllegalStateException: Messages are not available at the moment. Synchronize the conversation first.
at com.twilio.conversations.ConversationImpl.getMessages(ConversationImpl.java:214)
at com.twilio.conversations.ConversationImpl.getLastMessages(ConversationImpl.java:282)
at QuickstartConversationsManager.loadPreviousMessages(QuickstartConversationsManager.java:222)
at QuickstartConversationsManager.access$600(QuickstartConversationsManager.java:43)
at QuickstartConversationsManager$3.onSuccess(QuickstartConversationsManager.java:156)
at QuickstartConversationsManager$3.onSuccess(QuickstartConversationsManager.java:147)
at java.lang.reflect.Method.invoke(Native Method)
at com.twilio.conversations.internal.RethrowingForwarder$RethrowingProxy.invoke(RethrowingForwarder.java:121)
at java.lang.reflect.Proxy.invoke(Proxy.java:1006)
at $Proxy10.onSuccess(Unknown Source)
at com.twilio.conversations.internal.CallbackListenerForwarder$1.run(CallbackListenerForwarder.java:34)
at android.os.Handler.handleCallback(Handler.java:883)
at android.os.Handler.dispatchMessage(Handler.java:100)
at android.os.Looper.loop(Looper.java:214)
at android.app.ActivityThread.main(ActivityThread.java:7356)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:492)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:930)
Any ideas on what is missing or what is wrong?
I know this has been a while, but I experienced this issue while moving from Twilio Chat to Twilio Conversation. How I fixed it was to wrap the method you are calling in a synchronization Status check.
Caused by: java.lang.IllegalStateException: Messages are not available at the moment. Synchronize the conversation first. is meaning conversation may be out of sync.
if (conversation?.synchronizationStatus?.isAtLeast(Conversation.SynchronizationStatus.ALL) == true) {
conversation?.setAllMessagesRead { value -> Timber.v("Unread Count:" + value) }
}
Here is twilio documentation about what do if your conversation is out of sync or what to do with the else statement.
https://www.twilio.com/docs/conversations/best-practices-sdk-clients#mobile-sdks-specifics
I am a graduate student (master's) and use an in-house code for running my simulations that use MPI. Earlier, I used OpenMPI on a supercomputer we used to access and since it shut down I've been trying to switch to another supercomputer that has Intel MPI installed on it. The problem is, the same code that was working perfectly fine earlier now gives memory leaks after a set number of iterations (time steps). Since the code is relatively large and my knowledge of MPI is very basic, it is proving very difficult to debug it.
So I installed OpenMPI onto this new supercomputer I am using, but it gives the following error message upon execution and then terminates:
Invalid number of PE
Please check partitioning pattern or number of PE
NOTE: The error message is repeated for as many numbers of nodes I used to run the case (here, 8). Compiled using mpif90 with -fopenmp for thread parallelisation.
There is in fact no guarantee that running it on OpenMPI won't give the memory leak, but it is worth a shot I feel, as it was running perfectly fine earlier.
PS: On Intel MPI, this is the error I got (compiled with mpiifort with -qopenmp)
Abort(941211497) on node 16 (rank 16 in comm 0): Fatal error in PMPI_Isend: >Unknown error class, error stack:
PMPI_Isend(152)...........: MPI_Isend(buf=0x2aba1cbc8060, count=4900, dtype=0x4c000829, dest=20, tag=0, MPI_COMM_WORLD, request=0x7ffec8586e5c) failed
MPID_Isend(662)...........:
MPID_isend_unsafe(282)....:
MPIDI_OFI_send_normal(305): failure occurred while allocating memory for a request object
Abort(203013993) on node 17 (rank 17 in comm 0): Fatal error in PMPI_Isend: >Unknown error class, error stack:
PMPI_Isend(152)...........: MPI_Isend(buf=0x2b38c479c060, count=4900, dtype=0x4c000829, dest=21, tag=0, MPI_COMM_WORLD, request=0x7fffc20097dc) failed
MPID_Isend(662)...........:
MPID_isend_unsafe(282)....:
MPIDI_OFI_send_normal(305): failure occurred while allocating memory for a request object
[mpiexec#cx0321.obcx] HYD_sock_write (../../../../../src/pm/i_hydra/libhydra/sock/hydra_sock_intel.c:357): write error (Bad file descriptor)
[mpiexec#cx0321.obcx] cmd_bcast_root (../../../../../src/pm/i_hydra/mpiexec/mpiexec.c:164): error sending cmd 15 to proxy
[mpiexec#cx0321.obcx] send_abort_rank_downstream (../../../../../src/pm/i_hydra/mpiexec/intel/i_mpiexec.c:557): unable to send response downstream
[mpiexec#cx0321.obcx] control_cb (../../../../../src/pm/i_hydra/mpiexec/mpiexec.c:1576): unable to send abort rank to downstreams
[mpiexec#cx0321.obcx] HYDI_dmx_poll_wait_for_event (../../../../../src/pm/i_hydra/libhydra/demux/hydra_demux_poll.c:79): callback returned error status
[mpiexec#cx0321.obcx] main (../../../../../src/pm/i_hydra/mpiexec/mpiexec.c:1962): error waiting for event"
I will be happy to provide the code in case somebody is willing to take a look at it. It is written using Fortran with some of the functions written in C. My research progress has been completely halted due to this problem and nobody at my lab has enough experience with MPI to resolve this.
06-22 08:17:30.568 31107-31119/? E/CastService: [instance-4]
ICastDeviceControllerListener can't be null. 06-22 08:17:30.578
8284-8601/? E/EnterpriseContainerManager: ContainerPolicy Service is
not yet ready!!! 06-22 08:17:30.578 31107-31136/? E/Publisher:
ProcessDatabaseInternal start 06-22 08:17:30.578 32326-32326/?
E/ViewRootImpl: sendUserActionEvent() mView == null 06-22 08:17:30.588
32326-32326/? E/AndroidRuntime: FATAL EXCEPTION: main
java.lang.IllegalStateException:
A fatal developer error has occurred. Check the logs for further
information.
at com.google.android.gms.internal.jl$h.b(Unknown Source)
at com.google.android.gms.internal.jl$h.g(Unknown Source)
at com.google.android.gms.internal.jl$b.hy(Unknown Source)
at com.google.android.gms.internal.jl$a.handleMessage(Unknown Source)
at android.os.Handler.dispatchMessage(Handler.java:99)
at android.os.Looper.loop(Looper.java:137)
at android.app.ActivityThread.main(ActivityThread.java:5283)
at java.lang.reflect.Method.invokeNative(Native Method)
at java.lang.reflect.Method.invoke(Method.java:511)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:1102)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:869)
at dalvik.system.NativeStart.main(Native Method) 06-22 08:17:30.919
8284-8333/? E/android.os.Debug: !#Dumpstate > dumpstate -k -t -z -d -o
/data/log/dumpstate_app_error 06-22 08:17:36.414 31107-31136/?
E/Publisher: ProcessDatabaseInternal start
I have this issue while connecting to chromecast. I've gone back to the previous code, and I still have the same issue, so something must have changed with chromecast. When I click my chromecast device to connect to "Sankey", this is when the crash occurs. Image below:
Research on this has pointed to a problem with the manifest, and not declaring the app_id properly. Below is my manifest file which shows this, and also the google play services version.
<meta-data android:name="com.google.android.gms.games.APP_ID"
android:value="#string/control_panel_app_id" />
<meta-data
android:name="com.google.android.gms.version"
android:value="#integer/google_play_services_version" />
Here is the declarations in strings.xml with last 4 digits blocked out:
string name="control_panel_app_id" translatable="false">75468636XXXX
Checking the logs in vicinity of the crash has not given me any useful information.
My app was previously running cast SDK v1. I had two options to fix it: 1) wait approximately 3 months until google updated their gms code. 2) upgrade to cast v2.
I chose option 2.
Upgrading to cast v2 was done by the following:
change gradle files, so everything referencing any part of google play is version 11.0.0. ex: com.google.android.gms:play-services-games:11.0.0
required deleting references to "AppStateManager" in GameHelper.java (this is not necessary for cast, but was part of my project).
required changing minSdkVersion from 11 to 14 :(
in gradle file(s), update compileSdkVersion to 25, and buildToolsVersion to 25.0.2
Hope this helps someone out.
You may refer in this link. Make sure that you have it inside <application> tag. Also make sure that you are using the correct App ID. Here's how. Hope this helps!
I am using Junit 4.x to test a method.
The method under the test is expected to throw an IllegalArgumentException. The method is a blocking method (synchronous) which internally makes a remote ssh connection executes a script and captures result, or throws exception.
To test this, I have written my JUnit test code as below.
#Test (timeout=3000, expected=IllegalArgumentException.class)
public final void testReadFolderWithInvalidFolder() {
final String folder = "/home/rv_nath/xxxyyyZzz";
rfc.readFolder(folder);
}
The testReadFolder() method above is supposed to wait upto 3 seconds (becoz of timeout=3000) before checking whether the expected exception is thrown or not). But it returns immediately, reporting that the test case has failed.
Can anyone help me figure out what is going wrong in the above. If more details required, let me know.
Here is the failure trace from Junit...
java.lang.AssertionError: Should have thrown IllegalArgumentException.
at org.junit.Assert.fail(Assert.java:91)
at com.comviva.remotefilebrowser.server.RemoteFileCaseTest.testReadFolderWithInvalidFolder(RemoteFileCaseTest.java:94)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:616)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
at org.junit.internal.runners.statements.FailOnTimeout$1.run(FailOnTimeout.java:28)
Is there a bug in Junit4 timeout implementation, or am I missing something here?
Because, if I run the test case in debug mode (and trace through it, then it takes time to finish the remote execution, but it definitely works and the test case passes). The problem occurs only if I choose to run the test case, instead of debug it.
thanks and regards,
RV
Sorry for the above naive question. It was a problem with the way, I used JSch library routines for reading remote data.
Just posting here, so it may help novice users like me :)
The JSch library was throwing some exception, which I was not capturing properly. The called method was capturing the exception and was returning immediately. After the correction, it works correctly.
I changed the JTA transaction timeout from admin console and set to 300, even after changing it fails saying JTA transaction unexpectedly rolled back (maybe due to a timeout) with a:
weblogic.transaction.RollbackException: Transaction timed out after 181 seconds`
To make sure whether my changes (timeout value 300) got reflected for that domain or not I checked under domain config.xml it got reflected with 300.
My question is, is there any other place also do I need to update the transaction timeout value and do I need to restart the server ?
Full stack trace after the exception from server below:
Caused by: org.springframework.transaction.UnexpectedRollbackException: JTA transaction unexpectedly rolled back (maybe due to a timeout); nested exception is weblogic.transaction.RollbackException: Transaction
timed out after 180 seconds
BEA1-160A800A149091F72E5E
at org.springframework.transaction.jta.JtaTransactionManager.doCommit(JtaTransactionManager.java:1031)
at org.springframework.transaction.support.AbstractPlatformTransactionManager.processCommit(AbstractPlatformTransactionManager.java:709)
at org.springframework.transaction.support.AbstractPlatformTransactionManager.commit(AbstractPlatformTransactionManager.java:678)
at org.springframework.transaction.interceptor.TransactionAspectSupport.completeTransactionAfterThrowing(TransactionAspectSupport.java:359)
at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:110)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171)
at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
at $Proxy103.saveRegistryData(Unknown Source)
at gov.cms.pqri.arch.submission.registry.bean.RegDataAccessManager.persistRegistry(RegDataAccessManager.java:54)
... 14 more
Caused by: weblogic.transaction.RollbackException: Transaction timed out after 180 seconds
BEA1-160A800A149091F72E5E
at weblogic.transaction.internal.TransactionImpl.throwRollbackException(TransactionImpl.java:1818)
at weblogic.transaction.internal.ServerTransactionImpl.internalCommit(ServerTransactionImpl.java:333)
at weblogic.transaction.internal.ServerTransactionImpl.commit(ServerTransactionImpl.java:227)
at weblogic.transaction.internal.TransactionManagerImpl.commit(TransactionManagerImpl.java:281)
at org.springframework.transaction.jta.JtaTransactionManager.doCommit(JtaTransactionManager.java:1028)
... 22 more
after changing the stuck Thread Max time to 300 under servers -> configuration -> tuning (tab) from admin console it is getting updated and working fine.
I have also came across this issue and have resolved the same, since this is related to JTA transaction so we need to increase the timeout of JTA as well along with the time out for stuck max thread. Please click on JTA from the weblogic console home and increase the JTA timeout from 30(by default) to 300.
We met same issue on Weblogic 12.1.2 [JTA transaction unexpectedly rolled back (maybe due to a timeout)] after all investigation we found the root cause of the problem.In my opinion it occurs due to huge dataset processing transactional and near the end of the process If an exception is thrown, JTA is rolling back data as expected.But it does not give the details of the error.In our case ,it mostly cause because of the database integrity (e.g we try to insert data a column with smaller size than data.)
In summary,it will be the best way to investigate db logs instead of increasing stuck Thread Max time.Thread max time can be a solution,but not a proper solution for real enterprise systems.
Also this issue discussed on another stackover link and hibernate jira issue
And solution suggested:
This is a default behaviour of Weblogic JTA realization. To obtain
root exception you should set system property
weblogic.transaction.allowOverrideSetRollbackReason to true.
One of the solution is add this line into
/bin/setDomainEnv.cmd:
set JAVA_OPTIONS=%JAVA_OPTIONS% -Dweblogic.transaction.allowOverrideSetRollbackReason=true
I got my JTA timeouts increased by adding jta.properties file into config folder of my app with lines:
com.atomikos.icatch.default_jta_timeout=600000
com.atomikos.icatch.max_timeout=600000