I have an application that is creating StreamingSubscription (using EWS managed API) for many hundreds of room resource mailboxes in EXO, and I'm trying to make the code tolerant of a subscription going "bad" and needing to be re-created. Here's the behavior I'm seeing at the moment.
I first divide up the mailboxes into groups according to best practices, and then within each group:
I create a StreamingSubscription for each mailbox
I add all the subscriptions to a connection and open the connection
Some time passes, and the OnSubscriptionError event fires for
one subscription. At this point I find that the subscription in
question is no longer in the connection's CurrentSubscriptions
collection, but I'm able to identify which mailbox it was originally
for.
I then flag that mailbox so that the code will try to re-create its
subscription.
When the code tries to re-create the failed subscription, this error is thrown:
Request failed because EWS could not contact the appropriate CAS server for this request.
Thereafter, my code tries again once per minute to create that subscription, and that same error is thrown each time. This continues for as long as I allow it to run.
If I then stop my Windows service and start it again, all the subscriptions are created successfully, including that failed one.
Here's my question. Why is it able to successfully create the subscription after stopping and re-starting the service, but can't re-create it after the OnSubscriptionError?
Related
I see something like the following error while using azure event hub to send event message. But as I see in the azure portal, the metric shows that the event message is sent to the event hub. So I'm puzzled by what this error message means.
As I read from the azure doc (https://learn.microsoft.com/en-us/azure/event-hubs/event-hubs-amqp-troubleshoot), it said "You see the following error on the AMQP connection when all links in the connection have been closed because there was no activity (idle) and a new link hasn't been created in 5 minutes."
The doc also said "You can avoid them by making send/receive calls on the connection/link, which automatically recreates the connection/link."
What should be done regarding this error message ? As although the event message can be sent, I worry whether there may be any potential issue there.
" Error{condition=amqp:connection:forced, description='The connection was inactive for more than the allowed 300000 milliseconds and is closed by container 'LinkTracker'. TrackingId:00000000000000000000000000000000000_G21, SystemTracker:gateway5, Timestamp:2019-03-06T17:32:00', info=null} "
I once tried that if I call the close() method in EventHubProducerClient (by refer to sample code in https://learn.microsoft.com/en-us/azure/event-hubs/event-hubs-java-get-started-send), this error seems not appear again. However, if doing so, when every time need to send the event, it will mean need to create a new EventHubProducerClient. I'm not sure if this may create another problem (like time required to create the new EventHubProducerClient, and memory consumption) if creating a new EventHubProducerClient for every send event, as there can be many events to send.
On another search, I found in How to configure Producer.close() in Eventhub, that it is recommended to close the producer client after using it.
However, if the above error message is actually not an error, whether to close or not may not matter.
I have inherited from a colleague who left a system module that integrates with Exchange Online in Office 365. Essentially what this module does is interact with with the remote Exchange service via EWS Managed API; subscribe for push notifications on changes in a user's calendar.
Change events do get posted to our web service and that is fine. And based on the frequency parameter we defined, the status checks messages also get posted on expected intervals, as per description about the subscription keep-alive behaviour.
The problem is, in observation, the subscription does not perpetuate despite responding with SubscriptionStatusType.OK to keep it ongoing. We never send SubscriptionStatusType.Unsubscribe since there is no error condition found in notification in messages. It seems to only last 9 to 14 hours before the Exchange service stops sending any status checks or change notification messages. When we make subscriptions from two separate web servers (different notification callback URLs), their subscriptions seem to die out around the same time.
Haven't found any clues that would cause the Exchange service to cancel/expire our subscriptions. What other conditions might contribute to this premature unsubscribe?
Exchange will "lose" subscriptions on a fairly regular basis, especially in the O365 environment because mailboxes are continually being shuffled onto different servers in order to load balance the entire ecosystem. Even in an on-prem Exchange you can lose subscription if a CAS restarts. Unfortunately to build a reliable app, you have to check periodically that you heard from Exchange via some kind of notification or heartbeat.
I'm creating an application that downloads an attachment from an email that's automatically generated at midnight every night. The attachment is downloaded into a directory and from there is then parsed into a database.
The main problem with this is that the email generation takes time, so the actually delivery time is unknown. Instead of having a program running the entire time, waiting on it to arrive, it would be far more elegant to have it automatically run the service to download the attachment when the email drops in the inbox, much in the same way as a FileSystemWatcher works on local directories.
The email server runs Exchange 2003
Is there a way, programmatically or otherwise, to cause a service to run on receiving a new email?
Exchange has the ability to run event sinks when certain things occur on the server.
http://support.microsoft.com/kb/324021 shows an example of doing this to create a catchall email address.
Details of the exchange 2003 SDK are at: http://msdn.microsoft.com/en-us/library/ms986138(v=exchg.65).aspx
My workflow needs to wait for either an email approval via Bookmark or a WCF approval via Receive, so I used a Parallel activity. The email approval works just fine but I am trying to test the WCF and cant figure out what URL to use in WCF test client to access the Workflow.
I would be grateful for any leads because I am very new to WCF and am not very sure how to go about solving this problem.
You are using workflow service and then your second receive activity must be correlate with your first one and cancreateinstance check box set to false and service contract name is same as first one.
When you generate proxy for the workflow service, operation method is available for call from client.
You can refer this article
http://www.codeproject.com/Articles/50820/Establishing-Correlation-Between-Multiple-RECEIVE
I'm pretty new to MSMQ 4.0. I got stuck with below scenario;
Service A takes User Details and Returns an User ID.
Then Service B takes Billing detials with User ID.
Now I have to Queue these steps. I'm planning to use Transaction Queue.
Could some one please help me with
1)Get the ID from first message and include it in the second message.
2)If at least one step failed I have to rollback(transaction Queue does it for me) retry or 5 times and if it still failed then move it to VerifyAdminQueue for verification by Admin.I dont like using DeadLetter Queue etc.,
Thanks in advance.
Services built with MSMQ queues are truly one-way. This means that there is no built in concept of a response. There are many ways you can implement a request-response communication pattern using MSMQ but with all of them you will need to construct and send the response back to the caller yourself.
With one way actions, rollback is very simple, and indeed MSMQ will rollback any failed steps in the transmission of a message. More complex operations such as request-response however lack any concept of a transaction in MSMQ and so any rollback across more than one message transmission steps will require you to write compensatory code.