I need to integrate outlook corporate emails in CRM. For this is use java EWS API.
I read microsoft documentation of EWS but I still have some questions, maybe someone can help.
First I need to connect with ExchangeService
ExchangeService service = new ExchangeService(ExchangeVersion.Exchange2010_SP2)
ExchangeCredentials credentials = new WebCredentials(email, password)
service.setCredentials(credentials)
service.autodiscoverUrl(email, new RedirectionUrlCallback())
For this connection to be established takes about 5 seconds, it is pretty much for a real time application. I'm ok to create this connection only one time and then reuse it but as I read ExchangeService is not thread safe, so I need to create a connection to send an email, then close the connection, then create again a new connection when I need to subscribe for notifications etc. Please tell me if there is another approach to deal with exchange service connection.
Bwt I tried to reuse the exchange service connection and I get this
microsoft.exchange.webservices.data.core.exception.service.remote.ServiceRequestException: The request failed. Connection is still allocated
Another question is about streaming subscription that enables client applications to discover events that occur in the Exchange store, I think this is the right fit method for me
StreamingSubscriptionConnection conn = new StreamingSubscriptionConnection(service, 30);
conn.addSubscription(subscription);
conn.addOnNotificationEvent(new SubscriptionConnectionListener());
conn.addOnDisconnect(this);
conn.open();
So first I need the connection to the ExchangeService to be opened, and then I need to open the SubscriptionConnection. Because SubscriptionConnectionListener should wait all the time for new events I don't close the connection. Connection expiry after 30 minutes. I can catch the expiry connection and opened again. How to deal with that when 1000 users have opened subscription connections with their exchange service, basically if the subscription connection remain opened for new events also the exchange service connection used for subscription should stay alive.
This are my concerns, maybe some are because I never deal with this things before. Please help.
Thanks in advanced
Related
Im using an MQTTSN Gateway Version 1.2 from;
https://github.com/simon622/mqtt-sn
I notice that a when a client connection goes to sleep and then subsequently wakes up, its IP address may well have changed on the network. When the next PINGREQ message is sent by a client, the gateway is unable to establish its identity from the network address and so the session simply times out.
Is there anyway of updating the network address in this scenario to tie it back to the original session without having the overhead of a new CONNECT?
I tried issuing a new PINGREQ, but the gateway was unable to link the new network address to an existing gateway session.
You're correct in stating that a client may well recycle their IP address during a network event (ie. a network stack power down, or roaming between cells on a cellular network). These events typically require a completely new CONNECT to be issued in order to re-authenticate with a gateway, since typically in SN UDP implementations, the network address is used as part of the identification mechanism. You can CONNECT(clean=false) to maintain session state.
Allowing a client to re-establish (or bind to an existing) session using a PINGREQ alone (with the presence of a clientId) would be very insecure and would present an easy attack vector for session hijacking.
Hope this helps clarify things.
In my Java application I am using the failover transport to connect to a local ActiveMQ broker:
failover:(tcp://0.0.0.0:61616)
I create one single connection that I reuse in the rest of the application:
ActiveMQConnection connection = (ActiveMQConnection) connectionFactory.createConnection();
In another part of the application when I receive some external call I need to send a message to the broker, and so, for doing that I create a new "Session":
Session locSession = connection.createSession(false, Session.AUTO_ACKNOWLEDGE);
When the broker is down my app tries to reconnect to the broker forever (this is the expected behavior I really want to have).
However, the problem is that if the broker is down and I receive a call that invokes the code that executes the connection.createSession(false, Session.AUTO_ACKNOWLEDGE) then my app hangs forever on this line of code waiting for the app to reconnect successfully to the broker and then create the session.
Please, do you know any way to check before I execute createSession if the connection object is trying to reconnect or it is really connected? If I am able to know this I could avoid the creation of the session if the app is not connected to the broker (only trying to reconnect) and therefore I would avoid to hanging on connection.createSession forever (I would raise an exception).
I wasn't able to find any property or method on ActiveMQConnection to gather this information.
The failover: url provides a setting startupMaxReconnectAttempts to prevent infinite retry when connecting to the broker the first time.
Also note-- If you want an exception to bubble up, that conflicts with requirement to have infinite retry. You would need to adjust the failover settings to match your intended behavior, by setting a max count or max time to perform retry, then throw an exception and unblock your caller.
For example, you could indicate you only want to retry for 5 minutes, then receive an exception to handle in the code to prevent the infinite blocking.
Thank you all for your help and suggestions. They helped me a lot in re-focusing the problem.
However I f found the answer to my question using the method "getTransport().isConnected()".
In our java mail (using Java Mail API) application we first connect to the mail server, fetch messages, process headers and then afterwards process the message bodies and attachments using pop3 as usual.
Session session = Session.getInstance(props, null);
Store store = session.getStore(urln);
store.connect();
Folder f = store.getFolder("INBOX");
f.open(READ);
Messages m = f.getMessages(..);
for (Message m : messages) {
if (!store.isConnected()) {
//raise exception
}
processSubject();
processFrom();
processBodyAndAttachments();
..
}
The implementation works fine on most environments, but on some customer the storeconnection gets lost during the process in the for loop. We can see the raises exception in the logs. My questions:
AFAIK, the mail server can sometimes reject new connections, but does
it terminate current living connections (may be becasue of too much
connections or disconnects old ones to give access to the new ones?)
When the store is disconnected, does the folder gets closed too?
Is it better to check the folder?
The connection may be lost everywhere in the for loop and it does not
seem to be a good practise to put isConnected check everywhere in the
loop, it will make the code dirty and also cause performance issues,
is it a good practise to put in a try catch block and check for
IOExceptions? (Folder closed) Or other suggestions? Which exceptions
should be handled? There may be some cases where the message is not
parseable but connection is healthy.
What about adding a disconnect listener?
Network connections can be broken for a variety of reasons. Your program always has to be prepared for the connection to drop at any time.
With POP3, there is only one connection, so if the connection is dropped the store should be disconnected and the folder should be closed.
If the Folder is open, check the Folder. Otherwise check the Store.
You need a strategy for handling failures. If you keep track of what messages have been successfully processed you may be able to restart the processing at the next message after a failure. A lot of the details depend on your environment and your application requirements.
A disconnect listener won't make this easier.
I am developing a chat server through netty websocket. Our client side is mostly browser based.
What's happening is, when I refresh the browser it closes the websocket connection and losses everything and creates a new socket when browser is loaded again.
Is there any mechanism which shall reconnect with my previous websocket session at server side.
I am planning to cache all user session and if received any connection close event from client side then without deleting user session information waiting more 30-60s,in between if server receive new connection request from same client(detecting through cookies id) then replacing by new session information.
My problem is if I do not remove session when server receive connection close event , other read/write operation through this session's channel creating problem.
What I can understand from following is
My problem is if I do not remove session when server receive connection close event , other read/write operation through this session's channel creating problem.
Your chat logic is tightly coupled with the channel/channel handler object.
If you can move the chat logic to a separate class which I call "Session" and have onEventXXX callbacks in that class and have chat logic on top of it (separate chain of classes may be), when there is a write operation, write the message using session.write(...). The "Session" have to delegate it to the underlying channel.
When the underlying channel is closed, you can keep the "Session" object for while and reattach with it's new channel.
To do this you might need to create a separate Netty handler called "SessionHandler" and process channel events/session creation.
I am trying to create a client socket connection, when a new request is created a connection is established & data transfer takes place. Is there any way that once the Connection is created it will be open for all time ? If yes then how can create it & also how can I identify what request is sent & got the response for the same request?
Looking forward for your response.
You can create a connection for all time, by not closing it. However the trick is detecting when a connection has failed. e.g. the client/server has restarted.
If you want to match requests to responses you can use a request id, but a much simpler approach is to only send one request at a time per socket, that way the response you get is for the request you just sent. You can use more than one socket in a thread if this is required.