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!
Related
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.
The line numbers in stack traces for IOS builds do not seem to
correspond to either the original sources or the .m sources generated
by the build process. Is there a way to interpret them ?
For example, in the trade below online_root.start:721 is refers to
a method in a file with only 111 lines. The correspinding .m file
has only 319 lines.
*** CN1 log ****
[null] 0:0:48,666 - Exception: java.lang.NullPointerException - null
java.lang.NullPointerException
at online_Root.start:721
at util_JWSApplication.runMain:216
at util_JWSApplication.xmain:124
at com_boardspace_BoardspaceLauncher.launchLobby:110
at com_boardspace_BoardspaceLauncher.doit:0
at com_boardspace_BoardspaceLauncher.run:51
at java_lang_Thread.runImpl:153
*** End of CN1 log ****
Try using a platform for crashing such as HockeyApp or Crashlytics, that would be easiest way to interpret the crash logs on an iOS device. If you don't go that route, you will need to understand the atos command, basically address to symbol. There are plenty of resources here about atos and how to get it working, this is the route I took and works well.
In my company we´ve installed the app GuiXT Liquid UI on Ipad mini to access to our SAP-Systems.
The login works fine and we can open transactions (those which were delivered by SAP and also self-written), but as soon as we want to change variant, display a list or anything else, an Runtime Error occurs.
While opening the same transactions with the “normal” gui on windows-pcs everything works.
Following informations I get from the error message:
Runtime Errors MESSAGE_TYPE_X
Error analysis
Short text of error message:
Control Frame Work : Error in data stream <DATAMANAGER><TABLES><DATACHAN
GES HANDLE="2"><IT I; current tag PROPERTY,
Long text of error message:
Technical information about the message:
Message class....... "CNDP"
Number.............. 008
Variable 1.......... "<DATAMANAGER><TABLES><DATACHANGES HANDLE="2"><IT I"
Variable 2.......... "PROPERTY"
Variable 3.......... " "
Variable 4.......... " "
Information on where terminated
Termination occurred in the ABAP program "CL_GUI_DATAMANAGER============CP" -
in "TRACE_XML".
The main program was "RAZUGA_ALV01 ".
In the source code you have the termination point in line 2136
of the (Include) program "CL_GUI_DATAMANAGER============CL".
This is a really old question and I hope you found a solution.
I stumbled upon it while searching for help on a similar (but not exactly the same) error.
I found this note which doesn't apply to my system/error, but might apply to yours, so I'll leave it here for reference:
2318244 - Shortdump occurs in /IDXGC/PDOCMON01 when click some Process Step No. to display step additional data
Regards,
tao
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