几次请求后的Restlet会在CPU上产生负载

时间:2013-11-26 08:24:04

标签: java restlet

我正在创建API的问题。我正在使用Restlet来创建带有json响应的API。首先,我阅读了restlet的文档,我使用了他们在这里介绍的简单模型:http://restlet.org/discover/firststeps

我的代码几乎相同但有些部分。我的 ServerResource 是这样的:

public class CategoriesResource extends ServerResource {

    @Get("json")
    public StringRepresentation represent(Representation entity) {
        dbOperations db = new dbOperations();
        db.connect();

        Series<Header> responseHeaders = (Series<Header>) getResponse().getAttributes().get("org.restlet.http.headers");
        if (responseHeaders == null) {
        responseHeaders = new Series(Header.class);
        getResponse().getAttributes().put("org.restlet.http.headers", responseHeaders);
        }
        responseHeaders.add("Access-Control-Allow-Origin", "*"); 
        return new StringRepresentation(db.getCategoriesJson(), MediaType.APPLICATION_JSON);
    }

}

我在db操作中使用gson库创建json响应我有一行:

CategoriesGson json = null;
json = new CategoriesGson(a, b, c, d);
// databases operations, most getting information from database
jsonList.add(gson.toJson(json));
return jsonList.toString();

主要问题是CPU负载在几次按F5后我在CPU上负载很多。我正在搜索问题,我能够做转储线程正在给这个用法。

Restlet-9860934" prio=10 tid=0x8828d000 nid=0x12ee runnable [0x87f89000]
   java.lang.Thread.State: RUNNABLE
    at java.lang.String.valueOf(String.java:2854)
    at java.lang.StringBuilder.append(StringBuilder.java:128)
    at org.restlet.engine.connector.Way.toString(Way.java:594)
    at java.lang.String.valueOf(String.java:2854)
    at java.lang.StringBuilder.append(StringBuilder.java:128)
    at org.restlet.engine.connector.Way.onSelected(Way.java:471)
    at org.restlet.util.SelectionRegistration.onSelected(SelectionRegistration.java:325)
    at org.restlet.engine.connector.Connection.onSelected(Connection.java:612)
    - locked <0x937a7550> (a java.nio.HeapByteBuffer)
    at org.restlet.util.SelectionRegistration.onSelected(SelectionRegistration.java:325)
    at org.restlet.engine.connector.ConnectionController.onSelected(ConnectionController.java:219)
    at org.restlet.engine.connector.ServerConnectionController.onSelected(ServerConnectionController.java:99)
    at org.restlet.engine.connector.ConnectionController.selectKeys(ConnectionController.java:308)
    at org.restlet.engine.connector.ConnectionController.doRun(ConnectionController.java:171)
    at org.restlet.engine.connector.Controller.run(Controller.java:159)
    at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
    at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
    at java.util.concurrent.FutureTask.run(FutureTask.java:166)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
    at java.lang.Thread.run(Thread.java:724)

这是restlet线程,我认为这是错误的。我不知道如何解决这个问题。我正在寻找这个问题,我在github上发现只有问题386和794。如果有人知道如何解决这个问题,请告诉我。

1 个答案:

答案 0 :(得分:0)

我遇到了完全相同的错误,我只知道如何重现它:

public Restlet createInboundRoot() {
    Router router = new Router(getContext());
    ChallengeAuthenticator authenticator = new ChallengeAuthenticator(getContext(), ChallengeScheme.HTTP_BASIC, "cancel");

    Verifier verifier = new Verifier() {        // not even used
        @Override
        public int verify(Request arg0, Response arg1) {
            return Verifier.RESULT_VALID;
        }
    };

    authenticator.setVerifier(verifier);
    router.attach("/test", HelloResource.class);

    Authorizer authorizer = new Authorizer() {      // authorizer only being used to delay request          
        @Override
        protected boolean authorize(Request arg0, Response arg1) {
            try {
                Thread.sleep(5000);                 // request is delayed by 5000ms
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
            return true;
        }
    };
    authorizer.setNext(router);

    authenticator.setNext(authorizer);
    return authenticator;
}

所以我做的很简单。我把请求推迟了5s。 当我在浏览器中请求资源时,我立即取消请求。之后我的CPU使用率上升到100%并保持在该水平......