[jira] [Updated] (SSHD-119) [PATCH] more specific docstring for Command interface
[ https://issues.apache.org/jira/browse/SSHD-119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bobby Powers updated SSHD-119: -- Attachment: (was: 0001-Command-update-javadoc-for-start-to-be-more-specific.patch) > [PATCH] more specific docstring for Command interface > - > > Key: SSHD-119 > URL: https://issues.apache.org/jira/browse/SSHD-119 > Project: MINA SSHD > Issue Type: Improvement >Reporter: Bobby Powers >Priority: Minor > Attachments: > 0001-Command-update-javadoc-for-start-to-be-more-specific.patch > > > attached is an updated docstring based on Baldur Norddahl's comments. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (SSHD-119) [PATCH] more specific docstring for Command interface
[ https://issues.apache.org/jira/browse/SSHD-119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bobby Powers updated SSHD-119: -- Attachment: 0001-Command-update-javadoc-for-start-to-be-more-specific.patch > [PATCH] more specific docstring for Command interface > - > > Key: SSHD-119 > URL: https://issues.apache.org/jira/browse/SSHD-119 > Project: MINA SSHD > Issue Type: Improvement >Reporter: Bobby Powers >Priority: Minor > Attachments: > 0001-Command-update-javadoc-for-start-to-be-more-specific.patch > > > attached is an updated docstring based on Baldur Norddahl's comments. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (SSHD-119) [PATCH] more specific docstring for Command interface
[ https://issues.apache.org/jira/browse/SSHD-119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bobby Powers updated SSHD-119: -- Attachment: 0001-Command-update-javadoc-for-start-to-be-more-specific.patch > [PATCH] more specific docstring for Command interface > - > > Key: SSHD-119 > URL: https://issues.apache.org/jira/browse/SSHD-119 > Project: MINA SSHD > Issue Type: Improvement >Reporter: Bobby Powers >Priority: Minor > Attachments: > 0001-Command-update-javadoc-for-start-to-be-more-specific.patch > > > attached is an updated docstring based on Baldur Norddahl's comments. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (SSHD-119) [PATCH] more specific docstring for Command interface
[PATCH] more specific docstring for Command interface - Key: SSHD-119 URL: https://issues.apache.org/jira/browse/SSHD-119 Project: MINA SSHD Issue Type: Improvement Reporter: Bobby Powers Priority: Minor Attachments: 0001-Command-update-javadoc-for-start-to-be-more-specific.patch attached is an updated docstring based on Baldur Norddahl's comments. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [MINA 3] Session write queue
After a second (third ?) thought, sounds like trying to have only one queue per IoProcessor is not really a good idea. It brings little, and cost a lot. Let's get back to one session/one writing queue. Thanks for the good feedback, Steve ! -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
[jira] [Commented] (SSHD-118) uploading and then renaming a file doesn't work (on windows)
[
https://issues.apache.org/jira/browse/SSHD-118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13021164#comment-13021164
]
Otto Frost commented on SSHD-118:
-
Added fix for the real problem in the description
Tested with cygwin openssh sftp client, works ok.
Tested with ftptosftp bridge in mindterm 3.4 (3.1.2 not working for other
reasons)
> uploading and then renaming a file doesn't work (on windows)
>
>
> Key: SSHD-118
> URL: https://issues.apache.org/jira/browse/SSHD-118
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 0.5.0
> Environment: windows xp professional sun jdk 1.5.0.22, jre 1.6
> windows 2003 server SP2 sun jdk jre 1.5.0.22
>Reporter: Otto Frost
>Priority: Critical
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> I logon, and then
> put xx xx
> rename xx yy
> O1706@WKE198515 ~
> $ sftp -oport= a@localhost
> Connecting to localhost...
> a@localhost's password:
> sftp> cd tmp
> sftp> put xx
> Uploading xx to /C:/NWDS7.1EHP1/workspace/minasshd_custom/tmp/xx
> xx100% 1039 1.0KB/s 00:00
> sftp> rename xx yy
> Couldn't rename file "/C:/NWDS7.1EHP1/workspace/minasshd_custom/tmp/xx" to
> "/C:/
> NWDS7.1EHP1/workspace/minasshd_custom/tmp/yy": Failure
> sftp>
> The problem is that the file isn't closed after uploading,
> SftpSubSystem.process SSH_FXP_WRITE
> NativeSshFile.createOutputStream doesn't close the file, even though the
> close method is called.
> I can't rename the file from the os either because mina sshd holds it locked
> after upload. When mina sshd is shut down I can rename the file. After
> restarting minasshd the file can be renamed (from mina sshd or from the os).
> Here is the correction:
> class NativeSshFile
> public void truncate() throws IOException {
> // modification
> // permission check
> // and close the raf
> if (!isWritable()) {
> throw new IOException("No write permission : " +
> file.getName());
> }
> RandomAccessFile raf = new RandomAccessFile(file, "rw");
> if (raf != null) {
> raf.setLength(0);
> raf.close();
> }
> }
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (SSHD-118) uploading and then renaming a file doesn't work (on windows)
[
https://issues.apache.org/jira/browse/SSHD-118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Otto Frost updated SSHD-118:
Description:
I logon, and then
put xx xx
rename xx yy
O1706@WKE198515 ~
$ sftp -oport= a@localhost
Connecting to localhost...
a@localhost's password:
sftp> cd tmp
sftp> put xx
Uploading xx to /C:/NWDS7.1EHP1/workspace/minasshd_custom/tmp/xx
xx100% 1039 1.0KB/s 00:00
sftp> rename xx yy
Couldn't rename file "/C:/NWDS7.1EHP1/workspace/minasshd_custom/tmp/xx" to "/C:/
NWDS7.1EHP1/workspace/minasshd_custom/tmp/yy": Failure
sftp>
The problem is that the file isn't closed after uploading,
SftpSubSystem.process SSH_FXP_WRITE
NativeSshFile.createOutputStream doesn't close the file, even though the close
method is called.
I can't rename the file from the os either because mina sshd holds it locked
after upload. When mina sshd is shut down I can rename the file. After
restarting minasshd the file can be renamed (from mina sshd or from the os).
Here is the fix:
class NativeSshFile
public void truncate() throws IOException {
// modification
// permission check
// and close the raf
if (!isWritable()) {
throw new IOException("No write permission : " +
file.getName());
}
RandomAccessFile raf = new RandomAccessFile(file, "rw");
if (raf != null) {
raf.setLength(0);
raf.close();
}
}
was:
I logon, and then
put xx xx
rename xx yy
O1706@WKE198515 ~
$ sftp -oport= a@localhost
Connecting to localhost...
a@localhost's password:
sftp> cd tmp
sftp> put xx
Uploading xx to /C:/NWDS7.1EHP1/workspace/minasshd_custom/tmp/xx
xx100% 1039 1.0KB/s 00:00
sftp> rename xx yy
Couldn't rename file "/C:/NWDS7.1EHP1/workspace/minasshd_custom/tmp/xx" to "/C:/
NWDS7.1EHP1/workspace/minasshd_custom/tmp/yy": Failure
sftp>
The problem is that the file isn't closed after uploading,
SftpSubSystem.process SSH_FXP_WRITE
NativeSshFile.createOutputStream doesn't close the file, even though the close
method is called.
I can't rename the file from the os either because mina sshd holds it locked
after upload. When mina sshd is shut down I can rename the file. After
restarting minasshd the file can be renamed (from mina sshd or from the os).
Here is the fix:
class NativeSshFile
public void truncate() throws IOException {
// e.on modification
// permission check
// and close the raf
if (!isWritable()) {
throw new IOException("No write permission : " +
file.getName());
}
RandomAccessFile raf = new RandomAccessFile(file, "rw");
if (raf != null) {
raf.setLength(0);
raf.close();
}
}
> uploading and then renaming a file doesn't work (on windows)
>
>
> Key: SSHD-118
> URL: https://issues.apache.org/jira/browse/SSHD-118
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 0.5.0
> Environment: windows xp professional sun jdk 1.5.0.22, jre 1.6
> windows 2003 server SP2 sun jdk jre 1.5.0.22
>Reporter: Otto Frost
>Priority: Critical
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> I logon, and then
> put xx xx
> rename xx yy
> O1706@WKE198515 ~
> $ sftp -oport= a@localhost
> Connecting to localhost...
> a@localhost's password:
> sftp> cd tmp
> sftp> put xx
> Uploading xx to /C:/NWDS7.1EHP1/workspace/minasshd_custom/tmp/xx
> xx100% 1039 1.0KB/s 00:00
> sftp> rename xx yy
> Couldn't rename file "/C:/NWDS7.1EHP1/workspace/minasshd_custom/tmp/xx" to
> "/C:/
> NWDS7.1EHP1/workspace/minasshd_custom/tmp/yy": Failure
> sftp>
> The problem is that the file isn't closed after uploading,
> SftpSubSystem.process SSH_FXP_WRITE
> NativeSshFile.createOutputStream doesn't close the file, even though the
> close method is called.
> I can't rename the file from the os either because mina sshd holds it locked
> after upload. When mina sshd is shut down I can rename the file. After
> restarting minasshd the file can be renamed (from mina sshd or from the os).
> Here is the fix:
> class NativeSshFile
> public void truncate() throws IOException {
> // modification
> // permission check
> // and close the raf
> if (!isWritable()) {
> throw new IOException("No write permission : " +
> file.getName());
> }
> RandomAccessFile r
[jira] [Updated] (SSHD-118) uploading and then renaming a file doesn't work (on windows)
[
https://issues.apache.org/jira/browse/SSHD-118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Otto Frost updated SSHD-118:
Description:
I logon, and then
put xx xx
rename xx yy
O1706@WKE198515 ~
$ sftp -oport= a@localhost
Connecting to localhost...
a@localhost's password:
sftp> cd tmp
sftp> put xx
Uploading xx to /C:/NWDS7.1EHP1/workspace/minasshd_custom/tmp/xx
xx100% 1039 1.0KB/s 00:00
sftp> rename xx yy
Couldn't rename file "/C:/NWDS7.1EHP1/workspace/minasshd_custom/tmp/xx" to "/C:/
NWDS7.1EHP1/workspace/minasshd_custom/tmp/yy": Failure
sftp>
The problem is that the file isn't closed after uploading,
SftpSubSystem.process SSH_FXP_WRITE
NativeSshFile.createOutputStream doesn't close the file, even though the close
method is called.
I can't rename the file from the os either because mina sshd holds it locked
after upload. When mina sshd is shut down I can rename the file. After
restarting minasshd the file can be renamed (from mina sshd or from the os).
Here is the correction:
class NativeSshFile
public void truncate() throws IOException {
// modification
// permission check
// and close the raf
if (!isWritable()) {
throw new IOException("No write permission : " +
file.getName());
}
RandomAccessFile raf = new RandomAccessFile(file, "rw");
if (raf != null) {
raf.setLength(0);
raf.close();
}
}
was:
I logon, and then
put xx xx
rename xx yy
O1706@WKE198515 ~
$ sftp -oport= a@localhost
Connecting to localhost...
a@localhost's password:
sftp> cd tmp
sftp> put xx
Uploading xx to /C:/NWDS7.1EHP1/workspace/minasshd_custom/tmp/xx
xx100% 1039 1.0KB/s 00:00
sftp> rename xx yy
Couldn't rename file "/C:/NWDS7.1EHP1/workspace/minasshd_custom/tmp/xx" to "/C:/
NWDS7.1EHP1/workspace/minasshd_custom/tmp/yy": Failure
sftp>
The problem is that the file isn't closed after uploading,
SftpSubSystem.process SSH_FXP_WRITE
NativeSshFile.createOutputStream doesn't close the file, even though the close
method is called.
I can't rename the file from the os either because mina sshd holds it locked
after upload. When mina sshd is shut down I can rename the file. After
restarting minasshd the file can be renamed (from mina sshd or from the os).
Here is the fix:
class NativeSshFile
public void truncate() throws IOException {
// modification
// permission check
// and close the raf
if (!isWritable()) {
throw new IOException("No write permission : " +
file.getName());
}
RandomAccessFile raf = new RandomAccessFile(file, "rw");
if (raf != null) {
raf.setLength(0);
raf.close();
}
}
> uploading and then renaming a file doesn't work (on windows)
>
>
> Key: SSHD-118
> URL: https://issues.apache.org/jira/browse/SSHD-118
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 0.5.0
> Environment: windows xp professional sun jdk 1.5.0.22, jre 1.6
> windows 2003 server SP2 sun jdk jre 1.5.0.22
>Reporter: Otto Frost
>Priority: Critical
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> I logon, and then
> put xx xx
> rename xx yy
> O1706@WKE198515 ~
> $ sftp -oport= a@localhost
> Connecting to localhost...
> a@localhost's password:
> sftp> cd tmp
> sftp> put xx
> Uploading xx to /C:/NWDS7.1EHP1/workspace/minasshd_custom/tmp/xx
> xx100% 1039 1.0KB/s 00:00
> sftp> rename xx yy
> Couldn't rename file "/C:/NWDS7.1EHP1/workspace/minasshd_custom/tmp/xx" to
> "/C:/
> NWDS7.1EHP1/workspace/minasshd_custom/tmp/yy": Failure
> sftp>
> The problem is that the file isn't closed after uploading,
> SftpSubSystem.process SSH_FXP_WRITE
> NativeSshFile.createOutputStream doesn't close the file, even though the
> close method is called.
> I can't rename the file from the os either because mina sshd holds it locked
> after upload. When mina sshd is shut down I can rename the file. After
> restarting minasshd the file can be renamed (from mina sshd or from the os).
> Here is the correction:
> class NativeSshFile
> public void truncate() throws IOException {
> // modification
> // permission check
> // and close the raf
> if (!isWritable()) {
> throw new IOException("No write permission : " +
> file.getName());
> }
> RandomAcc
[jira] [Commented] (SSHD-118) uploading and then renaming a file doesn't work (on windows)
[
https://issues.apache.org/jira/browse/SSHD-118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13021155#comment-13021155
]
Otto Frost commented on SSHD-118:
-
if (raf!=null)
raf.close();
I'm rather safe than sorry. Don't know under which conditions, but in my
experience it usually dumps if the file failed to open.
Added fix for the real problem in the description
> uploading and then renaming a file doesn't work (on windows)
>
>
> Key: SSHD-118
> URL: https://issues.apache.org/jira/browse/SSHD-118
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 0.5.0
> Environment: windows xp professional sun jdk 1.5.0.22, jre 1.6
> windows 2003 server SP2 sun jdk jre 1.5.0.22
>Reporter: Otto Frost
>Priority: Critical
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> I logon, and then
> put xx xx
> rename xx yy
> O1706@WKE198515 ~
> $ sftp -oport= a@localhost
> Connecting to localhost...
> a@localhost's password:
> sftp> cd tmp
> sftp> put xx
> Uploading xx to /C:/NWDS7.1EHP1/workspace/minasshd_custom/tmp/xx
> xx100% 1039 1.0KB/s 00:00
> sftp> rename xx yy
> Couldn't rename file "/C:/NWDS7.1EHP1/workspace/minasshd_custom/tmp/xx" to
> "/C:/
> NWDS7.1EHP1/workspace/minasshd_custom/tmp/yy": Failure
> sftp>
> The problem is that the file isn't closed after uploading,
> SftpSubSystem.process SSH_FXP_WRITE
> NativeSshFile.createOutputStream doesn't close the file, even though the
> close method is called.
> I can't rename the file from the os either because mina sshd holds it locked
> after upload. When mina sshd is shut down I can rename the file. After
> restarting minasshd the file can be renamed (from mina sshd or from the os).
> Here is the fix:
> class NativeSshFile
> public void truncate() throws IOException {
> // e.on modification
> // permission check
> // and close the raf
> if (!isWritable()) {
> throw new IOException("No write permission : " +
> file.getName());
> }
> RandomAccessFile raf = new RandomAccessFile(file, "rw");
> if (raf != null) {
> raf.setLength(0);
> raf.close();
> }
> }
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (SSHD-118) uploading and then renaming a file doesn't work (on windows)
[
https://issues.apache.org/jira/browse/SSHD-118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Otto Frost updated SSHD-118:
Description:
I logon, and then
put xx xx
rename xx yy
O1706@WKE198515 ~
$ sftp -oport= a@localhost
Connecting to localhost...
a@localhost's password:
sftp> cd tmp
sftp> put xx
Uploading xx to /C:/NWDS7.1EHP1/workspace/minasshd_custom/tmp/xx
xx100% 1039 1.0KB/s 00:00
sftp> rename xx yy
Couldn't rename file "/C:/NWDS7.1EHP1/workspace/minasshd_custom/tmp/xx" to "/C:/
NWDS7.1EHP1/workspace/minasshd_custom/tmp/yy": Failure
sftp>
The problem is that the file isn't closed after uploading,
SftpSubSystem.process SSH_FXP_WRITE
NativeSshFile.createOutputStream doesn't close the file, even though the close
method is called.
I can't rename the file from the os either because mina sshd holds it locked
after upload. When mina sshd is shut down I can rename the file. After
restarting minasshd the file can be renamed (from mina sshd or from the os).
Here is the fix:
class NativeSshFile
public void truncate() throws IOException {
// e.on modification
// permission check
// and close the raf
if (!isWritable()) {
throw new IOException("No write permission : " +
file.getName());
}
RandomAccessFile raf = new RandomAccessFile(file, "rw");
if (raf != null) {
raf.setLength(0);
raf.close();
}
}
was:
I logon, and then
put xx xx
rename xx yy
O1706@WKE198515 ~
$ sftp -oport= a@localhost
Connecting to localhost...
a@localhost's password:
sftp> cd tmp
sftp> put xx
Uploading xx to /C:/NWDS7.1EHP1/workspace/minasshd_custom/tmp/xx
xx100% 1039 1.0KB/s 00:00
sftp> rename xx yy
Couldn't rename file "/C:/NWDS7.1EHP1/workspace/minasshd_custom/tmp/xx" to "/C:/
NWDS7.1EHP1/workspace/minasshd_custom/tmp/yy": Failure
sftp>
The problem is that the file isn't closed after uploading,
SftpSubSystem.process SSH_FXP_WRITE
NativeSshFile.createOutputStream doesn't close the file, even though the close
method is called.
I can't rename the file from the os either because mina sshd holds it locked
after upload. When mina sshd is shut down I can rename the file. After
restarting minasshd the file can be renamed (from mina sshd or from the os).
Here is the fix:
class NativeSshFile
public void truncate() throws IOException{
RandomAccessFile raf = new RandomAccessFile(file, "rw");
raf.setLength(0);
raf.close();
}
> uploading and then renaming a file doesn't work (on windows)
>
>
> Key: SSHD-118
> URL: https://issues.apache.org/jira/browse/SSHD-118
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 0.5.0
> Environment: windows xp professional sun jdk 1.5.0.22, jre 1.6
> windows 2003 server SP2 sun jdk jre 1.5.0.22
>Reporter: Otto Frost
>Priority: Critical
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> I logon, and then
> put xx xx
> rename xx yy
> O1706@WKE198515 ~
> $ sftp -oport= a@localhost
> Connecting to localhost...
> a@localhost's password:
> sftp> cd tmp
> sftp> put xx
> Uploading xx to /C:/NWDS7.1EHP1/workspace/minasshd_custom/tmp/xx
> xx100% 1039 1.0KB/s 00:00
> sftp> rename xx yy
> Couldn't rename file "/C:/NWDS7.1EHP1/workspace/minasshd_custom/tmp/xx" to
> "/C:/
> NWDS7.1EHP1/workspace/minasshd_custom/tmp/yy": Failure
> sftp>
> The problem is that the file isn't closed after uploading,
> SftpSubSystem.process SSH_FXP_WRITE
> NativeSshFile.createOutputStream doesn't close the file, even though the
> close method is called.
> I can't rename the file from the os either because mina sshd holds it locked
> after upload. When mina sshd is shut down I can rename the file. After
> restarting minasshd the file can be renamed (from mina sshd or from the os).
> Here is the fix:
> class NativeSshFile
> public void truncate() throws IOException {
> // e.on modification
> // permission check
> // and close the raf
> if (!isWritable()) {
> throw new IOException("No write permission : " +
> file.getName());
> }
> RandomAccessFile raf = new RandomAccessFile(file, "rw");
> if (raf != null) {
> raf.setLength(0);
> raf.close();
> }
> }
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (SSHD-118) uploading and then renaming a file doesn't work (on windows)
[
https://issues.apache.org/jira/browse/SSHD-118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Otto Frost updated SSHD-118:
Description:
I logon, and then
put xx xx
rename xx yy
O1706@WKE198515 ~
$ sftp -oport= a@localhost
Connecting to localhost...
a@localhost's password:
sftp> cd tmp
sftp> put xx
Uploading xx to /C:/NWDS7.1EHP1/workspace/minasshd_custom/tmp/xx
xx100% 1039 1.0KB/s 00:00
sftp> rename xx yy
Couldn't rename file "/C:/NWDS7.1EHP1/workspace/minasshd_custom/tmp/xx" to "/C:/
NWDS7.1EHP1/workspace/minasshd_custom/tmp/yy": Failure
sftp>
The problem is that the file isn't closed after uploading,
SftpSubSystem.process SSH_FXP_WRITE
NativeSshFile.createOutputStream doesn't close the file, even though the close
method is called.
I can't rename the file from the os either because mina sshd holds it locked
after upload. When mina sshd is shut down I can rename the file. After
restarting minasshd the file can be renamed (from mina sshd or from the os).
Here is the fix:
class NativeSshFile
public void truncate() throws IOException{
RandomAccessFile raf = new RandomAccessFile(file, "rw");
raf.setLength(0);
raf.close();
}
was:
I logon, and then
put xx xx
rename xx yy
O1706@WKE198515 ~
$ sftp -oport= a@localhost
Connecting to localhost...
a@localhost's password:
sftp> cd tmp
sftp> put xx
Uploading xx to /C:/NWDS7.1EHP1/workspace/minasshd_custom/tmp/xx
xx100% 1039 1.0KB/s 00:00
sftp> rename xx yy
Couldn't rename file "/C:/NWDS7.1EHP1/workspace/minasshd_custom/tmp/xx" to "/C:/
NWDS7.1EHP1/workspace/minasshd_custom/tmp/yy": Failure
sftp>
The problem is that the file isn't closed after uploading,
SftpSubSystem.process SSH_FXP_WRITE
NativeSshFile.createOutputStream doesn't close the file, even though the close
method is called.
I can't rename the file from the os either because mina sshd holds it locked
after upload. When mina sshd is shut down I can rename the file. After
restarting minasshd the file can be renamed (from mina sshd or from the os).
Remaining Estimate: 1h (was: 2h)
Original Estimate: 1h (was: 2h)
> uploading and then renaming a file doesn't work (on windows)
>
>
> Key: SSHD-118
> URL: https://issues.apache.org/jira/browse/SSHD-118
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 0.5.0
> Environment: windows xp professional sun jdk 1.5.0.22, jre 1.6
> windows 2003 server SP2 sun jdk jre 1.5.0.22
>Reporter: Otto Frost
>Priority: Critical
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> I logon, and then
> put xx xx
> rename xx yy
> O1706@WKE198515 ~
> $ sftp -oport= a@localhost
> Connecting to localhost...
> a@localhost's password:
> sftp> cd tmp
> sftp> put xx
> Uploading xx to /C:/NWDS7.1EHP1/workspace/minasshd_custom/tmp/xx
> xx100% 1039 1.0KB/s 00:00
> sftp> rename xx yy
> Couldn't rename file "/C:/NWDS7.1EHP1/workspace/minasshd_custom/tmp/xx" to
> "/C:/
> NWDS7.1EHP1/workspace/minasshd_custom/tmp/yy": Failure
> sftp>
> The problem is that the file isn't closed after uploading,
> SftpSubSystem.process SSH_FXP_WRITE
> NativeSshFile.createOutputStream doesn't close the file, even though the
> close method is called.
> I can't rename the file from the os either because mina sshd holds it locked
> after upload. When mina sshd is shut down I can rename the file. After
> restarting minasshd the file can be renamed (from mina sshd or from the os).
> Here is the fix:
> class NativeSshFile
> public void truncate() throws IOException{
>
> RandomAccessFile raf = new RandomAccessFile(file, "rw");
> raf.setLength(0);
> raf.close();
> }
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SSHD-118) uploading and then renaming a file doesn't work (on windows)
[ https://issues.apache.org/jira/browse/SSHD-118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13021112#comment-13021112 ] Bobby Powers commented on SSHD-118: --- do you mean on line 383 of NativeSshFile? Under what condition could raf be null? Does that fix the issue for you? > uploading and then renaming a file doesn't work (on windows) > > > Key: SSHD-118 > URL: https://issues.apache.org/jira/browse/SSHD-118 > Project: MINA SSHD > Issue Type: Bug >Affects Versions: 0.5.0 > Environment: windows xp professional sun jdk 1.5.0.22, jre 1.6 > windows 2003 server SP2 sun jdk jre 1.5.0.22 >Reporter: Otto Frost >Priority: Critical > Original Estimate: 2h > Remaining Estimate: 2h > > I logon, and then > put xx xx > rename xx yy > O1706@WKE198515 ~ > $ sftp -oport= a@localhost > Connecting to localhost... > a@localhost's password: > sftp> cd tmp > sftp> put xx > Uploading xx to /C:/NWDS7.1EHP1/workspace/minasshd_custom/tmp/xx > xx100% 1039 1.0KB/s 00:00 > sftp> rename xx yy > Couldn't rename file "/C:/NWDS7.1EHP1/workspace/minasshd_custom/tmp/xx" to > "/C:/ > NWDS7.1EHP1/workspace/minasshd_custom/tmp/yy": Failure > sftp> > The problem is that the file isn't closed after uploading, > SftpSubSystem.process SSH_FXP_WRITE > NativeSshFile.createOutputStream doesn't close the file, even though the > close method is called. > I can't rename the file from the os either because mina sshd holds it locked > after upload. When mina sshd is shut down I can rename the file. After > restarting minasshd the file can be renamed (from mina sshd or from the os). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (SSHD-118) uploading and then renaming a file doesn't work (on windows)
[ https://issues.apache.org/jira/browse/SSHD-118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Otto Frost updated SSHD-118: Environment: windows xp professional sun jdk 1.5.0.22, jre 1.6 windows 2003 server SP2 sun jdk jre 1.5.0.22 was: windows xp professional jdk 1.5.0.22, jre 1.6 windows 2003 server SP2 jdk jre 1.5.0.22 > uploading and then renaming a file doesn't work (on windows) > > > Key: SSHD-118 > URL: https://issues.apache.org/jira/browse/SSHD-118 > Project: MINA SSHD > Issue Type: Bug >Affects Versions: 0.5.0 > Environment: windows xp professional sun jdk 1.5.0.22, jre 1.6 > windows 2003 server SP2 sun jdk jre 1.5.0.22 >Reporter: Otto Frost >Priority: Critical > Original Estimate: 2h > Remaining Estimate: 2h > > I logon, and then > put xx xx > rename xx yy > O1706@WKE198515 ~ > $ sftp -oport= a@localhost > Connecting to localhost... > a@localhost's password: > sftp> cd tmp > sftp> put xx > Uploading xx to /C:/NWDS7.1EHP1/workspace/minasshd_custom/tmp/xx > xx100% 1039 1.0KB/s 00:00 > sftp> rename xx yy > Couldn't rename file "/C:/NWDS7.1EHP1/workspace/minasshd_custom/tmp/xx" to > "/C:/ > NWDS7.1EHP1/workspace/minasshd_custom/tmp/yy": Failure > sftp> > The problem is that the file isn't closed after uploading, > SftpSubSystem.process SSH_FXP_WRITE > NativeSshFile.createOutputStream doesn't close the file, even though the > close method is called. > I can't rename the file from the os either because mina sshd holds it locked > after upload. When mina sshd is shut down I can rename the file. After > restarting minasshd the file can be renamed (from mina sshd or from the os). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SSHD-118) uploading and then renaming a file doesn't work (on windows)
[ https://issues.apache.org/jira/browse/SSHD-118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13021105#comment-13021105 ] Bobby Powers commented on SSHD-118: --- This is interesting, I think I've seen the same thing on one of our servers although I haven't had time to track it down. On first look, we seem to be trying to do the right thing, in SSH_FXP_WRITE we wrap the outputstream.write() with try finally that closes the stream. The close method is even overwritten to close the stream as well as the RandomAccessFile the stream is working on. > uploading and then renaming a file doesn't work (on windows) > > > Key: SSHD-118 > URL: https://issues.apache.org/jira/browse/SSHD-118 > Project: MINA SSHD > Issue Type: Bug >Affects Versions: 0.5.0 > Environment: windows xp professional jdk 1.5.0.22, jre 1.6 > windows 2003 server SP2 jdk jre 1.5.0.22 >Reporter: Otto Frost >Priority: Critical > Original Estimate: 2h > Remaining Estimate: 2h > > I logon, and then > put xx xx > rename xx yy > O1706@WKE198515 ~ > $ sftp -oport= a@localhost > Connecting to localhost... > a@localhost's password: > sftp> cd tmp > sftp> put xx > Uploading xx to /C:/NWDS7.1EHP1/workspace/minasshd_custom/tmp/xx > xx100% 1039 1.0KB/s 00:00 > sftp> rename xx yy > Couldn't rename file "/C:/NWDS7.1EHP1/workspace/minasshd_custom/tmp/xx" to > "/C:/ > NWDS7.1EHP1/workspace/minasshd_custom/tmp/yy": Failure > sftp> > The problem is that the file isn't closed after uploading, > SftpSubSystem.process SSH_FXP_WRITE > NativeSshFile.createOutputStream doesn't close the file, even though the > close method is called. > I can't rename the file from the os either because mina sshd holds it locked > after upload. When mina sshd is shut down I can rename the file. After > restarting minasshd the file can be renamed (from mina sshd or from the os). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (SSHD-118) uploading and then renaming a file doesn't work (on windows)
[ https://issues.apache.org/jira/browse/SSHD-118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Otto Frost updated SSHD-118: raf.close() should be changed to if (raf!=null) raf.close(); > uploading and then renaming a file doesn't work (on windows) > > > Key: SSHD-118 > URL: https://issues.apache.org/jira/browse/SSHD-118 > Project: MINA SSHD > Issue Type: Bug >Affects Versions: 0.5.0 > Environment: windows xp professional jdk 1.5.0.22, jre 1.6 > windows 2003 server SP2 jdk jre 1.5.0.22 >Reporter: Otto Frost >Priority: Critical > Original Estimate: 2h > Remaining Estimate: 2h > > I logon, and then > put xx xx > rename xx yy > O1706@WKE198515 ~ > $ sftp -oport= a@localhost > Connecting to localhost... > a@localhost's password: > sftp> cd tmp > sftp> put xx > Uploading xx to /C:/NWDS7.1EHP1/workspace/minasshd_custom/tmp/xx > xx100% 1039 1.0KB/s 00:00 > sftp> rename xx yy > Couldn't rename file "/C:/NWDS7.1EHP1/workspace/minasshd_custom/tmp/xx" to > "/C:/ > NWDS7.1EHP1/workspace/minasshd_custom/tmp/yy": Failure > sftp> > The problem is that the file isn't closed after uploading, > SftpSubSystem.process SSH_FXP_WRITE > NativeSshFile.createOutputStream doesn't close the file, even though the > close method is called. > I can't rename the file from the os either because mina sshd holds it locked > after upload. When mina sshd is shut down I can rename the file. After > restarting minasshd the file can be renamed (from mina sshd or from the os). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (SSHD-118) uploading and then renaming a file doesn't work (on windows)
uploading and then renaming a file doesn't work (on windows) Key: SSHD-118 URL: https://issues.apache.org/jira/browse/SSHD-118 Project: MINA SSHD Issue Type: Bug Affects Versions: 0.5.0 Environment: windows xp professional jdk 1.5.0.22, jre 1.6 windows 2003 server SP2 jdk jre 1.5.0.22 Reporter: Otto Frost Priority: Critical I logon, and then put xx xx rename xx yy O1706@WKE198515 ~ $ sftp -oport= a@localhost Connecting to localhost... a@localhost's password: sftp> cd tmp sftp> put xx Uploading xx to /C:/NWDS7.1EHP1/workspace/minasshd_custom/tmp/xx xx100% 1039 1.0KB/s 00:00 sftp> rename xx yy Couldn't rename file "/C:/NWDS7.1EHP1/workspace/minasshd_custom/tmp/xx" to "/C:/ NWDS7.1EHP1/workspace/minasshd_custom/tmp/yy": Failure sftp> The problem is that the file isn't closed after uploading, SftpSubSystem.process SSH_FXP_WRITE NativeSshFile.createOutputStream doesn't close the file, even though the close method is called. I can't rename the file from the os either because mina sshd holds it locked after upload. When mina sshd is shut down I can rename the file. After restarting minasshd the file can be renamed (from mina sshd or from the os). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DIRMINA-830) Unconditional wait() in Read- and WriteWorker of SerialSessionImpl
[ https://issues.apache.org/jira/browse/DIRMINA-830?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13021067#comment-13021067 ] Julien Vermillard commented on DIRMINA-830: --- Since I can't reproduce the bug here (no test code) can you try the attached patch ? I think it should fix the problem. > Unconditional wait() in Read- and WriteWorker of SerialSessionImpl > -- > > Key: DIRMINA-830 > URL: https://issues.apache.org/jira/browse/DIRMINA-830 > Project: MINA > Issue Type: Bug > Components: Transport >Affects Versions: 2.0.2 > Environment: win32 x86 >Reporter: Christian Schwarz > Labels: rs232, rxtx, serial > Attachments: patch.diff > > > The inner worker classes of SerialSessionImpl violates the guarded block > contract for Object#wait(). Under certain conditions it is possible that a > session write starved. > The wait loops of Read- and WriteWorker should be inside the synchronized > block! We have some starvations while writing data to or serial session. We > found out that in this case the WriteWorker-Thread waits endless for data to > write. Because we write data asynchron to the serial session, we assume that > a race condition occures. One thread is inside the unguarded > WriterWorker#flushWrites() while an other invoke SerialProcessor#flush(). > http://download.oracle.com/javase/tutorial/essential/concurrency/guardmeth.html > states-> Always invoke wait inside a loop that tests for the condition being > waited for. Don't assume that the interrupt was for the particular condition > you were waiting for, or that the condition is still true. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DIRMINA-830) Unconditional wait() in Read- and WriteWorker of SerialSessionImpl
[ https://issues.apache.org/jira/browse/DIRMINA-830?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julien Vermillard updated DIRMINA-830: -- Attachment: patch.diff > Unconditional wait() in Read- and WriteWorker of SerialSessionImpl > -- > > Key: DIRMINA-830 > URL: https://issues.apache.org/jira/browse/DIRMINA-830 > Project: MINA > Issue Type: Bug > Components: Transport >Affects Versions: 2.0.2 > Environment: win32 x86 >Reporter: Christian Schwarz > Labels: rs232, rxtx, serial > Attachments: patch.diff > > > The inner worker classes of SerialSessionImpl violates the guarded block > contract for Object#wait(). Under certain conditions it is possible that a > session write starved. > The wait loops of Read- and WriteWorker should be inside the synchronized > block! We have some starvations while writing data to or serial session. We > found out that in this case the WriteWorker-Thread waits endless for data to > write. Because we write data asynchron to the serial session, we assume that > a race condition occures. One thread is inside the unguarded > WriterWorker#flushWrites() while an other invoke SerialProcessor#flush(). > http://download.oracle.com/javase/tutorial/essential/concurrency/guardmeth.html > states-> Always invoke wait inside a loop that tests for the condition being > waited for. Don't assume that the interrupt was for the particular condition > you were waiting for, or that the condition is still true. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (FTPSERVER-407) Wherever possible, immutable private fields should be marked final
[ https://issues.apache.org/jira/browse/FTPSERVER-407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved FTPSERVER-407. Resolution: Fixed > Wherever possible, immutable private fields should be marked final > -- > > Key: FTPSERVER-407 > URL: https://issues.apache.org/jira/browse/FTPSERVER-407 > Project: FtpServer > Issue Type: Improvement >Reporter: Sebb > Attachments: final.patch > > > Using final for fields that are not intended to change is (IMO) good practice. > Also final fields help to ensure thread-safety. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (FTPSERVER-406) StringBuffer => StringBuilder for internal use
[ https://issues.apache.org/jira/browse/FTPSERVER-406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved FTPSERVER-406. Resolution: Fixed > StringBuffer => StringBuilder for internal use > -- > > Key: FTPSERVER-406 > URL: https://issues.apache.org/jira/browse/FTPSERVER-406 > Project: FtpServer > Issue Type: Improvement >Reporter: Sebb >Priority: Minor > Fix For: 1.0.6, 1.1.0 > > Attachments: StringBuilder.patch > > > StringBuilder should be used in preference to StringBuffer for local variables -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (FTPSERVER-405) Make Map field final (improve thread-safety)
[ https://issues.apache.org/jira/browse/FTPSERVER-405?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved FTPSERVER-405. Resolution: Fixed > Make Map field final (improve thread-safety) > > > Key: FTPSERVER-405 > URL: https://issues.apache.org/jira/browse/FTPSERVER-405 > Project: FtpServer > Issue Type: Improvement > Components: Ftplets >Reporter: Sebb > Fix For: 1.0.6, 1.1.0 > > Attachments: DefaultFtpletContainer.patch > > > Patch to make the field final -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (DIRMINA-830) Unconditional wait() in Read- and WriteWorker of SerialSessionImpl
Unconditional wait() in Read- and WriteWorker of SerialSessionImpl -- Key: DIRMINA-830 URL: https://issues.apache.org/jira/browse/DIRMINA-830 Project: MINA Issue Type: Bug Components: Transport Affects Versions: 2.0.2 Environment: win32 x86 Reporter: Christian Schwarz The inner worker classes of SerialSessionImpl violates the guarded block contract for Object#wait(). Under certain conditions it is possible that a session write starved. The wait loops of Read- and WriteWorker should be inside the synchronized block! We have some starvations while writing data to or serial session. We found out that in this case the WriteWorker-Thread waits endless for data to write. Because we write data asynchron to the serial session, we assume that a race condition occures. One thread is inside the unguarded WriterWorker#flushWrites() while an other invoke SerialProcessor#flush(). http://download.oracle.com/javase/tutorial/essential/concurrency/guardmeth.html states-> Always invoke wait inside a loop that tests for the condition being waited for. Don't assume that the interrupt was for the particular condition you were waiting for, or that the condition is still true. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [MINA 3] Session write queue
On 4/18/11 12:14 PM, Julien Vermillard wrote:
Le Mon, 18 Apr 2011 10:26:42 +0200,
Emmanuel Lecharny a écrit :
On 4/18/11 10:01 AM, Steve Ulrich wrote:
Hi!
I'm sceptical about it. Maybe you could design it in a way, that
the IoProcessor is replaceable, so one could test the behaviour.
And this is why I posted my suggestion on the mailing list :) My idea
might well be totally off base.
Cons:
* Imagine a bunch of smaller write requests per session. Currently
an IoProcessor at least have a chance to optimize the writes by
flushing all data of a single session at once, thus minimizing the
TCP/IP-packages. Under heavy load, a single queue will be stuffed
with a lot of write requests from different sessions and the
IoProcesser will write each one in the order they are written to
the queue, causing a higher fragmentation.
Fair enough. But we can mitigate this risk on the IoProcessor too, by
pulling out of the queue all the messages for a session, until the
socket can't accept any more writing. Something like :
while () {
WriteReqest message = queue.get();
Session session = message.getSession();
Channel channel = session.getChannel();
while ( channel is ready for write) do {
channel.write( message );
message = queue.get( session );
}
}
I think how it's going to behave (vs Queue in the session) will be the
perf of "queue.get( session );".
what kind of structure you want to use ?
I have replied to Steve in another mail, but, yes, this issue has to be
addressed.
It may be one of the reason we want each session to have its own queue.
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: [MINA 3] Session write queue
On 4/18/11 12:13 PM, Steve Ulrich wrote:
D4n Outlook. This time with a better quotation... I hope
Emmanuel Lecharny [mailto:elecha...@gmail.com] wrote
Fair enough. But we can mitigate this risk on the IoProcessor too, by
pulling out of the queue all the messages for a session, until the
socket can't accept any more writing. Something like :
while () {
WriteReqest message = queue.get();
Session session = message.getSession();
Channel channel = session.getChannel();
while ( channel is ready for write) do {
channel.write( message );
message = queue.get( session );
}
}
That would require a queue per session. So I don't see a difference to the
prior model. I thought you wanted a single queue for all session of an
IoProcessor.
No, only one queue is necessary, if we search for the message in the
queue for a specific session. Now, the problem would be to have the
rigth design for this queue (ie, it has to be searchable without having
to do a full scan).
Not sure if it's smart, though.
Does it sounds crazy ?
No, but I'm currently not seeing the difference, besides the fact that the
IoProcessor handles the queues. Maybe I'm misunderstanding your suggestion.
See upper. But I'm not sure it's the right idea.
* An additional cpu cost will be the increased synchronization
efforts inside the queue... There will be more threads, writing to the
same queue at the same time.
No, because the IoProcessor is using one single thread.
Ok, I'm not too deep into the IoProcessor, but I thought the writing requests
of different sessions (put to the queue) could be handled simultaneously, while
the IoProcessor itself is single-threaded (poll from the queue).
Each session is attached to an IoProcessor, so you may have messages
sent in parallel. But a session will always be processed by a single
IoProcessor.
H, whatever the queues use, it's irrelevant. There is no reason
that
we don't use the same in the IoProcessor queue, as we have the exact
same number of elements in this queue than the number of all the
elements used in all the Session queues.
Maybe there is a little overhead for each queue, but I don't think that it is
big enough to justify a design for itself.
Yes, right.
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: [MINA 3] Session write queue
Le Mon, 18 Apr 2011 10:26:42 +0200,
Emmanuel Lecharny a écrit :
> On 4/18/11 10:01 AM, Steve Ulrich wrote:
> > Hi!
> >
> > I'm sceptical about it. Maybe you could design it in a way, that
> > the IoProcessor is replaceable, so one could test the behaviour.
> And this is why I posted my suggestion on the mailing list :) My idea
> might well be totally off base.
> > Cons:
> >
> > * Imagine a bunch of smaller write requests per session. Currently
> > an IoProcessor at least have a chance to optimize the writes by
> > flushing all data of a single session at once, thus minimizing the
> > TCP/IP-packages. Under heavy load, a single queue will be stuffed
> > with a lot of write requests from different sessions and the
> > IoProcesser will write each one in the order they are written to
> > the queue, causing a higher fragmentation.
> Fair enough. But we can mitigate this risk on the IoProcessor too, by
> pulling out of the queue all the messages for a session, until the
> socket can't accept any more writing. Something like :
>
> while () {
> WriteReqest message = queue.get();
> Session session = message.getSession();
> Channel channel = session.getChannel();
>
> while ( channel is ready for write) do {
> channel.write( message );
> message = queue.get( session );
> }
> }
I think how it's going to behave (vs Queue in the session) will be the
perf of "queue.get( session );".
what kind of structure you want to use ?
>
> Does it sounds crazy ?
> > * With this the IoProcessor will be constantly switching between
> > sessions, checking the state of the session, etc.
> See above
> > * An additional cpu cost will be the increased synchronization
> > efforts inside the queue... There will be more threads, writing to
> > the same queue at the same time.
> No, because the IoProcessor is using one single thread.
> > The memory is bought with costs at network throughput and processor
> > cycles.
> >
> > What do you mean by "it's not a free data structure in term of
> > memory consumption"? As far as I understand, a linked queue
> > contains only elements, if there is something stored in there.
> H, whatever the queues use, it's irrelevant. There is no reason
> that we don't use the same in the IoProcessor queue, as we have the
> exact same number of elements in this queue than the number of all
> the elements used in all the Session queues.
>
> My expalanition was just plain silly. Thanks for pointing this out.
> > Pro:
> > * Behaviour may be more fair.
> >
> > Write-Throttling may be done by a filter. IMHO It's the better
> > place anyway.
>
> Absolutly.
> > So you may have the option to place the write throttle at the start
> > of your queue and save processor speed.
>
> Yes. The problem is to deal with the throttle in a filter, which is
> not totally obvious.
>
> Thanks !
>
--
Julien Vermillard
Archean Technologies
http://www.archean.fr
signature.asc
Description: PGP signature
RE: [MINA 3] Session write queue
D4n Outlook. This time with a better quotation... I hope
> Emmanuel Lecharny [mailto:elecha...@gmail.com] wrote
>
> Fair enough. But we can mitigate this risk on the IoProcessor too, by
> pulling out of the queue all the messages for a session, until the
> socket can't accept any more writing. Something like :
>
> while () {
> WriteReqest message = queue.get();
> Session session = message.getSession();
> Channel channel = session.getChannel();
>
> while ( channel is ready for write) do {
> channel.write( message );
> message = queue.get( session );
> }
> }
That would require a queue per session. So I don't see a difference to the
prior model. I thought you wanted a single queue for all session of an
IoProcessor.
> Does it sounds crazy ?
No, but I'm currently not seeing the difference, besides the fact that the
IoProcessor handles the queues. Maybe I'm misunderstanding your suggestion.
> > * An additional cpu cost will be the increased synchronization
> efforts inside the queue... There will be more threads, writing to the
> same queue at the same time.
> No, because the IoProcessor is using one single thread.
Ok, I'm not too deep into the IoProcessor, but I thought the writing requests
of different sessions (put to the queue) could be handled simultaneously, while
the IoProcessor itself is single-threaded (poll from the queue).
> H, whatever the queues use, it's irrelevant. There is no reason
> that
> we don't use the same in the IoProcessor queue, as we have the exact
> same number of elements in this queue than the number of all the
> elements used in all the Session queues.
Maybe there is a little overhead for each queue, but I don't think that it is
big enough to justify a design for itself.
> > Write-Throttling may be done by a filter. IMHO It's the better place
> anyway.
>
> Absolutly.
> > So you may have the option to place the write throttle at the start
> of your queue and save processor speed.
>
> Yes. The problem is to deal with the throttle in a filter, which is not
> totally obvious.
Yes, I have tried it by myself, but didn't get too far.
regards
Steve
--
PROEMION GmbH
Steve Ulrich
IT Development (IT/DEV)
Donaustrasse 14
D-36043 Fulda, Germany
Phone +49 (0) 661 9490-601
Fax +49 (0) 661 9490-333
http://www.proemion.com/
mailto:steve.ulr...@proemion.com
Geschäftsführer: Dipl. Ing. Robert Michaelides
Amtsgericht-Registergericht-Fulda: 5 HRB 1867
--
E-mail and any attachments may be confidential. If you have received this
E-mail and you are not a named addressee, please inform the sender immediately
by E-mail and then delete this E-mail from your system. If you are not a named
addressee, you may not use, disclose, distribute, copy or print this E-mail.
Addressees should scan this E-mail and any attachments for viruses. No
representation or warranty is made as to the absence of viruses in this E-mail
or any of its attachments.
AKTUELLES
http://www.rmcan.de/
NEWS
http://www.rmcan.com/
[jira] [Commented] (DIRMINA-653) IoSession.write not thread-safe? Loosing messages under heavy multi-threaded write on same session.
[
https://issues.apache.org/jira/browse/DIRMINA-653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13020955#comment-13020955
]
Christian Schwarz commented on DIRMINA-653:
---
Yes, the BufferDataException is thrown when we use the fixed code ! The fix
works good for the race condition of the compressor, the following exception
disappeared:
:java.io.IOException: Unknown error. Error code : -3 and message : invalid
stored block lengths
> IoSession.write not thread-safe? Loosing messages under heavy multi-threaded
> write on same session.
> ---
>
> Key: DIRMINA-653
> URL: https://issues.apache.org/jira/browse/DIRMINA-653
> Project: MINA
> Issue Type: Bug
> Components: Core, Filter
>Affects Versions: 2.0.0-M4
> Environment: Windows Vista 64-bit
>Reporter: Mauritz Lovgren
> Fix For: 2.0.0-M5
>
>
> I am writing a stress-test that tests multi-thread safetyness of our
> stateless encoder / decoder under heavy load and I am observing that messages
> are silently lost during session.write(Object), (the lost messages do not
> seem to reach the underlying socket buffer at all).
> I am using one encoder / decoder that is stateless. No executor filter, only
> the filter codec and a basic io handler.
> Synchronizing on the session.write makes the problem go away;
> synchronized (session)
> {
> future = session.write(message);
> }
> Do I really have to synchronize on the session to solve this issue?
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [MINA 3] Session write queue
On 4/18/11 10:01 AM, Steve Ulrich wrote:
Hi!
I'm sceptical about it. Maybe you could design it in a way, that the
IoProcessor is replaceable, so one could test the behaviour.
And this is why I posted my suggestion on the mailing list :) My idea
might well be totally off base.
Cons:
* Imagine a bunch of smaller write requests per session. Currently an
IoProcessor at least have a chance to optimize the writes by flushing all data
of a single session at once, thus minimizing the TCP/IP-packages. Under heavy
load, a single queue will be stuffed with a lot of write requests from
different sessions and the IoProcesser will write each one in the order they
are written to the queue, causing a higher fragmentation.
Fair enough. But we can mitigate this risk on the IoProcessor too, by
pulling out of the queue all the messages for a session, until the
socket can't accept any more writing. Something like :
while () {
WriteReqest message = queue.get();
Session session = message.getSession();
Channel channel = session.getChannel();
while ( channel is ready for write) do {
channel.write( message );
message = queue.get( session );
}
}
Does it sounds crazy ?
* With this the IoProcessor will be constantly switching between sessions,
checking the state of the session, etc.
See above
* An additional cpu cost will be the increased synchronization efforts inside
the queue... There will be more threads, writing to the same queue at the same
time.
No, because the IoProcessor is using one single thread.
The memory is bought with costs at network throughput and processor cycles.
What do you mean by "it's not a free data structure in term of memory
consumption"?
As far as I understand, a linked queue contains only elements, if there is
something stored in there.
H, whatever the queues use, it's irrelevant. There is no reason that
we don't use the same in the IoProcessor queue, as we have the exact
same number of elements in this queue than the number of all the
elements used in all the Session queues.
My expalanition was just plain silly. Thanks for pointing this out.
Pro:
* Behaviour may be more fair.
Write-Throttling may be done by a filter. IMHO It's the better place anyway.
Absolutly.
So you may have the option to place the write throttle at the start of your
queue and save processor speed.
Yes. The problem is to deal with the throttle in a filter, which is not
totally obvious.
Thanks !
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: [MINA 3] Session write queue
Hi! I'm sceptical about it. Maybe you could design it in a way, that the IoProcessor is replaceable, so one could test the behaviour. Cons: * Imagine a bunch of smaller write requests per session. Currently an IoProcessor at least have a chance to optimize the writes by flushing all data of a single session at once, thus minimizing the TCP/IP-packages. Under heavy load, a single queue will be stuffed with a lot of write requests from different sessions and the IoProcesser will write each one in the order they are written to the queue, causing a higher fragmentation. * With this the IoProcessor will be constantly switching between sessions, checking the state of the session, etc. * An additional cpu cost will be the increased synchronization efforts inside the queue... There will be more threads, writing to the same queue at the same time. The memory is bought with costs at network throughput and processor cycles. What do you mean by "it's not a free data structure in term of memory consumption"? As far as I understand, a linked queue contains only elements, if there is something stored in there. Pro: * Behaviour may be more fair. Write-Throttling may be done by a filter. IMHO It's the better place anyway. So you may have the option to place the write throttle at the start of your queue and save processor speed. regards Steve Emmanuel Lecharny [mailto:elecha...@gmail.com] wrote: Hi, in MINA 2, each session has a write queue. It sounds a bit spurious, as a session is associated with a IoProcessor in charge of writing data. What if we remove this write queue, to move to to the IoProcessor ? Let's analyze the issues we will face and advantages we will get if we change this. o We will spare a queue for each session, thus consuming less memory. The WriteQueue is a ConcurrentLinkedQueue, and it's not a free data structure in term of memory consumption. o Throttling will become more difficult to manage, because we won't be able to check if the number of messages or bytes has reached its limit in the IoProcessor. o If the write queue is associated with the session, suspending write will just be a matter to forbid the IoProcessor to read the queue. If we move the queue to the IoProcessor, we will have to check for each message present in the queue that its associated session is forbidding the write If you see some more potential issues, -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com -- PROEMION GmbH Steve Ulrich IT Development (IT/DEV) Donaustrasse 14 D-36043 Fulda, Germany Phone +49 (0) 661 9490-601 Fax +49 (0) 661 9490-333 http://www.proemion.com/ mailto:steve.ulr...@proemion.com Geschäftsführer: Dipl. Ing. Robert Michaelides Amtsgericht-Registergericht-Fulda: 5 HRB 1867 -- E-mail and any attachments may be confidential. If you have received this E-mail and you are not a named addressee, please inform the sender immediately by E-mail and then delete this E-mail from your system. If you are not a named addressee, you may not use, disclose, distribute, copy or print this E-mail. Addressees should scan this E-mail and any attachments for viruses. No representation or warranty is made as to the absence of viruses in this E-mail or any of its attachments. AKTUELLES http://www.rmcan.de/ NEWS http://www.rmcan.com/
