xmlrpc 和 System.Net.WebException .net 3.5 c#
我使用 CookComputing.XmlRpc;
尝试使用一些请求连接到 trac 但我得到这个:
System.Net.WebExceptionStatus.ReceiveFailure
{“底层连接是 已关闭:发生意外错误 接收时。”}
{"无法读取数据 从传输连接:An 现有连接被强制 由远程主机关闭。"}
A- 当我使用 Visual Studio 2008 运行应用程序时,错误是间歇性。B-
当我运行已编译的应用程序时,它从不工作 C-
当我使用 fiddler 来听时,我的应用程序始终有效(来自 Visual Studio 或编译)
这就是我使用的:
//Trac Code
[XmlRpcUrl("http://trac:8080/Project/login/xmlrpc")]
public interface Trac : IXmlRpcProxy
{
[XmlRpcMethod("ticket.query")
int[] query(string queryStr);
[XmlRpcMethod("ticket.get")]
object[] get(int id);
}
用法:
//sometimes it fails here:
int[] a = proxy.query("status!=closed&owner=" + user);
//sometimes here:
foreach (int ticketid in a)
{
tickets.Add((proxy.get(ticketid))[3]);
System.Threading.Thread.Sleep(1000);
}
I use CookComputing.XmlRpc;
Trying to connect to trac using some requests but I get this:
System.Net.WebExceptionStatus.ReceiveFailure
{"The underlying connection was
closed: An unexpected error occurred
on a receive."}{"Unable to read data
from the transport connection: An
existing connection was forcibly
closed by the remote host."}
A- when I run my application using Visual Studio 2008, the error is intermittent.
B- when I run my compiled application it never works.
C- when I use fiddler to listen, my application always works (from visual studio or compiled)
This is what I use:
//Trac Code
[XmlRpcUrl("http://trac:8080/Project/login/xmlrpc")]
public interface Trac : IXmlRpcProxy
{
[XmlRpcMethod("ticket.query")
int[] query(string queryStr);
[XmlRpcMethod("ticket.get")]
object[] get(int id);
}
Usage:
//sometimes it fails here:
int[] a = proxy.query("status!=closed&owner=" + user);
//sometimes here:
foreach (int ticketid in a)
{
tickets.Add((proxy.get(ticketid))[3]);
System.Threading.Thread.Sleep(1000);
}
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
“fiddler Works”这句话让我想起了“缓冲”流与“无缓冲”流。由于 fiddler 缓冲整个流以显示,然后将其完全发送,因此可能会导致行为发生变化,与 Visual Studio 调试器同上。
这不是一个真正的答案,但也许是一个线索。
the ´fiddler works´ remark reminds me off the ´buffered´ versus ´unbuffered´ streams. Since fiddler buffers the entire stream to show and then sends it on completely it might cause changes in behavior, visual studio debugger idem.
Not a real answer, but maybe a lead leading to one.