You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
* Update Apache Proton-J dependency (0.29.0 --> 0.31.0) (#407)
* PartitionReceiver - add a method that provides an EventPosition which corresponds to an EventData returned last by the receiver (#408)
* Support IsPartitionEmpty property for PartitionRuntimeInformation (#399)
* Move setPrefetchCount API to the ReceiverOptions class from the PartitionReceiver and update the settings of Default & Max Prefetch count (#410)
This pull request includes two major changes related to Prefetch API.
1) Move setPrefetchCount API to the ReceiverOptions class so that prefetch value specified by a user can be used instead of using default value when communicating to the service during link open and initializing a receiver. This change also addresses the receiver stuck issue caused by setPrefetchAPI in a race condition.
2) Change the default value and set the upper bound of the prefetch count. Note that prefetch count should be greater than or equal to maxEventCount which can be set when either a) calling receive() API or b) implementing the getMaxEventCount API of the SessionReceiverHandler interface.
* Fixes several issues in the reactor related components (#411)
This pull request contains the following changes.
1) Finish pending tasks when recreating the reactor and make sure pending calls scheduled on the old reactor get complete.
2) Fix the session open timeout issue which can result in NPE in proton-J engine.
3) Make session open timeout configurable and use the value of OperationTimeout.
4) Update the message of exceptions and include an entity name in the exception message.
5) API change - use ScheduledExecutorService.
6) Improve tracing.
* Implement comparable on EventData (#395)
* Update receive/send link creation logic and improve tracing (#414)
* Prep for releasing client 2.0.0 and EPH 2.2.0 (#415)
* Ensure that links are closed when transport error occurrs (#417)
* ensure links are recreated on transport/connection failure
* update API document for EventProcessorOptions class
* add traces for link create/close case
* Prep for releasing client 2.1.0 and EPH 2.3.0 (#418)
* Update prefetch sendflow logic and increment version for new release (#420)
* Fix args for proxy auth call to Authenticator (#421)
* Prepare EPH 2.3.4 release (#423)
* Prepare EPH 2.4.0 release (#423) (#424)
* Handle proton:io errors with meaningful error msg (#427)
* Handle proton:io errors with meaningful error msg
* Use Proton-supplied message if present
* Minor changes to lease scanner (#428)
* Add logging if the scanner threw an exception.
* Change logging level to warn when scanner shuts down for any reason.
* Scanner can call EventProcessorOptions.notifyOfException, which calls user code. Change notifyOfException to defensively catch any exceptions coming out of user code.
* Make EventData.SystemProperties completely public (#435)
Porting testability changes from .NET Core to Java: provide full access to EventData's SystemProperties so that a complete EventData can be fabricated in tests.
* Digest Support: init first connection with null headers (#431)
Related to Azure/qpid-proton-j-extensions#10
* Fix lease scanner issues when Storage unreachable (#434)
This fix is for issue #432. There are two parts:
AzureStorageCheckpointLeaseManager performs certain Storage actions within a forEach. If those actions fail, the StorageException gets wrapped in a NoSuchElementException. Catch those and strip off the NoSuchElementException, then handle the StorageException in the existing way.
The unexpected NoSuchElementExceptions were not being caught anywhere and the scanner thread was dying without rescheduling itself. Added code in PartitionMananger.scan to catch any exceptions that leak out of PartitionScanner and reschedule the scanner unless the host instance is shutting down.
* message receiver - fix null pointer error and ensure that receive link is recreated upon a failure (#439)
* message receiver/sender - fix null pointer error and ensure that receive/send link is recreated on a failure.
* Update version numbers for release (#440)
* Update prefetch count for a receiver (#441)
* Fix an issue of creating multiple sessions for $management & $cbs channel for a single connection and improve logging (#443)
* Fix an issue of creating multiple sessions for $management & $cbs for a connection and improve logging
* Update version numbers for new release (#444)
* Update spotbugs.xml report versions
# Publishing Events with the Java client for Azure Event Hubs
1
+
# Publishing Events with the Java client for Azure Event Hubs
2
2
3
-
The vast majority of Event Hub applications using this and the other client libraries are and will be event publishers.
3
+
The vast majority of Event Hub applications using this and the other client libraries are and will be event publishers.
4
4
And for most of these publishers, publishing events is extremely simple and handled with just a few API gestures.
5
5
6
6
## Getting Started
7
7
8
8
This library is available for use in Maven projects from the Maven Central Repository, and can be referenced using the
9
-
following dependency declaration inside of your Maven project file:
9
+
following dependency declaration inside of your Maven project file:
10
10
11
11
```XML
12
12
<dependency>
13
-
<groupId>com.microsoft.azure</groupId>
13
+
<groupId>com.microsoft.azure</groupId>
14
14
<artifactId>azure-eventhubs</artifactId>
15
-
<version>2.3.0</version>
15
+
<version>2.3.1</version>
16
16
</dependency>
17
17
```
18
-
19
-
For different types of build environments, the latest released JAR files can also be [explicitly obtained from the
20
-
Maven Central Repository](https://search.maven.org/#search%7Cga%7C1%7Ca%3A%22azure-eventhubs%22) or from [the Release distribution point on GitHub](https://github.com/Azure/azure-event-hubs/releases).
18
+
19
+
For different types of build environments, the latest released JAR files can also be [explicitly obtained from the
20
+
Maven Central Repository](https://search.maven.org/#search%7Cga%7C1%7Ca%3A%22azure-eventhubs%22) or from [the Release distribution point on GitHub](https://github.com/Azure/azure-event-hubs/releases).
21
+
22
+
23
+
For a simple event publisher, you'll need to import the *com.microsoft.azure.eventhubs* package for the Event Hub client classes.
21
24
22
25
23
-
For a simple event publisher, you'll need to import the *com.microsoft.azure.eventhubs* package for the Event Hub client classes.
24
-
25
-
26
26
```Java
27
27
importcom.microsoft.azure.eventhubs.*;
28
28
```
29
29
30
-
Event Hubs client library uses qpid proton reactor framework which exposes AMQP connection and message delivery related
30
+
Event Hubs client library uses qpid proton reactor framework which exposes AMQP connection and message delivery related
31
31
state transitions as reactive events. In the process,
32
32
the library will need to run many asynchronous tasks while sending and receiving messages to Event Hubs.
33
33
So, `EventHubClient` requires an instance of `Executor`, where all these tasks are run.
@@ -37,63 +37,63 @@ So, `EventHubClient` requires an instance of `Executor`, where all these tasks a
The entire client API is built for Java 8's concurrent task model, generally returning
60
+
61
+
The entire client API is built for Java 8's concurrent task model, generally returning
62
62
[*CompletableFuture<T>*](https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/CompletableFuture.html), so the library has these methods suffixed with *Sync* as their Synchronous counterparts/varaints.
63
63
64
64
## AMQP 1.0
65
65
Azure Event Hubs allows for publishing events using the HTTPS and AMQP 1.0 protocols. The Azure Event Hub endpoints
66
-
also support AMQP over the WebSocket protocol, allowing event traffic to leverage the same outbound TCP port as
67
-
HTTPS.
66
+
also support AMQP over the WebSocket protocol, allowing event traffic to leverage the same outbound TCP port as
67
+
HTTPS.
68
68
69
-
This client library is built on top of the [Apache Qpid Proton-J]() libraries and supports AMQP, which is significantly
70
-
more efficient at publishing event streams than HTTPS. AMQP 1.0 is an international standard published as ISO/IEC 19464:2014.
69
+
This client library is built on top of the [Apache Qpid Proton-J]() libraries and supports AMQP, which is significantly
70
+
more efficient at publishing event streams than HTTPS. AMQP 1.0 is an international standard published as ISO/IEC 19464:2014.
71
71
72
-
AMQP is session-oriented and sets up the required addressing information and authorization information just once for each
73
-
send link, while HTTPS requires doing so with each sent message. AMQP also has a compact binary format to express common
74
-
event properties, while HTTPS requires passing message metadata in a verbose text format. AMQP can also keep a significant
75
-
number of events "in flight" with asynchronous and robust acknowledgement flow, while HTTPS enforces a strict request-reply
72
+
AMQP is session-oriented and sets up the required addressing information and authorization information just once for each
73
+
send link, while HTTPS requires doing so with each sent message. AMQP also has a compact binary format to express common
74
+
event properties, while HTTPS requires passing message metadata in a verbose text format. AMQP can also keep a significant
75
+
number of events "in flight" with asynchronous and robust acknowledgement flow, while HTTPS enforces a strict request-reply
76
76
pattern.
77
77
78
-
AMQP 1.0 is a TCP based protocol. For Azure Event Hubs, all traffic *must* be protected using TLS (SSL) and is using
79
-
TCP port 5671.
78
+
AMQP 1.0 is a TCP based protocol. For Azure Event Hubs, all traffic *must* be protected using TLS (SSL) and is using
79
+
TCP port 5671.
80
80
81
81
This library will provide HTTPS support via WebSockets when Proton-J supports HTTPS.
82
82
83
83
## Connection Strings
84
84
85
85
Azure Event Hubs and Azure Service Bus share a common format for connection strings. A connection string holds all required
86
-
information to set up a connection with an Event Hub. The format is a simple property/value list of the form
87
-
{property}={value} with pairs separated by ampersands (&).
86
+
information to set up a connection with an Event Hub. The format is a simple property/value list of the form
87
+
{property}={value} with pairs separated by ampersands (&).
| Endpoint | URI for the Event Hubs namespace. Typically has the form *sb://{namespace}.servicebus.windows.net/*|
92
-
| EntityPath | Relative path of the Event Hub in the namespace. Commonly this is just the Event Hub name |
92
+
| EntityPath | Relative path of the Event Hub in the namespace. Commonly this is just the Event Hub name |
93
93
| SharedAccessKeyName | Name of a Shared Access Signature rule configured for the Event Hub or the Event Hub name. For publishers, the rule must include "Send" permissions. |
94
94
| SharedAccessKey | Base64-encoded value of the Shared Access Key for the rule |
95
95
| SharedAccessSignature | A previously issued Shared Access Signature token (not yet supported; will be soon) |
96
-
96
+
97
97
A connection string will therefore have the following form:
98
98
99
99
```
@@ -102,42 +102,42 @@ A connection string will therefore have the following form:
102
102
103
103
## Advanced Operations
104
104
105
-
The publisher example shown in the overview above sends an event into the Event Hub without further qualification. This is
106
-
the preferred and most flexible and reliable option. For specific needs, Event Hubs offers two extra options to
107
-
qualify send operations: Publisher policies and partion addressing.
105
+
The publisher example shown in the overview above sends an event into the Event Hub without further qualification. This is
106
+
the preferred and most flexible and reliable option. For specific needs, Event Hubs offers two extra options to
107
+
qualify send operations: Publisher policies and partion addressing.
108
108
109
109
### Partition Addressing
110
110
111
-
Any Event Hub's event store is split up into at least 4 partitions, each maintaining a separate event log. You can think
112
-
of partitions like lanes on a highway. The more events the Event Hub needs to handle, the more lanes (partitions) you have
113
-
to add. Each partition can handle at most the equivalent of 1 "throughput unit", equivalent to at most 1000 events per
111
+
Any Event Hub's event store is split up into at least 4 partitions, each maintaining a separate event log. You can think
112
+
of partitions like lanes on a highway. The more events the Event Hub needs to handle, the more lanes (partitions) you have
113
+
to add. Each partition can handle at most the equivalent of 1 "throughput unit", equivalent to at most 1000 events per
114
114
second and at most 1 Megabyte per second.
115
115
116
116
In some cases, publisher applications need to address partitions directly in order to pre-categorize events for consumption.
117
-
A partition is directly addressed either by using the partition's identifier or by using some string (partition key) that gets
117
+
A partition is directly addressed either by using the partition's identifier or by using some string (partition key) that gets
118
118
consistently hashed to a particular partition.
119
119
120
-
This capability, paired with a large number of partitions, may appear attractive for implementing a fine grained, per publisher
120
+
This capability, paired with a large number of partitions, may appear attractive for implementing a fine grained, per publisher
121
121
subscription scheme similar to what Topics offer in Service Bus Messaging - but it's not at all how the capability should be used
122
-
and it's likely not going to yield satisfying results.
123
-
124
-
Partition addressing is designed as a routing capability that consistently assigns events from the same sources to the same partition allowing
125
-
downstream consumer systems to be optimized, but under the assumption of very many of such sources (hundreds, thousands) share
126
-
the same partition. If you need fine-grained content-based routing, Service Bus Topics might be the better option.
122
+
and it's likely not going to yield satisfying results.
123
+
124
+
Partition addressing is designed as a routing capability that consistently assigns events from the same sources to the same partition allowing
125
+
downstream consumer systems to be optimized, but under the assumption of very many of such sources (hundreds, thousands) share
126
+
the same partition. If you need fine-grained content-based routing, Service Bus Topics might be the better option.
127
127
128
128
#### Using Partition Keys
129
129
130
130
Of the two addressing options, the preferable one is to let the hash algorithm map the event to the appropriate partition.
131
-
The gesture is a straightforward extra override to the send operation supplying the partition key:
131
+
The gesture is a straightforward extra override to the send operation supplying the partition key:
Copy file name to clipboardExpand all lines: eventhubs/data-plane/azure-eventhubs/src/main/java/com/microsoft/azure/eventhubs/ConnectionStringBuilder.java
Copy file name to clipboardExpand all lines: eventhubs/data-plane/azure-eventhubs/src/main/java/com/microsoft/azure/eventhubs/impl/ClientConstants.java
+1-1
Original file line number
Diff line number
Diff line change
@@ -37,7 +37,7 @@ public final class ClientConstants {
0 commit comments