Hi all, we saw that in MB 3.1.0, for several scenarios (ex: 10KB messages, with compression enabled) servers went OOM half way to 1M messages[1]. Please note that this happens with default flow control settings.
AFAIU this is what happened. 1. With MySQL, database was the overall bottleneck in both compression and non-compression scenarios. 2. MSSQL is faster than MySQL and with compression enabled DB is not the bottleneck anymore in inbound message flow. Compression was taking more execution time than db read/writes. Therefore, compression logic becomes the bottleneck in MSSQL scenario. 3. In "contentChunckHandler" (which compress chunks if compression enabled) has executed before[2] "messagePreprocessor" which has the flow control logic[3] implemented. Therefore, lag in compression has not counted in flow control logic. This leads inbound path accept messages from publishers more than server can handle. 4. This might have lead to the OOM. WDYT? [1] https://wso2.org/jira/browse/MB-1683 [2] https://github.com/wso2/andes/blob/v3.1.0/modules/andes-core/broker/src/main/java/org/wso2/andes/kernel/disruptor/inbound/InboundEventManager.java#L154 [3] https://github.com/wso2/andes/blob/v3.1.0/modules/andes-core/broker/src/main/java/org/wso2/andes/kernel/disruptor/inbound/MessagePreProcessor.java#L148 Thanks, -- Pumudu Ruhunage Software Engineer | WSO2 Inc http://wso2.com
_______________________________________________ Dev mailing list Dev@wso2.org http://wso2.org/cgi-bin/mailman/listinfo/dev
