|
It's there to ensure durability (assuming MSMQ is setup to be durable). There are now other options but prior to .NET 3.x it provided a durable solution for third party providers. It also works well in remote locations where connectivity isn't assured. Connectivity may not be an issue here but if the message received, somehow crashes the service/server or the server falls over for whatever reason, the message should still survive.
"You get that on the big jobs."
|
|
|
|
|
I understand, however, how can the message survive if the system crashes before being inserted into a queue? I guess once it is inserted, only afterwards it can survive.
I studied the code more and looks like nServiceBus is used as well. Any idea why nServiceBus is used? I did some research and I am starting to think nServiceBus is similar to WCF but has differences. Also nServiceBus is built using MSMQ so why are the messages being inserted into queues again if nServiceBus is taking care of that?
<b>CodingYoshi</b>
<i>Artificial Intelligence is <b>no</b> match for Human Stupidity.</i>
|
|
|
|
|
If the system crashes, before inserting into queue there isn’t much you can do. Hopefully the sender is expecting a response and so will assume that the message was not successful. If all is good, receive message, queue to MSMQ and then respond that message has been received. nServiceBus I know nothing about, sorry.
"You get that on the big jobs."
|
|
|
|
|
RobCroll wrote: in remote locations
Sure, but I'd likely roll my own socket messaging engine that the applications don't need to know about.
|
|
|
|
|
It was a while ago but the way I remember using MSMQ. The remote server would run a service that handled the tcp/ip communications with the remote applications. The remote server also had in and out MSMQ's. Another service would manage the MSMQ's in the city location. We didn't worry about testing for connectivity, MSMQ managed the "bridging" for us.
Hope that helps but it was a while ago. Also each OS had it's own version of MSMQ. That may not be the case now but ensuring the queues were durable could be problematic.
"You get that on the big jobs."
|
|
|
|
|
Hi,
I am in the middle of writing an ASP.Net program that will hand off a software key when the Web Server is called. I am receiving information from the caller in a "Query String" and saving it in a common class. After I have saved all the Query Strings, I am calling a Web Service to generate the key, using properties in the common class. If I successfully generate a key, I save the properties in the common class and the key to a SQL database on the server.
My question is should I use a static class or should I instantiate a new instance of the class? I'm concerned about the properties getting overlaid by the next caller before the key is generate and the information about the buyer is written to the SQL database. At least hopefully thinking that I will be selling that much software
Thank you,
Glenn
|
|
|
|
|
gmhanna wrote: I'm concerned about the properties getting overlaid by the next caller
That would also have been my concern, so I think you should stick with normal classes/objects.
V.
|
|
|
|
|
You can use a thread-safe Singleton class like this:
public sealed class Singleton {
private static Singleton _instance = null;
private static readonly object singletonLock = new object();
private Singleton() {}
public static Singleton Instance {
get {
lock (singletonLock) {
if (_instance == null) {
_instance = new Singleton();
}
return _instance;
}
}
}
}
"Don't confuse experts with facts" - Eric_V
|
|
|
|
|
This seems like something that should go in the session, if it is supposed to persist for more than one page hit.
|
|
|
|
|
<?xml version="1.0" encoding="utf-8"?>
<LicenceManager xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://visionontech.com/vbp/LicenceConfiguration">
<ApplicationName>ovE1c/0l6IoKP/KF6bpqv22zqoYuT3Wv</ApplicationName>
<LicenseType>7Ax330npgHE=</LicenseType>
<VersionType>bbUl/DISjDzJkqERNmGqY8eWlTKz+Er3qSWdcEGFDUdsWo9DJrviULY/entknwWw2Z67rm0RnqeB3ENiAa1blfEkGPtfeELVxVG44JG4J5w=</VersionType>
<CompanyName>KWZwGJLdl+pI240K/PURWg==</CompanyName>
<SerialNumber>7515b594-6afb-4f0f-bf4c-13351339191c</SerialNumber>
<MachineID>I50NMYu1RZix+7AuMOhIDyhyFkiepjdK1Sy93luDdi4nCxRLW+Yy259FgXAvKvX9</MachineID>
<Signature>9XvKvAXgF952yY+WLRxCn4idDul39yS1KdjpeikFyhyDIhOMuA7+xiZR1uYMN05I</Signature>
<City>Q6H8NNOnO80=</City>
<CreatedBy>TZdhgIlUIBo2BIm8yvL3ww==</CreatedBy>
<LicenseCreationDate>1xtf7PZmvZQ5e+ohObsHFHokaELQyvIq</LicenseCreationDate>
</LicenceManager>
my laptop licence is
i m using other computer d'not work plz help me brack my code
|
|
|
|
|
|
Sorry Mika, I accidentally clicked on your message instead of the offending one. Cheers.
I wasn't, now I am, then I won't be anymore.
|
|
|
|
|
No harm done
|
|
|
|
|
I just thought I'd let you know that your account is about to be deleted. Hacking isn't a supported activity here.
Buh-bye...
".45 ACP - because shooting twice is just silly" - JSOP, 2010 ----- You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010 ----- "Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass." - Dale Earnhardt, 1997
|
|
|
|
|
Hi, during handle the datagridview's rowvalidating event, if the cell's value did not pass the validation, I set the e.cancel = true. But if at this time I want to cancel add this new row or cancel editing the row, how can i do? the system did not allow me to leave this row, and I even can not close this application. please help me. thanks in advance.
|
|
|
|
|
|
Setting e.Cancel = true in the Validating event handler locks the user into edit mode and your observation about not being able to close the application is correct.
Editing can be cancelled by
1) The user pressing the ESC key.
or
2) In the Validating handler leave e.Cancel = false and call the DataGridView's CancelEdit() method.
Alan.
|
|
|
|
|
thanks.
Edit mode can be cancelled by press ESC key but the focus still limited in the datagridview. can not click anything else.
where to put the e.cancel =false? I want to validate the input but when the user give up and want to cancel insert such row, how to cancel it?
need more help. thanks.
|
|
|
|
|
Hi everyone,
I have "unlimited" processes (let's say 5 to 20 is a realistic number)
What I need is the following:
From time to time one of the processes has to signal the others that they have something to do.
There is no master, so I won't create some server which passes arround events for all interested processes.
There is also no message/content, so I would favor some low-level signalling. But without a master process IPC is not very handy at all.
WaitEventHandle seemed to be a good choice; even though it also works on process-level, it does not always work properly.
Every listening process has a thread whichs calls WaitOne(); when the event is sent it starts some action, calls Reset() and loops back to WaitOne().
The process which wants to indicate something creates a WaitEventHandle with the same name and calls Set().
In a simple hello world application this worked pretty well; but in some other application exactly the same approach never passes the second WaitOne(). Just as if noone would call Set anymore (but the other process still does!)
Is there any other useful low-level signalling? I am also not happy about the background thread with the do-while around the WaitOne().
Why are there no monitors or counters that simply fire an event when some equally named object in a different process/thread raises an event. :p
Cheerio,
Roland
|
|
|
|
|
Is it a requirement that there is no server? I would create a hub service (whether as an actual service or just an app which gets started with any process if it isn't already up) which each process connected to over TCP, and then you can use classic client/server notification and broadcasting. Peer-to-peer networks are notoriously a pain and that's essentially what you're suggesting, even if all the processes are on the same machine. (The other big bonus of using TCP and a hub process is that it makes it really easy to scale the problem to several machines in future.)
|
|
|
|
|
It's actually really a requirement.
We are working on local machine only (also in the future) and want to avoid the network stack.
As mentioned before, we only need some trigger, there is no information to transfer.
If we'd be using the network stack anyhow, I'd reather prefer to broadcast something on UDP instead of starting some server/hub along with the first process.
But since it is really just a trigger without any content, I cannot imagine that there is no simple signalling on OS-level...? Although, maybe there is really nothing.
|
|
|
|
|
Well, if you don't like the Wait On Event solution (come on, that has to work, everybody uses it) and you don't want to use network functions, the only other thing I can think of is file change notifications or registry change notifications.
|
|
|
|
|
Don Rolando wrote: In a simple hello world application this worked pretty well; but in some other
application exactly the same approach never passes the second WaitOne(). Just as
if noone would call Set anymore (but the other process still
does!)
I bet you were doing work in there.
Do this instead.
1. Create a thread safe notify queue (just a queue which moves a flag)
2. Create a thread that does NOTHING but wait for the notification and post to the queue. For safety use a timeout.
3. Create another thread that does the work. It does the work when something shows up on the queue.
You can implement 1/2 completely independently from the real version of 3 using whatever simulated work load you want.
|
|
|
|
|
jschell wrote: I bet you were doing work in there.
You are right, I did. For testing purpose I was calling a dispatcher to show in the UI that the EventWaitHandle's thread received the signal.
When removing the line with the dispatcher call, it works.
Ahm, but why does the dispatcher corrupt the whole EventWaitHandler?
To be honest, your suggested approach is also some kind of custom dispatcher, isn't it?
Could you enlight me why this has influence on the EventWaitHandle at all?
|
|
|
|
|
I wasn't commenting on your specific implementation since I didn't know what it was.
Rather your description of why it failed suggested that a timing problem of some sort was involved.
|
|
|
|