I'm working on integrated an application with Exchange using EWS Java. Yes, it's not officially supported, I know. It's all pretty straightforward and I have streaming notifications set up with the exchange server. However, I've hit a couple of snags that are a bit head-scratching.
First, it seems that every event (or batch of events) gets sent twice. For example, if I'm watching the Calendar for Modified events and I create a new appointment or modify an appointment, I'll get two identical notifications, each with an ItemEvent and a FolderEvent. They're definitely distinct objects coming in one right after the other and there is zero difference between the two events. Each object has the same value in any relevant field as the previous. The only difference seems to be the memory address.
Second, I'm hoping to make the notifications a bit more fine-grained. I want to see when a calendar item has been modified, but not when a calendar item is created. It appears that I can only watch the Calendar folder overall and that Modified includes new items. Is there any way to make that more precise?
EDIT: Actually, I found that this only seems to happen with Meetings created in the Calendar folder, and only those with other Attendees. Two NotificationEventArgs, each with a FolderEvent and an ItemEvent. On further inspection, I recently found that one ItemEvent is Created and one is Modified, which isn't terribly surprising to me now knowing how Exchange tends to handle Appointments. The idea was to watch for both created and modified items, although I suppose it could have been broken up into two streaming subscriptions or, given the behavior, set to only modified as that would have captured "new" Appointments anyway.
In any case, this was handled with a periodic SyncFolder (Much was changed between the asking of this and the final design), which worked out well in the end.
Although I dont have experience of working on EWS in Java, Ill try to answer your questions as the concept remains the same. My code references will be from C#
For the first part, the behavior you are experiencing is the expected behavior. When you subscribe to a folder, you get notified on any event that you have specified while creating the subscription takes place. Thus if you have subscribed to the "Calendar" folder for Modified and Create events, and you create or modify an appointment, you will get 2 notifications:
1 for the Folder level changes (FolderEvent): even if you create a new item, the folder has actually been "modified"
1 for the Item level changes (ItemEvent): for the created item
These two are NOT same. They may look similar as both inherit from "NotificationEvent" base class, but are different types.
http://msdn.microsoft.com/en-us/library/office/microsoft.exchange.webservices.data.folderevent(v=exchg.80).aspx
http://msdn.microsoft.com/en-us/library/office/microsoft.exchange.webservices.data.itemevent(v=exchg.80).aspx
For the second part, to see only modified events, select only "EventType.Modified" when you are creating the subscription. It would be good if you can share your code snippet to show how you are subscribing.
Related
I'm looking to see if this problem is feasible. I want to create an Android app that allows a user to enable Do Not Disturb for every event in user-specified calendars. I've already looked into the AlarmManager class, and it does not seem to work for this purpose. A single AlarmManager instance would work for one half of one event (turning Do Not Disturb On). Another AlarmManager instance would be required to turn Do Not Disturb off. This would have to repeat for every event (which is variable) in the specified calendars. Is there an easier approach to this, or am I looking at this problem all wrong? I know that this has been done in stock Android, but it only works for one calendar at a time. If there is a better solution to this, could you point me toward the proper Android SDK classes? I do not need a code example. Thanks.
I need some help with some modification of https://github.com/playframework/play-java-websocket-example.
This example based on own Source for given Stock ID. Every Source generate new stock value in some time interval:
public Source<StockUpdate, NotUsed> update() {
return source.throttle(1, duration, 1, ThrottleMode.shaping())
.map(sq -> new StockUpdate(sq.symbol, sq.price));
}
The example in much part is what I need (the "watch/unwatch" stocks idea) so I want to use it in very similiar way but I don't want to fake stock quote time interval generator in my app because I'm connected to real, one stock exchange source.
I read messages (in other part of my app) via java.io.InputStream and, for now, I put them in java.util.Queue (java.util.concurrent.LinkedBlockingQueue) via queue.offer(message) and now I want to get it somehow from Stock.update() (however I don't know it's best place).
So far I got know that I could use for example Source.queue(BUFFER_LENGTH, OverflowStrategy.backpressure()), but it doesn't have any reference to (my) queue.
I also know that I could use Source.queue(BUFFER_LENGTH, OverflowStrategy.backpressure()).to(...).run(...).offer(...) but unfortunatelly I don't know how to connect it in UserActor.addStock(Stock) with Flow, UniqueKillSwitch, etc.
Maybe someone needed modifications like me and could give some hints?
So far I got know that I could use for example Source.queue(BUFFER_LENGTH, OverflowStrategy.backpressure()), but it doesn't have any reference to (my) queue
You could change your code so it uses the Source.queue instead of the java.util.Queue. Alternatively you could have a thread to read from your queue and push it to the Source.queue.
I'm looking for something similar to RemovalListener/RemovalNotification - but notification of when values in the cache are modified. Notification would include the old value, as well as the new value that has just been added.
[update]
I only populate the cache via a CaceLoader (load & reload). The "source" of the cached elements are at times flakey (remote to the cache).
So the two primary reason for having the replacement element as well are:
Debug logging to indicate when/what values are actually retrieved
from the remote source. This one could be accomplished in a class
that does the remote retrieval.
Generate difference that can then be proactively pushed to (remote)
clients. e.g. publishing changes via blazeDS, rather than requiring
the clients to continuously "get".
It should be possible to implement this without additional notification via the reload method, and getting the current cache contents before going off and getting the new value, and then comparing the new value and the previous value - and then taking additional action. I was looking for a more generic way to decouple the modification notification.
Thanks.
You could file a Guava feature request asking for a method to be added to RemovalNotification that would return the replacement value when the cause is REPLACED. But please provide as much detail as possible about your problem and why this is a good solution for it.
I need to implement a WatchList class as a part of a Java client-server app. WL is essentially an array of Items, each of which has a timestamp. I am responsible for for the client side of the app. The WL might be updated on the client side manually, i.e. new elements can be added to it. It can also be modified with a regularly schedule update from the server. Similarly, regular uploads are also performed with the terms that had been added manually being sent to the server.
Since I am fairly new to Java, I need advice on what built-in instruments (classes) I should use to implement this WL class. It will obviously be some type of sorted structure with a custom comparator that would compare dates. I will probably also want to maintain it in a newest-items-first order so that I could quickly retrieve the newest items to send to the server. In which case the item that will be received during a download from the server will be added to the beginning of the list rather than at the end. Or keeping it in the newest-items-last order is just as efficient?
Thanks much!
Newest first or newest last, it's a purely functional choice. The comparator of one is just the inverse of the comparator of the other.
You'll need to understand the classes of the collections framework.
I wouldn't keep unsaved schedules at client side. If the client crashes, you lose all the unsaved items. Why don't you simply call the server each time an item is created at client-side?
We are developing a vehicle tracking system. Like every VTS, we have GPS devices fitted into the vehicles which keep sending location information to the server. On server, our TCP communicator process keeps reading that data and saves it into the database
Now, we need to check for some set of rule to trigger alerts for the vehicles, e.g We need alert when vehicle reaches to a particular location, if vehicle crosses specific speed-limit,etc.
Can you please suggest the best way to implement it?
We have thought of some ways to implement it,
1. Our TCP communicator, when receives the location, should check for the alerts.
2. There will be a process which will keep running every 15 minutes and check the location details in that 15 minutes for alerts.
I am looking for the suggestions to implement it, logic-wise as well as technology-wise. e.g. Whether we should use Drools or not?, etc.
Somebody from FedEx actually presented something like this in a JavaOne conference I attended a couple of years back.
Basically, the idea was, yes, using Drools Expert + Fusion to perform CEP (complex events processing) on vehicle location data.
As far as I can recall, a vehicle would periodically (every couple of seconds even) send its GPS coordinates to the engine (an event) which would then be digested by the rules engine, and depending on the rules could trigger certain actions such as raising alerts ("vehicle is stalled" or "out of course") or sending notifications ("vehicle will arrive at destination in ~15 minutes").
(Google for "drools fusion cep vehicle tracking" uncovers this presentation which should give you few more details or at least provide some insight.)
the way Drools work, is that you fill in alot of objects into the "Working Memory" of Drools. While you fill in the objects, Drools will find out which rules "fires" on the objects and stores the objects in a Rete-Tree. When you are finished putting the objects in the memory and you fire all rules, Drools will process the code you wrote corresponding to the rule.
I would suggest, that you make an object with all the data recieved from the vehicle necessary for your rules and put it in the working memory.
In Drools you should make many small rules, each just checking one thing and acting on the result.
It is not a good practice to let Drools get data needed for evaluation, but I can't see any problems in letting Drools trigger some events, that send messages to a vehicle or some other system. (I guess that should happen async, so that you don't slow down Drools) In fact, Drools offers you to hook up an eventlistener.
There's no reason to run every 15 minutes. That will introduce delay in the triggers and also result in bursts of load every 15 minutes followed be periods of no load.
You can have a flag in your database for new alert rules and new location data. When you scan for events, you can use a two-pass approach. Check all new rules against all location data and mark them no longer new. Then check all new location data against existing rules and mark them no longer new.
You can run this as often as you like. Ideally, you wouldn't wait that long because the longer you wait, the more work you accumulate.
As for having the TCP communicator check for relevant alerts over the scan the database periodically approach, the main advantage would be alerts would be immediate. The disadvantage would be that alert processing would slow down the TCP communicator path and you would be locked into a "one update means one check for alerts" model.
In the "scan the database" approach, if load gets too high, you can wind up checking for alerts only on every so many updates from high-frequency update sources. This naturally deals with load by reducing the amount of work needed, but it could result in a missed alert.
I think all the approaches you're considering will work fine.