I have a Nunit test which adds message into MSMQ.
In the teardown of the NUnit i want to remove all the message from the queue.
Is there a direct way to remove all the messages from the queue (some kind of refresh) ?
Is there a Purge() method on your queue object that would do the trick?
Edit: Yup - seems to be: http://msdn.microsoft.com/en-us/library/ms703966%28VS.85%29.aspx
Related
I see 'BrokerNotAvailableException' from the below list http://kafka.apache.org/20/javadoc/org/apache/kafka/common/errors/BrokerNotAvailableException.html
but I don't see this in the exceptions for a Callback.
https://kafka.apache.org/25/javadoc/org/apache/kafka/clients/producer/Callback.html
Does it mean, BrokerNotAvailableException will not happen when using Callback?
I am using ReplaySubject as a pipe when I feed the Observer with OnNext messages and then I subscribe to the message in another part of the code.
I tried ISubject first, by using Subject.Create(observer:, observable:) but this seems to do nothing, or in other words, the Observer is a sink that goes nowhere. Is there some code that will make the Subject do something pipe-like. For example, I want to inject onNext messages with a integral countN and I want the observable to broadcast N-many 0.00E0(s) in sequence.
UPDATE:
It seems I need to implement the ISubject interface. Is there source code for a simple implementation that functions the same as ReplaySubject, with simple, proper memory handling of buffer size and Observer collection and Disposable return object.
Ok, so you use
new Subject<Int32>()
to get a subject that is a pipe-line.
Someone care to explain what Subject.Create does?
Can you inherit from Subject or ReplaySubject? Should you be able to?
How can I test an actor? Since the calls are not synchronous, and one messages can cause multiple messages to be sent, what are the ways of testing it?
E.g. How can I test that my actor sent 3 messages in response to another message?
In general you cannot test what an actor has done unless it interacts with a trait or interface you provide in the construction or in an input message. So if you have an actor like the following.
actor MyActor
be do_stuff(receiver: MyReceiver)
You use a pattern where you combine a timer, for a timeout, and a wrapper actor that provides MyReceiver to test if the actor actually did send the message or sequence of messages that where expected.
Pony already includes the ponytest package with some support for this kind of tests. You can check the PonyTest actor at GitHub. Basically you have to specify a timeout and ensure one of your actors calls complete in the test helper for success. Note that the API has changed since the last stable version.
Tha Akka documentaton indicates:
A durable mailbox is a replacement for the standard actor mailbox that
is durable.
What is the mechanism used as a standard mailbox so an Actor can read its messages after a restart?
Thank you.
I've implemented a small project to check this out with my own hands.
The configuration of an Actor's mailbox is achieved via the dispatcher. The following are the possibilities for the mailbox:
UnboundedMailbox
BoundedMailbox
UnboundedPriorityMailbox
BoundedPriorityMailbox
and finally:
Durable mailboxes
I had to configure my actor system with a dispatcher which indicates that the mailbox is file based. The following lines were just neccesary in the configuration of the Actor System:
my-dispatcher {
mailbox-type = akka.actor.mailbox.FileBasedMailboxType
}
In adition, I configured the properties for the file based durable mailbox, with the indications provided in:
http://doc.akka.io/docs/akka/2.0.3/modules/durable-mailbox.html
Finally, the creator of the specific Actor I wanted to persist in a file creates the Actor with the following:
context.actorOf(Props[MyActor].withDispatcher("my-dispatcher"), "myactor1"
I still need more practice to make an Actor to be recreated and read the remaining messaged in the mailbox, but the main question is answered now.
Everything was found in the documentation, it was just a matter of getting things done.
Calling the !! method from one actor to another worker actor appears to keep the channel open even after the reply was received by the caller (ie: future is ready).
For example, using !! to send 11 different messages from one actor to another worker actor will result in 11 messages similar to the below being shown in the mailbox of the original caller, each with a different Channel#xxxx value.
!(scala.actors.Channel#11b456f,Exit(com.test.app.actor.QueryActor#4f7bc2,'normal))
Are these messages awaiting replies from the worker, as the original caller is sending an Exit message out upon it's own call to exit(), or are they generated on the other end, and for some reason have the print form shown above? By this point, the worker actor has already exited, so the original caller of !! will definitely never receive any replies.
This behavior is undesirable, as the original calling actor's mailbox fills with these exit messages (one for each channel created for each time !! was used).
How can this be stopped? Is the original caller automatically "linking" to the reply channels created on each !! call?
The reason why these Exit messages are sent to the original caller is that the caller links its temporary channel, which is used to receive the future result, to the callee. In particular, if the channel receives an exit signal, an Exit message is sent on that channel, which results in a message similar to what you describe to be sent to the actual caller (you can think of channels as tags on messages). This is done to allow (re-)throwing an exception inside the caller if the callee terminates before serving the future message send (the exception is thrown upon accessing the future).
The problem with the current implementation is that the caller receives an Exit message even if the future was already resolved. This is clearly a bug that should be filed on the Scala Trac. A possible fix is to only send an Exit message if the future has not been resolved, yet. In this case the Exit message will be removed whenever the future is accessed for the first time using apply or isSet.