Merge pull request #116822 from spelluru/ehubpartition0528

Fixed the statement

Author: PRMerger10

articles/event-hubs/event-processor-balance-partition-load.md

@@ -11,7 +11,7 @@ ms.devlang: na
 ms.topic: conceptual
 ms.tgt_pltfrm: na
 ms.workload: na
-ms.date: 01/16/2020
+ms.date: 05/28/2020
 ms.author: shvija 
 
 ---
@@ -41,7 +41,7 @@ When designing the consumer in a distributed environment, the scenario must hand
 
 ## Event processor or consumer client
 
-You don't need to build your own solution to meet these requirements. The Azure Event Hubs SDKs provide this functionality. In .NET or Java SDKs, you use an event processor client (EventProcessorClient), and in Python and Java Script SDKs, you use EventHubConsumerClient. In the old version of SDK, it was the event processor host (EventProcessorHost) that supported these features.
+You don't need to build your own solution to meet these requirements. The Azure Event Hubs SDKs provide this functionality. In .NET or Java SDKs, you use an event processor client (EventProcessorClient), and in Python and JavaScript SDKs, you use EventHubConsumerClient. In the old version of SDK, it was the event processor host (EventProcessorHost) that supported these features.
 
 For the majority of production scenarios, we recommend that you use the event processor client for reading and processing events. The processor client is intended to provide a robust experience for processing events across all partitions of an event hub in a performant and fault tolerant manner while providing a means to checkpoint its progress. Event processor clients are also capable of working cooperatively within the context of a consumer group for a given event hub. Clients will automatically manage distribution and balancing of work as instances become available or unavailable for the group.
 
@@ -51,7 +51,7 @@ An event processor instance typically owns and processes events from one or more
 
 Each event processor is given a unique identifier and claims ownership of partitions by adding or updating an entry in a checkpoint store. All event processor instances communicate with this store periodically to update its own processing state as well as to learn about other active instances. This data is then used to balance the load among the active processors. New instances can join the processing pool to scale up. When instances go down, either due to failures or to scale down, partition ownership is gracefully transferred to other active processors.
 
-Partition ownership records in the checkpoint store keeps track of Event Hubs namespace,  event hub name, consumer group, event processor identifier (also known as owner), partition id and the last modified time.
+Partition ownership records in the checkpoint store keep track of Event Hubs namespace,  event hub name, consumer group, event processor identifier (also known as owner), partition ID and the last modified time.
 
 
 
@@ -89,7 +89,7 @@ When the checkpoint is performed to mark an event as processed, an entry in chec
 
 ## Thread safety and processor instances
 
-By default, event processor or consumer is thread safe and behaves in a synchronous manner. When events arrive for a partition, the function that processes the events is called. Subsequent messages and calls to this function queue up behind the scenes as the message pump continues to run in the background on other threads. This thread safety removes the need for thread-safe collections and dramatically increases performance.
+By default, the function that processes the events is called sequentially for a given partition. Subsequent events and calls to this function from the same partition queue up behind the scenes as the event pump continues to run in the background on other threads. Note that events from different partitions can be processed concurrently and any shared state that is accessed across partitions have to be synchronized.
 
 ## Next steps
 See the following quick starts: