|
Hi,
from the symptoms you described, this could well be a bug in your code, failing to check existence
properly, and failing to create a directory that already exists (and was created by someone considered different from yourself).
Luc Pattyn [Forum Guidelines] [My Articles]
- before you ask a question here, search CodeProject, then Google
- the quality and detail of your question reflects on the effectiveness of the help you are likely to get
- use the code block button (PRE tags) to preserve formatting when showing multi-line code snippets
|
|
|
|
|
Hello everybody in this forum , i would like to ask one question
i am developing a .Net remoting task , in which there is a server to publish a remote object that is registered on a definite port and a client which calls that remote object based on the remote uri of the remote object from the server .
now , in my task , when i run the server and the client , everything goes very well but i would like to run multiple client instances on the same machine .
when i do that it tells me "http channel is already registered" because in the client program i register an http channel but i would like to run multiple clients here is the code in the server.
<br />
HttpChannel channel = new HttpChannel(6064);<br />
<br />
ChannelServices.RegisterChannel(channel);<br />
<br />
RemotingConfiguration.RegisterWellKnownServiceType(typeof(RemotingManager), "RemotingManager.soap", WellKnownObjectMode.Singleton);<br />
and in the client side
<br />
<br />
HttpChannel mychannel = new HttpChannel();<br />
ChannelServices.RegisterChannel(mychannel);<br />
IRemotingManager mgr = (IRemotingManager)Activator.GetObjcet(typeof(IRemotingManager),"http://localhost:6064/RemotingManager.soap");<br />
......................<br />
.......................<br />
so when i run the client program it works so well and it fetches the remote object and everything goes well , but when i run multiple instances of the client program it tells me "the http channel is already registered" is there any way around that ?????
please help , i need to run multiple instances of the same client program on the same machine without having this port conflict ....
Thanks in advance.
Human knowledge belongs to the world.
|
|
|
|
|
snouto wrote: but when i run multiple instances of the client program it tells me "the http channel is already registered"
What happens if you try to Activate the second instance after that error?
Also, it's not a good idea to post code that doesn't compile unless you are asking about a compiler error.
snouto wrote: Activator.GetObjcet
This tells us you did not post your actual code that executes since that won't even compile. Therefore we can't trust anything we are looking at.
|
|
|
|
|
sorry mike , it is activator.GetObject(...) , but you still didn't reply to me about the core problem not mistypo ....
Look Deeper inside the core not the pheriphery
thanks
Human knowledge belongs to the world.
|
|
|
|
|
snouto wrote: but you still didn't reply to me about the core problem
Yes I did
led mike wrote: What happens if you try to Activate the second instance after that error?
|
|
|
|
|
if you think so , so your place is not here in code project
Human knowledge belongs to the world.
|
|
|
|
|
|
snouto wrote: your place is not here in code project
The gold triangle says it is. He did answer your question - he asked you what happened if you tried to open the second object anyway. It is possible for multiple instances to talk to the same port - it is not possible for the same port to be opened up many times. Work your way round that issue and you will find the answer.
|
|
|
|
|
can you explain more please your answer . how can i open multiple instances to talk to the same port , you mean to create a tcpchannel and give it a specific port like
TCPChannel mychannel = new TcpChannel(3030);
for example .
or put a port in the httpchannel constructor , can you clarify using a demo line of code for that port section , thanks for you
Human knowledge belongs to the world.
|
|
|
|
|
Nice Post Pete O! Surely you have solved his problem! Let me look at his reply..
Oh dear, what a shame. 
Look at the time! It flies by when you're, ummm doing whatever this is. 
Have a great weekend dude! ![Beer | [beer]](https://www.codeproject.com/script/Forums/Images/beer.gif)
|
|
|
|
|
I need a XML parser which uses XML schema.Plz help.
|
|
|
|
|
If you mean that you need an XML parser that reads an XML schema, then you're in luck because an XML schema file is written in XML! Any ol' XML parser will do, including the one(s) in System.XML.
Now, if you mean that you want to validate an XML document against an XML schema, that's a whole 'nother ball of wax. A really good place to start is at Validating XML Data with XmlReader[^].
"we must lose precision to make significant statements about complex systems."
-deKorvin on uncertainty
|
|
|
|
|
Hi,
I try to understand what is sync block index in reference type -
I google it and still did not find anything that explain it in way i understand.
Can someone please explain what is it ?
Thanks.
|
|
|
|
|
It's a very scary and 'under-the-hood' kind of thing. It appears to be an integer that is added to all (or some, sources don't agree) objects and has something to do with locking and the GC.
Before I go about unearthing huge PDF's containing detailed descriptions, is there there anything in particular that you'd like to know about it?
|
|
|
|
|
|
The SyncBlock is part of the .NET type internal structures (namely the OBJECTREF structure), and primarily has to do with thread synchronization. Generally, a SyncBlock is not created for classes, and the index # will be 0. If you use the lock() statement, then the CLR will create a SyncBlock entry for the current type, and associate it with the current AppDomain. When the lock block is entered, the CLR will create a Monitor object and stick it in the SyncBlock, along with the classes hash code (the AppDomainID and hash code are intended to support COM interop, and are not really used for pure managed code). The SyncBlock will then stay alive for the lifetime of its associated object and appdomain.
The SyncBlock index is a 1-based index into something called the Syncblk Entry Table, which is an indirection into the actual SyncBlock List which contains pointers to each SyncBlock instance. The reason for the multiple levels of indirection are intended to support the GC, which can freely move objects (such as SyncBlocks) around in memory. Each object instance itself contains a numeric 1-based index into the Syncblk Entry Table rather than a direct pointer so that the GC IS free to move SyncBlocks around in memory without requireing too much overhead to maintain type system integrity.
|
|
|
|
|
|
One difficulty with the normal exception system is that while it allows applications to use catch exceptions from which other exceptions are inherited, the normal exception hierarchy is based upon what type of problem occurred, rather than upon what the problem 'means'. An TimeoutException that occurs in one circumstance should probably be handled totally differently from one that occurs in another.
Although .Net allows one to define a custom hierarchy for one's own exceptions, each exception class needs to repeat the code for the four standard New() methods, and so creating a significant number of classes can be a nuisance.
One approach which would seem to hold some promise would be for an application to express its own exceptions using generic classes, something like:
Class GenEx
Inherits Exception
... New() methods here
End Class
Class GenEx(of T)
Inherits GenEx
... New() methods here
End Class
Class GenEx(of T, U)
Inherits GenEx(of T)
... New() methods here
End Class
Class GenEx(of T, U, V)
Inherits GenEx(of T, U)
... New() methods here
End Class
etc. if more nesting is desired.
Then if an object of type MyThing wants to throw an exception for a timeout condition, it can throw a New GenEx(of MyThing, TimeoutException) which can be caught by a Catch of either GenEx, GenEx(of MyThing), or GenEx(of MyThing, TimeoutException).
Things get a little clunky if MyThing is itself an inherited class; catch statements for GenEx(of MyThingsParent) won't catch a throw of type GenEx(of MyThing). In designing the throw statements for MyThing, however, one could throw a GenEx(of MyThingsParent, MyThing, TimeoutException) [though that would unfortunately only get snagged by a Catch of GenEx(of MyThingsParent) and not one of GenEx(of MyThingsParent, TimeoutException)] or a GenEx(of MyThingsParent, MyThing, TimeoutException) [ignoring the actual type of MyThing].
Has anyone else tried anything at all similar to this approach? With what effects (good or bad)?
Pro: it would facilitate a more useful exception hierarchy based upon the type of object trying to do something than upon the nature of the result.
Con: unless one had a procedure for cataloging the exceptions one was actually using, it could turn into a real mess.
Any thoughts?
|
|
|
|
|
supercat9 wrote: clever idea or bad idea
Or possibly both. 
I dunno, I just tried the syntax in C# and got no errors, so it seems valid.
I just haven't yet thought of a use for it.
If you could come up with a situation in which to use it, you may be more convincing.
|
|
|
|
|
I just haven't yet thought of a use for it.
Well, one use is to reduce the amount of copy/pasted code for custom exceptions. Not in and of itself sufficient reason to use a new pattern, though if using a wider range of exceptions is helpful and the reduced copy/paste requirement would encourages such practices, that could be a good thing.
More generally, it seems to me that there are many situations where a routine's caller will sometimes want to know the specifics of something that went wrong, and others where the caller's concern is simply whether or not it worked. For example, if I send a request for information to another machine and I don't get a valid reply, there are a number of things that could have gone wrong (note that the protocol is designed for communicating with an embeded system via serial or TCP, so it includes its own sequence numbers, checksums, etc. to allow for the possibility of dropped or garbled bytes):
- Connection attempt failed at transport layer
- Connection died at transport layer
- No response received
- Garbage packet received
- Valid-seeming packet received, but with wrong sequence number
- Valid packet received indicating remote end received out-of-sequence packet
- Valid packet: "Command unknown"
- Valid packet: "Credentials refused"
- Valid packet: "Command invalid in this context"
- Valid packet, but not the expected type
- Valid packet, but not the expected length
In some cases, if a command/reply exchange fails, it won't really matter why, and it will make sense to just catch a generic 'something went wrong while exchanging packets' exception. In others, different exception causes should be handled differently. At that level (send/receive one packet), basic inheritance would suffice, though copying/pasting code for all the different exceptions would be annoying.
At a higher level, though, the effective meaning of the above errors may depend upon what the system was doing when it occurred. If certain exceptions happen on certain commands, for example, the system should probably try to re-establish synchronization with the remote machine as soon as possible. In other case, that wouldn't be helpful.
Thinking about it, perhaps the best trick wouldn't be to use nested generic exceptions, but rather to take advantage of the 'When' clause in VB.net; if a custom exception class contains an integer with a bitmask enumeration type, then an exception handler could test for any combination of flags without requiring any hierarchical relationship. Maybe that would be the best approach. I wonder if there would be any adverse performance consequences.
|
|
|
|
|
In this particular example, I would use one or maybe two exceptions (one for 1-4, another for 5-10) with an extra field that can store an enum value defining the error that occurred. Unless you find yourself with situations where you want to catch one type of error and not another, there's no need to make different exception types. Even then, you could catch the single exception type, handle it if you can, and rethrow it if you cannot.
|
|
|
|
|
I think this entire thread is an case for "everybody prod microsoft into putting the CLR exception filtering support into c#" :P
|
|
|
|
|
supercat9 wrote: clever idea or bad idea
A finer blend of both. For some cases, it wouldn't be meaningful to have unneeded exception clauses and for code readability purposes, you can club them into generic.
Vasudevan Deepak Kumar
Personal Homepage
Tech Gossips
The woods are lovely, dark and deep,
But I have promises to keep,
And miles to go before I sleep,
And miles to go before I sleep!
|
|
|
|
|
Hi,
I have created 5 SSIS packages. All these are password protected. One of the packages is Driver package that calls Other packages based on some settings in the config file.
Till now I was executing these packages using a job in SQL server. But now I want to execute packages from VB.net code.
Please suggest how can I execute SSIS package from VB.NET.
Any sample code would be very helpul.
Thanks In Advance
CodeManiac
xxxxxxxxxx
xxxxxxxxxx
|
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
