Ads Showing on HoneyComb Webview but Not ICS Webview - android-3.0-honeycomb

I have tweaked my Honeycomb application to work on ICS. All is well EXCEPT my ads in the webview no longer display. I have made no code changes to this section. The ICS compatible code shows ads on a HoneyComb device but not on an ICS device. What is different and how do I handle?
Here are logs that I receive on ICS device, but not HoneyComb or lower:
03-08 14:50:42.485: W/webview(24262): java.lang.Throwable: Warning: A WebView method was called on thread 'Thread-617'. All WebView methods must be called on the UI thread. Future versions of WebView may not support use on other threads.
03-08 14:50:42.485: W/webview(24262): at android.webkit.WebView.checkThread(WebView.java:9468)
03-08 14:50:42.485: W/webview(24262): at android.webkit.WebView.getSettings(WebView.java:4143)
03-08 14:50:42.485: W/webview(24262): at com.accuweather.android.tablet.ads.AdView$2.run(AdView.java:160)
03-08 14:50:42.495: W/System.err(24262): java.io.IOException: java.net.URISyntaxException: Invalid % sequence: %wl in query at index 138: http://www.accuweather.com/adrequest/adrequest.asmx/getAdCode?strAppID=lenovo&strPartnerCode=lenovo&strIpAddress=fe80::42fc:89ff:fe93:9fcb%wlan0&strUserAgent=Mozilla%2F5.0+%28Linux%3B+U%3B+Android+4.0.3%3B+en-us%3B+Xoom+Build%2FIML77%29+AppleWebKit%2F534.30+%28KHTML%2C+like+Gecko%29+Version%2F4.0+Safari%2F534.30&strCurrentZipCode=cityId=335315&strWeatherIcon=12&strUUID=99000052310400
03-08 14:50:42.495: W/System.err(24262): at libcore.net.http.HttpEngine.<init>(HttpEngine.java:194)
03-08 14:50:42.495: W/System.err(24262): at libcore.net.http.HttpURLConnectionImpl.newHttpEngine(HttpURLConnectionImpl.java:256)
03-08 14:50:42.495: W/System.err(24262): at libcore.net.http.HttpURLConnectionImpl.initHttpEngine(HttpURLConnectionImpl.java:243)
03-08 14:50:42.495: W/System.err(24262): at libcore.net.http.HttpURLConnectionImpl.connect(HttpURLConnectionImpl.java:78)
03-08 14:50:42.495: W/System.err(24262): at com.accuweather.android.tablet.ads.AdView$AdRequest.getInputStreamFromURL(AdView.java:345)
03-08 14:50:42.495: W/System.err(24262): at com.accuweather.android.tablet.ads.AdView$AdRequest.makeRequest(AdView.java:293)
03-08 14:50:42.495: W/System.err(24262): at com.accuweather.android.tablet.ads.AdView$2.run(AdView.java:159)
03-08 14:50:42.495: W/System.err(24262): Caused by: java.net.URISyntaxException: Invalid % sequence: %wl in query at index 138: http://www.accuweather.com/adrequest/adrequest.asmx/getAdCode?strAppID=lenovo&strPartnerCode=lenovo&strIpAddress=fe80::42fc:89ff:fe93:9fcb%wlan0&strUserAgent=Mozilla%2F5.0+%28Linux%3B+U%3B+Android+4.0.3%3B+en-us%3B+Xoom+Build%2FIML77%29+AppleWebKit%2F534.30+%28KHTML%2C+like+Gecko%29+Version%2F4.0+Safari%2F534.30&strCurrentZipCode=cityId=335315&strWeatherIcon=12&strUUID=99000052310400
03-08 14:50:42.495: W/System.err(24262): at libcore.net.UriCodec.validate(UriCodec.java:58)
03-08 14:50:42.495: W/System.err(24262): at java.net.URI.parseURI(URI.java:406)
03-08 14:50:42.495: W/System.err(24262): at java.net.URI.<init>(URI.java:204)
03-08 14:50:42.495: W/System.err(24262): at java.net.URL.toURILenient(URL.java:510)
03-08 14:50:42.495: W/System.err(24262): at libcore.net.http.HttpEngine.<init>(HttpEngine.java:192)
03-08 14:50:42.495: W/System.err(24262): ... 6 more

The ICS WebView implementation was revamped, so a lot of us are having issues with pre-ICS and ICS WebView behavior.
It looks like you have two problems.
First, you want to encode your query, as it looks like you can't pass that "%" which has a special meaning in HTML escaping. It looks like it is happening in the strIpAddress parameter. You can use code like this:
String encodedIPAddress = URLEncoder.encode(strIpAddressValue);
I would encode each parameter value, then put those all together into your final URL String using String.format or just String +. This way you'll avoid any future similar problems.
Second, Android is complaining that you're not calling the WebView from a UI thread. I would wrap the method (I'm assuming you're calling it showAd()) that you are calling in runInUiThread like so:
activity.runOnUiThread(new Runnable() {
public void run() {
webView.showAd();
}
});

in my case, I had following line inside Activity.runOnUiThread(Runnable runnable).
webView.setWebChromeClient(WebChromeClient webChromeClient);
which showed the progress meter.
When I commented out that line, the application stopped showing
the error you mentioned.

Related

PrematureCloseException: Connection prematurely closed DURING response When down load with azure blob

I try to download the large file from azure blob storage by these line of code:
BlobClient blobAsyncClient = new BlobServiceClientBuilder().connectionString(connectionString1)
.buildClient()
.getBlobContainerClient(blob)
.getBlobClient(client);
blobAsyncClient.downloadToFile(path);
And i got this exception:
reactor.core.Exceptions$ReactiveException: reactor.netty.http.client.HttpClientOperations$PrematureCloseException: Connection prematurely closed DURING response
at reactor.core.Exceptions.propagate(Exceptions.java:326)
at reactor.core.publisher.BlockingSingleSubscriber.blockingGet(BlockingSingleSubscriber.java:91)
at reactor.core.publisher.Mono.block(Mono.java:1500)
at com.azure.storage.common.implementation.StorageImplUtils.blockWithOptionalTimeout(StorageImplUtils.java:99)
at com.azure.storage.blob.specialized.BlobClientBase.downloadToFileWithResponse(BlobClientBase.java:557)
at com.gooddata.cloudresource.service.connection.BlobStorageDataSourceService.validateConnection(BlobStorageDataSourceService.java:89)
at com.gooddata.cloudresource.model.worker.CloudConnectionValidationWorker.lambda$doProcessTask$1(CloudConnectionValidationWorker.java:55)
at java.util.Optional.ifPresent(Optional.java:159)
at com.gooddata.cloudresource.model.worker.CloudConnectionValidationWorker.doProcessTask(CloudConnectionValidationWorker.java:55)
at com.gooddata.cloudresource.model.worker.CloudConnectionValidationWorker.doProcessTask(CloudConnectionValidationWorker.java:33)
at com.gooddata.gcf.worker.AbstractWorker.processTask(AbstractWorker.java:27)
at com.gooddata.gcf.http.TaskHolder.call(TaskHolder.java:52)
at com.gooddata.gcf.http.TaskHolder.call(TaskHolder.java:26)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
Suppressed: java.lang.Exception: #block terminated with an error
After changing downloadToFileWithResponse with ParallelTransferOptions has block size is 0.5MB for each chunk some times its works.
Can someone help tell me why it happened?
Do we have any stable solution for this?
Please check with this link
If you are downloading large file from Azure blob you could try to use Shared Access Signature (SAS), or serve the file in chunk
To serve the file in chunk please check with this thread

hystrix many threads in waiting state

We have used hystrix - circuit breaker pattern [library] in our one of the module.
usecase is:- we are polling 16 number of messages from kafka and processing them using pararllel stream,so, for each message in workflow it takes 3 rest calls which are protected by hystric command. Now, issue is when I try to run my single instance then CPU shows spikes and thread dump shows many threads in waiting state for all the 3 commands. Like below:-
Omitted thread name but assume all all thread pools it shows same thing:-
Thread Pool-7" #82
Thread State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0x000000004cee2312> (a java.util.concurrent.SynchronousQueue$TransferStack)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
at java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:458)
at java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:362)
at java.util.concurrent.SynchronousQueue.take(SynchronousQueue.java:924)
at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1074)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
Could you please help me in fine tuning application and thread pool parameters?
what I am missing here?
The default isolation strategy of Hystrix is threadpool and its default size is just 10. It means that only 10 REST calls can be running at the same time in your case.
First, try to increase the below default property to big one.
hystrix.threadpool.default.coreSize=1000 # default is 10
If it works, adjust the value to the proper one.
default can be replaced with the proper HystrixThreadPoolKey for each thread pool.
If you are using Semaphore isolation strategy, try to increase the below one.
hystrix.command.default.execution.isolation.semaphore.maxConcurrentRequests=1000
Above one's default is also just 10. default can be replaced with HystrixCommandKey name for each semaphore.
Updated
To choose the isolation strategy, you can use the below property.
hystrix.command.default.execution.isolation.strategy=THREAD or SEMAPHORE
default can be replaced with HystrixCommandKey. It means that you can assign different strategy for each hystrix command.

Spring WebSockets Runtime Monitoring STOMP Frames - explanation

I'm working on an application who uses websockets.
I've implemented the STOMP sub-protocol in my web application and it's working just fine.
The clients are disconnecting from the socket correctly but my server is throwing a LOG which I do not understand well even if I read the Spring documentation in this topic.
so.. the section im trying to understand is this: 25.4.16 Runtime Monitoring
from this doc: http://docs.spring.io/spring/docs/current/spring-framework-reference/html/websocket.html
and the LOG that my server is throwing is represented by this:
INFORMACIÓN: WebSocketSession[2 current WS(2)-HttpStream(0)-HttpPoll(0), 7 total, 0 closed abnormally (0 connect failure, 0 send limit, 0 transport error)], stompSubProtocol[processed CONNECT(7)-CONNECTED(7)-DISCONNECT(0)], stompBrokerRelay[null], inboundChannel[pool size = 0, active threads = 0, queued tasks = 0, completed tasks = 66], outboundChannelpool size = 0, active threads = 0, queued tasks = 0, completed tasks = 16], sockJsScheduler[pool size = 4, active threads = 1, queued tasks = 3, completed tasks = 2443]
So.. following the explanation of the docs, I understand that this part of the LOG: WebSocketSession[2 current WS(2) represent that I have 2 clients currently on my socket right? but when I read this: stompSubProtocol[processed CONNECT(7)-CONNECTED(7)-DISCONNECT(0)] I get totalyconfused.
So that means that I have 7 clients connected under the sub-protocol? or that I had 7 clients?
also I want to know how to customize the default time the log appears. By default its 30 minuts, how can I change that? or catch every single thing on the runtime monitoring?
appreciate your help.
I think this just is a count of the total number of frames of each type (CONNECT, CONNECTED, DISCONNECT) that have been received from the STOMP client. From the looks of it you only have 2 connected web socket clients WebSocketSession[2 current WS(2)...

Websphere server that may be hung

I am getting the below error.... Kindly help
[8/5/14 21:06:54:277 GMT-08:00] 00000091 DiscoveryTx W DCSV1115W: DCS Stack DefaultCoreGroup at Member PT_STS_HK_CELL\PT_STS_HK_APP_Node02\PT_STS_QLCOMM_CL02: Member PT_STS_HK_CELL\PT_STS_HK_APP_Node02\nodeagent connection was closed. Member will be removed from view. DCS connection status is Discovery|Ptp, transmitter closed.
[8/5/14 21:07:23:562 GMT-08:00] 00000010 MbuRmmAdapter W DCSV1115W: DCS Stack DefaultCoreGroup at Member PT_STS_HK_CELL\PT_STS_HK_APP_Node02\PT_STS_QLCOMM_CL02: Member PT_STS_HK_CELL\PT_STS_HK_APP_Node02\PT_STS_PYMTCAPTURE_CL02 connection was closed. Member will be removed from view. DCS connection status is View|Gossip, this member is suspected by the other member.
[8/5/14 21:08:00:079 GMT-08:00] 00000091 DiscoveryTx W DCSV1115W: DCS Stack DefaultCoreGroup at Member PT_STS_HK_CELL\PT_STS_HK_APP_Node02\PT_STS_QLCOMM_CL02: Member PT_STS_HK_CELL\PT_STS_HK_APP_Node02\PT_STS_DOWNSTREAM_CL02 connection was closed. Member will be removed from view. DCS connection status is Discovery|Ptp, transmitter closed.
[8/5/14 21:08:16:296 GMT-08:00] 00000010 RmmPtpGroup W DCSV1112W: DCS Stack DefaultCoreGroup at Member PT_STS_HK_CELL\PT_STS_HK_APP_Node02\PT_STS_QLCOMM_CL02: Member PT_STS_HK_CELL\PT_STS_HK_APP_Node02\PT_STS_DOWNSTREAM_CL02 failed to respond to periodic heartbeats. Member will be removed from view. Configured Timeout is 180000 milliseconds. DCS logical channel is View|Ptp.
[8/5/14 21:08:29:236 GMT-08:00] 00000091 DiscoveryTx W DCSV1115W: DCS Stack DefaultCoreGroup at Member PT_STS_HK_CELL\PT_STS_HK_APP_Node02\PT_STS_QLCOMM_CL02: Member PT_STS_HK_CELL\PT_STS_HK_DMGR_Node\dmgr connection was closed. Member will be removed from view. DCS connection status is Discovery|Ptp, transmitter closed.
[8/5/14 21:10:20:892 GMT-08:00] 00000018 ApplicationMo W DCSV0004W: DCS Stack DefaultCoreGroup at Member PT_STS_HK_CELL\PT_STS_HK_APP_Node02\PT_STS_QLCOMM_CL02: Did not receive adequate CPU time slice. Last known CPU usage time at 21:03:08:272 GMT-08:00. Inactivity duration was 402 seconds.
[8/5/14 21:11:14:131 GMT-08:00] 00000043 ThreadMonitor W WSVR0605W: Thread "WMQJCAResourceAdapter : 5" (00000067) has been active for 657039 milliseconds and may be hung. There is/are 2 thread(s) in total in the server that may be hung.
at com.ibm.ejs.ras.TraceLogger.doLog(TraceLogger.java:332)
at com.ibm.ejs.ras.TraceLogger.processEvent(TraceLogger.java:319)
at com.ibm.ws.logging.WsHandlerWrapper.publish(WsHandlerWrapper.java:43)
at java.util.logging.Logger.log(Logger.java:1121)
at com.ibm.ejs.ras.Tr.logToJSR47Logger(Tr.java:1681)
at com.ibm.ejs.ras.Tr.fireEvent(Tr.java:1643)
at com.ibm.ejs.ras.Tr.fireTraceEvent(Tr.java:1565)
at com.ibm.ejs.ras.Tr.entry(Tr.java:816)
at com.ibm.ws.sib.utils.ras.SibTr.entry(SibTr.java:912)
at com.ibm.ws.wmqcsi.trace.TraceImpl.methodExit(TraceImpl.java:349)
at com.ibm.msg.client.commonservices.trace.Trace.methodExitInternal(Trace.java:715)
at com.ibm.msg.client.commonservices.trace.Trace.exit(Trace.java:628)
at com.ibm.msg.client.wmq.v6.jms.internal.JMSMessage._setJMSXObjectProperty(JMSMessage.java:3928)
at com.ibm.msg.client.wmq.v6.jms.internal.MQJMSMessage.write(MQJMSMessage.java:1223)
at com.ibm.msg.client.wmq.v6.jms.internal.MQMessageProducer.sendInternal(MQMessageProducer.java:1139)
at com.ibm.msg.client.wmq.v6.jms.internal.MQMessageProducer.send(MQMessageProducer.java:768)
at com.ibm.msg.client.wmq.v6.jms.internal.MQMessageProducer.send(MQMessageProducer.java:2713)
at com.ibm.msg.client.jms.internal.JmsMessageProducerImpl.sendMessage(JmsMessageProducerImpl.java:872)
at com.ibm.msg.client.jms.internal.JmsMessageProducerImpl.send_(JmsMessageProducerImpl.java:727)
at com.ibm.msg.client.jms.internal.JmsMessageProducerImpl.send(JmsMessageProducerImpl.java:398)
at com.ibm.mq.jms.MQMessageProducer.send(MQMessageProducer.java:281)
at com.ibm.ejs.jms.JMSQueueSenderHandle.send(JMSQueueSenderHandle.java:204)
you are receiving CPU Starvation errors. This could be because you are thrashing the garbage collector, your heap is not big enough or something else is taking up the CPU time. You need to find the process or processes that are taking up the CPU and examine why they are running high.
Regards,
Brian
The log entry starting with
ThreadMonitor W WSVR0605W: Thread "WMQJCAResourceAdapter : 5" (00000067) has been
active for 657039 milliseconds and may be hung.
indicates that this thread has been active for that period of time BUT the thread stack it generates is just the thread at the point in time that the log entry is generated. This means it could have been stuck for 90% of the time in one point in the code and the stack trace generated is just where it is now.
What that particular thread is doing at that point is appending an entry into the trace logs when the application is attempting to send an MQ JMS message. So there is no indication that that thread is hung at that point.
A couple of things to try:
Investigate the CPU usage as the CPU starvation messages indicate that is a problem.
Search the SystemOut.log for corresponding messages saying threads are no longer hung.
Take a javacore to see the threads at 2 minute intervals to see what threads are moving.
Turn off trace unless you need it.
This is the general error that might be encountered during server start phase.
Basic idea behind this is that, when you start the server, threads are getting initialized for your process/job that you want to run on server.
That thread is waiting for few resources which helps them to run the process/job. But at that point of time thread may get hung, because of un-availablity of resources.
One way to fix it - Kill the process from background because of which that thread is hung.
Again start the server.
Do the following steps:
- Ensure that Deployment manager is up and running
- verify that app server and node agent are stopped - no java processes related to node agent and app server running
- go to NODE_PROFILE\bin (not deployment manager profile)
- run syncNode.sh/bat
- run startNode.sh/bat
- if node agents starts successfully you should be able to start server from command line or web console

Weblogic Stuck Thread on JDBC call

We frequently get a series of Stuck threads on our Weblogic servers. I've analyzed this over a period of time.
What I'd like to understand is whether this stuck thread block indicates it is still reading data from the open socket to the database since the queries are simple SELECT stuff?
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(SocketInputStream.java:129)
at oracle.net.ns.Packet.receive(Packet.java:239)
at oracle.net.ns.DataPacket.receive(DataPacket.java:92)
We've run netstat and other commands, the sockets from the Weblogic app server to the Database match the number of connections in the pool.
Any ideas what else we should be investigating here?
Stack trace of thread dump:
"[STUCK] ExecuteThread: '2' for queue: 'weblogic.kernel.Default (self-tuning)'" daemon prio=10 tid=0x61a5b000 nid=0x25f runnable [0x6147b000..0x6147eeb0]
java.lang.Thread.State: RUNNABLE
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(SocketInputStream.java:129)
at oracle.net.ns.Packet.receive(Packet.java:239)
at oracle.net.ns.DataPacket.receive(DataPacket.java:92)
at oracle.net.ns.NetInputStream.getNextPacket(NetInputStream.java:172)
at oracle.net.ns.NetInputStream.read(NetInputStream.java:117)
at oracle.net.ns.NetInputStream.read(NetInputStream.java:92)
at oracle.net.ns.NetInputStream.read(NetInputStream.java:77)
at oracle.jdbc.driver.T4CMAREngine.unmarshalUB1(T4CMAREngine.java:1023)
at oracle.jdbc.driver.T4CMAREngine.unmarshalSB1(T4CMAREngine.java:999)
at oracle.jdbc.driver.T4C8Oall.receive(T4C8Oall.java:584)
at oracle.jdbc.driver.T4CStatement.doOall8(T4CStatement.java:183)
at oracle.jdbc.driver.T4CStatement.fetch(T4CStatement.java:1000)
at oracle.jdbc.driver.OracleResultSetImpl.close_or_fetch_from_next(OracleResultSetImpl.java:314)
- locked <0x774546e0> (a oracle.jdbc.driver.T4CConnection)
at oracle.jdbc.driver.OracleResultSetImpl.next(OracleResultSetImpl.java:228)
- locked <0x774546e0> (a oracle.jdbc.driver.T4CConnection)
at weblogic.jdbc.wrapper.ResultSet_oracle_jdbc_driver_OracleResultSetImpl.next(Unknown Source)
The bit starting from weblogic.work.ExecuteThread.run to here has been omitted. We have 8 sets of thread dumps - and each show the thread waiting on the same line, and the same object locked
at oracle.jdbc.driver.OracleResultSetImpl.close_or_fetch_from_next(OracleResultSetImpl.java:314)
- locked <0x774546e0> (a oracle.jdbc.driver.T4CConnection)
At the time the stack was printed, it seems blocked waiting for more data from the server
at oracle.jdbc.driver.OracleResultSetImpl.next(OracleResultSetImpl.java:228)
Maybe it is just the query which is taking more than StuckThreadMaxTimeand WL issues a Warning.
If possible I would try:
Find which query or queries are getting the threads stuck and check execution time
Use Wireshark to analyze communication with database
Have a look at the driver source code (JD comes to mind) to understand stack trace
if you use weblogic debug flag -Dweblogic.debug.DebugJDBCSQL you will be able to trace the SQL which is actually being executed

Resources