[jira] [Commented] (VFS-296) [FTP] Socket timeout setting doesn't work if connect hangs
[ https://issues.apache.org/jira/browse/VFS-296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14609647#comment-14609647 ] Philipp Brügger commented on VFS-296: - Hi Bernd, so the only blocking ticket to release 2.1 is the VFS-498 ? Please let us know how we can help you releasing finally a next version? We are all waiting for this release!!! > [FTP] Socket timeout setting doesn't work if connect hangs > -- > > Key: VFS-296 > URL: https://issues.apache.org/jira/browse/VFS-296 > Project: Commons VFS > Issue Type: Bug >Affects Versions: Nightly Builds >Reporter: Andreas Persson > Fix For: 2.1 > > Attachments: sotimeout.patch, sotimeout_v2.patch > > > The fix from VFS-216 doesn't help if the ftp server doesn't reply with any > messages at all (could happen if it's behind a badly configured firewall for > example). What happens is that the client.connect() called from > FtpClientFactory hangs, and this line is before timeout parameter is set. > I suggest the change in the attached patch. > The scenario can be tested with "netcat -l" instead of a real ftp server. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SCXML-233) SCInstance becomes not serialzable after triggering event
[
https://issues.apache.org/jira/browse/SCXML-233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14609490#comment-14609490
]
Adam Bien commented on SCXML-233:
-
The code was moved to:
https://github.com/AdamBien/stateful/blob/master/stateful/src/test/java/com/airhacks/stateful/machine/boundary/StateManagerTest.java
It is the ignored test.
I'm working with 2.0 Snapshots. Also it seems only to happen with JSEvaluator.
The serialization of SCInstance#contexts (Map) fails.
> SCInstance becomes not serialzable after triggering event
> -
>
> Key: SCXML-233
> URL: https://issues.apache.org/jira/browse/SCXML-233
> Project: Commons SCXML
> Issue Type: Bug
>Affects Versions: 2.0
>Reporter: Adam Bien
>Priority: Critical
>
> Triggering an event on SCXML executor with attached JSEvaluator makes the
> SCInstance not-serializable. Seems like SCXMLExecutor#.triggerEvent
> invocation sets a reference to SCXMLExecutor in SCInstance.
> Reproducer:
> https://github.com/AdamBien/stateful/blob/master/stateful/src/test/java/com/airhacks/stateful/machine/boundary/StateManagerTest.java
> Exception:
> {code}
> java.io.NotSerializableException: org.apache.commons.scxml2.SCXMLExecutor
> at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1184)
> at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:348)
> at java.util.HashMap.internalWriteEntries(HashMap.java:1777)
> at java.util.HashMap.writeObject(HashMap.java:1354)
> at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at
> java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:988)
> at
> java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1496)
> at
> java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1432)
> at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178)
> at
> java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1548)
> at
> java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1509)
> at
> java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1432)
> at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178)
> at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:348)
> at java.util.HashMap.internalWriteEntries(HashMap.java:1777)
> at java.util.HashMap.writeObject(HashMap.java:1354)
> at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at
> java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:988)
> at
> java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1496)
> at
> java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1432)
> at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178)
> at
> java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1548)
> at
> java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1509)
> at
> java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1432)
> at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178)
> at
> java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1548)
> at
> java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1509)
> at
> java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1432)
> at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178)
> at
> java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1548)
> at
> java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1509)
> at
> java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1432)
> at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178)
> at
> java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1548)
> at
> java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1509)
> at
> java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1432)
> at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178)
> at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:348)
> at java.util.HashMap.internalWriteEntries(HashMap.java:1777)
> at java.util.HashMap.writeObject(HashMap.j
[jira] [Updated] (SCXML-233) SCInstance becomes not serialzable after triggering event
[
https://issues.apache.org/jira/browse/SCXML-233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adam Bien updated SCXML-233:
Description:
Triggering an event on SCXML executor with attached JSEvaluator makes the
SCInstance not-serializable. Seems like SCXMLExecutor#.triggerEvent invocation
sets a reference to SCXMLExecutor in SCInstance.
Reproducer:
https://github.com/AdamBien/stateful/blob/master/stateful/src/test/java/com/airhacks/stateful/machine/boundary/StateManagerTest.java
Exception:
{code}
java.io.NotSerializableException: org.apache.commons.scxml2.SCXMLExecutor
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1184)
at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:348)
at java.util.HashMap.internalWriteEntries(HashMap.java:1777)
at java.util.HashMap.writeObject(HashMap.java:1354)
at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at
java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:988)
at
java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1496)
at
java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1432)
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178)
at
java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1548)
at
java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1509)
at
java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1432)
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178)
at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:348)
at java.util.HashMap.internalWriteEntries(HashMap.java:1777)
at java.util.HashMap.writeObject(HashMap.java:1354)
at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at
java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:988)
at
java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1496)
at
java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1432)
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178)
at
java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1548)
at
java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1509)
at
java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1432)
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178)
at
java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1548)
at
java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1509)
at
java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1432)
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178)
at
java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1548)
at
java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1509)
at
java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1432)
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178)
at
java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1548)
at
java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1509)
at
java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1432)
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178)
at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:348)
at java.util.HashMap.internalWriteEntries(HashMap.java:1777)
at java.util.HashMap.writeObject(HashMap.java:1354)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at
java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:988)
at
java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1496)
at
java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1432)
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178)
at
java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1548)
at
java.io.ObjectOutputStream.writeSeria
[jira] [Commented] (SCXML-233) SCInstance becomes not serialzable after triggering event
[
https://issues.apache.org/jira/browse/SCXML-233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14609486#comment-14609486
]
Woonsan Ko commented on SCXML-233:
--
I don't see an attachment or the test class.
{quote}
Seems like SCXMLExecutor#.triggerEvent invocation sets a reference to
SCXMLExecutor in SCInstance
{quote}
As far as I know, [~adouma] resolved the issue while fixing SCXML-196 and
SCXML-197. So, SCInstance doesn't have SCXMLExecutor member any more.
> SCInstance becomes not serialzable after triggering event
> -
>
> Key: SCXML-233
> URL: https://issues.apache.org/jira/browse/SCXML-233
> Project: Commons SCXML
> Issue Type: Bug
>Affects Versions: 2.0
>Reporter: Adam Bien
>Priority: Critical
>
> Triggering an event on SCXML executor with attached JSEvaluator makes the
> SCInstance not-serializable. Seems like SCXMLExecutor#.triggerEvent
> invocation sets a reference to SCXMLExecutor in SCInstance.
> Reproducer:
> https://github.com/AdamBien/stateful/blob/master/statefulapp/src/test/java/com/airhacks/stateful/machine/boundary/StateManagerTest.java
> Exception:
> {code}
> java.io.NotSerializableException: org.apache.commons.scxml2.SCXMLExecutor
> at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1184)
> at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:348)
> at java.util.HashMap.internalWriteEntries(HashMap.java:1777)
> at java.util.HashMap.writeObject(HashMap.java:1354)
> at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at
> java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:988)
> at
> java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1496)
> at
> java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1432)
> at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178)
> at
> java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1548)
> at
> java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1509)
> at
> java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1432)
> at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178)
> at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:348)
> at java.util.HashMap.internalWriteEntries(HashMap.java:1777)
> at java.util.HashMap.writeObject(HashMap.java:1354)
> at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at
> java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:988)
> at
> java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1496)
> at
> java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1432)
> at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178)
> at
> java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1548)
> at
> java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1509)
> at
> java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1432)
> at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178)
> at
> java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1548)
> at
> java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1509)
> at
> java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1432)
> at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178)
> at
> java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1548)
> at
> java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1509)
> at
> java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1432)
> at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178)
> at
> java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1548)
> at
> java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1509)
> at
> java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1432)
> at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178)
> at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:348)
> at java.util.HashMap.internalWriteEntries(HashMap.java:1777)
> at java.util.HashMap.writeObject(HashMap.java:1354)
[jira] [Updated] (SCXML-233) SCInstance becomes not serialzable after triggering event
[
https://issues.apache.org/jira/browse/SCXML-233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Woonsan Ko updated SCXML-233:
-
Description:
Triggering an event on SCXML executor with attached JSEvaluator makes the
SCInstance not-serializable. Seems like SCXMLExecutor#.triggerEvent invocation
sets a reference to SCXMLExecutor in SCInstance.
Reproducer:
https://github.com/AdamBien/stateful/blob/master/statefulapp/src/test/java/com/airhacks/stateful/machine/boundary/StateManagerTest.java
Exception:
{code}
java.io.NotSerializableException: org.apache.commons.scxml2.SCXMLExecutor
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1184)
at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:348)
at java.util.HashMap.internalWriteEntries(HashMap.java:1777)
at java.util.HashMap.writeObject(HashMap.java:1354)
at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at
java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:988)
at
java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1496)
at
java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1432)
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178)
at
java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1548)
at
java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1509)
at
java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1432)
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178)
at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:348)
at java.util.HashMap.internalWriteEntries(HashMap.java:1777)
at java.util.HashMap.writeObject(HashMap.java:1354)
at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at
java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:988)
at
java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1496)
at
java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1432)
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178)
at
java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1548)
at
java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1509)
at
java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1432)
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178)
at
java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1548)
at
java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1509)
at
java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1432)
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178)
at
java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1548)
at
java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1509)
at
java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1432)
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178)
at
java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1548)
at
java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1509)
at
java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1432)
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178)
at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:348)
at java.util.HashMap.internalWriteEntries(HashMap.java:1777)
at java.util.HashMap.writeObject(HashMap.java:1354)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at
java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:988)
at
java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1496)
at
java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1432)
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178)
at
java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1548)
at
java.io.ObjectOutputStream.write
[jira] [Commented] (VFS-296) [FTP] Socket timeout setting doesn't work if connect hangs
[ https://issues.apache.org/jira/browse/VFS-296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14609478#comment-14609478 ] Remko Popma commented on VFS-296: - We will try to use jstack if the problem occurs again. Is there a snapshot or beta build somewhere that includes this fix? > [FTP] Socket timeout setting doesn't work if connect hangs > -- > > Key: VFS-296 > URL: https://issues.apache.org/jira/browse/VFS-296 > Project: Commons VFS > Issue Type: Bug >Affects Versions: Nightly Builds >Reporter: Andreas Persson > Fix For: 2.1 > > Attachments: sotimeout.patch, sotimeout_v2.patch > > > The fix from VFS-216 doesn't help if the ftp server doesn't reply with any > messages at all (could happen if it's behind a badly configured firewall for > example). What happens is that the client.connect() called from > FtpClientFactory hangs, and this line is before timeout parameter is set. > I suggest the change in the attached patch. > The scenario can be tested with "netcat -l" instead of a real ftp server. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (SCXML-233) SCInstance becomes not serialzable after triggering event
Adam Bien created SCXML-233: --- Summary: SCInstance becomes not serialzable after triggering event Key: SCXML-233 URL: https://issues.apache.org/jira/browse/SCXML-233 Project: Commons SCXML Issue Type: Bug Affects Versions: 2.0 Reporter: Adam Bien Priority: Critical Triggering an event on SCXML executor with attached JSEvaluator makes the SCInstance not-serializable. Seems like SCXMLExecutor#.triggerEvent invocation sets a reference to SCXMLExecutor in SCInstance. Reproducer: https://github.com/AdamBien/stateful/blob/master/statefulapp/src/test/java/com/airhacks/stateful/machine/boundary/StateManagerTest.java Exception: java.io.NotSerializableException: org.apache.commons.scxml2.SCXMLExecutor at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1184) at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:348) at java.util.HashMap.internalWriteEntries(HashMap.java:1777) at java.util.HashMap.writeObject(HashMap.java:1354) at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:988) at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1496) at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1432) at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178) at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1548) at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1509) at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1432) at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178) at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:348) at java.util.HashMap.internalWriteEntries(HashMap.java:1777) at java.util.HashMap.writeObject(HashMap.java:1354) at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:988) at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1496) at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1432) at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178) at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1548) at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1509) at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1432) at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178) at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1548) at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1509) at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1432) at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178) at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1548) at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1509) at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1432) at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178) at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1548) at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1509) at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1432) at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178) at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:348) at java.util.HashMap.internalWriteEntries(HashMap.java:1777) at java.util.HashMap.writeObject(HashMap.java:1354) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:988) at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1496) at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1432) at java.io.ObjectOut
[jira] [Commented] (MATH-1179) kolmogorovSmirnovTest poor performance in monteCarloP method
[ https://issues.apache.org/jira/browse/MATH-1179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14608953#comment-14608953 ] Phil Steitz commented on MATH-1179: --- A note on exactP, As pointed out in [1], if the combined dataset (two samples merged) contains ties, the permutation-based method used by exactP is not correct. That's why R gives a warning when you ask for exact p-values in the presence of ties. In [1] a more sophisticated Monte Carlo method is presented for dealing with the presence of ties. The naive implementation we currently have (unless and until we find reference to and replace it with the Jenrich-Kim method) might actually be correct in the presence of ties if we insert the ties in the data from which the combinatorial enumeration is done or just use the actual data instead of n + m as an integer to compute the full set of possible D values. A good general reference on the 2-sample statistic is [2], but that is unfortunately not freely available. [1] http://www.cirano.qc.ca/files/publications/2001s-56.pdf [2] http://dx.doi.org/10.1080/01621459.1969.10501082 > kolmogorovSmirnovTest poor performance in monteCarloP method > > > Key: MATH-1179 > URL: https://issues.apache.org/jira/browse/MATH-1179 > Project: Commons Math > Issue Type: Bug >Reporter: Gilad > Fix For: 4.0 > > Attachments: KSTest-JavaAndR.txt, KSTestSnippet.txt > > > I'm using the kolmogovSmirnovTest method to calculate pvalues. > However, when i try running the test on two double[] of sizes 5 and 45 the > results take over 10 seconds to calculate. > This seems very long, whereas in R it takes a few miliseconds for the same > calculation. > I'd be very happy to hear any comment you may have on the subject. >Gilad -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (VFS-296) [FTP] Socket timeout setting doesn't work if connect hangs
[ https://issues.apache.org/jira/browse/VFS-296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14608808#comment-14608808 ] Bernd Eckenfels commented on VFS-296: - Hello, if you have a stack trace of such a hang it might be good to check. Yes there is a plan, but dont hold your breath :) https://wiki.apache.org/commons/VfsReleaseState > [FTP] Socket timeout setting doesn't work if connect hangs > -- > > Key: VFS-296 > URL: https://issues.apache.org/jira/browse/VFS-296 > Project: Commons VFS > Issue Type: Bug >Affects Versions: Nightly Builds >Reporter: Andreas Persson > Fix For: 2.1 > > Attachments: sotimeout.patch, sotimeout_v2.patch > > > The fix from VFS-216 doesn't help if the ftp server doesn't reply with any > messages at all (could happen if it's behind a badly configured firewall for > example). What happens is that the client.connect() called from > FtpClientFactory hangs, and this line is before timeout parameter is set. > I suggest the change in the attached patch. > The scenario can be tested with "netcat -l" instead of a real ftp server. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (VFS-296) [FTP] Socket timeout setting doesn't work if connect hangs
[ https://issues.apache.org/jira/browse/VFS-296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14608489#comment-14608489 ] Remko Popma commented on VFS-296: - At my company we are using version 2.0 and have recently experienced our app hanging while trying to send files over FTP. This has happened 4 times in the previous 9 business days. We are not sure what (if anything) has changed. At the moment we are manually recovering any time this happens. We would love to upgrade to a version that includes this fix but 2.1 is not out yet. Is there a plan to release 2.1 in the near future? > [FTP] Socket timeout setting doesn't work if connect hangs > -- > > Key: VFS-296 > URL: https://issues.apache.org/jira/browse/VFS-296 > Project: Commons VFS > Issue Type: Bug >Affects Versions: Nightly Builds >Reporter: Andreas Persson > Fix For: 2.1 > > Attachments: sotimeout.patch, sotimeout_v2.patch > > > The fix from VFS-216 doesn't help if the ftp server doesn't reply with any > messages at all (could happen if it's behind a badly configured firewall for > example). What happens is that the client.connect() called from > FtpClientFactory hangs, and this line is before timeout parameter is set. > I suggest the change in the attached patch. > The scenario can be tested with "netcat -l" instead of a real ftp server. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (NET-577) Fails to parse FEAT response from Microsoft FTP Service
Jochen Kemnade created NET-577:
--
Summary: Fails to parse FEAT response from Microsoft FTP Service
Key: NET-577
URL: https://issues.apache.org/jira/browse/NET-577
Project: Commons Net
Issue Type: Bug
Components: FTP
Affects Versions: 3.3
Reporter: Jochen Kemnade
This is probably rather a bug in the server implementation, but anyway.
The response from a Microsoft FTP Service I'm trying to work with looks like
that:
{noformat}
211-FEAT
SIZE
MDTM
211 END
{noformat}
So, after parsing the response, the entries in the features map are {{ SIZE}}
and {{ MDTM}}.
While it doesn't adhere to the RFC (there's supposed to be a single leading
space for each feature), it should be possible to work around that kind of
broken response.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (NET-558) getModificationTime() returns complete received line including response code
[ https://issues.apache.org/jira/browse/NET-558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14608099#comment-14608099 ] Jochen Kemnade commented on NET-558: If I use the `substring(4)` approach in 3.3 with a WINDOWS ftp server, there's still a trailing newline in the response. Not sure if that'll be an issue in 3.4. > getModificationTime() returns complete received line including > response code > -- > > Key: NET-558 > URL: https://issues.apache.org/jira/browse/NET-558 > Project: Commons Net > Issue Type: Bug > Components: FTP >Affects Versions: 3.3 > Environment: The ftp server supports MDTM. >Reporter: Ralph Becker >Priority: Minor > Labels: commons-net, ftp > Fix For: 3.4 > > > When retrieving the last modification time of a file on the server via the > method getModificationTime(String filename) it returns something like > "213 2014112706" where only the part after the space is the relevant data. > I digged deeper and i found that the first part before the space is the > positive > response code which is not removed before getModificationTime returns. > I consider this a minor bug as i think there is a simple work around > (split by space, use second part only) but i do not believe that > the result of the method is what a user expects regarding the documentation > of that method. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (NET-558) getModificationTime() returns complete received line including response code
[
https://issues.apache.org/jira/browse/NET-558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14608099#comment-14608099
]
Jochen Kemnade edited comment on NET-558 at 6/30/15 10:40 AM:
--
If I use the {{substring(4)}} approach in 3.3 with a WINDOWS ftp server,
there's still a trailing newline in the response. Not sure if that'll be an
issue in 3.4.
was (Author: jkemnade):
If I use the `substring(4)` approach in 3.3 with a WINDOWS ftp server, there's
still a trailing newline in the response. Not sure if that'll be an issue in
3.4.
> getModificationTime() returns complete received line including
> response code
> --
>
> Key: NET-558
> URL: https://issues.apache.org/jira/browse/NET-558
> Project: Commons Net
> Issue Type: Bug
> Components: FTP
>Affects Versions: 3.3
> Environment: The ftp server supports MDTM.
>Reporter: Ralph Becker
>Priority: Minor
> Labels: commons-net, ftp
> Fix For: 3.4
>
>
> When retrieving the last modification time of a file on the server via the
> method getModificationTime(String filename) it returns something like
> "213 2014112706" where only the part after the space is the relevant data.
> I digged deeper and i found that the first part before the space is the
> positive
> response code which is not removed before getModificationTime returns.
> I consider this a minor bug as i think there is a simple work around
> (split by space, use second part only) but i do not believe that
> the result of the method is what a user expects regarding the documentation
> of that method.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (JEXL-157) Replace File.pathSeparator with File.separator
[ https://issues.apache.org/jira/browse/JEXL-157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated JEXL-157: -- Affects Version/s: 2.1.1 Fix Version/s: 3.0 2 > Replace File.pathSeparator with File.separator > -- > > Key: JEXL-157 > URL: https://issues.apache.org/jira/browse/JEXL-157 > Project: Commons JEXL > Issue Type: Bug >Affects Versions: 2.1.1, 3.0 > Environment: Debian Jessie 8.1 64 Bit > Maven 3.0.5-3 > OpenJDK 7u79-2.5.5-1~deb8u1 > German language >Reporter: Lars Cebulla >Assignee: Henri Biestro >Priority: Blocker > Fix For: 3.0, 2 > > > Hi, > I got errors when I try to compile / test JEXL because ClassCreatorTest fails. > At line 51, it uses "File.pathSeparator", which is wrong. It has to be just > "File.separator". > Thanks in advance! -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (JEXL-157) Replace File.pathSeparator with File.separator
[
https://issues.apache.org/jira/browse/JEXL-157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14608077#comment-14608077
]
Sebb edited comment on JEXL-157 at 6/30/15 10:19 AM:
-
Note: it was probably not spotted because System.getProperty("java.io.tmpdir")
returns a string ending with "/" - i.e. the separator char - (at least on my
system) and pathSeparator (\:) is valid as a leading filename character on many
systems.
I think it's safer to use the appropriate File class ctor rather than making
assumptions about how OS file path names are constructed.
was (Author: s...@apache.org):
Note: it was probably not spotted because System.getProperty("java.io.tmpdir")
returns a string ending with "/" - i.e. the separator char - (at least on my
system) and pathSeparator (:) is valid as a leading filename character on many
systems.
I think it's safer to use the appropriate File class ctor rather than making
assumptions about how OS file path names are constructed.
> Replace File.pathSeparator with File.separator
> --
>
> Key: JEXL-157
> URL: https://issues.apache.org/jira/browse/JEXL-157
> Project: Commons JEXL
> Issue Type: Bug
>Affects Versions: 3.0
> Environment: Debian Jessie 8.1 64 Bit
> Maven 3.0.5-3
> OpenJDK 7u79-2.5.5-1~deb8u1
> German language
>Reporter: Lars Cebulla
>Assignee: Henri Biestro
>Priority: Blocker
>
> Hi,
> I got errors when I try to compile / test JEXL because ClassCreatorTest fails.
> At line 51, it uses "File.pathSeparator", which is wrong. It has to be just
> "File.separator".
> Thanks in advance!
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (JEXL-157) Replace File.pathSeparator with File.separator
[
https://issues.apache.org/jira/browse/JEXL-157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14608077#comment-14608077
]
Sebb commented on JEXL-157:
---
Note: it was probably not spotted because System.getProperty("java.io.tmpdir")
returns a string ending with "/" - i.e. the separator char - (at least on my
system) and pathSeparator (:) is valid as a leading filename character on many
systems.
I think it's safer to use the appropriate File class ctor rather than making
assumptions about how OS file path names are constructed.
> Replace File.pathSeparator with File.separator
> --
>
> Key: JEXL-157
> URL: https://issues.apache.org/jira/browse/JEXL-157
> Project: Commons JEXL
> Issue Type: Bug
>Affects Versions: 3.0
> Environment: Debian Jessie 8.1 64 Bit
> Maven 3.0.5-3
> OpenJDK 7u79-2.5.5-1~deb8u1
> German language
>Reporter: Lars Cebulla
>Assignee: Henri Biestro
>Priority: Blocker
>
> Hi,
> I got errors when I try to compile / test JEXL because ClassCreatorTest fails.
> At line 51, it uses "File.pathSeparator", which is wrong. It has to be just
> "File.separator".
> Thanks in advance!
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (JEXL-157) Replace File.pathSeparator with File.separator
[ https://issues.apache.org/jira/browse/JEXL-157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14608065#comment-14608065 ] Sebb commented on JEXL-157: --- Jexl3: URL: http://svn.apache.org/r1688417 Log: JEXL-157 Replace File.pathSeparator with File.separator Alternate fix - use File(parent,child) ctor Jexl2: URL: http://svn.apache.org/r1688418 Log: JEXL-157 Replace File.pathSeparator with File.separator Alternate fix - use File(parent,child) ctor > Replace File.pathSeparator with File.separator > -- > > Key: JEXL-157 > URL: https://issues.apache.org/jira/browse/JEXL-157 > Project: Commons JEXL > Issue Type: Bug >Affects Versions: 3.0 > Environment: Debian Jessie 8.1 64 Bit > Maven 3.0.5-3 > OpenJDK 7u79-2.5.5-1~deb8u1 > German language >Reporter: Lars Cebulla >Assignee: Henri Biestro >Priority: Blocker > > Hi, > I got errors when I try to compile / test JEXL because ClassCreatorTest fails. > At line 51, it uses "File.pathSeparator", which is wrong. It has to be just > "File.separator". > Thanks in advance! -- This message was sent by Atlassian JIRA (v6.3.4#6332)
