cancel
Showing results for 
Search instead for 
Did you mean: 

Strange (threading?) issue regarding rest services

atcevik
Champ in-the-making
Champ in-the-making
Hello,

I am using angularjs to call activiti-rest interface.

The scenario I am following is,

1. Listing all tasks of a user - OK

Request URL:http://localhost:8088/activiti-rest/service/tasks?assignee=kermit&start=0
Request Method:GET
Status Code:200 OK

2. Completing the task - OK
Request URL:http://localhost:8088/activiti-rest/service/task/578/complete
Request Method:PUT
Status Code:200 OK


3. Refreshing the task list - NOT OK!

Request URL:http://localhost:8088/activiti-rest/service/tasks?assignee=kermit&start=0
Request Method:GET
Status Code:404 Not Found

it is strange, as the call is the same at (1), double checked it. The response is strange,

<html>
<head>
   <title>Status page</title>
</head>
<body style="font-family: sans-serif;">
<p style="font-size: 1.2em;font-weight: bold;margin: 1em 0px;">No task found for taskId &apos;578&apos;</p>
<p>The server has not found anything matching the request URI</p>
<p>You can get technical details <a href="http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.5">here</a>.<br>
Please continue your visit at our <a href="/">home page</a>.
</p>
</body>
</html>



Huh ? TaskID ? I havent been sending one… The headers :

Accept:application/json, text/plain, */*
Accept-Charset:ISO-8859-1,utf-8;q=0.7,*;q=0.3
Accept-Encoding:gzip,deflate,sdch
Accept-Language:en-US,en;q=0.8
Authorization:Basic a2VybWl0Omtlcm1pdA==
Connection:keep-alive
Host:localhost:8088
Referer:http://localhost:8088/angularjs_1/app/index.html
User-Agent:Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.31 (KHTML, like Gecko) Chrome/26.0.1410.64 Safari/537.31


Actually, after the error, I resent the same call, using chromes developer tools, so no modification, and returns http 200 again after the failure.

The only difference, is calling the list method just after the complete method on the failing one. I am calling the list method immediately after calling complete, as the complete call is implemented in a callback, maybe the function has not been finished yet, so that might be the reason, but the failure message is garbage. I am wondering if there are some multithreading problems. Would be really glad if you could help me out. Thanks.
3 REPLIES 3

frederikherema1
Star Contributor
Star Contributor
Seems really strange that the "/tasks?assignee=XXX" call returns an error-message for the "/task/XXX" call. Is it possible that the framework you're using has some issues with sending a new HTTP-request from within the response-callback of the task-complete success?

Can you verify (using net-console or firebug or whatever) that the http-call done from the callback is indeed the "/tasks?assignee=XXX"? Because we're using rest let for URL-to-resource mapping and I really doubt there is a bug in restlet-routing. Also, since the error-message is "No task found for taskId &apos;578&apos;", it actually means that rest let received a call to tasks/578. Since restlet uses a new resource for each request, there is no way that it's a problem with server-side threading, as the container will NOT use the same request-context for multiple incoming requests. I suspect that the client-framework has a sticky URL somewhere…

atcevik
Champ in-the-making
Champ in-the-making
Dear Frederik,

Yes, I am sure that the call is done to that adress, as I stated, I repeat the call using the captured packet by the chrome dev tools and the fault does not occur on the repititive manual call. I do not change the log nor the adress, just resend it. Thus, the XHR call made from the browser is actually sent to the correct adress. My previous message includes log from the browser, not hand crafted. So the request url etc there are the actual adresses.

As I stated previously, the call is somehow an immediate call, maybe the update of the task mentioned in the log is not completed while listing the tasks of the same user, and I guess might be a problem regarding jpa/persistence at the activiti side.

frederikherema1
Star Contributor
Star Contributor
The headers included do not say anything about the URL that is called. I'm pretty confident that this is something client-related, as we use Restlet for routing to the correct resource, which is a proven technology that won't just 'route" the request to the wrong resource just like that…