[JBoss JIRA] (ISPN-12367) ServerRunMode.FORKED can leak running "tail -f tail -f .../server/log/server.log" processes
by Radoslav Husar (Jira)
[ https://issues.redhat.com/browse/ISPN-12367?page=com.atlassian.jira.plugi... ]
Radoslav Husar reassigned ISPN-12367:
-------------------------------------
Assignee: Radoslav Husar
> ServerRunMode.FORKED can leak running "tail -f tail -f .../server/log/server.log" processes
> -------------------------------------------------------------------------------------------
>
> Key: ISPN-12367
> URL: https://issues.redhat.com/browse/ISPN-12367
> Project: Infinispan
> Issue Type: Bug
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
> Priority: Major
>
> After a couple of test runs:
> {noformat}
> [rhusar@ribera clustering]$ ps
> PID TTY TIME CMD
> 44513 ttys000 0:00.03 /Applications/iTerm.app/Contents/MacOS/iTerm2 --server /usr/bin/login -fpl rhusar /Applications/iTerm.app/Contents/MacOS/iTerm2 --launch_shell
> 44516 ttys000 0:01.13 -bash
> 6297 ttys001 0:00.06 /Applications/iTerm.app/Contents/MacOS/iTerm2 --server /usr/bin/login -fpl rhusar /Applications/iTerm.app/Contents/MacOS/iTerm2 --launch_shell
> 6299 ttys001 0:00.54 -bash
> 15288 ttys001 0:02.20 watch jps -l | sort
> 2833 ttys002 0:00.00 tail -f /Users/rhusar/git/wildfly/testsuite/integration/clustering/target/infinispan-server-11.0.3.Final/server/log/server.log
> 2976 ttys002 0:00.01 tail -f /Users/rhusar/git/wildfly/testsuite/integration/clustering/target/infinispan-server-11.0.3.Final/server/log/server.log
> 3213 ttys002 0:00.01 tail -f /Users/rhusar/git/wildfly/testsuite/integration/clustering/target/infinispan-server-11.0.3.Final/server/log/server.log
> 3421 ttys002 0:00.01 tail -f /Users/rhusar/git/wildfly/testsuite/integration/clustering/target/infinispan-server-11.0.3.Final/server/log/server.log
> 3738 ttys002 0:00.01 tail -f /Users/rhusar/git/wildfly/testsuite/integration/clustering/target/infinispan-server-11.0.3.Final/server/log/server.log
> 4040 ttys002 0:00.01 tail -f /Users/rhusar/git/wildfly/testsuite/integration/clustering/target/infinispan-server-11.0.3.Final/server/log/server.log
> 4445 ttys002 0:00.01 tail -f /Users/rhusar/git/wildfly/testsuite/integration/clustering/target/infinispan-server-11.0.3.Final/server/log/server.log
> 4748 ttys002 0:00.01 tail -f /Users/rhusar/git/wildfly/testsuite/integration/clustering/target/infinispan-server-11.0.3.Final/server/log/server.log
> 6246 ttys002 0:00.01 tail -f /Users/rhusar/git/wildfly/testsuite/integration/clustering/target/infinispan-server-11.0.3.Final/server/log/server.log
> 6657 ttys002 0:00.01 tail -f /Users/rhusar/git/wildfly/testsuite/integration/clustering/target/infinispan-server-11.0.3.Final/server/log/server.log
> 6871 ttys002 0:00.01 tail -f /Users/rhusar/git/wildfly/testsuite/integration/clustering/target/infinispan-server-11.0.3.Final/server/log/server.log
> 7046 ttys002 0:00.01 tail -f /Users/rhusar/git/wildfly/testsuite/integration/clustering/target/infinispan-server-11.0.3.Final/server/log/server.log
> 7358 ttys002 0:00.01 tail -f /Users/rhusar/git/wildfly/testsuite/integration/clustering/target/infinispan-server-11.0.3.Final/server/log/server.log
> 7697 ttys002 0:00.01 tail -f /Users/rhusar/git/wildfly/testsuite/integration/clustering/target/infinispan-server-11.0.3.Final/server/log/server.log
> 9209 ttys002 0:00.01 tail -f /Users/rhusar/git/wildfly/testsuite/integration/clustering/target/infinispan-server-11.0.3.Final/server/log/server.log
> 9356 ttys002 0:00.01 tail -f /Users/rhusar/git/wildfly/testsuite/integration/clustering/target/infinispan-server-11.0.3.Final/server/log/server.log
> 9482 ttys002 0:00.01 tail -f /Users/rhusar/git/wildfly/testsuite/integration/clustering/target/infinispan-server-11.0.3.Final/server/log/server.log
> 9904 ttys002 0:00.02 tail -f /Users/rhusar/git/wildfly/testsuite/integration/clustering/target/infinispan-server-11.0.3.Final/server/log/server.log
> 10059 ttys002 0:00.01 tail -f /Users/rhusar/git/wildfly/testsuite/integration/clustering/target/infinispan-server-11.0.3.Final/server/log/server.log
> 10485 ttys002 0:00.01 tail -f /Users/rhusar/git/wildfly/testsuite/integration/clustering/target/infinispan-server-11.0.3.Final/server/log/server.log
> 10754 ttys002 0:00.01 tail -f /Users/rhusar/git/wildfly/testsuite/integration/clustering/target/infinispan-server-11.0.3.Final/server/log/server.log
> 10921 ttys002 0:00.01 tail -f /Users/rhusar/git/wildfly/testsuite/integration/clustering/target/infinispan-server-11.0.3.Final/server/log/server.log
> 11082 ttys002 0:00.01 tail -f /Users/rhusar/git/wildfly/testsuite/integration/clustering/target/infinispan-server-11.0.3.Final/server/log/server.log
> 11355 ttys002 0:00.01 tail -f /Users/rhusar/git/wildfly/testsuite/integration/clustering/target/infinispan-server-11.0.3.Final/server/log/server.log
> 15149 ttys002 0:00.01 tail -f /Users/rhusar/git/wildfly/testsuite/integration/clustering/target/infinispan-server-11.0.3.Final/server/log/server.log
> 15642 ttys002 0:00.01 tail -f /Users/rhusar/git/wildfly/testsuite/integration/clustering/target/infinispan-server-11.0.3.Final/server/log/server.log
> 15839 ttys002 0:00.01 tail -f /Users/rhusar/git/wildfly/testsuite/integration/clustering/target/infinispan-server-11.0.3.Final/server/log/server.log
> 16370 ttys002 0:00.01 tail -f /Users/rhusar/git/wildfly/testsuite/integration/clustering/target/infinispan-server-11.0.3.Final/server/log/server.log
> 16914 ttys002 0:00.01 tail -f /Users/rhusar/git/wildfly/testsuite/integration/clustering/target/infinispan-server-11.0.3.Final/server/log/server.log
> 17066 ttys002 0:00.01 tail -f /Users/rhusar/git/wildfly/testsuite/integration/clustering/target/infinispan-server-11.0.3.Final/server/log/server.log
> 17604 ttys002 0:00.01 tail -f /Users/rhusar/git/wildfly/testsuite/integration/clustering/target/infinispan-server-11.0.3.Final/server/log/server.log
> 17893 ttys002 0:00.01 tail -f /Users/rhusar/git/wildfly/testsuite/integration/clustering/target/infinispan-server-11.0.3.Final/server/log/server.log
> 18034 ttys002 0:00.01 tail -f /Users/rhusar/git/wildfly/testsuite/integration/clustering/target/infinispan-server-11.0.3.Final/server/log/server.log
> 18385 ttys002 0:00.01 tail -f /Users/rhusar/git/wildfly/testsuite/integration/clustering/target/infinispan-server-11.0.3.Final/server/log/server.log
> {noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years
[JBoss JIRA] (IPROTO-162) MirrorClass.getEnclosingClass() is broken and always returs null leading to wrong schema being generated
by Nistor Adrian (Jira)
[ https://issues.redhat.com/browse/IPROTO-162?page=com.atlassian.jira.plugi... ]
Nistor Adrian updated IPROTO-162:
---------------------------------
Description:
Message types generated with annotation processing during compile time should follow the nesting of the (annotated) classes from which they are generated. But since getEnclosingClass() always returns null that leads to all types wrongly becoming top level types in the generated schema starting with 4.3.0 when this bug appeared.
Interestingly, the runtime variant of this, ReflectionClass.getEnclosingClass() works correctly and we only test that one in our suite and not the compile time variant so it flew under the radar. The schema generated by the runtime annotation processor does indeed follow the nesting of the initial classes.
Fixing this issue is very important in the long run but will be disruptive for some users currently using nested annotated classes with compile time annotation processing.
The fix will have the important side effect of breaking the compatibility of data stored as a WrappedMessage (notably Infinispan) because the type name changes as a consequence of the nesting (but please note the structure of messages does not change!). These usages are not affected if the message types in question have a TypeId annotation, in which case WrappedMessage identifies the type base on its numeric id rather than its fully qualified name.
The only way to work around the data compat issue is to change your java classes so as not to use nesting with the end result of the schema being generated exactly as before this bug fix (all types are top level).
was:
Message types generated with annotation processing during compile time should follow the nesting of the (annotated) classes from which they are generated. But since getEnclosingClass() always returns null that leads to all types wrongly becoming top level types in the generated schema starting with 4.3.0 when this bug appeared.
Interestingly, the runtime variant of this, ReflectionClass.getEnclosingClass() works correctly and we only test that one in our suite, and not the compile time variant. The schema generated by the runtime annotation processor does indeed follow the nesting of the initial classes.
Fixing this issue is very important in the long run but will be disruptive for some users currently using nested annotated classes with compile time annotation processing.
The fix will have the important side effect of breaking the compatibility of data stored as a WrappedMessage (notably Infinispan) because the type name changes as a consequence of the nesting. These usages are not affected if the message types in question have a TypeId annotation, in which case WrappedMessage identifies the type base on its numeric id rather than its fully qualified name.
The only way to work around the data compat issue is to change your java classes so as not to use nesting with the end result of the schema being generated exactly as before this bug fix.
> MirrorClass.getEnclosingClass() is broken and always returs null leading to wrong schema being generated
> --------------------------------------------------------------------------------------------------------
>
> Key: IPROTO-162
> URL: https://issues.redhat.com/browse/IPROTO-162
> Project: Infinispan ProtoStream
> Issue Type: Bug
> Affects Versions: 4.3.0.Final
> Reporter: Nistor Adrian
> Assignee: Nistor Adrian
> Priority: Major
> Fix For: 4.4.0.Alpha1, 4.3.4.Final
>
>
> Message types generated with annotation processing during compile time should follow the nesting of the (annotated) classes from which they are generated. But since getEnclosingClass() always returns null that leads to all types wrongly becoming top level types in the generated schema starting with 4.3.0 when this bug appeared.
>
> Interestingly, the runtime variant of this, ReflectionClass.getEnclosingClass() works correctly and we only test that one in our suite and not the compile time variant so it flew under the radar. The schema generated by the runtime annotation processor does indeed follow the nesting of the initial classes.
>
> Fixing this issue is very important in the long run but will be disruptive for some users currently using nested annotated classes with compile time annotation processing.
> The fix will have the important side effect of breaking the compatibility of data stored as a WrappedMessage (notably Infinispan) because the type name changes as a consequence of the nesting (but please note the structure of messages does not change!). These usages are not affected if the message types in question have a TypeId annotation, in which case WrappedMessage identifies the type base on its numeric id rather than its fully qualified name.
> The only way to work around the data compat issue is to change your java classes so as not to use nesting with the end result of the schema being generated exactly as before this bug fix (all types are top level).
>
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years
[JBoss JIRA] (IPROTO-162) MirrorClass.getEnclosingClass() is broken and always returs null leading to wrong schema being generated
by Nistor Adrian (Jira)
[ https://issues.redhat.com/browse/IPROTO-162?page=com.atlassian.jira.plugi... ]
Nistor Adrian updated IPROTO-162:
---------------------------------
Description:
Message types generated with annotation processing during compile time should follow the nesting of the (annotated) classes from which they are generated. But since getEnclosingClass() always returns null that leads to all types wrongly becoming top level types in the generated schema starting with 4.3.0 when this bug appeared.
Interestingly, the runtime variant of this, ReflectionClass.getEnclosingClass() works correctly and we only test that one in our suite, and not the compile time variant. The schema generated by the runtime annotation processor does indeed follow the nesting of the initial classes.
Fixing this issue is very important in the long run but will be disruptive for some users currently using nested annotated classes with compile time annotation processing.
The fix will have the important side effect of breaking the compatibility of data stored as a WrappedMessage (notably Infinispan) because the type name changes as a consequence of the nesting. These usages are not affected if the message types in question have a TypeId annotation, in which case WrappedMessage identifies the type base on its numeric id rather than its fully qualified name.
The only way to work around the data compat issue is to change your java classes so as not to use nesting with the end result of the schema being generated exactly as before this bug fix.
was:
Message types generated with annotation processing during compile time should follow the nesting of the (annotated) classes from which they are generated. But since getEnclosingClass() always returns null that leads to all types wrongly becoming top level types in the generated schema starting with 4.3.0 when this bug appeared.
Interestingly, the runtime variant of this, ReflectionClass.getEnclosingClass() works correctly and we only test that one in our suite. The schema generated by the runtime annotation processor does indeed follow the nesting of the initial classes.
Fixing this issue is very important in the long run but will be disruptive for some users currently using nested annotated classes with compile time annotation processing.
The fix will have the important side effect of breaking the compatibility of data stored as WrappedMessage (notably Infinispan) because the type name changes as a consequence of the nesting.
The only way to work around the data compat issue is to change your java classes do as not to use nesting and basically with the end result of the schema being generated exactly as before the fix.
> MirrorClass.getEnclosingClass() is broken and always returs null leading to wrong schema being generated
> --------------------------------------------------------------------------------------------------------
>
> Key: IPROTO-162
> URL: https://issues.redhat.com/browse/IPROTO-162
> Project: Infinispan ProtoStream
> Issue Type: Bug
> Affects Versions: 4.3.0.Final
> Reporter: Nistor Adrian
> Assignee: Nistor Adrian
> Priority: Major
> Fix For: 4.4.0.Alpha1, 4.3.4.Final
>
>
> Message types generated with annotation processing during compile time should follow the nesting of the (annotated) classes from which they are generated. But since getEnclosingClass() always returns null that leads to all types wrongly becoming top level types in the generated schema starting with 4.3.0 when this bug appeared.
>
> Interestingly, the runtime variant of this, ReflectionClass.getEnclosingClass() works correctly and we only test that one in our suite, and not the compile time variant. The schema generated by the runtime annotation processor does indeed follow the nesting of the initial classes.
>
> Fixing this issue is very important in the long run but will be disruptive for some users currently using nested annotated classes with compile time annotation processing.
> The fix will have the important side effect of breaking the compatibility of data stored as a WrappedMessage (notably Infinispan) because the type name changes as a consequence of the nesting. These usages are not affected if the message types in question have a TypeId annotation, in which case WrappedMessage identifies the type base on its numeric id rather than its fully qualified name.
> The only way to work around the data compat issue is to change your java classes so as not to use nesting with the end result of the schema being generated exactly as before this bug fix.
>
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years
[JBoss JIRA] (IPROTO-162) MirrorClass.getEnclosingClass() is broken and always returs null leading to wrong schema being generated
by Nistor Adrian (Jira)
[ https://issues.redhat.com/browse/IPROTO-162?page=com.atlassian.jira.plugi... ]
Nistor Adrian updated IPROTO-162:
---------------------------------
Description:
Message types generated with annotation processing during compile time should follow the nesting of the (annotated) classes from which they are generated. But since getEnclosingClass() always returns null that leads to all types wrongly becoming top level types in the generated schema starting with 4.3.0 when this bug appeared.
Interestingly, the runtime variant of this, ReflectionClass.getEnclosingClass() works correctly and we only test that one in our suite. The schema generated by the runtime annotation processor does indeed follow the nesting of the initial classes.
Fixing this issue is very important in the long run but will be disruptive for some users currently using nested annotated classes with compile time annotation processing.
The fix will have the important side effect of breaking the compatibility of data stored as WrappedMessage (notably Infinispan) because the type name changes as a consequence of the nesting.
The only way to work around the data compat issue is to change your java classes do as not to use nesting and basically with the end result of the schema being generated exactly as before the fix.
was:
Message types generated with annotation processing during compile time should follow the nesting of the classes from which they are generated. But since getEnclosingClass() always returns null that leads to all types becoming top level types in the generated schema.
Interestingly, the runtime variant of this, ReflectionClass.getEnclosingClass() works correctly and we only test that one in our suite.
> MirrorClass.getEnclosingClass() is broken and always returs null leading to wrong schema being generated
> --------------------------------------------------------------------------------------------------------
>
> Key: IPROTO-162
> URL: https://issues.redhat.com/browse/IPROTO-162
> Project: Infinispan ProtoStream
> Issue Type: Bug
> Affects Versions: 4.3.0.Final
> Reporter: Nistor Adrian
> Assignee: Nistor Adrian
> Priority: Major
> Fix For: 4.4.0.Alpha1, 4.3.4.Final
>
>
> Message types generated with annotation processing during compile time should follow the nesting of the (annotated) classes from which they are generated. But since getEnclosingClass() always returns null that leads to all types wrongly becoming top level types in the generated schema starting with 4.3.0 when this bug appeared.
>
> Interestingly, the runtime variant of this, ReflectionClass.getEnclosingClass() works correctly and we only test that one in our suite. The schema generated by the runtime annotation processor does indeed follow the nesting of the initial classes.
>
> Fixing this issue is very important in the long run but will be disruptive for some users currently using nested annotated classes with compile time annotation processing.
> The fix will have the important side effect of breaking the compatibility of data stored as WrappedMessage (notably Infinispan) because the type name changes as a consequence of the nesting.
> The only way to work around the data compat issue is to change your java classes do as not to use nesting and basically with the end result of the schema being generated exactly as before the fix.
>
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years