RE: Re: Android and WCF DataService
Thierry- I have been working on my android app...but noticed some strange behaviors in the android logs that I wanted to pass your way. Here is a cut of sample code I am using in my app. String remoteServiceEndPoint = http://blah.blah.blah/iMMeta/webdataservice.svc;; Service myService = new Service(remoteServiceEndPoint); SysShoot ActiveShoot= new SysShoot(); ShootProviderHelper myHelper = new ShootProviderHelper(); QuerySysShoot theShootQuery = myService.createQuery(/sysShoots()?$filter=isActive eq true, SysShoot.class); IteratorSysShoot iShoot= theShootQuery.iterator(); Below is a snipit of log from my app that spits out for the above code. I wanted to check with you on a few things. 04-30 11:15:32.625: INFO/global(518): Default buffer size used in BufferedReader constructor. It would be better to be explicit if an 8k-char buffer is required. 04-30 11:15:33.115: INFO/global(518): Default buffer size used in BufferedReader constructor. It would be better to be explicit if an 8k-char buffer is required. 04-30 11:15:33.575: INFO/org.restlet(518): Starting the default HTTP client 04-30 11:15:34.034: INFO/global(518): Default buffer size used in BufferedInputStream constructor. It would be better to be explicit if an 8k buffer is required. 04-30 11:15:34.055: INFO/global(518): Default buffer size used in BufferedOutputStream constructor. It would be better to be explicit if an 8k buffer is required. 04-30 11:15:45.764: INFO/org.restlet(518): Get the metadata for http://digital-furnace.com/iMMeta/webdataservice.svc/ at http://digital-furnace.com/iMMeta/webdataservice.svc/$metadata 04-30 11:15:45.945: INFO/global(518): Default buffer size used in BufferedReader constructor. It would be better to be explicit if an 8k-char buffer is required. 04-30 11:15:46.485: INFO/global(518): Default buffer size used in BufferedReader constructor. It would be better to be explicit if an 8k-char buffer is required. 04-30 11:15:46.965: INFO/org.restlet(518): Starting the default HTTP client 04-30 11:15:47.275: INFO/global(518): Default buffer size used in BufferedInputStream constructor. It would be better to be explicit if an 8k buffer is required. 04-30 11:15:47.295: INFO/global(518): Default buffer size used in BufferedOutputStream constructor. It would be better to be explicit if an 8k buffer is required. 04-30 11:15:53.944: DEBUG/dalvikvm(518): GC freed 12463 objects / 646712 bytes in 109ms 04-30 11:16:01.104: INFO/global(518): Default buffer size used in BufferedReader constructor. It would be better to be explicit if an 8k-char buffer is required. 04-30 11:16:01.725: INFO/global(518): Default buffer size used in BufferedReader constructor. It would be better to be explicit if an 8k-char buffer is required. 04-30 11:16:02.234: INFO/org.restlet(518): Starting the default HTTP client 04-30 11:16:02.555: INFO/global(518): Default buffer size used in BufferedInputStream constructor. It would be better to be explicit if an 8k buffer is required. 04-30 11:16:02.574: INFO/global(518): Default buffer size used in BufferedOutputStream constructor. It would be better to be explicit if an 8k buffer is required. 04-30 11:16:06.775: DEBUG/dalvikvm(518): GC freed 14622 objects / 764968 bytes in 98ms 04-30 11:16:11.654: DEBUG/dalvikvm(518): GC freed 13481 objects / 835208 bytes in 107ms 04-30 11:16:16.834: DEBUG/dalvikvm(518): GC freed 13575 objects / 809480 bytes in 92ms 04-30 11:16:22.145: DEBUG/dalvikvm(518): GC freed 13529 objects / 808816 bytes in 111ms 04-30 11:16:27.974: DEBUG/dalvikvm(518): GC freed 14672 objects / 874640 bytes in 113ms 04-30 11:16:33.394: DEBUG/dalvikvm(518): GC freed 13786 objects / 820520 bytes in 99ms 04-30 11:16:38.265: DEBUG/dalvikvm(518): GC freed 13235 objects / 822288 bytes in 101ms So for Service myService = new Service(remoteServiceEndPoint); QuerySysShoot theShootQuery = myService.createQuery(/sysShoots()?$filter=isActive eq true, SysShoot.class); IteratorSysShoot iShoot= theShootQuery.iterator(); 1- It is doing a roundtrip to the server...Is there anyway to cache the requests until the query is actually called by hitting the iterator or someother method to start getting the results? It seems kinda Chatty over Chunky 2-There is a TON of GC going on for all the objects getting created as you can tell by the logs. The result of the query is not very big...but there are a log of objects being subject to GC. Is that normal? My app becomes non-responsive until the last GC(although I thought the GC was non-blocking..unless the CPU is maxed). As you can tell from the timestamps...it takes quite a while for the GC to finish. Any help sorting out what is going on with RestLet and WCF would be great. Matthew Hello Matthew, I just would like to tell you that the internal connector now works on Android.
Re: SSL modifications since 2.0 RC 1 ?
Hi Nicolas, On 28/04/2010 12:55, Nicolas Rinaudo wrote: This might be an important bit of information. After running a few more tests, I realised that Safari would: - fail ignoring certificates if the server is running on OS X. - succeed in ignoring certificates if the server is running on Debian Lenny (5.0) This might be an OS X only issue after all. I've looked a bit more into this issue, and it doesn't seem OSX-specific (on the server side) unfortunately. It's not even specific to self-signed certificates (I've tried with a trusted cert), the Simple connector or Restlet. I've managed to reproduce it with a basic Jetty server [1] running with the Sun JVM on a Linux box. It has similar symptoms to the buffer issue we had a few weeks ago [2], but I don't know whether it's a Java or a Safari problem at this stage. It appears with Simple, because Simple always requests (wants) a client certificate. It also happens with Jetty if it's configured to do so. To (try to) keep it short, when a TLS server requests a client certificate during the handshake, and extra TLS message is sent (CertificateRequest), which contains a list of the names of the CAs from which the server would be willing to accept client certificates. In Java, this list is automatically populated by the default SSLContext with the list of names corresponding to the certificates held in the truststore. The more certificates in the truststore, the longer the list, and thus the bigger the packet. On the current OSX 10.6, the default truststore [3] seems to have about 160 certificates, whereas on an Ubuntu 9.10 (Sun JVM) the default trust store contains about 75. When I use the Mac's truststore on the Linux box, this fails too. When I use a smaller truststore on the Mac, it works there. I've tried to debug the SSL handshake on the Java side and it looks like it works fine, internally; however, when looking at the packets with WireShark, not everything sent by the server according to the Java debugging logs seems to be effectively sent. I suspect this is a buffer size problem similar to [2], although in this case, it happens with other servers, using NIO or BIO. A workaround would be to specify a smaller truststore or to turn off the optional client-certificate authentication. Best wishes, Bruno. [1] http://gist.github.com/385281 [2] http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2465481 [3] /Library/Java/Home/lib/security/cacerts [4] /usr/lib/jvm/java-6-sun/jre/lib/security/cacerts -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2599797
Client Custom Header
Hi, I'm trying to add a custom HTTP header to outgoing requests when using the restlet client API. Ideally i'm looking for some way to implement a helper class that can inject my header into every request as they are processed. However in looking through the documentation i'm not really finding what i'm looking for. I see in the FAQ it's possible to access headers but this seems to be from the server perspective. How do I get access from a client perspective? Thanks in advance, Jean-Philippe Steinmetz -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2599941
Tomcat Restlet Threads and OutOfMemoryException
I'm running a Tomcat Container version 6.0.26 with JDK 1.6_20 in Linux with Restlet 2.0 RC3. I'm seeing a lot of the following when I shut my Tomcat instance down: SEVERE: A web application created a ThreadLocal with key of type [java.lang.ThreadLocal] (value [java.lang.threadlo...@3fb0ed]) and a value of type [org.restlet.Application] (value [org.restlet.applicat...@b5423f]) but failed to remove it when the web application was stopped. To prevent a memory leak, the ThreadLocal has been forcibly removed. Apr 30, 2010 1:28:55 PM org.apache.catalina.loader.WebappClassLoader clearThreadLocalMap SEVERE: A web application created a ThreadLocal with key of type [java.lang.ThreadLocal] (value [java.lang.threadlo...@15306c6]) and a value of type [org.restlet.Response] (value [WAR/null 200 The request has succeeded]) but failed to remove it when the web application was stopped. To prevent a memory leak, the ThreadLocal has been forcibly removed. Apr 30, 2010 1:28:55 PM org.apache.catalina.loader.WebappClassLoader clearThreadLocalMap SEVERE: A web application created a ThreadLocal with key of type [java.lang.ThreadLocal] (value [java.lang.threadlo...@1e1cb7d]) and a value of type [org.restlet.engine.component.ChildContext] (value [org.restlet.engine.component.childcont...@f683b0]) but failed to remove it when the web application was stopped. To prevent a memory leak, the ThreadLocal has been forcibly removed. If I test it long enough, the Container returns with an OutOfMemoryException: java.lang.OutOfMemoryError: unable to create new native thread java.lang.Thread.start0(Native Method) java.lang.Thread.start(Thread.java:597) java.util.concurrent.ThreadPoolExecutor.addIfUnderCorePoolSize(ThreadPoolExecutor.java:703) java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:652) java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:78) java.util.concurrent.Executors$DelegatedExecutorService.submit(Executors.java:600) org.restlet.engine.http.connector.BaseHelper.start(BaseHelper.java:461) org.restlet.engine.http.connector.BaseClientHelper.start(BaseClientHelper.java:652) org.restlet.engine.http.connector.HttpClientHelper.start(HttpClientHelper.java:58) org.restlet.Client.start(Client.java:350) org.restlet.Restlet.handle(Restlet.java:217) org.restlet.Client.handle(Client.java:229) org.restlet.Client.handle(Client.java:223) ca.nrc.cadc.restlet.freemarker.StandardHeaderTemplateDirective.execute(StandardHeaderTemplateDirective.java:104) I couldn't see any bugs related to this. Any insight into this? Thank you! Dustin -- Dustin N. Jenkins | Tel/Tél: 250.363.3101 | dustin.jenk...@nrc-cnrc.gc.ca facsimile/télécopieur: (250) 363-0045 National Research Council Canada | 5071 West Saanich Rd, Victoria BC. V9E 2E7 Conseil national de recherches Canada | 5071, ch. West Saanich, Victoria (C.-B) V9E 2E7 Government of Canada | Gouvernement du Canada -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=252
Re: Tomcat Restlet Threads and OutOfMemoryException
Oh, and my Restlet beans (Application, Context, Router, and Resources) are all Spring-loaded beans with scope = prototype. Thanks again, Dustin On 04/30/2010 01:50 PM, Dustin N. Jenkins wrote: I'm running a Tomcat Container version 6.0.26 with JDK 1.6_20 in Linux with Restlet 2.0 RC3. I'm seeing a lot of the following when I shut my Tomcat instance down: SEVERE: A web application created a ThreadLocal with key of type [java.lang.ThreadLocal] (value [java.lang.threadlo...@3fb0ed]) and a value of type [org.restlet.Application] (value [org.restlet.applicat...@b5423f]) but failed to remove it when the web application was stopped. To prevent a memory leak, the ThreadLocal has been forcibly removed. Apr 30, 2010 1:28:55 PM org.apache.catalina.loader.WebappClassLoader clearThreadLocalMap SEVERE: A web application created a ThreadLocal with key of type [java.lang.ThreadLocal] (value [java.lang.threadlo...@15306c6]) and a value of type [org.restlet.Response] (value [WAR/null 200 The request has succeeded]) but failed to remove it when the web application was stopped. To prevent a memory leak, the ThreadLocal has been forcibly removed. Apr 30, 2010 1:28:55 PM org.apache.catalina.loader.WebappClassLoader clearThreadLocalMap SEVERE: A web application created a ThreadLocal with key of type [java.lang.ThreadLocal] (value [java.lang.threadlo...@1e1cb7d]) and a value of type [org.restlet.engine.component.ChildContext] (value [org.restlet.engine.component.childcont...@f683b0]) but failed to remove it when the web application was stopped. To prevent a memory leak, the ThreadLocal has been forcibly removed. If I test it long enough, the Container returns with an OutOfMemoryException: java.lang.OutOfMemoryError: unable to create new native thread java.lang.Thread.start0(Native Method) java.lang.Thread.start(Thread.java:597) java.util.concurrent.ThreadPoolExecutor.addIfUnderCorePoolSize(ThreadPoolExecutor.java:703) java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:652) java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:78) java.util.concurrent.Executors$DelegatedExecutorService.submit(Executors.java:600) org.restlet.engine.http.connector.BaseHelper.start(BaseHelper.java:461) org.restlet.engine.http.connector.BaseClientHelper.start(BaseClientHelper.java:652) org.restlet.engine.http.connector.HttpClientHelper.start(HttpClientHelper.java:58) org.restlet.Client.start(Client.java:350) org.restlet.Restlet.handle(Restlet.java:217) org.restlet.Client.handle(Client.java:229) org.restlet.Client.handle(Client.java:223) ca.nrc.cadc.restlet.freemarker.StandardHeaderTemplateDirective.execute(StandardHeaderTemplateDirective.java:104) I couldn't see any bugs related to this. Any insight into this? Thank you! Dustin -- Dustin N. Jenkins | Tel/Tél: 250.363.3101 | dustin.jenk...@nrc-cnrc.gc.ca facsimile/télécopieur: (250) 363-0045 National Research Council Canada | 5071 West Saanich Rd, Victoria BC. V9E 2E7 Conseil national de recherches Canada | 5071, ch. West Saanich, Victoria (C.-B) V9E 2E7 Government of Canada | Gouvernement du Canada -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=254
