In my project I have the following code snippet
if(strcmp(msg->getName(),"failedAck") == 0 || ......)
{
msg->removeControlInfo();
msg->setControlInfo(info);
recvControls++;
sendDirect(msg, table, "ackIn");
}
Essentially the a message arrives at its final destination (lets call it A*), and if it is a type of specified messages, it is sent to another module (B*) which uses the information it carries to perform an operation.
The problem I am having is that after sending the message to the other B*, I delete the message after I am done using it. However, it still appears as part of A* when I look in the inspector. And when I try and delete the message in A* I get an error message saying can't delete the message because it is currently scheduled.
I can't figure out why this happens, Does this mean that sendDirect() does not change the ownership of the message (contrary to the manual)?
Help in this matter will be greatly appreciated, currently dealing with memory management issues in my simulation, and this is a part of it.
I would like to withdraw this question and say thanks to everyone who looked at it. I just recently discovered that the items were being deleted when they were supposed to be. however, i had forgotten that i was making a clone of the object for other uses, that why it was showing up in the inspector. My apologies.
Related
After moving over from Bot Framework v3 and studying the docs/samples, I'm still not understanding why the WaterfallStep dialog handling in v4 was implemented in such a way.
Why was it chosen to process the result of the previous step in the next step within a waterfall?
Given a waterfall with 3 Steps PromptName, PromptAge and PromptLocation, I see the following:
Method naming: Given the 2nd and 3rd prompt, method naming gets unclear. Naturally we would do AskForAge() or AskForLocation() but this is misleading due to the next point
SOLID Principals: Isn't "single responsibility principal" violated as we do two things in each step? Storing the previous response while asking for the next one in the same method, which ultimately leads in method names like AskForLocationAndStoreAge()
Code duplication: Due to the fact that each step assumes concrete input from its previous step, it can't be reused easily nor can order be changed. Even the simplest samples are hard to read.
I'm looking for some clarification on why the design was chosen this way or what I have missed in the concept.
This question seems largely opinion-based and therefore I don't know that it is appropriate for Stack Overflow. It turns out there is actually a good place to ask these kinds of questions, and it's the BotBuilder GitHub repo. I will attempt to answer it all the same.
Why was it chosen to process the result of the previous step in the next step within a waterfall?
This has to do with how bot conversations work. In its most basic form, without any dialogs or state or anything, a bot works by answering questions or otherwise responding to messages from the user. That is to say, a bot program's entire lifespan is to receive one message, process it, and provide a response while the message it received is still "active" in some sense. Then every following message the bot receives from the user is processed in the same way as though the first message was never received, like the message is being processed by an entirely new instance of the program with no memory of previous messages.
To make bot conversations feel more continuous, bot state and dialogs are needed. With dialogs and specifically prompt dialogs, the bot is now able to ask the user a question rather than just answer questions the user asked. In order to do this, the bot needs to store information about the conversation somewhere so that when the next message is received from the user the new "instance" of the bot program will know that the message from the user should be interpreted as a response to the question that the previous instance of the program asked. It's like leaving a note for someone working the next shift to let them know about something that happened during the previous shift that they need to follow up on.
Knowing all this, it seems only natural to process the result of the previous step in the next step within a waterfall because of the nature of conversations and dialogs. In a waterfall dialog containing prompts, the bot will receive messages pertaining to the last message the bot sent. So it needs to process the result of the previous step in the next step. It also needs to respond to the message, and in a waterfall that often means asking another question.
Isn't "single responsibility principal" violated as we do two things in each step? Storing the previous response while asking for the next one in the same method, which ultimately leads in method names like AskForLocationAndStoreAge()
As I understand it, the single responsibility principle refers to classes and not methods. If it does refer to methods, then that principle may well be violated or bent in some way in this case. However, it doesn't have to be. You are free to make multiple methods to handle each step, or even to make multiple steps to handle each message. If you wanted, your waterfall could contain a step that processes the result of the previous prompt and then continues on into the next step which makes a new prompt.
Due to the fact that each step assumes concrete input from its previous step, it can't be reused easily nor can order be changed. Even the simplest samples are hard to read.
You ultimately have control over how the input is validated/interpreted so it can be as concrete as you want. The reusability of a dialog or waterfall step has everything to do with how similar the different things you want to do are, the same as in any area of programming. If the samples are hard to read, I recommend raising issues with those samples. Of course, you can still raise an issue with the design of the SDK itself in the appropriate repo, but please do consider including suggestions for the way you think it should be instead.
I've got a software i'm working on that pulls in emails from an exchange account. I use the ItemId.UniqueId to save to db. This allows me to check all incoming messages to see if they've been processed before.
The problem is that i'm seeing some messages come in twice. I can't work out why, though i can see that the UniqueId is different, so it's been updated.
I know if you move an email to a folder it give is a new UniqueId - which will then look like a new message...
Is there a way that I can get around this? Is there an ID that doesn't change?
PidTagSearchKey https://msdn.microsoft.com/en-us/library/office/cc815908.aspx doesn't change be isn't guaranteed to be unique (see table in doc) eg if somebody copies a Message between folders then the PidTagSearchKey will be the same, but for what you want to use it for it should do the trick.
When I'm trying to get email items from Exchange (Office 365) using EWS.
I'm trying to do that by chunks with 500 messages. Sometimes, when I'm call method findItem I'm getting error : "Resources are unavailable. Try again later., Cannot seek a row."
Googling didn't provide anythings. I don't understand what does it mean and how to solve this.
Thanks
I can't say as I've run into this specific error before, but when dealing with O365, you'll often encounter these kinds of "go away, come back later" messages, and will have to implement a retry mechanism. Reducing your chunk size might help as well, but the message does contain your next step, i.e. "Try again later." Now if the request never succeeds after retry, this might be a deeper issue, but it does sound like a transient error from what you've described.
The email being retrieved is within a folder that may have too many items. Retrieving such items usually returns similar errors. Splitting the folder such that each folder holds a max of 70,000 items may help.
In my app, multiple people can chat on a topic. However once the topic has been closed by its owner, chat should also be disabled on that topic.
My Tables -
ChatComment - a new comment is stored here as a record - it contains pointer to Topic
Topic - details related to topic for eg. body, owner, status - open/closed
I'm using cloud functions to create a new comment made by a person on its owner. So everytime I call the cloud function to write new comment, it first queries 'Topic' class to check if topic is still open or not, if its open itll go forward to create new comment in comment class, or else it will throw error.
My problem is that in realtime so many people chat on the topic so frequently that the first query(that checks if topic is still open) occurs for each comment and adds a delay. It really kills user experience.
Can we write a filter to meet above conditions? Please advice me how to deal with this in any other way if possible?
A common pattern is to fake it, the idea works like this:
For the user making the comment, as soon as they enter a comment show it in the topic as if it was added normally. Then start the async call to your cloud function and update the status based on the result.
You might choose to do nothing with the confirmation, or do something like iOS Messages app that shows a "Delivered" tag.
If the cloud function comes back with an error because the topic was closed, update the message to highlight that it was rejected (strikethrough is appropriate here) and disable the ability to add more comments.
This gives the illusion of speed in a delayed system.
I have a data model which is sort of like this simplified drawing:
alt text http://dl.dropbox.com/u/545670/thedatamodel.png
It's a little weird, but the idea is that the app manages multiple accounts/identities a person may have into a single messaging system. Each account is associated with one user on the system, and each message could potentially be seen/sent-to multiple accounts (but they have a globally unique ID hence the messageID property which is used on import to fetch message objects that may have already been downloaded and imported by a prior session).
The app is used from a per-account point of view - what I mean is that you choose which account you want to use, then you see the messages and stuff from that account's point of view in your window. So I have the messages attached to the account so that I can easily get the messages that should be shown using a fetch like this:
fetch.fetchPredicate = [NSPredicate predicateWithFormat:#"%# IN accounts", theAccount];
fetch.sortDescriptors = [NSArray arrayWithObject:[[NSSortDescriptor alloc] initWithKey:#"date" ascending:NO]];
fetch.fetchLimit = 20;
This seems like the right way to set this up in that the messages are shared between accounts and if a message is marked as read by one, I want it seen as being read by the other and so on.
Anyway, after all this setup, the big problem is that memory usage seems to get a little crazy. When I setup a test case where it's importing hundreds of messages into the system, and periodically re-fetching (using the fetch mentioned above) and showing them in a list (only the last 20 are referenced by the list), memory just gets crazy. 60MB.. 70MB... 100MB.. etc.
I tracked it down to the many-to-many relation between Account and Message. Even with garbage collection on, the managed objects are still being referenced strongly by the account's messages relationship property. I know this because I put a log in the finalize of my Message instance and never see it - but if I periodically reset the context or do refreshObject:mergeChanges: on the account object, I see the finalize messages and memory usage stays pretty consistent (although still growing somewhat, but considering I'm importing stuff, that's to be expected). The problem is that I can't really reset the context or the account object all the time because that really messes up observers that are observing other attributes of the account object!
I might just be modeling this wrong or thinking about it wrong, but I keep reading over and over that it's important to think of Core Data as an object graph and not a database. I think I've done that here, but it seems to be causing trouble. What should I do?
Use the Object Graph instrument. It'll tell you all of the ownerships keeping an object alive.
Have you read the section of the docs on this topic?