[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

microsoft.public.dotnet.framework.remoting

My custom channel blocks exception, but tcp channel does not

msnews.microsoft.com

11/4/2004 11:01:00 PM

On frame 1.1, I made a bi-directional socket channel, when server throws a
custom exception, client always get a RemotingException with "Server
encountered an internal error. For more information, turn on customErrors
in the server's .config file.", but client can get the correct exception
when I do the same thing with tcp channel. Anybody knows the problem?

Thanks in advance.

Simon
5 Answers

Robert Jordan

11/5/2004 10:31:00 AM

0

Hi,

> On frame 1.1, I made a bi-directional socket channel, when server throws a
> custom exception, client always get a RemotingException with "Server
> encountered an internal error. For more information, turn on customErrors
> in the server's .config file.", but client can get the correct exception
> when I do the same thing with tcp channel. Anybody knows the problem?

What's your default ServerFormatterSinkProvider?
If it's a BinaryServerFormatterSinkProvider you may try to set
its TypeFilterLevel property to TypeFilterLevel.Full.

However, if you already have these settings

<channel ...>
<serverProviders>
<formatter ref="binary" typeFilterLevel="Full" />
</serverProviders>
</channel>

then you probably don't correctly chain into the sink chain,
or don't chain at all.

Another source of this exception may be your own buggy
implementation. I got this all the time during development.

bye
Rob

msnews.microsoft.com

11/5/2004 3:11:00 PM

0


"Robert Jordan" <robertj@gmx.net> wrote in message
news:cmfkpb$3o5$04$1@news.t-online.com...
> Hi,
>
> > On frame 1.1, I made a bi-directional socket channel, when server throws
a
> > custom exception, client always get a RemotingException with "Server
> > encountered an internal error. For more information, turn on
customErrors
> > in the server's .config file.", but client can get the correct exception
> > when I do the same thing with tcp channel. Anybody knows the problem?
>
> What's your default ServerFormatterSinkProvider?
> If it's a BinaryServerFormatterSinkProvider you may try to set
> its TypeFilterLevel property to TypeFilterLevel.Full.
>
> However, if you already have these settings
>
> <channel ...>
> <serverProviders>
> <formatter ref="binary" typeFilterLevel="Full" />
> </serverProviders>
> </channel>
>
> then you probably don't correctly chain into the sink chain,
> or don't chain at all.
>
> Another source of this exception may be your own buggy
> implementation. I got this all the time during development.
>
> bye
> Rob


Thank you for the reply. I have fixed it by set "__CustomErrorsEnabled" in
message header to false before call ProcessMessage. This is the part of my
code:
msg.Headers["__CustomErrorsEnabled"] = false;//To pass all exceptions to
client

ServerChannelSinkStack stack = new ServerChannelSinkStack();

stack.Push(this,msg);

ServerProcessing proc =
_nextSink.ProcessMessage(stack,null,msg.Headers,msg.Body,out responseMsg,
out responseHeaders,out responseStream);


Another thing I found is tcp channel has better performance than my socket
channel, do you have experience to improve it?

Thanks again.

Simon

Robert Jordan

11/5/2004 7:25:00 PM

0

Hi,

> Thank you for the reply. I have fixed it by set "__CustomErrorsEnabled" in
> message header to false before call ProcessMessage. This is the part of my
> code:
> msg.Headers["__CustomErrorsEnabled"] = false;//To pass all exceptions to
> client
>
> ServerChannelSinkStack stack = new ServerChannelSinkStack();
>
> stack.Push(this,msg);
>
> ServerProcessing proc =
> _nextSink.ProcessMessage(stack,null,msg.Headers,msg.Body,out responseMsg,
> out responseHeaders,out responseStream);

That's the same as

<system.runtime.remoting>
<customErrors mode="off" />

Do you have this setting in your server's config too?

> Another thing I found is tcp channel has better performance than my socket
> channel, do you have experience to improve it?

Indeed, the implementation seems to be very smart.

Do you really need more performance? A bidirectional channel is intended
to be used across firewals, isn't it?

bye
Rob

msnews.microsoft.com

11/5/2004 9:45:00 PM

0


"Robert Jordan" <robertj@gmx.net> wrote in message
news:cmgk2c$t3e$02$1@news.t-online.com...
> Hi,
>
> > Thank you for the reply. I have fixed it by set "__CustomErrorsEnabled"
in
> > message header to false before call ProcessMessage. This is the part of
my
> > code:
> > msg.Headers["__CustomErrorsEnabled"] = false;//To pass all exceptions to
> > client
> >
> > ServerChannelSinkStack stack = new ServerChannelSinkStack();
> >
> > stack.Push(this,msg);
> >
> > ServerProcessing proc =
> > _nextSink.ProcessMessage(stack,null,msg.Headers,msg.Body,out
responseMsg,
> > out responseHeaders,out responseStream);
>
> That's the same as
>
> <system.runtime.remoting>
> <customErrors mode="off" />
>
> Do you have this setting in your server's config too?

No, I don't have a config file. By my test, this setting in config works for
tcp and http only, for custom channel, you have to do it like my code.
Furthermore, RemotingConfigure.Configure() leads to remoting on Frame 1.1
leaking memory in [STMThread] mode.

> > Another thing I found is tcp channel has better performance than my
socket
> > channel, do you have experience to improve it?
>
> Indeed, the implementation seems to be very smart.
>
> Do you really need more performance? A bidirectional channel is intended
> to be used across firewals, isn't it?
>

Yes, it is intended to across firewalls and I really need more performance.
Now the response time is almost doubled comparing to tcp channel.

> bye
> Rob

Robert Jordan

11/5/2004 10:49:00 PM

0

>>Do you really need more performance? A bidirectional channel is intended
>>to be used across firewals, isn't it?
>>
>
>
> Yes, it is intended to across firewalls and I really need more performance.
> Now the response time is almost doubled comparing to tcp channel.

I made the same experience with named pipe channels. Named
pipes are supposed to be 50% faster then TCP for loopback
communication, but I got almost the same speed as TcpChannel.
However, it took me less then 10h to implement the channel, so
I'm not surprised about the speed.

You may have a look at Mono's (http://ww...) implementation.

BTW, which skeleton is your channel based on? I'm using that
from ".NET Remoting" by Scott McLean.

bye
Rob