Open avromf opened 9 years ago
Btw, maybe it will be better to use PoolingHttpClientConnectionManager
instead of BasicHttpClientConnectionManager
.
I think the implementation of any streaming requests is quite broken at the moment. We switched to a BasicHttpClientConnectionManager
because the old implementation was leaking connections all over the place. I still think this change if fine, but for the streaming subs we need more than 1 connection, so it probably needs it's own connection manager (which would be a pooling one without any limits).
But another issue with the streaming subscriptions is the whole threading model. The current model (see HangingServiceRequestBase
) simply spawns it's own thread pool, starts a thread (and then immediately shuts down the thread pool), and will call the callbacks whenever any data is received (and not fully cleanup after itself). I don't think all users are aware of the extra threads being created, which may cause all kinds of multi-threading bugs.
Wouldn't it be better to create some await()
of select()
call to wait for a response to one or more subscriptions? In that case the developers can choose to handle the multi-threading themselves.
I've just dug a little bit in the networking part and.. it looks like it should be completely rewritten.
+1
What about using protected and factory methods like Spring does so devs can extend clases?
For example, instead of having
HttpClientConnectionManager httpConnectionManager = new BasicHttpClientConnectionManager(registry);
in ExchangeServiceBase.initializeHttpClient
you can have a
HttpClientConnectionManager httpConnectionManager = createHttpClientConnectionManager(registry);
where createHttpClientConnectionManager is a protected method that we can override.
I am basically struck at the same issue.
Unable to findItems(...) using the same service instance, I am getting "java.lang.IllegalStateException: Connection is still allocated".
Is there any work around (or) temporary fix for the same ?
@ganeshgowtham Make sure you are using the 2.0 release.
I am using version 2.0 as said.
Still facing problem, it works when we have code in sync block.
Connection is leaking and though i have disconnect on service via listener
I access to e-mails asynchronously but get the same error with version 2.0. I had to do that:
synchronized (this) { message = EmailMessage.bind(service, userItem.getId()); message.load(propertySet); }
However this breaks my async design. Any ideas?
@ganeshgowtham @kamaci Looking at what you both have said, you don't mention anywhere that you were trying to use streaming subscriptions. The original bug that I reported and later fixed was specifically for streaming subscriptions. If you are getting this error and are not using streaming subscriptions, then it maybe it is a separate issue.
I am using streaming subscription to get calendar events.
Side note I have another query, for every calendar event creation I am getting atleast 7-8 notification events.
In chaos which one to consume and which one to discard.
-- Thanks Ganesh Gowtham
On 29-May-2017 10:18 PM, "Avrom" notifications@github.com wrote:
@ganeshgowtham https://github.com/ganeshgowtham @kamaci https://github.com/kamaci Looking at what you both have said, you don't mention anywhere that you were trying to use streaming subscriptions. The original bug that I reported and later fixed was specifically for streaming subscriptions. If you are getting this error and are not using streaming subscriptions, then it maybe it is a separate issue.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/OfficeDev/ews-java-api/issues/276#issuecomment-304699514, or mute the thread https://github.com/notifications/unsubscribe-auth/ADTVb18V3NJcvgOo2XxD8BzQFTyvR7O6ks5r-vbCgaJpZM4D4k18 .
@ganeshgowtham Do you have some sample code for testing this?
@avromf I do not use streaming subscription. Is it a known bug that I should synchronize access to ExchangeService object?
@avromf OK I see that it is not thread safe: https://msdn.microsoft.com/en-us/library/microsoft.exchange.webservices.data.exchangeservice(v=exchg.80).aspx
Issue is still there in 2018. Happy 3 year anniversary (almost)!
Issue is fixed, this might be because of synchronization.
On Jan 26, 2018 11:25 PM, "Alexandre M. Reis" notifications@github.com wrote:
Issue is still there in 2018. Happy 3 year anniversary (almost)!
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/OfficeDev/ews-java-api/issues/276#issuecomment-360856710, or mute the thread https://github.com/notifications/unsubscribe-auth/ADTVbwU6_jJSI6pzX9GSE4AwJVB6CLekks5tOhGPgaJpZM4D4k18 .
For the following code:
I get the following error:
I should note that this used to work in the past.
Continuing with some tests on this, creating a separate ExchangeService object for sending the email works. However, the following code still does not work.
The line subscription.unsubscribe(); will still result in an "Connection is still allocated" error. Also, if I comment it out, the line conn.close(); hangs.