[JBoss JIRA] (JBJCA-1294) caching the value of isTraceEnabled
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/JBJCA-1294?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on JBJCA-1294:
------------------------------------------------
Brad Maxwell <bmaxwell(a)redhat.com> changed the Status of [bug 1259840|https://bugzilla.redhat.com/show_bug.cgi?id=1259840] from POST to MODIFIED
> caching the value of isTraceEnabled
> -----------------------------------
>
> Key: JBJCA-1294
> URL: https://issues.jboss.org/browse/JBJCA-1294
> Project: IronJacamar
> Issue Type: Bug
> Affects Versions: 1.2.6.Final
> Reporter: Johnathon Lee
> Assignee: Bartosz Baranowski
> Fix For: WildFly/IronJacamar 1.3.2.Final, 1.0.35.Final
>
>
> caching the value of isTraceEnabled does not allow for complete dynamic control of the logging level. This has ramifications in support scenarios where diagnostics are needed and the ability to reload an instance to enable TRACE level logging is prohibitive.
> see examples of TRACE being cached:
> grep 'log.isTraceEnabled();' -r * --include='*.java'
> Replacement of all if (trace) with calls to log.tracef would be needed.
> Note, that some "if (trace)" would have to be replaced by if (log.isTraceEnabled()) calls, as they guard multiple lines of code, and even synchronization blocks
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 11 months
[JBoss JIRA] (JBJCA-1294) caching the value of isTraceEnabled
by Jesper Pedersen (JIRA)
[ https://issues.jboss.org/browse/JBJCA-1294?page=com.atlassian.jira.plugin... ]
Jesper Pedersen closed JBJCA-1294.
----------------------------------
> caching the value of isTraceEnabled
> -----------------------------------
>
> Key: JBJCA-1294
> URL: https://issues.jboss.org/browse/JBJCA-1294
> Project: IronJacamar
> Issue Type: Bug
> Affects Versions: 1.2.6.Final
> Reporter: Johnathon Lee
> Assignee: Bartosz Baranowski
> Fix For: WildFly/IronJacamar 1.3.2.Final, 1.0.35.Final
>
>
> caching the value of isTraceEnabled does not allow for complete dynamic control of the logging level. This has ramifications in support scenarios where diagnostics are needed and the ability to reload an instance to enable TRACE level logging is prohibitive.
> see examples of TRACE being cached:
> grep 'log.isTraceEnabled();' -r * --include='*.java'
> Replacement of all if (trace) with calls to log.tracef would be needed.
> Note, that some "if (trace)" would have to be replaced by if (log.isTraceEnabled()) calls, as they guard multiple lines of code, and even synchronization blocks
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 11 months
[JBoss JIRA] (JBJCA-1294) caching the value of isTraceEnabled
by Jesper Pedersen (JIRA)
[ https://issues.jboss.org/browse/JBJCA-1294?page=com.atlassian.jira.plugin... ]
Jesper Pedersen resolved JBJCA-1294.
------------------------------------
Resolution: Done
> caching the value of isTraceEnabled
> -----------------------------------
>
> Key: JBJCA-1294
> URL: https://issues.jboss.org/browse/JBJCA-1294
> Project: IronJacamar
> Issue Type: Bug
> Affects Versions: 1.2.6.Final
> Reporter: Johnathon Lee
> Assignee: Bartosz Baranowski
> Fix For: WildFly/IronJacamar 1.3.2.Final, 1.0.35.Final
>
>
> caching the value of isTraceEnabled does not allow for complete dynamic control of the logging level. This has ramifications in support scenarios where diagnostics are needed and the ability to reload an instance to enable TRACE level logging is prohibitive.
> see examples of TRACE being cached:
> grep 'log.isTraceEnabled();' -r * --include='*.java'
> Replacement of all if (trace) with calls to log.tracef would be needed.
> Note, that some "if (trace)" would have to be replaced by if (log.isTraceEnabled()) calls, as they guard multiple lines of code, and even synchronization blocks
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 11 months
[JBoss JIRA] (WFLY-5830) Infinite loop when login to the admin console
by Pierre CLERMONT (JIRA)
Pierre CLERMONT created WFLY-5830:
-------------------------------------
Summary: Infinite loop when login to the admin console
Key: WFLY-5830
URL: https://issues.jboss.org/browse/WFLY-5830
Project: WildFly
Issue Type: Feature Request
Components: Web (Undertow)
Affects Versions: 8.2.1.Final
Environment: Linux Suse 64 bits
Reporter: Pierre CLERMONT
Assignee: Stuart Douglas
Attachments: stack.log
After create an user using the add-user.sh script, it is impossible to access to the admin console.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 11 months
[JBoss JIRA] (DROOLS-918) Janino java compiler issue
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-918?page=com.atlassian.jira.plugin... ]
Mario Fusco resolved DROOLS-918.
--------------------------------
Resolution: Cannot Reproduce
I'm flagging this issue as "Cannot Reproduce". Feel free to reopen it when you will be able to provide a reproducer for this problem.
> Janino java compiler issue
> --------------------------
>
> Key: DROOLS-918
> URL: https://issues.jboss.org/browse/DROOLS-918
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.2.0.Final
> Reporter: sam dai
> Assignee: Mario Fusco
>
> Recently I upgraded drools from version 6.0.0 Final to version 6.2.0 Final, I found some bpm process can't be deployed, the error message is as below.
> {color:#d04437}java.lang.IllegalArgumentException: Errors while parsing knowledge base + errors added Unable to generate action invoker. Unknown variable or type "Process_org$u46$drools$u46$bpmn2$u46$90f495e7$u45$788b$u45$472c$u45$abb3$u45$b37125d5a81e_$u43$_2014$u45$06$u45$18_05$u58$40$u58$29_$u45$0700162982687"
> A method named "action1" is not declared in any enclosing class nor any supertype, nor through a static import
> Expression "Process_org$u46$drools$u46$bpmn2$u46$90f495e7$u45$788b$u45$472c$u45$abb3$u45$b37125d5a81e_$u43$_2014$u45$06$u45$18_05$u58$40$u58$29_$u45$0700162982687" is not an rvalue{color}
> The java compiler is "JANINO" by setting the value of system property "drools.dialect.java.compiler" as "JANINO". If I use ECLIPSE java compiler, will not have this issue. I debugged the code, found code of line 82 of org.drools.compiler.rule.builder.dialect.DialectUtil.java is changed from
> {color:#205081}final String newName = prefix + "_" + NON_ALPHA_REGEX.matcher(name).replaceAll("_");{color}
> to
> {color:#205081}final String newName = prefix + "_" + normalizeRuleName( name );{color}
> If I changed it back, bpm process can be deployed successfully.
> Then I did more testing. for a name "org.drools.bpmn2.fc1291c5-c25c-4c6b-aba3-76efdcd16136 + 2014-03-07 13:06:29 -0800",
> if I use script "normalizeRuleName( name )", the value will be "org$u46$drools$u46$bpmn2$u46$fc1291c5$u45$c25c$u45$4c6b$u45$aba3$u45$76efdcd16136_$u43$_2014$u45$03$u45$07_13$u58$06$u58$29_$u45$0800",
> if use script "NON_ALPHA_REGEX.matcher(name).replaceAll("_");", the value will be
> "org_drools_bpmn2_fc1291c5_c25c_4c6b_aba3_76efdcd16136___2014_03_07_13_06_29__0800"
> So I wonder if this is a bug or I missed some configuration.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 11 months
[JBoss JIRA] (WFLY-5520) Manually migrated EAP 6.x profiles fail to boot due to 'default-clustered-sfsb-cache' used in runtime
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-5520?page=com.atlassian.jira.plugin.... ]
Radoslav Husar edited comment on WFLY-5520 at 12/10/15 8:11 AM:
----------------------------------------------------------------
[~emmartins], [~lthon], *until* this issue is fixed and *if* the above solution is accepted where the "upgrade" happens in the parser, I believe to get a proper profile from "manually" curated one, or the one obtained from Eduardo's tooling, you need to run this batch to get values on par with EAP7 defaults.
{code}
batch
/subsystem=ejb3:undefine-attribute(name=default-clustered-sfsb-cache)
/subsystem=ejb3:write-attribute(name=default-sfsb-cache,value=clustered)
/subsystem=ejb3:write-attribute(name=default-sfsb-passivation-disabled-cache,value=simple)
run-batch
{code}
Also, lets note here that the attached profiles are not good for testing: either the above should have happened, or the schemas should not have been upgraded to new versions. If the fix happens, the tooling needs to be rerun with the updated parser code.
was (Author: rhusar):
[~emmartins], [~lthon], *until* this issue is fixed and *if* the above solution is accepted where the "upgrade" happens in the parser, I believe to get a proper profile from "manually" curated one, or the one obtained from Eduardo's tooling, you need to run this batch to get values on par with EAP7 defaults.
{code}
batch
/subsystem=ejb3:undefine-attribute(name=default-clustered-sfsb-cache)
/subsystem=ejb3:write-attribute(name=default-sfsb-cache,value=distributable)
/subsystem=ejb3:write-attribute(name=default-sfsb-passivation-disabled-cache,value=simple)
run-batch
{code}
Also, lets note here that the attached profiles are not good for testing: either the above should have happened, or the schemas should not have been upgraded to new versions. If the fix happens, the tooling needs to be rerun with the updated parser code.
> Manually migrated EAP 6.x profiles fail to boot due to 'default-clustered-sfsb-cache' used in runtime
> -----------------------------------------------------------------------------------------------------
>
> Key: WFLY-5520
> URL: https://issues.jboss.org/browse/WFLY-5520
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, EJB
> Affects Versions: 10.0.0.CR2
> Reporter: Eduardo Martins
> Assignee: Radoslav Husar
> Priority: Critical
> Attachments: eap-6.1-migrated-configs.zip, eap-6.4-migrated-configs.zip
>
>
> If you try (curated) EAP 6 standalone-ha.xml configuration on WildFly the server will fail to boot due to an EJB3 subsystem attribute.
> Server boot console log:
> mbp:migration-tests emmartins$ ./default-config-manual-copy/wildfly-10.0.0.CR3-SNAPSHOT/bin/standalone.sh -c standalone-ha.xml
> =========================================================================
> JBoss Bootstrap Environment
> JBOSS_HOME: /Users/emmartins/wildfly/migration-tests/default-config-manual-copy/wildfly-10.0.0.CR3-SNAPSHOT
> JAVA: /Library/Java/JavaVirtualMachines/jdk1.8.0_40.jdk/Contents/Home/bin/java
> JAVA_OPTS: -server -Xms64m -Xmx512m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true
> =========================================================================
> 11:37:25,583 INFO [org.jboss.modules] (main) JBoss Modules version 1.4.4.Final
> 11:37:25,896 INFO [org.jboss.msc] (main) JBoss MSC version 1.2.6.Final
> 11:37:25,985 INFO [org.jboss.as] (MSC service thread 1-7) WFLYSRV0049: WildFly Full 10.0.0.CR3-SNAPSHOT (WildFly Core 2.0.0.CR6) starting
> 11:37:27,307 INFO [org.jboss.as.controller.management-deprecated] (ServerService Thread Pool -- 7) WFLYCTL0028: Attribute 'default-stack' in the resource at address '/subsystem=jgroups' is deprecated, and may be removed in future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation.
> 11:37:27,307 INFO [org.jboss.as.controller.management-deprecated] (ServerService Thread Pool -- 15) WFLYCTL0028: Attribute 'default-clustered-sfsb-cache' in the resource at address '/subsystem=ejb3' is deprecated, and may be removed in future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation.
> 11:37:27,385 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 15) WFLYCTL0013: Operation ("add") failed - address: ([("subsystem" => "ejb3")]) - failure description: "WFLYEJB0451: Attribute 'default-clustered-sfsb-cache' is not supported on current version servers; it is only allowed if its value matches 'default-sfsb-cache'"
> 11:37:27,586 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) "WFLYCTL0193: Failed executing subsystem ejb3 boot operations"
> 11:37:27,588 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("parallel-subsystem-boot") failed - address: ([]) - failure description: "\"WFLYCTL0193: Failed executing subsystem ejb3 boot operations\""
> 11:37:27,591 FATAL [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0056: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details.
> 11:37:27,594 INFO [org.jboss.as.server] (Thread-2) WFLYSRV0220: Server shutdown has been requested.
> 11:37:27,603 INFO [org.jboss.as] (MSC service thread 1-7) WFLYSRV0050: WildFly Full 10.0.0.CR3-SNAPSHOT (WildFly Core 2.0.0.CR6) stopped in 6ms
> Attached is the standalone-ha.xml config, with just threads subsystem removed, and web subsystem migrated to undertow, that should be able to boot the server.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 11 months
[JBoss JIRA] (JGRP-1992) GOOGLE_PING discovery fails if port 443 isn't used
by Alan Field (JIRA)
[ https://issues.jboss.org/browse/JGRP-1992?page=com.atlassian.jira.plugin.... ]
Alan Field commented on JGRP-1992:
----------------------------------
For 3.6.7, the port could be set in GOOGLE_PING to work around this. I'll try to send a PR today
> GOOGLE_PING discovery fails if port 443 isn't used
> --------------------------------------------------
>
> Key: JGRP-1992
> URL: https://issues.jboss.org/browse/JGRP-1992
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.6
> Reporter: Alan Field
> Assignee: Bela Ban
> Fix For: 3.6.7
>
>
> I was doing some testing with GCE, and I ran into the following issue. I have the following in my JGroups configuration file:
> <GOOGLE_PING access_key="access_key"
> secret_access_key="secret_access_key"
> location="jdg-cluster" />
> But I was getting the following exception when starting the JChannel:
> caused by: javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection?
> at sun.security.ssl.InputRecord.handleUnknownRecord(InputRecord.java:710)
> at sun.security.ssl.InputRecord.read(InputRecord.java:527)
> at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:973)
> at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1375)
> at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1403)
> at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1387)
> at sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:559)
> at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:185)
> at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1513)
> at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1441)
> at java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:480)
> at sun.net.www.protocol.https.HttpsURLConnectionImpl.getResponseCode(HttpsURLConnectionImpl.java:338)
> at org.jgroups.protocols.S3_PING$AWSAuthConnection.checkBucketExists(S3_PING.java:485)
> at org.jgroups.protocols.S3_PING.init(S3_PING.java:98)
> at org.jgroups.protocols.GOOGLE_PING.init(GOOGLE_PING.java:16)
> at org.jgroups.stack.ProtocolStack.initProtocolStack(ProtocolStack.java:860)
> at org.jgroups.stack.ProtocolStack.setup(ProtocolStack.java:481)
> at org.jgroups.JChannel.init(JChannel.java:854)
> at org.jgroups.JChannel.<init>(JChannel.java:159)
> at org.jgroups.JChannel.<init>(JChannel.java:129)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.buildChannel(JGroupsTransport.java:415)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.initChannel(JGroupsTransport.java:316)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.initChannelAndRPCDispatcher(JGroupsTransport.java:360)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.start(JGroupsTransport.java:198)
> 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 org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:176)
> at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:870)
> at org.infinispan.factories.AbstractComponentRegistry.invokeStartMethods(AbstractComponentRegistry.java:639)
> at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:628)
> at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:531)
> at org.infinispan.factories.GlobalComponentRegistry.start(GlobalComponentRegistry.java:238)
> at org.infinispan.manager.DefaultCacheManager.wireAndStartCache(DefaultCacheManager.java:583)
> at org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:549)
> at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:420)
> at org.radargun.service.InfinispanEmbeddedService.startCaches(InfinispanEmbeddedService.java:119)
> at org.radargun.service.Infinispan51EmbeddedService.startCaches(Infinispan51EmbeddedService.java:100)
> at org.radargun.service.InfinispanLifecycle.start(InfinispanLifecycle.java:45)
> at org.radargun.service.InfinispanKillableLifecycle.start(InfinispanKillableLifecycle.java:51)
> at org.radargun.stages.lifecycle.LifecycleHelper.start(LifecycleHelper.java:59)
> at org.radargun.stages.lifecycle.ServiceStartStage.executeOnSlave(ServiceStartStage.java:83)
> at org.radargun.SlaveBase.scenarioLoop(SlaveBase.java:87)
> at org.radargun.SlaveBase$ScenarioRunner.run(SlaveBase.java:151)
> If I skip the check for the existence of the bucket, I get the same exception when trying to read or write the file. I worked around it by making GOOGLE_PING use the SSL port:
> <GOOGLE_PING access_key="access_key"
> secret_access_key="secret_access_key"
> location="jdg-cluster"
> port="443" />
> I have looked at the docs for migrating from S3 to Google Cloud Storage (https://cloud.google.com/storage/docs/migrating?hl=en), and they don't mention this requirement. I also verified that S3_PING works without any changes.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 11 months
