[JBoss JIRA] (LOGMGR-99) Infinite recursion when exception stack frame class lookup fails
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/LOGMGR-99?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on LOGMGR-99:
-----------------------------------------------
Kabir Khan <kkhan(a)redhat.com> changed the Status of [bug 1071695|https://bugzilla.redhat.com/show_bug.cgi?id=1071695] from POST to MODIFIED
> Infinite recursion when exception stack frame class lookup fails
> ----------------------------------------------------------------
>
> Key: LOGMGR-99
> URL: https://issues.jboss.org/browse/LOGMGR-99
> Project: JBoss Log Manager
> Issue Type: Bug
> Affects Versions: 1.5.1.Final
> Reporter: James Livingston
> Assignee: James Perkins
> Priority: Critical
> Fix For: 1.3.3.Final, 1.4.4.Final, 1.5.4.Final, 2.0.0.Beta2
>
> Attachments: logmgr99.war
>
>
> To print out the jar information in exception stack traces, the log manager needs to resolve the class name from StackTraceElement to the Class object. Since the log manager cannot know which classloader was used, guessClass() tries the TCCL, the logmanager's classloader and finally the system classloader.
> It is possible that the TCCL contains a class of the same name as the one in the stack frame, but it not the same class. This can easily happen if the application packages a jar that is also used by the container. In this situation, the class may not be able to be loaded, such as if the application-packages class is missing it's dependencies.
> If Class.forName() would throw a NoClassDefFoundError or similar, JBoss Modules (or other classloader implementation) may attempt to log this using java.util.logging API. This can result in infinite recursion, for example
> {code}
> ...
> at org.jboss.logmanager.Logger.log(Logger.java:367)
> at org.jboss.modules.log.JDKModuleLogger.doLog(JDKModuleLogger.java:109)
> at org.jboss.modules.log.JDKModuleLogger.classDefineFailed(JDKModuleLogger.java:194)
> at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:401)
> at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:243)
> at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:73)
> at org.jboss.modules.Module.loadModuleClass(Module.java:527)
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:182)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:468)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:456)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:398)
> at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:120)
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:266)
> at org.jboss.logmanager.formatters.Formatters$12.guessClass(Formatters.java:578)
> at org.jboss.logmanager.formatters.Formatters$12.renderExtended(Formatters.java:421)
> at org.jboss.logmanager.formatters.Formatters$12.renderRaw(Formatters.java:388)
> at org.jboss.logmanager.formatters.Formatters$JustifyingFormatStep.render(Formatters.java:150)
> at org.jboss.logmanager.formatters.MultistepFormatter.format(MultistepFormatter.java:86)
> at org.jboss.logmanager.ExtFormatter.format(ExtFormatter.java:35)
> at org.jboss.logmanager.handlers.WriterHandler.doPublish(WriterHandler.java:49)
> at org.jboss.logmanager.ExtHandler.publish(ExtHandler.java:76)
> at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:290)
> at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:298)
> at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:298)
> at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:298)
> at org.jboss.logmanager.Logger.logRaw(Logger.java:721)
> at org.jboss.logmanager.Logger.logRaw(Logger.java:731)
> at org.jboss.logmanager.Logger.log(Logger.java:367)
> ...
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
9 years, 11 months
[JBoss JIRA] (JGRP-1903) TCPPING: discovery dissemination for static discovery protocols
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1903?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1903:
--------------------------------
The _coordinator_ (only) does the following on a view change (if discovery dissemination is enabled and discovery protocol is static):
* Determines the set of new members N and left members L
* Sends information about everyone except self and L to N
* Sends information about N to everyone except self and L
There should also be a JMX exposed operation which sends information about everyone to everyone (except self)
> TCPPING: discovery dissemination for static discovery protocols
> ---------------------------------------------------------------
>
> Key: JGRP-1903
> URL: https://issues.jboss.org/browse/JGRP-1903
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.6.1
>
>
> For {{TCPPING}}, usually all members have to be listed in {{initial_hosts}}. If we don't know all of the members up front, we could have the coordinator disseminate the IP address and port information dynamically.
> Say {{TCPPING.initial_hosts}} only lists A (the coord). When members B, C, D and E join (in that order), we have the following caches:
> |A|B|C|D|E|
> |ABCDE|AB|AC|AD|AE|
> Every member has information about itself and A, but not about other members. So, for example, D won't be able to send a unicast to C, and vice versa. Or, when E sends a multicast, it would only be delivered to itself and A, but not to B, C and D.
> h5. Solution
> * When we have a static discovery layer, have the coordinator broadcast its cache information to the rest of the cluster
> * This can be done when a new member join, or periodically, or upon request (JMX)
> * Should be goverened by a property: if someone lists all members in {{initial_hosts}}, then he may want to turn this off
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
9 years, 11 months
[JBoss JIRA] (JGRP-1903) TCPPING: discovery dissemination for static discovery protocols
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1903?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1903:
--------------------------------
Since this is done mainly for the {{TCP:TCPPING}} combo, using {{TCP}} to send the information is reliable.
> TCPPING: discovery dissemination for static discovery protocols
> ---------------------------------------------------------------
>
> Key: JGRP-1903
> URL: https://issues.jboss.org/browse/JGRP-1903
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.6.1
>
>
> For {{TCPPING}}, usually all members have to be listed in {{initial_hosts}}. If we don't know all of the members up front, we could have the coordinator disseminate the IP address and port information dynamically.
> Say {{TCPPING.initial_hosts}} only lists A (the coord). When members B, C, D and E join (in that order), we have the following caches:
> |A|B|C|D|E|
> |ABCDE|AB|AC|AD|AE|
> Every member has information about itself and A, but not about other members. So, for example, D won't be able to send a unicast to C, and vice versa. Or, when E sends a multicast, it would only be delivered to itself and A, but not to B, C and D.
> h5. Solution
> * When we have a static discovery layer, have the coordinator broadcast its cache information to the rest of the cluster
> * This can be done when a new member join, or periodically, or upon request (JMX)
> * Should be goverened by a property: if someone lists all members in {{initial_hosts}}, then he may want to turn this off
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
9 years, 11 months
[JBoss JIRA] (SECURITY-851) Base64Utils class cuts leading zeroes from encoded bytes
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/SECURITY-851?page=com.atlassian.jira.plug... ]
RH Bugzilla Integration commented on SECURITY-851:
--------------------------------------------------
Ondrej Kotek <okotek(a)redhat.com> changed the Status of [bug 1125004|https://bugzilla.redhat.com/show_bug.cgi?id=1125004] from ON_QA to VERIFIED
> Base64Utils class cuts leading zeroes from encoded bytes
> --------------------------------------------------------
>
> Key: SECURITY-851
> URL: https://issues.jboss.org/browse/SECURITY-851
> Project: PicketBox
> Issue Type: Bug
> Affects Versions: PicketBox_4_0_21.Beta2
> Reporter: Josef Cacek
> Assignee: Josef Cacek
> Priority: Blocker
> Fix For: PicketBox_4_0_21.Final
>
>
> Vault util is failing for some password/salt/iteration combinations because Base64Utils class strips zeroes from provided byte array.
> So if a user encodes a key with length 8 and the leading byte of the key is zero, then after decoding he only gets 7 (or less) bytes.
> For instance:
> {code}
> encode ( { 0, 81, 121, -37, 46, -64, 20, 114 } ) -> "1HUTikm1Ho"
> decode ("1HUTikm1Ho") -> { 81, 121, -37, 46, -64, 20, 114 }
> {code}
> As a result the PBEUtil will fail with javax.crypto.IllegalBlockSizeException.
> IMHO the same problem can occur on other places where the Base64Utils class is used (not only the Vault).
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
9 years, 11 months
[JBoss JIRA] (JGRP-1903) TCPPING: discovery dissemination for static discovery protocols
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1903?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-1903:
---------------------------
Description:
For {{TCPPING}}, usually all members have to be listed in {{initial_hosts}}. If we don't know all of the members up front, we could have the coordinator disseminate the IP address and port information dynamically.
Say {{TCPPING.initial_hosts}} only lists A (the coord). When members B, C, D and E join (in that order), we have the following caches:
|A|B|C|D|E|
|ABCDE|AB|AC|AD|AE|
Every member has information about itself and A, but not about other members. So, for example, D won't be able to send a unicast to C, and vice versa. Or, when E sends a multicast, it would only be delivered to itself and A, but not to B, C and D.
h5. Solution
* When we have a static discovery layer, have the coordinator broadcast its cache information to the rest of the cluster
* This can be done when a new member join, or periodically, or upon request (JMX)
* Should be goverened by a property: if someone lists all members in {{initial_hosts}}, then he may want to turn this off
was:
For {{TCPPING}}, usually all members have to be listed in {{initial_hosts}}. If we don't know all of the members up front, we could have the coordinator disseminate the IP address and port information dynamically.
Say {{TCPPING.initial_hosts}} only lists A (the coord). When members B, C, D and E join (in that order), we have the following caches:
|A|B|C|D|E|
|ABCDE|AB|AC|AD|AE|
Every member has information about itself and A, but not about other members. So, for example, D won't be able to send a unicast to C, and vice versa. Or, when E sends a multicast, it would only be delivered to itself and A, but not to B, C and D.
h5. Solution
* When we have a static discovery layer, have the coordinator broadcast its cache information to the rest of the cluster
* This can be done when a new member join, or periodically, or upon request (JMX)
> TCPPING: discovery dissemination for static discovery protocols
> ---------------------------------------------------------------
>
> Key: JGRP-1903
> URL: https://issues.jboss.org/browse/JGRP-1903
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.6.1
>
>
> For {{TCPPING}}, usually all members have to be listed in {{initial_hosts}}. If we don't know all of the members up front, we could have the coordinator disseminate the IP address and port information dynamically.
> Say {{TCPPING.initial_hosts}} only lists A (the coord). When members B, C, D and E join (in that order), we have the following caches:
> |A|B|C|D|E|
> |ABCDE|AB|AC|AD|AE|
> Every member has information about itself and A, but not about other members. So, for example, D won't be able to send a unicast to C, and vice versa. Or, when E sends a multicast, it would only be delivered to itself and A, but not to B, C and D.
> h5. Solution
> * When we have a static discovery layer, have the coordinator broadcast its cache information to the rest of the cluster
> * This can be done when a new member join, or periodically, or upon request (JMX)
> * Should be goverened by a property: if someone lists all members in {{initial_hosts}}, then he may want to turn this off
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
9 years, 11 months
[JBoss JIRA] (JGRP-1903) TCPPING: discovery dissemination for static discovery protocols
by Bela Ban (JIRA)
Bela Ban created JGRP-1903:
------------------------------
Summary: TCPPING: discovery dissemination for static discovery protocols
Key: JGRP-1903
URL: https://issues.jboss.org/browse/JGRP-1903
Project: JGroups
Issue Type: Feature Request
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 3.6.1
For {{TCPPING}}, usually all members have to be listed in {{initial_hosts}}. If we don't know all of the members up front, we could have the coordinator disseminate the IP address and port information dynamically.
Say {{TCPPING.initial_hosts}} only lists A (the coord). When members B, C, D and E join (in that order), we have the following caches:
|A|B|C|D|E|
|ABCDE|AB|AC|AD|AE|
Every member has information about itself and A, but not about other members. So, for example, D won't be able to send a unicast to C, and vice versa. Or, when E sends a multicast, it would only be delivered to itself and A, but not to B, C and D.
h5. Solution
* When we have a static discovery layer, have the coordinator broadcast its cache information to the rest of the cluster
* This can be done when a new member join, or periodically, or upon request (JMX)
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
9 years, 11 months
[JBoss JIRA] (DROOLS-651) Bindings do not cache actual values
by Marc Dzaebel (JIRA)
[ https://issues.jboss.org/browse/DROOLS-651?page=com.atlassian.jira.plugin... ]
Marc Dzaebel edited comment on DROOLS-651 at 11/21/14 4:37 AM:
---------------------------------------------------------------
The documentation uses the term _binding variable_ 8 times, so bindings seems to be variables too (but of course special ones). I understand that these bindings are not yet cached because of constraint idempotence. However, in my view the implication should be, that especially a non changing result +can+ be cached! Rather than a _good practice_, the documentation says:
{quote} "Property accessors +must+ not change the state of the object in a way that may effect the rules. Remember that the rule engine effectively +caches+ the results of its matching in between invocations to make it faster."
{quote}
So if kind of functional immutability is required and used inside the engine, I would indeed think about caching method calls (with variables) in constraints, as this saves potentially massive processor time and would be much more intuitive.
I don't understand your sentence
{quote} "If you can't or desire not to guarantee this property, Drools won't enforce it caching the first value returned."
{quote}
Is it possible, to enforce Drools to cache variable bindings? Drools shouldn't cache values, that change.
Let me say that I'm still intrigued about the huge, powerful Drools framework and that we get this as Open Source including this helpful support. Feel free to change the issue-type to a feature request, as the behavior is not strictly incorrect but optimizable.
was (Author: mdzaebel):
The documentation uses the term _binding variable_ 8 times, so bindings seems to be a variables too (but of course special ones). I understand that these bindings are not yet cached because of constraint idempotence. However, in my view the implication should be, that especially a non changing result +can+ be cached! Rather than a _good practice_, the documentation says:
{quote} "Property accessors +must+ not change the state of the object in a way that may effect the rules. Remember that the rule engine effectively +caches+ the results of its matching in between invocations to make it faster."
{quote}
So if kind of functional immutability is required and used inside the engine, I would indeed think about caching method calls (with variables) in constraints, as this saves potentially massive processor time and would be much more intuitive.
I don't understand your sentence
{quote} "If you can't or desire not to guarantee this property, Drools won't enforce it caching the first value returned."
{quote}
Is it possible, to enforce Drools to cache variable bindings? Drools shouldn't cache values, that change.
Let me say that I'm still intrigued about the huge, powerful Drools framework and that we get this as Open Source including this helpful support. Feel free to change the issue-type to a feature request, as the behavior is not strictly incorrect but optimizable.
> Bindings do not cache actual values
> -----------------------------------
>
> Key: DROOLS-651
> URL: https://issues.jboss.org/browse/DROOLS-651
> Project: Drools
> Issue Type: Enhancement
> Affects Versions: 6.2.0.Beta3
> Environment: Win7, Drools 6.2.0 Beta3 (probably all Drools versions)
> Reporter: Marc Dzaebel
> Assignee: Mario Fusco
> Priority: Minor
>
> Create sample Drools project, add following method to the Message class:
> {noformat} public List<String> list() {
> System.out.println("Call!");
> return Arrays.asList("one", "two");
> } {noformat}
> sample.drl:
> {noformat}
> package com.sample
> import com.sample.DroolsTest.Message;
> import java.util.List;
> import java.util.ArrayList;
>
> rule ""
> when m : Message(L : list(), L.size>0)
> then System.out.println("L:"+L);
> end
> {noformat}
> Running the project will result in the following output:
> {noformat}
> Call!
> Call!
> L:[one, two]
> {noformat}
> So _list()_ is called *two* times (duplicate). This may be due to the replacement of "L" with _list()_ in the second constraint. This is ok for simple +getters+ as here HotSpot optimizes this away. However, long running methods will produce unnecessary overhead, especially if further constraints on "L" are added (which I verified produce additional calls to list()). So at least methods with one or more arguments should be saved in temporary variables that should be used in further constraints. A fix of this problem will certainly accelerate Drools performance on similar patterns. If this is not feasible, at least a comment should be added to the documentation.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
9 years, 11 months