RE: Restlet + Spring + Hibernte + Oauth : Injected Dao is null
Hi Thierry, I had the same issue, IIRC the problem is that Restlet instantiates a Resource per request. If that Resource is not managed by spring,your injected DAO will always be null. You need to use org.restlet.ext.spring.SpringFinder in your Application like so: (be warned, there's more to this than what I just show here, and I'm using the WadlApplication class.In short you will need the full Spring initialised Restlet paradigm defined) bean name=rootResource class=com.foo.resource.RootServerResource / bean id=myApplication class=org.restlet.ext.wadl.WadlApplication constructor-arg util:property-path path=component.context / /constructor-arg property name=encoderService.enabled value=true/ property name=name value=My Server Component / property name=description value=My Service component / property name=owner value=My Company / property name=author value=Ioannis Mavroukakis / property name=autoDescribing value=true/ property name=inboundRoot bean class=org.restlet.ext.spring.SpringRouter constructor-arg ref=myApplication / property name=attachments map entry key=/ bean class=org.restlet.ext.spring.SpringFinder lookup-method name=create bean=rootResource / /bean /entry /map /property /bean /property /bean -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2993167
Re: Multiple @Get request on one single Resource using Oauth2
You need to provide a separate resource for your single contact call.
On 24 Jul 2012, at 13:59, Thierry LAU la...@sfeir.com wrote:
I changed MyApplication code :
@Override
public synchronized Restlet createInboundRoot(){
OAuthParameters p = new OAuthParameters(Client ID, Client Secret,
OAUTH_BASE, Scopes.toRoles(ContactsResource.API_URI + +
ContactResource.API_URI));
p.setAuthorizePath(auth);
p.setAccessTokenPath(token);
OAuthProxy op = new OAuthProxy(p, getContext().createChildContext());
op.setNext(ContactsResource.class);
Router root = new Router(getContext());
root.attach(/contactsCallback, op);
root.attach(/contactCallback, op);
return root;
}
This is the resources code :
public class ContactResource extends ServerResource {
public static final String API_URI =
https://www.google.com/m8/feeds/contacts/default/full/1766a4a8833d805;;
@Get
public Representation getContacts(){
OAuthUser u = (OAuthUser) getRequest().getClientInfo().getUser();
String token = u.getAccessToken();
Reference ref = new Reference(API_URI);
ref.addQueryParameter(OAuthServerResource.OAUTH_TOKEN, token);
ClientResource cr = new ClientResource(ref);
return cr.get();
}
}
public class ContactsResource extends ServerResource {
public static final String API_URI =
https://www.google.com/m8/feeds/contacts/default/full;;
@Get
public Representation getContacts(){
OAuthUser u = (OAuthUser) getRequest().getClientInfo().getUser();
String token = u.getAccessToken();
Reference ref = new Reference(API_URI);
ref.addQueryParameter(OAuthServerResource.OAUTH_TOKEN, token);
ClientResource cr = new ClientResource(ref);
return cr.get();
}
}
When I call /contactsCallback, I'm able to fetch my contact list
but whe I call /contactCallback to fetch One contact, it's the list of all my
contact which are returned (the same as the previous call)
What am I doing wrong ?
Thanks
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2992692
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2992697
Re: Multiple @Get request on one single Resource using Oauth2
Sorry my bad , will teach me for trying to reply on a smartphone..:-) that dual
approach though doesn't seem very clean..what if you have loads more resources?
On 24 Jul 2012, at 14:15, Thierry LAU la...@sfeir.com wrote:
Thanks for your reply but this is what I have done. I have one
ContactResource to fetch one contact and one ContactsResource to fetch all
contacts.
But I have in the meanwhile found the solution. Here it is :
@Override
public synchronized Restlet createInboundRoot(){
ListRole roles = new ArrayListRole();
roles.add(Scopes.toRole(ContactResource.API_URI));
roles.add(Scopes.toRole(ContactsResource.API_URI));
OAuthParameters p = new
OAuthParameters(661001134658-1jhic0b7e5datb1vdmlonljejaq7v9ip.apps.googleusercontent.com,
TWvcKjJPBxyJc0FeC9hW77mt, OAUTH_BASE, roles);
p.setAuthorizePath(auth);
p.setAccessTokenPath(token);
OAuthProxy op = new OAuthProxy(p, getContext().createChildContext());
op.setNext(ContactsResource.class);
OAuthProxy op1 = new OAuthProxy(p, getContext().createChildContext());
op1.setNext(ContactResource.class);
Router root = new Router(getContext());
root.attach(/contactCallback, op1);
root.attach(/contactsCallback, op);
return root;
}
I have to create One OAuthProxy per resource and attach it to the route with
the corresponding url.
Hope this will help others
Thierry LAU
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2992698
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2992703
Re: Restlet thread pool exhaustion
Hi Thierry, Yes with regards to the jetty extension. I don't use the Restlet client for my testing, I use loadUI. Thanks, Ioannis On 11 Jul 2012, at 08:24, Thierry Boileau thierry.boil...@restlet.com wrote: Hello Robert, Ioanis, did you try to use the simple or jetty extensions? They provide a HTTP server connector that we consider to be more stable than the internal HTTP connector which is fine for development but not for production systems. We are on the way to provide a good one with the 2.1 release. I guess the same question applies for the client application : you can use the net or the httpclient extensions. We consider also that these extensions provide a more stable client connector than the internal one. Best regards, Thierry Boileau Yes it was. I let Restlet do all the heavy resource lifting and made sure my domain logic was as clean as possible. I do not recall a single instance where I had to explicitly clean up something belonging to Restlet. Hi Robert, neat project you have going on there. I will answer a tiny part of your question, I've load tested 2.1-RC5 heavily and after careful tweaking I've yet to reach the worker limit scenario you detail here. My setup is: 150 maxThreads, 10 minThreads, 145 lowThreads, maxQueued 20 but ofc YMMV. Thanks for the reply Ioannis. So did the careful tweaking you did come down to just those parameters above? -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2977064 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2977951 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2983299
Re: Restlet thread pool exhaustion
Yes it was. I let Restlet do all the heavy resource lifting and made sure my domain logic was as clean as possible. I do not recall a single instance where I had to explicitly clean up something belonging to Restlet. On 6 Jul 2012, at 20:20, Robert Brewer rbre...@lava.net wrote: On 6 Jul 2012, at 06:06:38, Ioannis Mavroukakis imavrouka...@gmail.com wrote: Hi Robert, neat project you have going on there. I will answer a tiny part of your question, I've load tested 2.1-RC5 heavily and after careful tweaking I've yet to reach the worker limit scenario you detail here. My setup is: 150 maxThreads, 10 minThreads, 145 lowThreads, maxQueued 20 but ofc YMMV. Thanks for the reply Ioannis. So did the careful tweaking you did come down to just those parameters above? -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2977064 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2977951
Re: Restlet thread pool exhaustion
Hi Robert, neat project you have going on there. I will answer a tiny part of your question, I've load tested 2.1-RC5 heavily and after careful tweaking I've yet to reach the worker limit scenario you detail here. My setup is: 150 maxThreads, 10 minThreads, 145 lowThreads, maxQueued 20 but ofc YMMV. On 6 Jul 2012, at 04:40, Robert Brewer rbre...@lava.net wrote: Hello Restlet folks. I'm the lead developer on the WattDepot system, which collects and stores energy data, and we use Restlet on both server and client sides. We recently switched from Restlet 1.1.8 to 2.0.11 and now have some pretty severe stability problems. Our sensor client spawns multiple threads (one per power meter being polled), each of which does PUTs to our server. The problem we have run into is that after a period of time (about 2-3 days), the server stops accepting connections. The ending log file entries on the server look something like this: Jul 5, 2012 3:48:33 PM org.restlet.engine.http.connector.BaseHelper$1 rejectedExecution WARNING: Unable to run the following server-side task: Read connection messages: true Jul 5, 2012 3:48:33 PM org.restlet.engine.http.connector.BaseHelper$1 rejectedExecution INFO: Worker service state: Full Jul 5, 2012 3:48:33 PM org.restlet.engine.http.connector.BaseHelper$1 rejectedExecution INFO: Worker service tasks: 0 queued, 10 active, 71196 completed, 71206 scheduled. Jul 5, 2012 3:48:33 PM org.restlet.engine.http.connector.BaseHelper$1 rejectedExecution INFO: Worker service thread pool: 1 core size, 10 largest size, 10 maximum size, 10 current size Jul 5, 2012 3:48:33 PM org.restlet.engine.http.connector.Controller run INFO: Stop accepting new connections and transactions. Consider increasing the maximum number of threads. At this point, using netstat, I can see many established TCP connections to the server, and the server does not respond to further connections. Terminating the client causes the TCP connections to go away (as one would expect), but the server still does not respond to new connections. I've created a client that sends bogus data very quickly so that I can more easily reproduce the problem (and test fixes). The amount of time before the problem occurs seems to vary from as little as 5 minutes, to 35 minutes (or more) so the time to failure is not deterministic. I've searched this mailing list, and found helpful threads like this one that explain how to increase the maximum number of threads for HTTP listening: http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447viewType=browseAlldsMessageId=2625612 However, increasing maxThreads from the default of 10 seems like it would just postpone the thread exhaustion, rather than solve the underlying problem. Another classic cause of thread exhaustion appears to be a failure to release ClientResources after use, as discussed in this very helpful thread: http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447viewType=browseAlldsMessageId=2885182#messagefocus The SimpleServerPut example code given in that thread produces log messages very similar to the ones we see, and when a call to clientResource.release() is added to SimpleServerPut the problems go away. I've read over our relevant client code, and I think we are calling clientResource.release() after each use, but it is possible there is some path where it isn't getting called. So here are my questions: 1) What's going on when the server gets wedged? If a client was holding open too many connections, I could see how the server would stop accepting new ones, but when I stop the client, the server remains wedged. Is Restlet leaking threads somehow? It seems like this should never happen. 2) Is there a good way to tell if we are failing to release a ClientResource somewhere? 3) Is it legal to call ClientResource.release() more than once? I might try wrapping the client methods in a big try/catch/finally to ensure that release() is always being called. 4) Having to ensure that each ClientResource is explicitly released seems like a pain. Is there a way to avoid this? This stability problem is preventing us starting a beta test of a project that relies on WattDepot, so I'm eager to resolve this quickly. I'm open to any suggestions on how to debug, fix, or workaround this problem. Would upgrading to Restlet 2.1 help? Thank you! -- Robert Brewer http://excitedcuriosity.wordpress.com/ https://www.facebook.com/kukuicup -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2976364 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2976752
Re: Idling app has ~2MB of garbage collected every 30 seconds
Well I'm speculating here as I haven't seen the code, but it *sounds like*
a classic producer/consumer scenario, which might be best served with a
blocking queue. So at one end you'd have your NIO selector or whatever
else feeding the queue, and at the other end, a consumer picking up jobs
via either take() or poll() (which blocks if there's no element to be
taken).The cool thing about this, is that it promotes work stealing, so you
could have multiple queues and consumers, which can steal work from other
queues when idle.
As I forewarned, I haven't delved deep into the code, so I may be talking
out of my ass :)
Cheers,
Ioannis
On 22 June 2012 17:41, Jerome Louvel jerome.lou...@restlet.com wrote:
Hi Ioannis,
Regarding the GC of iterators, I've fixed the one under our control in RF
2.1 and 2.2/master branches yesterday. The second one is inside the NIO
selector code so we can't remove it, which leads to the second solution
anyway. I've also started to implement the notification/wakeup logic but
haven't got it done yet.
This takes us back to you remark. The NIO Selector#select method is here
to allow a single thread to handle thousands of concurrent connections in a
scalable manner. You register for IO interest for specific
channels/connections and wait for it to return and tell you the selected
one that are ready for processing.
Could you explain a bit more about a blocking queue could help us solve
this issue?
Best regards,
Jerome
--
http://www.restlet.com
http://twitter.com/#!/jlouvel
-Message d'origine-
De : Ioannis Mavroukakis [mailto:imavrouka...@gmail.com]
Envoyé : vendredi 22 juin 2012 01:17
À : discuss@restlet.tigris.org
Objet : Re: Idling app has ~2MB of garbage collected every 30 seconds
Hi Jerome ,
You're welcome, it's an interesting discussion. Is interrupting the
cleanest way of doing this ? Wouldn't a blocking queue serve better in the
context of a producer/consumer scenario?
On 22 Jun 2012, at 00:31, Jerome Louvel jerome.lou...@restlet.com wrote:
Hi Yan, Ioannis,
Thanks for pointing your finger on this hot spot! The GC overhead is
clearly an issue that needs to be fixed and definitely worth a ticket in
GitHub.
A first and easy solution is to replace those two iterator objects
with regular loops to prevent unnecessary garbage collection.
The second and harder solution will require to have the controller
thread sleep by default (as long as possible to prevent unnecessary
CPU cycles) and indeed interrupt it when an event occurs:
1) NIO event detected
2) Connection event detected (new connection/message/entity chunk to
process)
See this wiki pages to details on this connector and the pending tasks:
http://wiki.restlet.org/developers/172-restlet/g3/354-restlet.html
Best regards,
Jerome
--
http://www.restlet.com
http://twitter.com/#!/jlouvel
-Message d'origine-
De : Ioannis Mavroukakis [mailto:imavrouka...@gmail.com] Envoyé :
jeudi 21 juin 2012 01:05 À : discuss@restlet.tigris.org Objet : Re:
Idling app has ~2MB of garbage collected every 30 seconds
Yes it could but you would you not end up having the overhead of
context switching from the thrown thread interrupts? On a low resource
device this can't be the best of situations I imagine.
On 21 Jun 2012, at 00:16, Yan Zhou yanzhou_2...@yahoo.com wrote:
Any objections if the following is added as a new issue in the issue
tracker?
I am thinking that the selectKeys(sleepTime) call below really should
be
able to return immediately (thread interrupted, for example) if there
has been a connection state change that needs attention. The sleepTime
will then have little effect on how soon or how often
controlConnections() is run.
Thanks,
Yan Zhou
Hi,
We are noticing that an idling Restlet server has about 2MB of
garbage
collected in 30 seconds.
I think I tracked it down to the loop in ConnectionController that
invokes the method below:
@Override
protected void doRun(long sleepTime) throws IOException {
super.doRun(sleepTime);
registerKeys();
updateKeys();
selectKeys(sleepTime);
controlConnections();
}
The sleepTime comes from the controllerSleepTimeMs parameter, which
is 1
by default.
So if the loop generates 60 bytes of garbage (2 iterator objects),
it'd
lead to: 60 x 1000 x 30 = 1,800,000 bytes or 1.8MB every 30 seconds.
Can I ask if this is a known issue? And if there are workarounds?
I have already tried tweaking the controllerSleepTimeMs and changing
it
to something like 3 (30 seconds). Every connection then takes up
to 30 seconds to close - probably not acceptable as a solution.
Additional info: Restlet 2.1 rc4 Android edition.
Thanks,
Yan Zhou
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId
=29722
Re: Idling app has ~2MB of garbage collected every 30 seconds
Cool, so in essence you wouldn't need to rely on interrupts to serve an incoming request, is that correct? On 23 June 2012 21:41, Jerome Louvel jerome.lou...@restlet.com wrote: Hi Ioannis, ** ** Actually, we use several queues down the road to process the messages (requests and responses), so it already almost works like you expect. See diagrams here: http://wiki.restlet.org/developers/172-restlet/g1/354-restlet.html ** ** Best regards, Jerome -- http://www.restlet.com http://twitter.com/#!/jlouvel ** ** ** ** ** ** ** ** *De :* Ioannis Mavroukakis [mailto:imavrouka...@gmail.com] *Envoyé :* samedi 23 juin 2012 13:11 *À :* discuss@restlet.tigris.org *Objet :* Re: Idling app has ~2MB of garbage collected every 30 seconds*** * ** ** Well I'm speculating here as I haven't seen the code, but it *sounds like* a classic producer/consumer scenario, which might be best served with a blocking queue. So at one end you'd have your NIO selector or whatever else feeding the queue, and at the other end, a consumer picking up jobs via either take() or poll() (which blocks if there's no element to be taken).The cool thing about this, is that it promotes work stealing, so you could have multiple queues and consumers, which can steal work from other queues when idle. As I forewarned, I haven't delved deep into the code, so I may be talking out of my ass :) Cheers, Ioannis On 22 June 2012 17:41, Jerome Louvel jerome.lou...@restlet.com wrote:*** * Hi Ioannis, Regarding the GC of iterators, I've fixed the one under our control in RF 2.1 and 2.2/master branches yesterday. The second one is inside the NIO selector code so we can't remove it, which leads to the second solution anyway. I've also started to implement the notification/wakeup logic but haven't got it done yet. This takes us back to you remark. The NIO Selector#select method is here to allow a single thread to handle thousands of concurrent connections in a scalable manner. You register for IO interest for specific channels/connections and wait for it to return and tell you the selected one that are ready for processing. Could you explain a bit more about a blocking queue could help us solve this issue? Best regards, Jerome -- http://www.restlet.com http://twitter.com/#!/jlouvel -Message d'origine- De : Ioannis Mavroukakis [mailto:imavrouka...@gmail.com] Envoyé : vendredi 22 juin 2012 01:17 À : discuss@restlet.tigris.org Objet : Re: Idling app has ~2MB of garbage collected every 30 seconds Hi Jerome , You're welcome, it's an interesting discussion. Is interrupting the cleanest way of doing this ? Wouldn't a blocking queue serve better in the context of a producer/consumer scenario? On 22 Jun 2012, at 00:31, Jerome Louvel jerome.lou...@restlet.com wrote: Hi Yan, Ioannis, Thanks for pointing your finger on this hot spot! The GC overhead is clearly an issue that needs to be fixed and definitely worth a ticket in GitHub. A first and easy solution is to replace those two iterator objects with regular loops to prevent unnecessary garbage collection. The second and harder solution will require to have the controller thread sleep by default (as long as possible to prevent unnecessary CPU cycles) and indeed interrupt it when an event occurs: 1) NIO event detected 2) Connection event detected (new connection/message/entity chunk to process) See this wiki pages to details on this connector and the pending tasks: http://wiki.restlet.org/developers/172-restlet/g3/354-restlet.html Best regards, Jerome -- http://www.restlet.com http://twitter.com/#!/jlouvel -Message d'origine- De : Ioannis Mavroukakis [mailto:imavrouka...@gmail.com] Envoyé : jeudi 21 juin 2012 01:05 À : discuss@restlet.tigris.org Objet : Re: Idling app has ~2MB of garbage collected every 30 seconds Yes it could but you would you not end up having the overhead of context switching from the thrown thread interrupts? On a low resource device this can't be the best of situations I imagine. On 21 Jun 2012, at 00:16, Yan Zhou yanzhou_2...@yahoo.com wrote: Any objections if the following is added as a new issue in the issue tracker? I am thinking that the selectKeys(sleepTime) call below really should be able to return immediately (thread interrupted, for example) if there has been a connection state change that needs attention. The sleepTime will then have little effect on how soon or how often controlConnections() is run. Thanks, Yan Zhou Hi, We are noticing that an idling Restlet server has about 2MB of garbage collected in 30 seconds. I think I tracked it down to the loop in ConnectionController that invokes the method below: @Override protected void doRun(long sleepTime) throws IOException
Re: Idling app has ~2MB of garbage collected every 30 seconds
I see! So if that's the case, is there a real benefit from IO controller thread? What would stop you replacing it with some other construct that feeds into the queues directly? On 23 June 2012 22:34, Jerome Louvel jerome.lou...@restlet.com wrote: That’s the way it already works indeed! There is just one IO controller thread that communicates with a pool of worker threads via a set of message queues, managed at the connector helper level. The wakeup issue here is only relevant for the IO controller thread to prevent it from spinning over and over. ** ** Best regards, Jerome -- http://www.restlet.com http://twitter.com/#!/jlouvel ** ** ** ** *De :* Ioannis Mavroukakis [mailto:imavrouka...@gmail.com] *Envoyé :* samedi 23 juin 2012 13:47 *À :* discuss@restlet.tigris.org *Objet :* Re: Idling app has ~2MB of garbage collected every 30 seconds*** * ** ** Cool, so in essence you wouldn't need to rely on interrupts to serve an incoming request, is that correct? On 23 June 2012 21:41, Jerome Louvel jerome.lou...@restlet.com wrote:*** * Hi Ioannis, Actually, we use several queues down the road to process the messages (requests and responses), so it already almost works like you expect. See diagrams here: http://wiki.restlet.org/developers/172-restlet/g1/354-restlet.html Best regards, Jerome -- http://www.restlet.com http://twitter.com/#!/jlouvel *De :* Ioannis Mavroukakis [mailto:imavrouka...@gmail.com] *Envoyé :* samedi 23 juin 2012 13:11 *À :* discuss@restlet.tigris.org *Objet :* Re: Idling app has ~2MB of garbage collected every 30 seconds*** * Well I'm speculating here as I haven't seen the code, but it *sounds like* a classic producer/consumer scenario, which might be best served with a blocking queue. So at one end you'd have your NIO selector or whatever else feeding the queue, and at the other end, a consumer picking up jobs via either take() or poll() (which blocks if there's no element to be taken).The cool thing about this, is that it promotes work stealing, so you could have multiple queues and consumers, which can steal work from other queues when idle. As I forewarned, I haven't delved deep into the code, so I may be talking out of my ass :) Cheers, Ioannis On 22 June 2012 17:41, Jerome Louvel jerome.lou...@restlet.com wrote:*** * Hi Ioannis, Regarding the GC of iterators, I've fixed the one under our control in RF 2.1 and 2.2/master branches yesterday. The second one is inside the NIO selector code so we can't remove it, which leads to the second solution anyway. I've also started to implement the notification/wakeup logic but haven't got it done yet. This takes us back to you remark. The NIO Selector#select method is here to allow a single thread to handle thousands of concurrent connections in a scalable manner. You register for IO interest for specific channels/connections and wait for it to return and tell you the selected one that are ready for processing. Could you explain a bit more about a blocking queue could help us solve this issue? Best regards, Jerome -- http://www.restlet.com http://twitter.com/#!/jlouvel -Message d'origine- De : Ioannis Mavroukakis [mailto:imavrouka...@gmail.com] Envoyé : vendredi 22 juin 2012 01:17 À : discuss@restlet.tigris.org Objet : Re: Idling app has ~2MB of garbage collected every 30 seconds Hi Jerome , You're welcome, it's an interesting discussion. Is interrupting the cleanest way of doing this ? Wouldn't a blocking queue serve better in the context of a producer/consumer scenario? On 22 Jun 2012, at 00:31, Jerome Louvel jerome.lou...@restlet.com wrote: Hi Yan, Ioannis, Thanks for pointing your finger on this hot spot! The GC overhead is clearly an issue that needs to be fixed and definitely worth a ticket in GitHub. A first and easy solution is to replace those two iterator objects with regular loops to prevent unnecessary garbage collection. The second and harder solution will require to have the controller thread sleep by default (as long as possible to prevent unnecessary CPU cycles) and indeed interrupt it when an event occurs: 1) NIO event detected 2) Connection event detected (new connection/message/entity chunk to process) See this wiki pages to details on this connector and the pending tasks: http://wiki.restlet.org/developers/172-restlet/g3/354-restlet.html Best regards, Jerome -- http://www.restlet.com http://twitter.com/#!/jlouvel -Message d'origine- De : Ioannis Mavroukakis [mailto:imavrouka...@gmail.com] Envoyé : jeudi 21 juin 2012 01:05 À : discuss@restlet.tigris.org Objet : Re: Idling app has ~2MB of garbage collected every 30 seconds Yes it could but you would you not end up having
Re: Idling app has ~2MB of garbage collected every 30 seconds
Hi Jerome ,
You're welcome, it's an interesting discussion. Is interrupting the cleanest
way of doing this ? Wouldn't a blocking queue serve better in the context of a
producer/consumer scenario?
On 22 Jun 2012, at 00:31, Jerome Louvel jerome.lou...@restlet.com wrote:
Hi Yan, Ioannis,
Thanks for pointing your finger on this hot spot! The GC overhead is clearly
an issue that needs to be fixed and definitely worth a ticket in GitHub.
A first and easy solution is to replace those two iterator objects with
regular loops to prevent unnecessary garbage collection.
The second and harder solution will require to have the controller thread
sleep by default (as long as possible to prevent unnecessary CPU cycles) and
indeed interrupt it when an event occurs:
1) NIO event detected
2) Connection event detected (new connection/message/entity chunk to
process)
See this wiki pages to details on this connector and the pending tasks:
http://wiki.restlet.org/developers/172-restlet/g3/354-restlet.html
Best regards,
Jerome
--
http://www.restlet.com
http://twitter.com/#!/jlouvel
-Message d'origine-
De : Ioannis Mavroukakis [mailto:imavrouka...@gmail.com]
Envoyé : jeudi 21 juin 2012 01:05
À : discuss@restlet.tigris.org
Objet : Re: Idling app has ~2MB of garbage collected every 30 seconds
Yes it could but you would you not end up having the overhead of context
switching from the thrown thread interrupts? On a low resource device this
can't be the best of situations I imagine.
On 21 Jun 2012, at 00:16, Yan Zhou yanzhou_2...@yahoo.com wrote:
Any objections if the following is added as a new issue in the issue
tracker?
I am thinking that the selectKeys(sleepTime) call below really should be
able to return immediately (thread interrupted, for example) if there has
been a connection state change that needs attention. The sleepTime will then
have little effect on how soon or how often controlConnections() is run.
Thanks,
Yan Zhou
Hi,
We are noticing that an idling Restlet server has about 2MB of garbage
collected in 30 seconds.
I think I tracked it down to the loop in ConnectionController that
invokes the method below:
@Override
protected void doRun(long sleepTime) throws IOException {
super.doRun(sleepTime);
registerKeys();
updateKeys();
selectKeys(sleepTime);
controlConnections();
}
The sleepTime comes from the controllerSleepTimeMs parameter, which is 1
by default.
So if the loop generates 60 bytes of garbage (2 iterator objects), it'd
lead to: 60 x 1000 x 30 = 1,800,000 bytes or 1.8MB every 30 seconds.
Can I ask if this is a known issue? And if there are workarounds?
I have already tried tweaking the controllerSleepTimeMs and changing it
to something like 3 (30 seconds). Every connection then takes up to 30
seconds to close - probably not acceptable as a solution.
Additional info: Restlet 2.1 rc4 Android edition.
Thanks,
Yan Zhou
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=29722
83
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=29723
87
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2972533
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2972585
Re: Idling app has ~2MB of garbage collected every 30 seconds
Yes it could but you would you not end up having the overhead of context
switching from the thrown thread interrupts? On a low resource device this
can't be the best of situations I imagine.
On 21 Jun 2012, at 00:16, Yan Zhou yanzhou_2...@yahoo.com wrote:
Any objections if the following is added as a new issue in the issue tracker?
I am thinking that the selectKeys(sleepTime) call below really should be able
to return immediately (thread interrupted, for example) if there has been a
connection state change that needs attention. The sleepTime will then have
little effect on how soon or how often controlConnections() is run.
Thanks,
Yan Zhou
Hi,
We are noticing that an idling Restlet server has about 2MB of garbage
collected in 30 seconds.
I think I tracked it down to the loop in ConnectionController that invokes
the method below:
@Override
protected void doRun(long sleepTime) throws IOException {
super.doRun(sleepTime);
registerKeys();
updateKeys();
selectKeys(sleepTime);
controlConnections();
}
The sleepTime comes from the controllerSleepTimeMs parameter, which is 1 by
default.
So if the loop generates 60 bytes of garbage (2 iterator objects), it'd lead
to: 60 x 1000 x 30 = 1,800,000 bytes or 1.8MB every 30 seconds.
Can I ask if this is a known issue? And if there are workarounds?
I have already tried tweaking the controllerSleepTimeMs and changing it to
something like 3 (30 seconds). Every connection then takes up to 30
seconds to close - probably not acceptable as a solution.
Additional info: Restlet 2.1 rc4 Android edition.
Thanks,
Yan Zhou
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2972283
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2972387
Re: Restlet Framework 2.1 RC5 and 2.0.14 released
Hi Dalia, Please do not hijack the release thread. The problem you have with ab has nothing to do with Restlet, as I've already explained to you in an earlier post. Use an alternative load tool like LoadUI or Apache JMeter On 23 May 2012, at 23:21, Dalia Sobhy dalia.mohso...@hotmail.com wrote: Hiii Jerome, I have a problem with restlet 2.0.12, When I type this cmd $ab -n 10 -c 5 http://localhost:8182/test/1235/retrievepatient This is ApacheBench, Version 2.3 $Revision: 655654 $ Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ Licensed to The Apache Software Foundation, http://www.apache.org/ Benchmarking localhost (be patient)...apr_poll: The timeout specified has expired (70007) $ curl http://localhost:8182/test/1235/retrievepatient info:address = 6 Elfanan Ahmed Osman zizenia; info:bloodGroup = O; info:dateOfBirth = Sat Nov 10 00:00:00 EET 3860; info:fullname = Nadia Badawi; info:gender = male; info:maritalStatus = MARRIED; So any info plzz because this is so critical to me, I want to test the performance of my restlet web app... -- View this message in context: http://restlet-discuss.1400322.n2.nabble.com/Restlet-Framework-2-1-RC5-and-2-0-14-released-tp7574149p7574251.html Sent from the Restlet Discuss mailing list archive at Nabble.com. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2964701 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2964784
Re: How to measure the performance of an app using Restlet 2.1
Yes both run under OSX IIRC. JMeter definitely, LoadUI probably. On 23 May 2012, at 23:14, Dalia Sobhy dalia.mohso...@hotmail.com wrote: Is there one for mac osx ?? -- View this message in context: http://restlet-discuss.1400322.n2.nabble.com/How-to-measure-the-performance-of-an-app-using-Restlet-2-1-tp7571360p7574242.html Sent from the Restlet Discuss mailing list archive at Nabble.com. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2964700 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2964785
Re: Restlet Framework 2.1 RC5 and 2.0.14 released
Yey! Well done :) On 23 May 2012 21:53, Jerome Louvel jerome.lou...@restlet.com wrote: Hi all, ** ** The core Restlet team is happy to announce two new releases of the framework! http://blog.restlet.com/2012/05/23/restlet-framework-2-1-rc5-and-2-0-14-released/ ** ** The blog post also covers exciting progress on other fronts: **· **next 2.2 version **· **book in pre-production **· **GitHub migration **· **JavaScript editions ** ** Best regards, Jerome -- http://www.restlet.com http://twitter.com/#!/jlouvel ** ** -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2964690
RE: Header-based routing
A quick and dirty way would be to use the request.clientInfo. agent property as described in http://wiki.restlet.org/docs_2.0/130-restlet.html . There might be more elegant ways though :) -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2964309
RE: Re: How to measure the performance of an app using Restlet 2.1
Hi Dalia, I personally use LoadUI, I like the connector oriented GUI and architecture. In a pinch you can also use ab - http://httpd.apache.org/docs/2.0/programs/ab.html -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2964329
RE: ClientResource, wrap and other best practices
Second part of your question, answered here I believe http://stackoverflow.com/questions/5914598/using-the-restlet-clientresource-correctly -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2964330
RE: Re: How to measure the performance of an app using Restlet 2.1
Apache/APR combination issue, see here https://issues.apache.org/bugzilla/show_bug.cgi?id=22686 Use loadUI or even Apache JMeter. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2964397
RE: Is it possible to (easily) have authenticated/non-authenticated versions...
Yeah the problem IMHO is that you're returning the guard, and the guard knows nothing about your URL scheme if I'm not mistaken. This needs something like router - guard - resource instead of guard - router - resource. alternatively, there should be an easy way to pattern match a guard to routes. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2961115
RE: Turning Nagel
Look at the HttpClientHelper's isSocketNoDelay() method (http://www.restlet.org/documentation/2.1/jee/engine/org/restlet/engine/connector/HttpClientHelper.html) -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2961118
RE: Is it possible to (easily) have authenticated/non-authenticated versions...
I haven't tested this so please accept my apologies if it doesn't work. You could use the following form of attach() public Route attach(String pathTemplate, Class? targetClass, int matchingMode) and attach your guard with a Template.MODE_STARTS_WITH matchingMode. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2960891
RE: Re: Re: Issue with restlet 2.1-RC4 under light load
Merci Thierry i'll give it a go under my test machine. I forgot to mention I'm using Spring to wire Restlet together, could this be part of the issue? Ioannis -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2958878
RE: Re: Re: Issue with restlet 2.1-RC4 under light load
I've attached my spring config, it would be greatly appreciated if you could
cast a quick sanity check..maybe something in the Spring coupling is causing me
all this grief.
Merci,
Ioannis
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2958919?xml version=1.0 encoding=UTF-8?
beans xmlns=http://www.springframework.org/schema/beans;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xmlns:context=http://www.springframework.org/schema/context;
xmlns:util=http://www.springframework.org/schema/util; xmlns:p=http://www.springframework.org/schema/p;
xmlns:cache=http://www.springframework.org/schema/cache;
xsi:schemaLocation=http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans.xsd
http://www.springframework.org/schema/util
http://www.springframework.org/schema/util/spring-util-3.0.xsd
http://www.springframework.org/schema/context
http://www.springframework.org/schema/context/spring-context-3.0.xsd
http://www.springframework.org/schema/cache
http://www.springframework.org/schema/cache/spring-cache.xsd;
!-- Autowired=on --
context:component-scan base-package=com.test.tktserver
scoped-proxy=interfaces /
!-- @Cacheable support --
cache:annotation-driven /
!-- Runtime properties --
util:properties id=runtimeProperties location=classpath:runtime.properties /
bean id=cacheManager class=org.springframework.cache.ehcache.EhCacheCacheManager
p:cache-manager-ref=ehcache /
!-- Ehcache library setup --
bean id=ehcache
class=org.springframework.cache.ehcache.EhCacheManagerFactoryBean
p:config-location=ehcache.xml /
!-- JSR-303 Validator --
bean id=validator
class=org.springframework.validation.beanvalidation.LocalValidatorFactoryBean /
bean id=component class=org.restlet.ext.spring.SpringComponent
qualifier value=main /
property name=name value=Server Component /
property name=description value=Service component /
property name=owner value=Ioannis Mavroukakis /
property name=author value=Ioannis Mavroukakis /
property name=client value=clap /
property name=server ref=server /
property name=defaultHost ref=defaultHost /
/bean
bean id=server class=org.restlet.ext.spring.SpringServer
constructor-arg value=http /
constructor-arg value=8111 /
property name=parameters
props
prop key=tracing#{runtimeProperties.tracing}/prop
prop key=maxThreads150/prop
prop key=minThreads10/prop
prop key=lowThreads145/prop
prop key=maxQueued80/prop
prop key=maxIoIdleTimeMs12/prop
prop key=directBufferstrue/prop
/props
/property
/bean
bean id=defaultHost class=org.restlet.ext.spring.SpringHost
constructor-arg ref=component /
property name=defaultAttachment ref=ticketServerApplication /
/bean
bean id=staticTradeSchema class=org.restlet.resource.Directory
constructor-arg
util:property-path path=component.context /
/constructor-arg
constructor-arg
bean id=localClapReference class=org.restlet.data.LocalReference
factory-method=createClapReference
constructor-arg
bean class=java.lang.Package factory-method=getPackage
constructor-arg value=com.test.tktserver /
/bean
/constructor-arg
/bean
/constructor-arg
/bean
bean name=rootResource class=com.test.tktserver.resource.RootServerResource /
bean name=businessCustomersResource
class=com.test.tktserver.resource.BusinessCustomersResource /
bean name=businessCurrenciesResource
class=com.test.tktserver.resource.BusinessCurrenciesResource /
bean name=businessBrokersResource class=com.test.tktserver.resource.BusinessBrokersResource /
bean name=tradeResource class=com.test.tktserver.resource.TradeServerResource /
bean name=tradeEnrichResource
class=com.test.tktserver.resource.TradeEnrichServerResource /
bean name=tradeGroupRefApprovalResource
class=com.test.tktserver.resource.TradeGroupRefApprovalResource /
bean name=tradeRefApprovalResource
class=com.test.tktserver.resource.TradeRefApprovalResource /
bean name=checkoutRefApprovalResource
class=com.test.tktserver.resource.CheckoutRefApprovalResource /
bean name=securityResource class=com.test.tktserver.resource.SecurityServerResource /
bean id=ticketServerApplication class=org.restlet.Application
constructor-arg
util:property-path path=component.context /
/constructor-arg
property name=name value=Server Component /
property name=description value=Service component /
property name=owner value=Ioannis Mavroukakis /
property name=author value=Ioannis Mavroukakis /
property name=inboundRoot
bean class=org.restlet.ext.spring.SpringRouter
constructor-arg ref=ticketServerApplication /
property name=attachments
map
entry key=/
bean class=org.restlet.ext.spring.SpringFinder
lookup-method name=create bean=rootResource /
/bean
/entry
entry key=/v1/trades
bean class
RE: Re: Restlet Put Method infinite loop
Hi Christie, I've tweaked my project's Spring config to add an https listener
and it worked fine, but Maven is managing all my dependencies.
2012-05-09 21:00:47,653 9676 INFO [main] [org.eclipse.jetty.util.log] (main:)
jetty-7.4.2.v20110526
2012-05-09 21:00:47,847 9870 INFO [main] [org.eclipse.jetty.util.log] (main:)
Started SelectChannelConnector@0.0.0.0:8111 STARTING
2012-05-09 21:00:48,407 10430 INFO [main] [org.eclipse.jetty.util.log] (main:)
jetty-7.4.2.v20110526
2012-05-09 21:00:49,233 11256 INFO [main] [org.eclipse.jetty.util.log] (main:)
Started SslSocketConnector@0.0.0.0:8411 STARTING
This is what my deps look like (using 2.1-RC4)
dependency
groupIdorg.restlet.jse/groupId
artifactIdorg.restlet/artifactId
version${restlet}/version
/dependency
dependency
groupIdorg.restlet.jse/groupId
artifactIdorg.restlet.ext.jaxb/artifactId
version${restlet}/version
/dependency
dependency
groupIdorg.restlet.jse/groupId
artifactIdorg.restlet.ext.jackson/artifactId
version${restlet}/version
/dependency
dependency
groupIdorg.restlet.jse/groupId
artifactIdorg.restlet.ext.jetty/artifactId
version${restlet}/version
/dependency
dependency
groupIdorg.restlet.jse/groupId
artifactIdorg.restlet.ext.spring/artifactId
version${restlet}/version
/dependency
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2958925
RE: Re: Re: Issue with restlet 2.1-RC4 under light load
Just a few more stats on this. Executed 3599 requests with loadui, ramping progressively up to 20 requests/sec. Out of those 3599 requests 121 came back with A response with a 200 (Ok) status should have an entity. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2958940
RE: Re: File extensions content negotiation for POST
Hi Lee, I'm a little confused, why do you define multipart as a handled extension in the @Post ? AFAIK all you need to do is declare @Post(tsv), and your converter should take care of the rest. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2958245
RE: mounting resources and final slash
Hi Danielle, I suppose you can, by setting the defaultMatchMode property on Router to org.restlet.routing.Template#STARTS_WITH. But why would you? If your uri after /proxy/ defines different resources, you're much better served by defining explicit handlers for each resource. What is your rationale behind your requirement? -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2958236
RE: Re: Issue with restlet 2.1-RC4 under light load
Hello Thierry, I've tried Jetty, I'm still experiencing the issue. Thanks, Ioannis -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2957348
RE: Re: Restlet in Action. Error in the listing 9.10.
The example is all wrong IMHO, it should look something like this
ListNumber emails = (newJacksonRepresentationListNumber(rep, new
ArrayListNumber())).getObject();
The point here is that the constructor is looking for an object of type T.
@SuppressWarnings(unchecked)
public JacksonRepresentation(MediaType mediaType, T object) { ...
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2956980
RE: Re: Issue with restlet 2.1-RC4 under light load
Hello Thierry, I'm using the (default) simple server connector, and the soak testing is done via LoadUI, which uses Apache-HttpClient behind the scenes. Would you suggest I used the jetty connector instead? Merci, Ioannis Hello Ioannis, could you tell us what kind of client and server are you using? Did you try with the simple or jetty server connector (just complete the classpath of your app with the org.restlet.ext.jetty.jar, or org.restlet.ext.simple.jar and their dependencies libraries, that is to say the jars located under lib/org.eclipse.jetty, or lib/org.simpleframework)? Best regards, Thierry Boileau -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2957109
Spring-Restlet integration issue
Hello there, I am following the examples of Restlet in Action and I've come against a block with the spring example. I have very conservatively adjusted it to suite my own Restlet App (which is running fine in standalone mode without Spring) but when I introduce Spring in the mix , it's as if my resources are no longer available to serve URI's. The spring XML bean id=componentChildContext class=org.restlet.Context lookup-method name=createChildContext bean=component.context / /bean bean id=defaultHost class=org.restlet.ext.spring.SpringHost constructor-arg ref=component / property name=serverPort value=8111 / property name=defaultAttachment ref=ticketServerApplication / /bean bean id=component class=org.restlet.ext.spring.SpringComponent property name=client value=clap / property name=server ref=server / property name=defaultHost ref=defaultHost / /bean bean id=component.context class=org.springframework.beans.factory.config.PropertyPathFactoryBean / bean id=server class=org.restlet.ext.spring.SpringServer constructor-arg value=http / constructor-arg value=8111 / /bean bean id=staticTradeSchema class=org.restlet.resource.Directory constructor-arg ref=componentChildContext / constructor-arg bean id=localClapReference class=org.restlet.data.LocalReference factory-method=createClapReference constructor-arg util:constant static-field=org.restlet.data.LocalReference.CLAP_CLASS / /constructor-arg constructor-arg value=/com/example/ticketserver / /bean /constructor-arg /bean bean id=rootResource class=com.example.ticketserver.resource.RootServerResource scope=prototype lazy-init=false / bean id=tradeResource class=com.example.ticketserver.resource.TradeServerResource scope=prototype lazy-init=false / bean id=ticketServerApplication class=org.restlet.Application constructor-arg ref=componentChildContext / property name=inboundRoot bean class=org.restlet.ext.spring.SpringRouter constructor-arg ref=ticketServerApplication / property name=attachments map entry key=/ bean class=org.restlet.ext.spring.SpringFinder lookup-method name=create bean=rootResource / /bean /entry entry key=/v1/trades/ bean class=org.restlet.ext.spring.SpringFinder lookup-method name=create bean=tradeResource / /bean /entry entry key=/v1/newtrade/ bean class=org.restlet.ext.spring.SpringFinder lookup-method name=create bean=tradeResource / /bean /entry entry key=/v1/static/ ref bean=staticTradeSchema / /entry /map /property /bean /property /bean The server will start up , but all I'm getting are 404's for the resources defined in the XML..Any suggestions? Thanks! -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2942849
