I am using Java EWS API in my web application to connect my application to MS Exchange and read user email requests. Also I am using a scheduler to pull subscription every 1 minute.
Problem is when I start my application, EWS-API works fine. It gets all new mails and processes it. But after few days, whenever the scheduler tries to pull the subscription inbox, the application throws the following error :
microsoft.exchange.webservices.data.ServiceResponseException: The specified subscription was not found.
Maybe it is thread issue or memory issue, I am not sure. Please suggest any reason for this issue.
Have a look at this article, the Client Access Server affinity issue it describes maybe what you are encountering.
http://blogs.msdn.com/b/exchangedev/archive/2011/07/20/client-access-server-affinity-and-network-load-balancing-considerations-for-programmatic-access-to-exchange-online.aspx
Supposedly if you use the EWS Java version 1.1 library (or later) you shouldn't get this particular issue however.
So I'd try checking your EWS library version, and if you still get the problem, add retry logic into your app to recreate the subscription when you encounter this error.
I have been using EWS Push subscription since 2017 so not sure if below might help or not but if you can share your code I can check and see if I can found something.
For Push Subscription I have seen many different errors and to avoid any issues I am using an Object Pool of connection and if I encounter any random error from Exchange Server, I discard current connection and create a new one which mostly solve these kind of issues.
Also you can try setting anchor mailbox while establishing connection it helps with some of the issues.
Also if you can share some sample code I am happy to check.
Related
we have a Restful web service created using Jersey and running on TomEE 7.0.3
we are using Android platform for client-side and it's using Retrofit for having communication with the server.
our system is modular and contains more than 14 parts.
about 3 weeks (until now), sometimes the clients getting too many follow-up requests as the response.
we searched for it in here and retrofit issues in github.
they said that it might be server falt so we trace the request with ngrep command on the server.
we saw that server was getting the request and also responding to it correctly even when clients get follow-up.
we also test this matter with different networks and this matter still remains.
so what else could cause this problem?
after several tests, we realized that this error is only on Android platforms (we tested the APIs with Postman when Android platforms were receiving Too many follow up request.
so after some more tests, we found out, when Android platforms get 408 as a response code they show this message. we changed the status code and this problem fixed.
I put this issue on square/okhttp repository in github and they put the bug flag on it.
you can see it here
---- update ----
they said it fixed in OkHttp v3.10
Long story short, I'm an intern in an IT company. I have a specific task assigned to me, basically it's a simple REST-based application that receives JSON's, processes them and stores them in the database.
I was assigned a new task, to add a functionality to send those processed JSONs in an e-mail.
Simple, right? I took a glance at Spring-Mail documentation, looked at some tutorials, and 40 minutes later my application was sending beautiful e-mails through throwaway gmail account.
But it turns out, that I actually have to use the company's Exchange service.
Thankfully there's an EWS API that provides all the necessary functionalities for that... right? Well, there's a catch. SMTP in the company is completely disabled, and I have a hard time configuring the application.
When I tried configuring the application like it's suggested through EWS wiki I did encounter some problems.
ExchangeService service = new ExchangeService();
ExchangeCredentials credentials = new WebCredentials("emailAddress", "password");
service.setCredentials(credentials);
That's pretty self explainatory.
However, the hard part begins here:
service.autodiscoverUrl("<your_email_address>");
This just doesn't work, even with the overloaded constructor (that includes RedirectionUrlCallback) which is recommended. I've tried multiple combinations, but nothing works.
You can also enter this address manually, but where do I get it from?
In my company Outlook I've found some links, that could be fitting, like:
https://autodiscover.COMPANY.com/EWS/Exchange.asmx
It however just doesn't work. When i enter this link in my browser is says that a service was created, another link that ends with /EWS/Services.wsdl is created, and it says that I should process it with SvcUtil.exe - honestly I have no idea what does it even mean, it's my first time I'm using the exchange and mailing APIs.
Where do I even go from here, do you have any tips? Should I try spring integration? What am I doing wrong? I'm feeling pretty down after wasting 7 hours on just trying to connect to the freaking mailbox, any help will be appreciated.
Not sure if it's relevant, but the Exchange version is 2016 CU4.
I want to monitor firebase client connections from my java server.
I have found a lot of examples on how to use onDisconnect from the client side (iOS), and it works great.
But is it possible to monitor client connections from a java server using the java server sdk? I simply want my server to know about user disconnects, but without the client having to 'tell' the firebase database that it has connected/disconnected.
The reason for this is mostly security, and a wish to trust the client as little as possible to do important tasks. Ideally most of my data should be 'read only' from the client, except for some 'write only' request queues consumed by the java server.
From the firebase java server documentation: https://firebase.google.com/docs/reference/serverreference/com/google/firebase/database/OnDisconnect
The OnDisconnect class is used to manage operations that will be run
on the server when this client disconnects. It can be used to add or
remove data based on a client's connection status. It is very useful
in applications looking for 'presence' functionality.
It seems like what I want to do is possible and supported, but I'm having a hard time figuring out how to make my server monitor 100-1000 connections realtime.
Lets say I'm monitoring a database reference that I know clients are monitoring. In that case none of the options to 'remove on disconnect' or to 'set on disconnect' are useful.
Thanks a lot for reading this, I'm REALLY loving firebase right now, just a few more issues to figure out :-) Also sorry for my english, I'm not a native speaker.
I've been through different questions about this topic, however, none of them have cleared my doubts on the best approach notifying the client side of a server-client IM app.
The Problem:
The whole problem is how to notify the client application of updates. I've alread seen the following approaches:
Clients keeps checking for updates: From time to time, client app performs a check in the server to see if there are updates for that specific user;
Problem: it is not performatic at all. Suppose you have one million users and each one of them checks for new updates every second. Serve would have to deal with one million requests per second. Wont work.
Client app opens a socket: The client app opens a socket and sends its address to the server. Server, by its turn, persists this information and connects to the socket whenever it needs to notify the client of some update.
Problem: Often the client will be connected to a NAT, so, the IP it has access to is in a non-visible range. In order to send messages to this client, a port forwarding in the NAT would have to be configured, which can't be done.
Despite of the technology, I think this approach will always be used, however, I have no idea how the problem described above can be solved.
Google Cloud Message (GCM): use the GCM service to notify the client of any update. Problem: It does't seems right to use a third server to handle the IM and it raises concerns about the scalability of the system. When the number of messages and users increases exponentially, it seems that the service will go down. Despite that, it seems that passing the information for two servers before delivering to the targets just adds bottlenecks in the process.
A combination of 2 and 3: uses GCM to reach the client when the last persist addres is no longer available.
Problem: same as described in 2
XMPP: I've seen many answers indicating the use of XMPP for IM applications, however, XMPP is a protocol - as per what I've foun in the web. I don't see how it can solve the problem described in 2 for instance.
Given the options above, can someone indicate me what line should I try to go for? Which one of these approaches has the best chances of success?
Thank y'all in advanced.
Use Google Cloud Messaging. Opposing to what you stated this service is built to scale to billions of users it will generally not introduce performance bottlenecks.
What you basically want to do is to use the messaging service to wake up devices. If you insist you can then still use your client server approach and thus your own protocol to have the client lookup new messages from the backend.
I have an XPages app using Java backend that tries to access mail databases via session.getDatabase("foo", "bar"). My script is only to collect all mail files that the logged in user is able to access (caught via try-catch). But there is one issue:
If the server the script will be executed is not able to reach the other server the well known error message will occur in the log. The message doesn't come from the JVM so it is not caught by my try-catch so far.
Is there a way to suppress this message? It is okay for me not to connect to that databases but I don't wanna get this message on the console.
In production environment I cannot assure that the server has a connection document set up so if I cannot reach it, I'm fine with it.
Any ideas appreciated :)
I strongly believe that the feature you are requesting Oliver is not possible.
The fact that you do not "generate/catch" the message in the JVM is due to the fact that the message is fired by the Notes engine itself (the core) and the JVM just hooks on it.
I have tried the NSPingServer C API as well to simulate your request and see if it would have not generated the error in the log but no luck there as well.
This is part of the core engine and any call you might do using standard LN functions will trigger this message.
If you have direct access to the servers (so no passthrugh) you might try to test if the port is reachable (via sockets) but this is way far too complicated in relation to the actual problem we are talking about.
I hope this helps in some way.
Cheers
Maurizio