[JBoss JIRA] (WFLY-9230) ServletPrintWriter.checkError does not flush
by tony weston (JIRA)
tony weston created WFLY-9230:
---------------------------------
Summary: ServletPrintWriter.checkError does not flush
Key: WFLY-9230
URL: https://issues.jboss.org/browse/WFLY-9230
Project: WildFly
Issue Type: Bug
Affects Versions: 10.1.0.Final
Reporter: tony weston
Assignee: Jason Greene
Priority: Minor
io.undertow.servlet.spec.ServletPrintWriter.checkError() does not flush the stream.
according to JDK docs, printWriter.checkError() 'Flushes the stream if it's not closed and checks its error state'. This bug discovered by accident when converting a Payara to wildfly, which used checkError to flush the stream, and check errors.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (JGRP-2209) Members leaving the cluster
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2209?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2209:
--------------------------------
Let's do this via email, not on the ticket. I can be reached at belaban at mailbox dot org.
Regards,
> Members leaving the cluster
> ---------------------------
>
> Key: JGRP-2209
> URL: https://issues.jboss.org/browse/JGRP-2209
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.0
> Environment: Linux
> Reporter: Swathi Kumar
> Assignee: Bela Ban
>
> We recently upgraded the jgroups jars from version 2_5_2/jgroups-all.jar to 3_4_0/jgroups-3.4.0.Alpha2.jar.
> With the upgrade we see our clusters are not stable.
> The members leave the cluster for short duration of time (say around 5-6m) and join back on their own.
> We initially suspected it to be a network issue and we involved the network team to investiate further.
> But after reviewing the network logs, it is very much evident that the network has no role to play in members leaving the cluster. The boxes on which the nodes/members are running are healthy and fine and the network is very fast and healthy too.
> We are not able to determine the root cause for the members leaving the clusters.
> Please note, we have multiple clusters configured (round about 5-6) and we are experiencing the same problem on all the clusters.
> We request you to kindly help us in resolving this issue.
> We have the below jgroups config properties in our application to create 3 channels (for security reasons have used a dummy host name here) :-
> jgroups_cluster.property_string=TCP(bind_addr=host_name_A;bind_port=34061):TCPPING(initial_hosts=host_name_A[34061],host_name_A[44061],host_name_A[54061];port_range=1;timeout=5000;num_initial_members=2):MERGE2(min_interval=3000;max_interval=5000):FD_ALL(interval=5000;timeout=20000):FD(timeout=5000;max_tries=48):VERIFY_SUSPECT(timeout=1500):pbcast.NAKACK(retransmit_timeout=100,200,300,600,1200,2400,4800;discard_delivered_msgs=true):pbcast.STABLE(stability_delay=1000;desired_avg_gossip=20000;max_bytes=0):pbcast.GMS(print_local_addr=true;join_timeout=5000)
> jgroups_cluster.distribution_property_string=TCP(bind_port= 34060;thread_pool_rejection_policy=run):TCPPING(initial_hosts=host_name_A[34060],host_name_A[44060],host_name_A[54060];port_range=1;timeout=5000;num_initial_members=2):MERGE2(min_interval=3000;max_interval=5000):FD_SOCK:FD(timeout=5000;max_tries=48):VERIFY_SUSPECT(timeout=1500):pbcast.NAKACK(retransmit_timeout=3000;discard_delivered_msgs=true):pbcast.STABLE(stability_delay=1000;desired_avg_gossip=20000;max_bytes=0):pbcast.GMS(join_timeout=5000;print_local_addr=true)
> jgroups_cluster.lock.protocolStack=TCP(bind_addr=host_name_A;bind_port=34062:TCPPING(initial_hosts=host_name_A[34062],host_name_A[44062],host_name_A[54062];port_range=1;timeout=5000;num_initial_members=2):MERGE2(min_interval=3000;max_interval=5000):FD_ALL(interval=5000;timeout=20000):FD(timeout=5000;max_tries=48):VERIFY_SUSPECT(timeout=1500):pbcast.NAKACK(retransmit_timeout=100,200,300,600,1200,2400,4800;discard_delivered_msgs=true):pbcast.STABLE(stability_delay=1000;desired_avg_gossip=20000;max_bytes=0):pbcast.GMS(print_local_addr=true;join_timeout=5000)
> Please let us know if you need any logs from our end.
> Kindly consider this on priority as our business is at stake with this issue happening on a daily basis.
> Many thanks in advance.
> Regards
> Swathi BN
> (IBM)
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (JGRP-2209) Members leaving the cluster
by Swathi Kumar (JIRA)
[ https://issues.jboss.org/browse/JGRP-2209?page=com.atlassian.jira.plugin.... ]
Swathi Kumar commented on JGRP-2209:
------------------------------------
Many thanks Bela for your willingness for a screen share session.
Please let me know your availability so that I can schedule a meeting to go over this issue.
Regards
Swathi BN
(IBM)
> Members leaving the cluster
> ---------------------------
>
> Key: JGRP-2209
> URL: https://issues.jboss.org/browse/JGRP-2209
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.0
> Environment: Linux
> Reporter: Swathi Kumar
> Assignee: Bela Ban
>
> We recently upgraded the jgroups jars from version 2_5_2/jgroups-all.jar to 3_4_0/jgroups-3.4.0.Alpha2.jar.
> With the upgrade we see our clusters are not stable.
> The members leave the cluster for short duration of time (say around 5-6m) and join back on their own.
> We initially suspected it to be a network issue and we involved the network team to investiate further.
> But after reviewing the network logs, it is very much evident that the network has no role to play in members leaving the cluster. The boxes on which the nodes/members are running are healthy and fine and the network is very fast and healthy too.
> We are not able to determine the root cause for the members leaving the clusters.
> Please note, we have multiple clusters configured (round about 5-6) and we are experiencing the same problem on all the clusters.
> We request you to kindly help us in resolving this issue.
> We have the below jgroups config properties in our application to create 3 channels (for security reasons have used a dummy host name here) :-
> jgroups_cluster.property_string=TCP(bind_addr=host_name_A;bind_port=34061):TCPPING(initial_hosts=host_name_A[34061],host_name_A[44061],host_name_A[54061];port_range=1;timeout=5000;num_initial_members=2):MERGE2(min_interval=3000;max_interval=5000):FD_ALL(interval=5000;timeout=20000):FD(timeout=5000;max_tries=48):VERIFY_SUSPECT(timeout=1500):pbcast.NAKACK(retransmit_timeout=100,200,300,600,1200,2400,4800;discard_delivered_msgs=true):pbcast.STABLE(stability_delay=1000;desired_avg_gossip=20000;max_bytes=0):pbcast.GMS(print_local_addr=true;join_timeout=5000)
> jgroups_cluster.distribution_property_string=TCP(bind_port= 34060;thread_pool_rejection_policy=run):TCPPING(initial_hosts=host_name_A[34060],host_name_A[44060],host_name_A[54060];port_range=1;timeout=5000;num_initial_members=2):MERGE2(min_interval=3000;max_interval=5000):FD_SOCK:FD(timeout=5000;max_tries=48):VERIFY_SUSPECT(timeout=1500):pbcast.NAKACK(retransmit_timeout=3000;discard_delivered_msgs=true):pbcast.STABLE(stability_delay=1000;desired_avg_gossip=20000;max_bytes=0):pbcast.GMS(join_timeout=5000;print_local_addr=true)
> jgroups_cluster.lock.protocolStack=TCP(bind_addr=host_name_A;bind_port=34062:TCPPING(initial_hosts=host_name_A[34062],host_name_A[44062],host_name_A[54062];port_range=1;timeout=5000;num_initial_members=2):MERGE2(min_interval=3000;max_interval=5000):FD_ALL(interval=5000;timeout=20000):FD(timeout=5000;max_tries=48):VERIFY_SUSPECT(timeout=1500):pbcast.NAKACK(retransmit_timeout=100,200,300,600,1200,2400,4800;discard_delivered_msgs=true):pbcast.STABLE(stability_delay=1000;desired_avg_gossip=20000;max_bytes=0):pbcast.GMS(print_local_addr=true;join_timeout=5000)
> Please let us know if you need any logs from our end.
> Kindly consider this on priority as our business is at stake with this issue happening on a daily basis.
> Many thanks in advance.
> Regards
> Swathi BN
> (IBM)
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (WFCORE-3185) Run parallel boot tasks in coarser grained chunks
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3185?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-3185:
-------------------------------------
Description:
Currently parallel boot works by executing one task per Extension.initializeParsers call, one per Extension.initialize call and 2 per subsystem, one for execution of Stage.MODEL ops and one for Stage.RUNTIME ops. The Extension.initializeParsers tasks complete before boot proceeds to the point where any Extension.initialize tasks run, and the Extension.initialize tasks complete before the Stage.MODEL tasks run. The Stage.MODEL tasks do the large bulk of their work before the Stage.RUNTIME tasks run, but they do block waiting for the Stage.RUNTIME tasks and the rest of the boot to complete.
The rough effect of all this is we are allocating 2 threads per subsystem to do parallel boot, and at various points we have 1 thread per subsystem concurrently working. For a brief period (doing Stage.DONE of the post-extension boot op) we have 2 threads per subsystem concurrently working.
My measurements show that all of this concurrent work reduces boot time about 400ms on my machine, using the full WildFly standalone-full.xml config. However, this approach uses a lot of threads. So the task here is to look into how to get the same or better boot speed while using fewer threads. (Note the threads will expire and be gc'd after boot.)
The obvious way to do this is to look at each of the 4 task types discussed in the first paragraph and group things into larger units of work than a single extension/subsystem.
Initial work on doing this shows that using more coarse grained chunks does not result in reduced boot time, but also seems not to increase boot time. Further measurement is needed to confirm this though, and small tweaks may show different results.
Another thing to consider is allowing the Stage.MODEL tasks to complete without waiting for the overall boot op to complete. This might reduce the max number of threads involved and perhaps will allow a tiny bit more parallelization of work. The key here is ensuring the Stage.MODEL tasks are not able to affect the state of the final system in an invalid way. That could be problematic or fragile, so it's just something to consider, and if done must be done with great care.
Even if this work produces no reduction in boot time, if it produces no increase there is some value in incorporating it, as avoiding unnecessary thread creation improves the impression of the efficiency and good design of the software.
was:
Currently parallel boot works by executing one task per Extension.initializeParsers call, one per Extension.initialize call and 2 per subsystem, one for execution of Stage.MODEL ops and one for Stage.RUNTIME ops. The Extension.initializeParsers tasks complete before boot proceeds to the point where any Extension.initialize tasks run, and the Extension.initialize tasks complete before the Stage.MODEL tasks run. The Stage.MODEL tasks do the large bulk of their work before the Stage.RUNTIME tasks run, but they do block waiting for the Stage.RUNTIME tasks and the rest of the boot to complete.
The rough effect of all this is we are allocating 2 threads per subsystem to do parallel boot, and at various points we have 1 thread per subsystem concurrently working. For a brief period (doing Stage.DONE of the post-extension boot op) we have 2 threads per subsystem concurrently working.
My measurements show that all of this concurrent work reduces boot time about 400ms on my machine, using the full WildFly standalone-full.xml config. However, this approach uses a lot of threads. So the task here is to look into how to get the same or better boot speed while using fewer threads. (Note the the threads will expire and be gc'd after boot.)
The obvious way to do that is to look at each of the 4 task types discussed in the first paragraph and group things into larger units of work than a single extension/subsystem.
Initial work on doing this shows that using more coarse grained chunks does not result in reduced boot time, but also seems not to increase boot time. Further measurement is needed to confirm this though, and small tweaks may show different results.
Another thing to consider is allowing the Stage.MODEL tasks to complete without waiting for the overall boot op to complete. This might reduce the max number of threads involved and perhaps will allow a tiny bit more parallelization of work. The key here is ensuring the Stage.MODEL tasks are not able to affect the state of the final system in an invalid way. That could be problematic or fragile, so it's just something to consider, and if done must be done with great care.
Even if this work produces no reduction in boot time, if it produces no gain, there is some value in incorporating it, as avoiding unnecessary thread creation improves the impression of the efficiency and good design of the software.
> Run parallel boot tasks in coarser grained chunks
> -------------------------------------------------
>
> Key: WFCORE-3185
> URL: https://issues.jboss.org/browse/WFCORE-3185
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Fix For: 4.0.0.Alpha1
>
>
> Currently parallel boot works by executing one task per Extension.initializeParsers call, one per Extension.initialize call and 2 per subsystem, one for execution of Stage.MODEL ops and one for Stage.RUNTIME ops. The Extension.initializeParsers tasks complete before boot proceeds to the point where any Extension.initialize tasks run, and the Extension.initialize tasks complete before the Stage.MODEL tasks run. The Stage.MODEL tasks do the large bulk of their work before the Stage.RUNTIME tasks run, but they do block waiting for the Stage.RUNTIME tasks and the rest of the boot to complete.
> The rough effect of all this is we are allocating 2 threads per subsystem to do parallel boot, and at various points we have 1 thread per subsystem concurrently working. For a brief period (doing Stage.DONE of the post-extension boot op) we have 2 threads per subsystem concurrently working.
> My measurements show that all of this concurrent work reduces boot time about 400ms on my machine, using the full WildFly standalone-full.xml config. However, this approach uses a lot of threads. So the task here is to look into how to get the same or better boot speed while using fewer threads. (Note the threads will expire and be gc'd after boot.)
> The obvious way to do this is to look at each of the 4 task types discussed in the first paragraph and group things into larger units of work than a single extension/subsystem.
> Initial work on doing this shows that using more coarse grained chunks does not result in reduced boot time, but also seems not to increase boot time. Further measurement is needed to confirm this though, and small tweaks may show different results.
> Another thing to consider is allowing the Stage.MODEL tasks to complete without waiting for the overall boot op to complete. This might reduce the max number of threads involved and perhaps will allow a tiny bit more parallelization of work. The key here is ensuring the Stage.MODEL tasks are not able to affect the state of the final system in an invalid way. That could be problematic or fragile, so it's just something to consider, and if done must be done with great care.
> Even if this work produces no reduction in boot time, if it produces no increase there is some value in incorporating it, as avoiding unnecessary thread creation improves the impression of the efficiency and good design of the software.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (DROOLS-1703) When incompatible varargs constructors exist, resolution sometimes incorrect
by Gerard Krupa (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1703?page=com.atlassian.jira.plugi... ]
Gerard Krupa updated DROOLS-1703:
---------------------------------
Summary: When incompatible varargs constructors exist, resolution sometimes incorrect (was: When multiple varargs constructors exist, resolution sometimes incorrect)
> When incompatible varargs constructors exist, resolution sometimes incorrect
> ----------------------------------------------------------------------------
>
> Key: DROOLS-1703
> URL: https://issues.jboss.org/browse/DROOLS-1703
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.5.0.Final
> Environment: Ubuntu 16..0.4 (x86_64)
> openjdk version "1.8.0_131"
> OpenJDK Runtime Environment (build 1.8.0_131-b12)
> OpenJDK 64-Bit Server VM (build 25.131-b12, mixed mode)
> Apache Maven 3.5.0 (ff8f5e7444045639af65f6095c62210b5713f426; 2017-04-03T19:39:06Z)
> Reporter: Gerard Krupa
> Assignee: Mario Fusco
>
> We have a class with 3 constructors:
> Thingy(String name)
> Thingy(String name, Object... args)
> Thingy(String name, String version, Object... args)
> When calling the constructor with a single paramater from a DRL:
> Thingy(drools.getRule().getName())
> we sometimes get an odd exception in our unit tests:
> {{[INFO] java.lang.StringIndexOutOfBoundsException: String index out of range: -1
> [INFO] at java.lang.String.substring(String.java:1927)
> [INFO] at org.mvel2.util.ErrorUtil.rewriteIfNeeded(ErrorUtil.java:17)
> [INFO] at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.getMethod(ReflectiveAccessorOptimizer.java:975)
> [INFO] at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.compileGetChain(ReflectiveAccessorOptimizer.java:396)
> [INFO] at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.optimizeAccessor(ReflectiveAccessorOptimizer.java:163)}}
> The root cause of the issue appears to be the selection of varargs constructors by ParseTools.getBestConstructorCandidate and getMethodScore. The scoring checks that the arguments from left to right match the expected parameter classes and scores based on their coerce-ability. The scoring then compares the number of parameters to arguments *only* if the accumulated score is still 0 (and at this point it's not zero because the first parameter matched the expected type).
> All 3 constructors in this list score and match the same and if the incompatible constructor is examined first then it's used. This in turn causes VarArgs.normalizeArgsForVarArgs to attempt to create an array of size -1 as it calculates the needed size of the varargs array. The reported exception seems to be generated as the exception handler itself crashes, being unable to deal with the root cause error.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (DROOLS-1703) When multiple varargs constructors exist, resolution sometimes incorrect
by Gerard Krupa (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1703?page=com.atlassian.jira.plugi... ]
Gerard Krupa updated DROOLS-1703:
---------------------------------
Steps to Reproduce: Create a class with the stated constructor types and attempt to call the first constructor from a rule. Rebuild multiple times (the error is intermittent depending on the order in which the constructors are evaluated). (was: Create a class with the above constructor types and attempt to call the first constructor from a rule. Rebuild multiple times (the error is intermittent depending on the order in which the constructors are evaluated).)
> When multiple varargs constructors exist, resolution sometimes incorrect
> ------------------------------------------------------------------------
>
> Key: DROOLS-1703
> URL: https://issues.jboss.org/browse/DROOLS-1703
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.5.0.Final
> Environment: Ubuntu 16..0.4 (x86_64)
> openjdk version "1.8.0_131"
> OpenJDK Runtime Environment (build 1.8.0_131-b12)
> OpenJDK 64-Bit Server VM (build 25.131-b12, mixed mode)
> Apache Maven 3.5.0 (ff8f5e7444045639af65f6095c62210b5713f426; 2017-04-03T19:39:06Z)
> Reporter: Gerard Krupa
> Assignee: Mario Fusco
>
> We have a class with 3 constructors:
> Thingy(String name)
> Thingy(String name, Object... args)
> Thingy(String name, String version, Object... args)
> When calling the constructor with a single paramater from a DRL:
> Thingy(drools.getRule().getName())
> we sometimes get an odd exception in our unit tests:
> {{[INFO] java.lang.StringIndexOutOfBoundsException: String index out of range: -1
> [INFO] at java.lang.String.substring(String.java:1927)
> [INFO] at org.mvel2.util.ErrorUtil.rewriteIfNeeded(ErrorUtil.java:17)
> [INFO] at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.getMethod(ReflectiveAccessorOptimizer.java:975)
> [INFO] at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.compileGetChain(ReflectiveAccessorOptimizer.java:396)
> [INFO] at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.optimizeAccessor(ReflectiveAccessorOptimizer.java:163)}}
> The root cause of the issue appears to be the selection of varargs constructors by ParseTools.getBestConstructorCandidate and getMethodScore. The scoring checks that the arguments from left to right match the expected parameter classes and scores based on their coerce-ability. The scoring then compares the number of parameters to arguments *only* if the accumulated score is still 0 (and at this point it's not zero because the first parameter matched the expected type).
> All 3 constructors in this list score and match the same and if the incompatible constructor is examined first then it's used. This in turn causes VarArgs.normalizeArgsForVarArgs to attempt to create an array of size -1 as it calculates the needed size of the varargs array. The reported exception seems to be generated as the exception handler itself crashes, being unable to deal with the root cause error.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (DROOLS-1703) When multiple varargs constructors exist, resolution sometimes incorrect
by Gerard Krupa (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1703?page=com.atlassian.jira.plugi... ]
Gerard Krupa updated DROOLS-1703:
---------------------------------
Description:
We have a class with 3 constructors:
Thingy(String name)
Thingy(String name, Object... args)
Thingy(String name, String version, Object... args)
When calling the constructor with a single paramater from a DRL:
Thingy(drools.getRule().getName())
we sometimes get an odd exception in our unit tests:
{{[INFO] java.lang.StringIndexOutOfBoundsException: String index out of range: -1
[INFO] at java.lang.String.substring(String.java:1927)
[INFO] at org.mvel2.util.ErrorUtil.rewriteIfNeeded(ErrorUtil.java:17)
[INFO] at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.getMethod(ReflectiveAccessorOptimizer.java:975)
[INFO] at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.compileGetChain(ReflectiveAccessorOptimizer.java:396)
[INFO] at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.optimizeAccessor(ReflectiveAccessorOptimizer.java:163)}}
The root cause of the issue appears to be the selection of varargs constructors by ParseTools.getBestConstructorCandidate and getMethodScore. The scoring checks that the arguments from left to right match the expected parameter classes and scores based on their coerce-ability. The scoring then compares the number of parameters to arguments *only* if the accumulated score is still 0 (and at this point it's not zero because the first parameter matched the expected type).
All 3 constructors in this list score and match the same and if the incompatible constructor is examined first then it's used. This in turn causes VarArgs.normalizeArgsForVarArgs to attempt to create an array of size -1 as it calculates the needed size of the varargs array. The reported exception seems to be generated as the exception handler itself crashes, being unable to deal with the root cause error.
was:
We have a class with 3 constructors:
Thingy(String name)
Thingy(String name, Object... args)
Thingy(String name, String version, Object... args)
When calling the constructor with a single paramater from a DRL:
Thingy(drools.getRule().getName())
we sometimes get an odd exception in our unit tests:
{{[INFO] java.lang.StringIndexOutOfBoundsException: String index out of range: -1
[INFO] at java.lang.String.substring(String.java:1927)
[INFO] at org.mvel2.util.ErrorUtil.rewriteIfNeeded(ErrorUtil.java:17)
[INFO] at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.getMethod(ReflectiveAccessorOptimizer.java:975)
[INFO] at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.compileGetChain(ReflectiveAccessorOptimizer.java:396)
[INFO] at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.optimizeAccessor(ReflectiveAccessorOptimizer.java:163)}}
The root cause of the issue appears to be the selection of varargs constructors by ParseTools.getBestConstructorCandidate and getMethodScore. The scoring checks that the arguments from left to right match the expected parameter classes and scores based on their coerce-ability. The scoring then compares the number of parameters to arguments *only* if the accumulated score is still 0 (and at this point it's not zero because the first parameter matched the expected type).
All 3 constructors in this list score and match the same and if the incompatible constructor is examined first then it's used. This in turn causes VarArgs.normalizeArgsForVarArgs to attempt to create an array of size -1 as it calculates the needed size of the varargs array.
> When multiple varargs constructors exist, resolution sometimes incorrect
> ------------------------------------------------------------------------
>
> Key: DROOLS-1703
> URL: https://issues.jboss.org/browse/DROOLS-1703
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.5.0.Final
> Environment: Ubuntu 16..0.4 (x86_64)
> openjdk version "1.8.0_131"
> OpenJDK Runtime Environment (build 1.8.0_131-b12)
> OpenJDK 64-Bit Server VM (build 25.131-b12, mixed mode)
> Apache Maven 3.5.0 (ff8f5e7444045639af65f6095c62210b5713f426; 2017-04-03T19:39:06Z)
> Reporter: Gerard Krupa
> Assignee: Mario Fusco
>
> We have a class with 3 constructors:
> Thingy(String name)
> Thingy(String name, Object... args)
> Thingy(String name, String version, Object... args)
> When calling the constructor with a single paramater from a DRL:
> Thingy(drools.getRule().getName())
> we sometimes get an odd exception in our unit tests:
> {{[INFO] java.lang.StringIndexOutOfBoundsException: String index out of range: -1
> [INFO] at java.lang.String.substring(String.java:1927)
> [INFO] at org.mvel2.util.ErrorUtil.rewriteIfNeeded(ErrorUtil.java:17)
> [INFO] at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.getMethod(ReflectiveAccessorOptimizer.java:975)
> [INFO] at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.compileGetChain(ReflectiveAccessorOptimizer.java:396)
> [INFO] at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.optimizeAccessor(ReflectiveAccessorOptimizer.java:163)}}
> The root cause of the issue appears to be the selection of varargs constructors by ParseTools.getBestConstructorCandidate and getMethodScore. The scoring checks that the arguments from left to right match the expected parameter classes and scores based on their coerce-ability. The scoring then compares the number of parameters to arguments *only* if the accumulated score is still 0 (and at this point it's not zero because the first parameter matched the expected type).
> All 3 constructors in this list score and match the same and if the incompatible constructor is examined first then it's used. This in turn causes VarArgs.normalizeArgsForVarArgs to attempt to create an array of size -1 as it calculates the needed size of the varargs array. The reported exception seems to be generated as the exception handler itself crashes, being unable to deal with the root cause error.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (DROOLS-1703) When multiple varargs constructors exist, resolution sometimes incorrect
by Gerard Krupa (JIRA)
Gerard Krupa created DROOLS-1703:
------------------------------------
Summary: When multiple varargs constructors exist, resolution sometimes incorrect
Key: DROOLS-1703
URL: https://issues.jboss.org/browse/DROOLS-1703
Project: Drools
Issue Type: Bug
Components: core engine
Affects Versions: 6.5.0.Final
Environment: Ubuntu 16..0.4 (x86_64)
openjdk version "1.8.0_131"
OpenJDK Runtime Environment (build 1.8.0_131-b12)
OpenJDK 64-Bit Server VM (build 25.131-b12, mixed mode)
Apache Maven 3.5.0 (ff8f5e7444045639af65f6095c62210b5713f426; 2017-04-03T19:39:06Z)
Reporter: Gerard Krupa
Assignee: Mario Fusco
We have a class with 3 constructors:
Thingy(String name)
Thingy(String name, Object... args)
Thingy(String name, String version, Object... args)
When calling the constructor with a single paramater from a DRL:
Thingy(drools.getRule().getName())
we sometimes get an odd exception in our unit tests:
{{[INFO] java.lang.StringIndexOutOfBoundsException: String index out of range: -1
[INFO] at java.lang.String.substring(String.java:1927)
[INFO] at org.mvel2.util.ErrorUtil.rewriteIfNeeded(ErrorUtil.java:17)
[INFO] at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.getMethod(ReflectiveAccessorOptimizer.java:975)
[INFO] at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.compileGetChain(ReflectiveAccessorOptimizer.java:396)
[INFO] at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.optimizeAccessor(ReflectiveAccessorOptimizer.java:163)}}
The root cause of the issue appears to be the selection of varargs constructors by ParseTools.getBestConstructorCandidate and getMethodScore. The scoring checks that the arguments from left to right match the expected parameter classes and scores based on their coerce-ability. The scoring then compares the number of parameters to arguments *only* if the accumulated score is still 0 (and at this point it's not zero because the first parameter matched the expected type).
All 3 constructors in this list score and match the same and if the incompatible constructor is examined first then it's used. This in turn causes VarArgs.normalizeArgsForVarArgs to attempt to create an array of size -1 as it calculates the needed size of the varargs array.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (WFCORE-3185) Run parallel boot tasks in coarser grained chunks
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3185?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-3185:
-------------------------------------
Description:
Currently parallel boot works by executing one task per Extension.initializeParsers call, one per Extension.initialize call and 2 per subsystem, one for execution of Stage.MODEL ops and one for Stage.RUNTIME ops. The Extension.initializeParsers tasks complete before boot proceeds to the point where any Extension.initialize tasks run, and the Extension.initialize tasks complete before the Stage.MODEL tasks run. The Stage.MODEL tasks do the large bulk of their work before the Stage.RUNTIME tasks run, but they do block waiting for the Stage.RUNTIME tasks and the rest of the boot to complete.
The rough effect of all this is we are allocating 2 threads per subsystem to do parallel boot, and at various points we have 1 thread per subsystem concurrently working. For a brief period (doing Stage.DONE of the post-extension boot op) we have 2 threads per subsystem concurrently working.
My measurements show that all of this concurrent work reduces boot time about 400ms on my machine, using the full WildFly standalone-full.xml config. However, this approach uses a lot of threads. So the task here is to look into how to get the same or better boot speed while using fewer threads. (Note the the threads will expire and be gc'd after boot.)
The obvious way to do that is to look at each of the 4 task types discussed in the first paragraph and group things into larger units of work than a single extension/subsystem.
Initial work on doing this shows that using more coarse grained chunks does not result in reduced boot time, but also seems not to increase boot time. Further measurement is needed to confirm this though, and small tweaks may show different results.
Another thing to consider is allowing the Stage.MODEL tasks to complete without waiting for the overall boot op to complete. This might reduce the max number of threads involved and perhaps will allow a tiny bit more parallelization of work. The key here is ensuring the Stage.MODEL tasks are not able to affect the state of the final system in an invalid way. That could be problematic or fragile, so it's just something to consider, and if done must be done with great care.
Even if this work produces no reduction in boot time, if it produces no gain, there is some value in incorporating it, as avoiding unnecessary thread creation improves the impression of the efficiency and good design of the software.
was:
Currently parallel boot works by executing one task per Extension.initializeParsers call, one per Extension.initialize call and 2 per subsystem, one for execution of Stage.MODEL ops and one for Stage.RUNTIME ops. The Extension.initializeParsers tasks complete before boot proceeds to the point where any Extension.initialize tasks run, and the Extension.initialize tasks complete before the Stage.MODEL tasks run. The Stage.MODEL tasks do the large bulk of their work before the Stage.RUNTIME tasks run, but they do block waiting for the Stage.RUNTIME tasks and the rest of the boot to complete.
The rough effect of all this is we are allocating 2 threads per subsystem to do parallel boot, and at various points we have 1 thread per subsystem concurrently working. For a brief period (doing Stage.DONE of the post-extension boot op) we have 2 threads per subsystem concurrently working.
My measurements show that all of this concurrent work reduces boot time about 400ms on my machine, using the full WildFly standalone-full.xml config. However, this approach uses a lot of threads. So the task here is to look into how to get the same or better boot speed while using fewer threads.
The obvious way to do that is to look at each of the 4 task types discussed in the first paragraph and group things into larger units of work than a single extension/subsystem.
Initial work on doing this shows that using more coarse grained chunks does not result in reduced boot time, but also seems not to increase boot time. Further measurement is needed to confirm this though, and small tweaks may show different results.
Another thing to consider is allowing the Stage.MODEL tasks to complete without waiting for the overall boot op to complete. This might reduce the max number of threads involved and perhaps will allow a tiny bit more parallelization of work. The key here is ensuring the Stage.MODEL tasks are not able to affect the state of the final system in an invalid way. That could be problematic or fragile, so it's just something to consider, and if done must be done with great care.
Even if this work produces no reduction in boot time, if it produces no gain, there is some value in incorporating it, as avoiding unnecessary thread creation improves the impression of the efficiency and good design of the software.
> Run parallel boot tasks in coarser grained chunks
> -------------------------------------------------
>
> Key: WFCORE-3185
> URL: https://issues.jboss.org/browse/WFCORE-3185
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Fix For: 4.0.0.Alpha1
>
>
> Currently parallel boot works by executing one task per Extension.initializeParsers call, one per Extension.initialize call and 2 per subsystem, one for execution of Stage.MODEL ops and one for Stage.RUNTIME ops. The Extension.initializeParsers tasks complete before boot proceeds to the point where any Extension.initialize tasks run, and the Extension.initialize tasks complete before the Stage.MODEL tasks run. The Stage.MODEL tasks do the large bulk of their work before the Stage.RUNTIME tasks run, but they do block waiting for the Stage.RUNTIME tasks and the rest of the boot to complete.
> The rough effect of all this is we are allocating 2 threads per subsystem to do parallel boot, and at various points we have 1 thread per subsystem concurrently working. For a brief period (doing Stage.DONE of the post-extension boot op) we have 2 threads per subsystem concurrently working.
> My measurements show that all of this concurrent work reduces boot time about 400ms on my machine, using the full WildFly standalone-full.xml config. However, this approach uses a lot of threads. So the task here is to look into how to get the same or better boot speed while using fewer threads. (Note the the threads will expire and be gc'd after boot.)
> The obvious way to do that is to look at each of the 4 task types discussed in the first paragraph and group things into larger units of work than a single extension/subsystem.
> Initial work on doing this shows that using more coarse grained chunks does not result in reduced boot time, but also seems not to increase boot time. Further measurement is needed to confirm this though, and small tweaks may show different results.
> Another thing to consider is allowing the Stage.MODEL tasks to complete without waiting for the overall boot op to complete. This might reduce the max number of threads involved and perhaps will allow a tiny bit more parallelization of work. The key here is ensuring the Stage.MODEL tasks are not able to affect the state of the final system in an invalid way. That could be problematic or fragile, so it's just something to consider, and if done must be done with great care.
> Even if this work produces no reduction in boot time, if it produces no gain, there is some value in incorporating it, as avoiding unnecessary thread creation improves the impression of the efficiency and good design of the software.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months