Thanks Tom.
I think there's are some naming inconsitencies which are causing a problem.
From what I can tell:
Your embedded GemFire instance is running on 10.50.38.205.
The locator sees this system as 'ccnscupadsgf01', however, I don't think that the embedded GF system knows itself by this name. Could this be the case? What does 'hostname' report on the embedded system?
These lines, in your logs, lead me to this conclusion:
locator.log:[info 2013/01/30 19:09:31.491 EST <main> tid=0x1] Initializing region _monitoringRegion_idcprdgflocator1(5733locator)49616
locator.log:[info 2013/01/30 19:09:48.543 EST <pool-1-thread-1> tid=0x35] Initializing region _monitoringRegion_ccnscupadsgf01(7967)<v1>29066
locator.log:[info 2013/01/30 19:09:48.703 EST <pool-1-thread-1> tid=0x35] Initializing region _notificationRegion_ccnscupadsgf01(7967)<v1>29066
gemfire-udf.log:[info 2013/01/30 19:08:13.080 EST <pool-2-thread-1> tid=0xe] Initializing region _monitoringRegion_10.50.38.205(7967)<v1>29066
gemfire-udf.log:[info 2013/01/30 19:08:13.298 EST <pool-2-thread-1> tid=0xe] Initializing region PdxTypes
gemfire-udf.log:[info 2013/01/30 19:08:15.273 EST <pool-2-thread-1> tid=0xe] Initializing region AsyncEventQueue_answerDataSourceRegionAsyncEventQueue_SERIAL_GATEWAY_SENDER_QUEUE
gemfire-udf.log:[info 2013/01/30 19:08:15.394 EST <pool-2-thread-1> tid=0xe] Initializing region __PRThe monitoring/management framework uses these _monitoringRegion/_notificationRegion regions. A pair of each of these regions is created between the management node (locator in this case) and the remote system and they obviously need to have consistent names across systems for events to be correctly propagated.
--Jens