Log Question
Hi, I am just wondering what these numbers represent? INFO: 2011-10-0109:26:36192.148.117.110 - - 80 GET /FLc- *307 0 - 7* http://xx.xx Mozilla/5.0 (iPhone; U; CPU iPhone OS 4_2_1 like Mac OS X; en-us) AppleWebKit/533.17.9 (KHTML, like Gecko) Version/5.0.2 Mobile/8C148 Safari/6533.18.5 - INFO: 2011-10-0109:28:38124.120.249.68 - - 80 GET /FLc- *307 0 0 4 * http://xx.xx Mozilla/5.0 (iPhone; U; CPU iPhone OS 4_3_5 like Mac OS X; en-us) AppleWebKit/533.17.9 (KHTML, like Gecko) Version/5.0.2 Mobile/8L1 Safari/6533.18.5 - INFO: 2011-10-0109:40:02110.49.113.242 - - 80 GET /Fbk- * 307 0 0 11* http://xx.xx Mozilla/5.0 (Linux; U; Android 2.2; en-us; GT-I9000 Build/FROYO) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1 - I understand that 307 is a temp redirect, but what are the following numbers? The problem I am actually happening is that the first row is a mobile phone browser which is failing to redirect, the two proceeding log rows work fine. Can anyone help? Thanks James -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2848650
Re: Log Question
Here's the code that's logging the second value after the status code…
// Append the received size
sb.append('\t');
if (request.getEntity() == null) {
sb.append('0');
} else {
sb.append((request.getEntity().getSize() == -1) ? - : Long
.toString(request.getEntity().getSize()));
}
From: James jam...@gmail.commailto:jam...@gmail.com
Reply-To: discuss
discuss@restlet.tigris.orgmailto:discuss@restlet.tigris.org
Date: Sat, 1 Oct 2011 05:18:03 -0500
To: discuss@restlet.tigris.orgmailto:discuss@restlet.tigris.org
discuss@restlet.tigris.orgmailto:discuss@restlet.tigris.org
Subject: Log Question
Hi,
I am just wondering what these numbers represent?
INFO: 2011-10-0109:26:36192.148.117.110 - - 80
GET /FLc- 307 0 - 7 http://xx.xx
Mozilla/5.0 (iPhone; U; CPU iPhone OS 4_2_1 like Mac OS X; en-us)
AppleWebKit/533.17.9 (KHTML, like Gecko) Version/5.0.2 Mobile/8C148
Safari/6533.18.5 -
INFO: 2011-10-0109:28:38124.120.249.68 - - 80
GET /FLc- 307 0 0 4 http://xx.xx
Mozilla/5.0 (iPhone; U; CPU iPhone OS 4_3_5 like Mac OS X; en-us)
AppleWebKit/533.17.9 (KHTML, like Gecko) Version/5.0.2 Mobile/8L1
Safari/6533.18.5 -
INFO: 2011-10-0109:40:02110.49.113.242 - - 80
GET /Fbk- 307 0 0 11 http://xx.xx
Mozilla/5.0 (Linux; U; Android 2.2; en-us; GT-I9000 Build/FROYO)
AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1 -
I understand that 307 is a temp redirect, but what are the following numbers?
The problem I am actually happening is that the first row is a mobile phone
browser which is failing to redirect, the two proceeding log rows work fine.
Can anyone help?
Thanks
James
This message and any included attachments are intended only for the addressee.
The information contained in this message is confidential and may constitute
proprietary or non-public information under international, federal, or state
laws. Unauthorized forwarding, printing, copying, distribution, or use of such
information is strictly prohibited and may be unlawful. If you are not the
addressee, please promptly delete this message and notify the sender of the
delivery error by e-mail.
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2848694
Asynchronous support in 2.1
html style=direction: ltr;
head
meta http-equiv=content-type content=text/html;
charset=ISO-8859-1stylebody
p { margin-bottom: 0cm; margin-top: 0pt; } /style
/head
body style=direction: ltr;
bidimailui-detected-decoding-type=latin-charset bgcolor=#FF
text=#00
pHi,/p
pI would like to resurrect a very old thread, from more than a
year ago:/p
pa class=moz-txt-link-freetext
href=http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447amp;dsMessageId=2612147;http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447amp;dsMessageId=2612147/a/p
pLooking at the state of Restlet 2.1, I can't seem to find a
solution to the old problem, which implies asynchronous support is
still broken./p
pTo rehash the problem:/p
pEven if I set autoCommitting to false, parts of the Restlet
framework upstream will modify the Response (there is nothing to
stop them, since they have no idea about autoCommit downstream).
Their actions can easily interfere with my own comitter code,
which may be trying to modify the response at the same time. So,
the commit as a whole ends up being non-atomic and prone to race
conditions./p
pMy suggestion back then was to throw a special exception class
that would force upstream Restlets to avoid any kind of messing
with the response. We don't like adding more exceptions, but in
this case there is an obvious advantage of using the exception
unrolling feature of the JVM to elegantly send messages upstream.
(Another solution would be to set a special flag in the response,
but this would require all upstream restlets to explicitly check
for this flag.)br
/p
pSo, I'm wondering what's the status of this now! This is a
feature I've been wanting to see in Restlet for years. The
potential is there (the concurrency stuff is well handled), but
there is still this missing piece of the mechanism.br
/p
p-Talbr
/p
/body
/html
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2848707
