Return-Path: X-Original-To: apmail-mina-users-archive@www.apache.org Delivered-To: apmail-mina-users-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 361C9EE4E for ; Fri, 15 Feb 2013 21:20:58 +0000 (UTC) Received: (qmail 21222 invoked by uid 500); 15 Feb 2013 21:20:57 -0000 Delivered-To: apmail-mina-users-archive@mina.apache.org Received: (qmail 21137 invoked by uid 500); 15 Feb 2013 21:20:57 -0000 Mailing-List: contact users-help@mina.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: users@mina.apache.org Delivered-To: mailing list users@mina.apache.org Received: (qmail 21126 invoked by uid 99); 15 Feb 2013 21:20:56 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 15 Feb 2013 21:20:56 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of r.cristian.ramirez@gmail.com designates 209.85.212.176 as permitted sender) Received: from [209.85.212.176] (HELO mail-wi0-f176.google.com) (209.85.212.176) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 15 Feb 2013 21:20:48 +0000 Received: by mail-wi0-f176.google.com with SMTP id hm14so1669847wib.3 for ; Fri, 15 Feb 2013 13:20:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=kb1naxqvBvulJm4sP4PBS3N1H4kUdoXl/+Bwc8Pm+Qg=; b=Ggdwf2pYW1F0pSTt0psTu77kvzh9pOHF3HeWM8qW1XLP3U31oDXUgjZPX/cJlWwCtw 8DGLxqS7fXfx8nI3v1JLIfUWAPV3vMCQ1BjZm8A04HgWdPIz+ro6Cfin/568lm/bcuGY PIYuITDcQHQGS+Tk54aQy/CtMvQymzI3WDYtw2zq0pkEKZEddMsSXGlXgxtftuPbIcy2 /1bQHhVhUwWzmK4sR+ILIGhqIVfqd4jlAYGxsQJD+5BG/yxalieBINfSuGSc8GuG4jpw R9lpe49pxJBTn8cL0gPURdIkIo6i8XWXfFi+ClUogmm0hb37B0Mdo2fzpR+8AZRmfQVk 2X3g== MIME-Version: 1.0 X-Received: by 10.195.13.200 with SMTP id fa8mr6980604wjd.15.1360963228495; Fri, 15 Feb 2013 13:20:28 -0800 (PST) Received: by 10.180.4.70 with HTTP; Fri, 15 Feb 2013 13:20:28 -0800 (PST) Date: Fri, 15 Feb 2013 23:20:28 +0200 Message-ID: Subject: Controlling lock operation inside the session.write() method From: Ricardo Cristian Ramirez To: users@mina.apache.org Content-Type: multipart/alternative; boundary=047d7bb04172c96fdc04d5c9f128 X-Virus-Checked: Checked by ClamAV on apache.org --047d7bb04172c96fdc04d5c9f128 Content-Type: text/plain; charset=ISO-8859-1 I have a client application which has a sending state. If sending state is enabled, this means client can send something to the server and if it is disabled, client can not send anything. Sending state is directed by server, i.e. server sends a message "sending_enabled" and client's state changes. And, when client's sending state is disabled, it should not send anything to the server. Currently, I have a mina client application whose connector is NioSocketConnector. On the client side, I use session.write() method for sending data. However, in order to achieve the above situation, I have to do some extra thing. Consider the below situation: check the client state before sending -> assume that sending is enabled, so we can send our data call session.write(...) -> code inside the write() method is being executed Now, assume that before locking the channel in the sender thread, it has lost the processor. Then, receiver thread takes the processor and got a message which says "sending_disabled". Hence, client's state is changed. When the sender thread takes the processor again, our message will be sent to the server without checking the client's state. However, that message should not send. Briefly, I want to make a check when the session.write() method locks the channel. Can I do this, how? --047d7bb04172c96fdc04d5c9f128--