[JBoss JIRA] (JGRP-2298) InputStream is processed after the different version error
by Bela Ban (Jira)
[ https://issues.jboss.org/browse/JGRP-2298?page=com.atlassian.jira.plugin.... ]
Bela Ban resolved JGRP-2298.
----------------------------
Resolution: Cannot Reproduce
Please re-open if you can come up with a reproducer
> InputStream is processed after the different version error
> ----------------------------------------------------------
>
> Key: JGRP-2298
> URL: https://issues.jboss.org/browse/JGRP-2298
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.0.11, 4.0.13
> Environment: OS: Debian 8
> Reporter: Boris Kantor
> Assignee: Bela Ban
> Priority: Major
> Fix For: 4.0.16
>
>
> Occasionally JGroups shows up a warning when receiving a message with a different JGroups version:
> {{JGRP000010: packet from 10.10.10.130:7800 has different version (0.0.0) than ours (4.0.11); packet is discarded | (Log4J2LogImpl.java:91)}}
> Although the message is then discarded, the socket connection will be kept open. The input stream still contains data that will be processed and falsly interpreted as the next message.
> If you have bad luck, the next bytes will match the correct version number. This leads then to following errors:
> {code:java}
> 2018-07-17 10:15:34.052 [Connect | ] WARN TCP - JGRP000010: packet from 10.10.10.130:7800 has different version (0.0.0) than ours (4.0.11); packet is discarded | (Log4J2LogImpl.java:91)
> 2018-07-17 10:15:34.059 [Connect | ] ERROR TCP - JGRP000030: jgm113: failed handling incoming message | (Log4J2LogImpl.java:116)
> java.lang.ClassNotFoundException: Class for magic number 8237 cannot be found
> at org.jgroups.conf.ClassConfigurator.create(ClassConfigurator.java:118)
> at org.jgroups.Message.readHeader(Message.java:869)
> at org.jgroups.Message.readFrom(Message.java:742)
> at org.jgroups.protocols.TP.handleSingleMessage(TP.java:1346)
> at org.jgroups.protocols.TP.receive(TP.java:1323)
> at org.jgroups.blocks.cs.BaseServer.receive(BaseServer.java:171)
> at org.jgroups.blocks.cs.TcpConnection$Receiver.run(TcpConnection.java:290)
> at eu.application.nac.cluster.jgroups.JGroupsTask.execute(JGroupsTask.java:41)
> at eu.application.nac.engine.scheduling.Task.run(Task.java:339)
> at java.lang.Thread.run(Thread.java:745)
> 2018-07-17 10:15:34.065 [Connect | ] ERROR TCP - JGRP000030: jgm113: failed handling incoming message | (Log4J2LogImpl.java:116)
> java.lang.ClassNotFoundException: Class for magic number 8237 cannot be found
> at org.jgroups.conf.ClassConfigurator.create(ClassConfigurator.java:118)
> at org.jgroups.Message.readHeader(Message.java:869)
> at org.jgroups.Message.readFrom(Message.java:742)
> at org.jgroups.protocols.TP.handleSingleMessage(TP.java:1346)
> at org.jgroups.protocols.TP.receive(TP.java:1323)
> at org.jgroups.blocks.cs.BaseServer.receive(BaseServer.java:171)
> at org.jgroups.blocks.cs.TcpConnection$Receiver.run(TcpConnection.java:290)
> at eu.application.nac.cluster.jgroups.JGroupsTask.execute(JGroupsTask.java:41)
> at eu.application.nac.engine.scheduling.Task.run(Task.java:339)
> at java.lang.Thread.run(Thread.java:745)
> 2018-07-17 10:15:34.072 [Connect | ] ERROR TCP - JGRP000030: jgm113: failed handling incoming message | (Log4J2LogImpl.java:116)
> java.io.IOException: length has to be 4 or 16 bytes (was 47 bytes)
> at org.jgroups.stack.IpAddress.readFrom(IpAddress.java:171)
> at org.jgroups.util.Util.readAddress(Util.java:1379)
> at org.jgroups.Message.readFrom(Message.java:731)
> at org.jgroups.protocols.TP.handleSingleMessage(TP.java:1346)
> at org.jgroups.protocols.TP.receive(TP.java:1323)
> at org.jgroups.blocks.cs.BaseServer.receive(BaseServer.java:171)
> at org.jgroups.blocks.cs.TcpConnection$Receiver.run(TcpConnection.java:290)
> at eu.application.nac.cluster.jgroups.JGroupsTask.execute(JGroupsTask.java:41)
> at eu.application.nac.engine.scheduling.Task.run(Task.java:339)
> at java.lang.Thread.run(Thread.java:745)
> 2018-07-17 10:15:34.076 [Connect | ] ERROR TCP - JGRP000030: jgm113: failed handling incoming message | (Log4J2LogImpl.java:116)
> java.lang.ClassNotFoundException: Class for magic number 28789 cannot be found
> at org.jgroups.conf.ClassConfigurator.create(ClassConfigurator.java:118)
> at org.jgroups.Message.readHeader(Message.java:869)
> at org.jgroups.Message.readFrom(Message.java:742)
> at org.jgroups.protocols.TP.handleSingleMessage(TP.java:1346)
> at org.jgroups.protocols.TP.receive(TP.java:1323)
> at org.jgroups.blocks.cs.BaseServer.receive(BaseServer.java:171)
> at org.jgroups.blocks.cs.TcpConnection$Receiver.run(TcpConnection.java:290)
> at eu.application.nac.cluster.jgroups.JGroupsTask.execute(JGroupsTask.java:41)
> at eu.application.nac.engine.scheduling.Task.run(Task.java:339)
> at java.lang.Thread.run(Thread.java:745)
> 2018-07-17 10:15:34.077 [Connect | ] ERROR TCP - JGRP000030: jgm113: failed handling incoming message | (Log4J2LogImpl.java:116)
> java.lang.ClassNotFoundException: Class for magic number 8237 cannot be found
> at org.jgroups.conf.ClassConfigurator.create(ClassConfigurator.java:118)
> at org.jgroups.Message.readHeader(Message.java:869)
> at org.jgroups.Message.readFrom(Message.java:742)
> at org.jgroups.protocols.TP.handleSingleMessage(TP.java:1346)
> at org.jgroups.protocols.TP.receive(TP.java:1323)
> at org.jgroups.blocks.cs.BaseServer.receive(BaseServer.java:171)
> at org.jgroups.blocks.cs.TcpConnection$Receiver.run(TcpConnection.java:290)
> at eu.application.nac.cluster.jgroups.JGroupsTask.execute(JGroupsTask.java:41)
> at eu.application.nac.engine.scheduling.Task.run(Task.java:339)
> at java.lang.Thread.run(Thread.java:745)
> 2018-07-17 10:15:34.078 [Connect | ] ERROR TCP - JGRP000030: jgm113: failed handling incoming message | (Log4J2LogImpl.java:116)
> java.io.IOException: length has to be 4 or 16 bytes (was 47 bytes)
> at org.jgroups.stack.IpAddress.readFrom(IpAddress.java:171)
> at org.jgroups.util.Util.readAddress(Util.java:1379)
> at org.jgroups.Message.readFrom(Message.java:731)
> at org.jgroups.protocols.TP.handleSingleMessage(TP.java:1346)
> at org.jgroups.protocols.TP.receive(TP.java:1323)
> at org.jgroups.blocks.cs.BaseServer.receive(BaseServer.java:171)
> at org.jgroups.blocks.cs.TcpConnection$Receiver.run(TcpConnection.java:290)
> at eu.application.nac.cluster.jgroups.JGroupsTask.execute(JGroupsTask.java:41)
> at eu.application.nac.engine.scheduling.Task.run(Task.java:339)
> at java.lang.Thread.run(Thread.java:745)
> 2018-07-17 10:15:34.078 [Connect | ] ERROR TCP - JGRP000030: jgm113: failed handling incoming message | (Log4J2LogImpl.java:116)
> java.lang.ClassNotFoundException: Class for magic number 8237 cannot be found
> at org.jgroups.conf.ClassConfigurator.create(ClassConfigurator.java:118)
> at org.jgroups.Message.readHeader(Message.java:869)
> at org.jgroups.Message.readFrom(Message.java:742)
> at org.jgroups.protocols.TP.handleSingleMessage(TP.java:1346)
> at org.jgroups.protocols.TP.receive(TP.java:1323)
> at org.jgroups.blocks.cs.BaseServer.receive(BaseServer.java:171)
> at org.jgroups.blocks.cs.TcpConnection$Receiver.run(TcpConnection.java:290)
> at eu.application.nac.cluster.jgroups.JGroupsTask.execute(JGroupsTask.java:41)
> at eu.application.nac.engine.scheduling.Task.run(Task.java:339)
> at java.lang.Thread.run(Thread.java:745)
> 2018-07-17 10:15:34.079 [Connect | ] ERROR TCP - JGRP000030: jgm113: failed handling incoming message | (Log4J2LogImpl.java:116)
> java.io.IOException: length has to be 4 or 16 bytes (was 47 bytes)
> at org.jgroups.stack.IpAddress.readFrom(IpAddress.java:171)
> at org.jgroups.util.Util.readAddress(Util.java:1379)
> at org.jgroups.Message.readFrom(Message.java:731)
> at org.jgroups.protocols.TP.handleSingleMessage(TP.java:1346)
> at org.jgroups.protocols.TP.receive(TP.java:1323)
> at org.jgroups.blocks.cs.BaseServer.receive(BaseServer.java:171)
> at org.jgroups.blocks.cs.TcpConnection$Receiver.run(TcpConnection.java:290)
> at eu.application.nac.cluster.jgroups.JGroupsTask.execute(JGroupsTask.java:41)
> at eu.application.nac.engine.scheduling.Task.run(Task.java:339)
> at java.lang.Thread.run(Thread.java:745)
> 2018-07-17 10:15:34.080 [Connect | ] ERROR TCP - JGRP000030: jgm113: failed handling incoming message | (Log4J2LogImpl.java:116)
> java.lang.ClassNotFoundException: Class for magic number 12320 cannot be found
> at org.jgroups.conf.ClassConfigurator.create(ClassConfigurator.java:118)
> at org.jgroups.Message.readHeader(Message.java:869)
> at org.jgroups.Message.readFrom(Message.java:742)
> at org.jgroups.protocols.TP.handleSingleMessage(TP.java:1346)
> at org.jgroups.protocols.TP.receive(TP.java:1323)
> at org.jgroups.blocks.cs.BaseServer.receive(BaseServer.java:171)
> at org.jgroups.blocks.cs.TcpConnection$Receiver.run(TcpConnection.java:290)
> at eu.application.nac.cluster.jgroups.JGroupsTask.execute(JGroupsTask.java:41)
> at eu.application.nac.engine.scheduling.Task.run(Task.java:339)
> at java.lang.Thread.run(Thread.java:745)
> 2018-07-17 10:15:34.089 [Connect | ] ERROR TCP - JGRP000030: jgm113: failed handling incoming message | (Log4J2LogImpl.java:116)
> java.lang.ClassNotFoundException: Class for magic number 25193 cannot be found
> at org.jgroups.conf.ClassConfigurator.create(ClassConfigurator.java:118)
> at org.jgroups.Message.readHeader(Message.java:869)
> at org.jgroups.Message.readFrom(Message.java:742)
> at org.jgroups.protocols.TP.handleSingleMessage(TP.java:1346)
> at org.jgroups.protocols.TP.receive(TP.java:1323)
> at org.jgroups.blocks.cs.BaseServer.receive(BaseServer.java:171)
> at org.jgroups.blocks.cs.TcpConnection$Receiver.run(TcpConnection.java:290)
> at eu.application.nac.cluster.jgroups.JGroupsTask.execute(JGroupsTask.java:41)
> at eu.application.nac.engine.scheduling.Task.run(Task.java:339)
> at java.lang.Thread.run(Thread.java:745)
> 2018-07-17 10:15:34.107 [Connect | ] ERROR TCP - JGRP000030: jgm113: failed handling incoming message | (Log4J2LogImpl.java:116)
> java.lang.ClassNotFoundException: Class for magic number 25970 cannot be found
> at org.jgroups.conf.ClassConfigurator.create(ClassConfigurator.java:118)
> at org.jgroups.Message.readHeader(Message.java:869)
> at org.jgroups.Message.readFrom(Message.java:742)
> at org.jgroups.util.Util.readMessageBatch(Util.java:1193)
> at org.jgroups.protocols.TP.handleMessageBatch(TP.java:1329)
> at org.jgroups.protocols.TP.receive(TP.java:1321)
> at org.jgroups.blocks.cs.BaseServer.receive(BaseServer.java:171)
> at org.jgroups.blocks.cs.TcpConnection$Receiver.run(TcpConnection.java:290)
> at eu.application.nac.cluster.jgroups.JGroupsTask.execute(JGroupsTask.java:41)
> at eu.application.nac.engine.scheduling.Task.run(Task.java:339)
> at java.lang.Thread.run(Thread.java:745)
> {code}
> When it comes to the payload of the message the size of the payload can be as big as 2GB ({{len=in.readInt();}}). On small machines this will lead to an OutOfMemoryError.
> There is a need for some handling of such misinterpreted messages. Like closing and reopening a socket connection or completely ignoring the following bytes until a new message begins or an other algorithm that would prevent the processing of the remaining bytes.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 5 months
[JBoss JIRA] (ELYWEB-35) Distributed sessions are immutable when obtained by id
by Pedro Igor (Jira)
Pedro Igor created ELYWEB-35:
--------------------------------
Summary: Distributed sessions are immutable when obtained by id
Key: ELYWEB-35
URL: https://issues.jboss.org/browse/ELYWEB-35
Project: Elytron Web
Issue Type: Bug
Components: Undertow Servlet
Affects Versions: 1.3.0.Final
Reporter: Pedro Igor
When deploying distributable JEE applications it is not possible to invalidate a session scope when obtaining the scope based on the id, using {{org.wildfly.security.http.HttpServerScopes#getScope(org.wildfly.security.http.Scope, java.lang.String)}}.
This is because the distributable session manager from Wildfly clustering subsystem returns a {{DistributableImmutableSession}} which does not support writes to the session and the {{invalidate}} method is a no-op.
This also implies that session scopes obtained by id cannot be used to set any attribute to the underlying session in Undertow.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 5 months
[JBoss JIRA] (JGRP-2316) DNS_PING is not using correct ports with SRV based service discovery
by Bela Ban (Jira)
[ https://issues.jboss.org/browse/JGRP-2316?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2316:
--------------------------------
DNS_PING works perfectly on Google Container Engine (GKE) (see below); all members cluster correctly and dig also works consistently:
{noformat}
bash-4.4$ dig _ping._tcp.jgrp.default.svc.cluster.local. SRV
; <<>> DiG 9.12.3 <<>> _ping._tcp.jgrp.default.svc.cluster.local. SRV
;; global options: +cmd
;; Got answer:
;; WARNING: .local is reserved for Multicast DNS
;; You are currently testing what happens when an mDNS query is leaked to DNS
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8968
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 3
;; QUESTION SECTION:
;_ping._tcp.jgrp.default.svc.cluster.local. IN SRV
;; ANSWER SECTION:
_ping._tcp.jgrp.default.svc.cluster.local. 30 IN SRV 10 33 7800 6136343230366238.jgrp.default.svc.cluster.local.
_ping._tcp.jgrp.default.svc.cluster.local. 30 IN SRV 10 33 7800 6163393939366665.jgrp.default.svc.cluster.local.
_ping._tcp.jgrp.default.svc.cluster.local. 30 IN SRV 10 33 7800 3236616662636137.jgrp.default.svc.cluster.local.
;; ADDITIONAL SECTION:
6136343230366238.jgrp.default.svc.cluster.local. 30 IN A 10.4.0.8
6163393939366665.jgrp.default.svc.cluster.local. 30 IN A 10.4.0.6
3236616662636137.jgrp.default.svc.cluster.local. 30 IN A 10.4.0.7
;; Query time: 1 msec
;; SERVER: 10.7.240.10#53(10.7.240.10)
;; WHEN: Wed Dec 05 15:59:16 UTC 2018
;; MSG SIZE rcvd: 218
{noformat}
It would be interesting to see why (SRV) dig *never* returns an entry in the format {{172-17-0-5.jgrp.default.svc.cluster.local.}}, but always as {{6136343230366238.jgrp.default.svc.cluster.local.}}
Also, all entries returned can be resolved by {{dig}} correctly, and there's never a single DNS resolution failure!
I guess this leaves minikube as culprit and not alpine linux!
> DNS_PING is not using correct ports with SRV based service discovery
> --------------------------------------------------------------------
>
> Key: JGRP-2316
> URL: https://issues.jboss.org/browse/JGRP-2316
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.0.15
> Reporter: dmcnair
> Assignee: Bela Ban
> Priority: Major
> Fix For: 4.0.16
>
>
> This is a follow-up to JGRP-2296 - which changed `DefaultDNSResolver.java` to preserve the port for SRV records. While that change is working as desired, `DNS_PING.java` is not using the port when doing member discovery.
> Here are the log entries using *4.0.15*
> {noformat}
> 2018-11-29 21:37:41,561 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-4,null,null) Entries collected from DNS (in 5 ms): [172.29.11.50:27106, 172.29.11.50:27105]
> 2018-11-29 21:37:41,562 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-4,null,null) 982d38761cba: sending discovery requests to hosts [172.29.11.50:27106, 172.29.11.50:27105] on ports [7600 .. 7600]
> {noformat}
> Since the port was found via the SRV record, it should be used instead of the *transportPort* port.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 5 months
[JBoss JIRA] (DROOLS-3407) Need to use one rule in each one of the agendas efficiently in Kie Drools 7.12
by Edson Tirelli (Jira)
[ https://issues.jboss.org/browse/DROOLS-3407?page=com.atlassian.jira.plugi... ]
Edson Tirelli commented on DROOLS-3407:
---------------------------------------
Rafael,
Not sure what the use case is, but maybe what you need is just to create an agenda for the rule itself, and set the auto-focus attribute? This way, the rule will be automatically activated and put on the top of the stack every time there is a change that affects/reactivates the rule?
> Need to use one rule in each one of the agendas efficiently in Kie Drools 7.12
> ------------------------------------------------------------------------------
>
> Key: DROOLS-3407
> URL: https://issues.jboss.org/browse/DROOLS-3407
> Project: Drools
> Issue Type: Enhancement
> Components: core engine
> Affects Versions: 7.12.0.Final
> Reporter: Rafael Jordá
> Assignee: Mario Fusco
> Priority: Major
> Labels: agenda, drools-tools, eclipse, rules
> Fix For: 7.12.0.Final
>
>
> Hi, I'm working in a project using Drools in Eclipse. I need to solve the following issue and I was wondering if you could help me.
> I have a rule that needs to be triggered in each one of the agendas that I've defined in my drl file (it is a very important rule).
> First, I tried not to set an agenda for that rule, but it only got executed at the end of the last agenda.
> So the only thing that came to my mind was defining that rule in each one of the agendas, i.e., the same rule is repeated in all of them, which is not the most efficient solution.
> Is this a normal issue? Is there a better solution?
> Thanks.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 5 months
[JBoss JIRA] (DROOLS-3407) Need to use one rule in each one of the agendas efficiently in Kie Drools 7.12
by Edson Tirelli (Jira)
[ https://issues.jboss.org/browse/DROOLS-3407?page=com.atlassian.jira.plugi... ]
Edson Tirelli reassigned DROOLS-3407:
-------------------------------------
Assignee: Mario Fusco (was: Edson Tirelli)
> Need to use one rule in each one of the agendas efficiently in Kie Drools 7.12
> ------------------------------------------------------------------------------
>
> Key: DROOLS-3407
> URL: https://issues.jboss.org/browse/DROOLS-3407
> Project: Drools
> Issue Type: Enhancement
> Components: core engine
> Affects Versions: 7.12.0.Final
> Reporter: Rafael Jordá
> Assignee: Mario Fusco
> Priority: Major
> Labels: agenda, drools-tools, eclipse, rules
> Fix For: 7.12.0.Final
>
>
> Hi, I'm working in a project using Drools in Eclipse. I need to solve the following issue and I was wondering if you could help me.
> I have a rule that needs to be triggered in each one of the agendas that I've defined in my drl file (it is a very important rule).
> First, I tried not to set an agenda for that rule, but it only got executed at the end of the last agenda.
> So the only thing that came to my mind was defining that rule in each one of the agendas, i.e., the same rule is repeated in all of them, which is not the most efficient solution.
> Is this a normal issue? Is there a better solution?
> Thanks.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 5 months
[JBoss JIRA] (DROOLS-3411) CRLF in ACTION cell of xlsx spreadsheet is not treated as is
by Hiroko Miura (Jira)
Hiroko Miura created DROOLS-3411:
------------------------------------
Summary: CRLF in ACTION cell of xlsx spreadsheet is not treated as is
Key: DROOLS-3411
URL: https://issues.jboss.org/browse/DROOLS-3411
Project: Drools
Issue Type: Bug
Components: core engine, decision tables
Affects Versions: 7.10.0.Final
Environment: - RHDM7.1.0
- Windows
Reporter: Hiroko Miura
Assignee: Toni Rikkola
Attachments: CheckTest.zip
Customer runs rule on Windows environment.
They then want to include CRLF(\r\n) in ACTION cell of XLSX spreadsheet as a value in order to generate error message. They expect that '\r\n' is treated as is, but when the rule is fired, it converted to ';\n'. Please take a look at attached reproducer.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 5 months
[JBoss JIRA] (WFLY-11451) Classloading issues on IBM JDK 8 when JProfiler agent is enabled
by Tomas Kyjovsky (Jira)
[ https://issues.jboss.org/browse/WFLY-11451?page=com.atlassian.jira.plugin... ]
Tomas Kyjovsky commented on WFLY-11451:
---------------------------------------
Same problem when I try to enable the IBM Healthcenter agent: {{-Xhealthcenter}}.
> Classloading issues on IBM JDK 8 when JProfiler agent is enabled
> ----------------------------------------------------------------
>
> Key: WFLY-11451
> URL: https://issues.jboss.org/browse/WFLY-11451
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 14.0.1.Final
> Environment: IBM JDK 8:
> java version "1.8.0_191"
> Java(TM) SE Runtime Environment (build 8.0.5.25 - pxa6480sr5fp25-20181030_01(SR5 FP25))
> IBM J9 VM (build 2.9, JRE 1.8.0 Linux amd64-64-Bit Compressed References 20181029_400846 (JIT enabled, AOT enabled)
> OpenJ9 - c5c78da
> OMR - 3d5ac33
> IBM - 8c1bdc2)
> JCL - 20181022_01 based on Oracle jdk8u191-b26
> Reporter: Tomas Kyjovsky
> Assignee: Jason Greene
> Priority: Major
>
> When I enable JProfiler agent for the server running on IBM JDK 8 the server doesn't start, throwing classloading exceptions.
> {noformat}
> =========================================================================
> JBoss Bootstrap Environment
> JBOSS_HOME: /home/tkyjovsk/workspace/KEYCLOAK-8983/wildfly-14.0.1.Final
> JAVA: /home/tkyjovsk/software/java/ibm-java-80/bin/java
> JAVA_OPTS: -server -Xms64m -Xmx512m -XX:MetaspaceSize=96M -XX:MaxMetaspaceSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true -agentpath:/home/tkyjovsk/software/tools/jprofiler9/bin/linux-x64/libjprofilerti.so=port=6766 -Xshareclasses:none
> =========================================================================
> JProfiler> Protocol version 55
> JProfiler> Using JVMTI
> JProfiler> Thread status info workaround enabled.
> JProfiler> Restricted JVMTI version 1.1 detected.
> JProfiler> 64-bit library
> JProfiler> Listening on port: 6766.
> JProfiler> Instrumenting native methods.
> JProfiler> Native library initialized
> JProfiler> VM initialized
> JProfiler> Waiting for a connection from the JProfiler GUI ...
> JProfiler> Using dynamic instrumentation
> JProfiler> Time measurement: elapsed time
> JProfiler> CPU profiling enabled
> WARNING: Failed to load the specified log manager class org.jboss.logmanager.LogManager
> Nov 30, 2018 1:48:31 PM org.jboss.msc.service.ServiceContainerImpl <clinit>
> INFO: JBoss MSC version 1.4.3.Final
> Nov 30, 2018 1:48:31 PM org.jboss.threads.Version <clinit>
> INFO: JBoss Threads version 2.3.2.Final
> Nov 30, 2018 1:48:31 PM org.jboss.as.server.BootstrapImpl internalBootstrap
> WARN: WFLYSRV0071: The operating system has limited the number of open files to 1024 for this process; a value of at least 4096 is recommended
> Nov 30, 2018 1:48:31 PM org.jboss.as.server.ApplicationServerService start
> INFO: WFLYSRV0049: WildFly Full 14.0.1.Final (WildFly Core 6.0.2.Final) starting
> Nov 30, 2018 1:48:33 PM org.wildfly.security.Version <clinit>
> INFO: ELY00001: WildFly Elytron version 1.6.0.Final
> Nov 30, 2018 1:48:34 PM org.jboss.as.controller.AbstractOperationContext executeStep
> ERROR: WFLYCTL0013: Operation ("parallel-extension-add") failed - address: ([])
> java.lang.RuntimeException: WFLYCTL0079: Failed initializing module org.jboss.as.logging
> at org.jboss.as.controller.extension.ParallelExtensionAddHandler$1.execute(ParallelExtensionAddHandler.java:115)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:999)
> at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:743)
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:467)
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1411)
> at org.jboss.as.controller.ModelControllerImpl.boot(ModelControllerImpl.java:495)
> at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:470)
> at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:432)
> at org.jboss.as.server.ServerService.boot(ServerService.java:427)
> at org.jboss.as.server.ServerService.boot(ServerService.java:386)
> at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:372)
> at java.lang.Thread.run(Thread.java:812)
> Caused by: java.util.concurrent.ExecutionException: java.lang.IllegalStateException: WFLYLOG0078: The logging subsystem requires the log manager to be org.jboss.logmanager.LogManager. The subsystem has not be initialized and cannot be used. To use JBoss Log Manager you must add the system property "java.util.logging.manager" and set it to "org.jboss.logmanager.LogManager"
> at java.util.concurrent.FutureTask.report(FutureTask.java:133)
> at java.util.concurrent.FutureTask.get(FutureTask.java:203)
> at org.jboss.as.controller.extension.ParallelExtensionAddHandler$1.execute(ParallelExtensionAddHandler.java:107)
> ... 11 more
> Caused by: java.lang.IllegalStateException: WFLYLOG0078: The logging subsystem requires the log manager to be org.jboss.logmanager.LogManager. The subsystem has not be initialized and cannot be used. To use JBoss Log Manager you must add the system property "java.util.logging.manager" and set it to "org.jboss.logmanager.LogManager"
> at org.jboss.as.logging.LoggingExtension.initialize(LoggingExtension.java:194)
> at org.jboss.as.controller.extension.ExtensionAddHandler.initializeExtension(ExtensionAddHandler.java:131)
> at org.jboss.as.controller.extension.ExtensionAddHandler.initializeExtension(ExtensionAddHandler.java:104)
> at org.jboss.as.controller.extension.ParallelExtensionAddHandler$ExtensionInitializeTask.call(ParallelExtensionAddHandler.java:144)
> at org.jboss.as.controller.extension.ParallelExtensionAddHandler$ExtensionInitializeTask.call(ParallelExtensionAddHandler.java:127)
> at java.util.concurrent.FutureTask.run(FutureTask.java:277)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378)
> at java.lang.Thread.run(Thread.java:812)
> at org.jboss.threads.JBossThread.run(JBossThread.java:485)
> Nov 30, 2018 1:48:34 PM org.jboss.as.server.ServerService$4 logExit
> FATAL: WFLYSRV0056: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details.
> {noformat}
> I tried to work around this by adding "{{org.jboss.logmanager}}" to {{JBOSS_MODULES_SYSTEM_PKGS}} and adding "{{-Djava.util.logging.manager=org.jboss.logmanager.LogManager -Xbootclasspath/p:...}}" in {{JAVA_OPTS}} but that just results in another class-loading error:
> {noformat}
> =========================================================================
> JBoss Bootstrap Environment
> JBOSS_HOME: /home/tkyjovsk/workspace/KEYCLOAK-8983/wildfly-14.0.1.Final
> JAVA: /home/tkyjovsk/software/java/ibm-java-80/bin/java
> JAVA_OPTS: -server -Xms64m -Xmx512m -XX:MetaspaceSize=96M -XX:MaxMetaspaceSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman,org.jboss.logmanager -Djava.awt.headless=true -agentpath:/home/tkyjovsk/software/tools/jprofiler9/bin/linux-x64/libjprofilerti.so=port=6766 -Xshareclasses:none -Djava.util.logging.manager=org.jboss.logmanager.LogManager -Xbootclasspath/p:/home/tkyjovsk/workspace/KEYCLOAK-8983/wildfly-14.0.1.Final/modules/system/layers/base/org/jboss/logmanager/main/jboss-logmanager-2.1.4.Final.jar
> =========================================================================
> JProfiler> Protocol version 55
> JProfiler> Using JVMTI
> JProfiler> Thread status info workaround enabled.
> JProfiler> Restricted JVMTI version 1.1 detected.
> JProfiler> 64-bit library
> JProfiler> Listening on port: 6766.
> JProfiler> Instrumenting native methods.
> JProfiler> Native library initialized
> JProfiler> VM initialized
> JProfiler> Waiting for a connection from the JProfiler GUI ...
> JProfiler> Using dynamic instrumentation
> JProfiler> Time measurement: elapsed time
> JProfiler> CPU profiling enabled
> java.lang.NoClassDefFoundError: org/wildfly/common/net/HostName
> at org.jboss.logmanager.ExtLogRecord.<init>(ExtLogRecord.java:87)
> at org.jboss.logmanager.Logger.log(Logger.java:796)
> at org.jboss.logging.JBossLogManagerLogger.doLogf(JBossLogManagerLogger.java:53)
> at org.jboss.logging.Logger.logf(Logger.java:2398)
> at org.jboss.msc.service.ServiceLogger_$logger.greeting(ServiceLogger_$logger.java:40)
> at org.jboss.msc.service.ServiceContainerImpl.<clinit>(ServiceContainerImpl.java:91)
> at org.jboss.msc.service.ServiceContainer$Factory.create(ServiceContainer.java:250)
> at org.jboss.as.server.BootstrapImpl$ShutdownHook.register(BootstrapImpl.java:229)
> at org.jboss.as.server.BootstrapImpl$ShutdownHook.access$100(BootstrapImpl.java:219)
> at org.jboss.as.server.BootstrapImpl.<init>(BootstrapImpl.java:70)
> at org.jboss.as.server.Bootstrap$Factory.newInstance(Bootstrap.java:278)
> at org.jboss.as.server.Main.main(Main.java:106)
> at org.jboss.modules.Module.run(Module.java:352)
> at org.jboss.modules.Module.run(Module.java:320)
> at org.jboss.modules.Main.main(Main.java:593)
> {noformat}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 5 months
[JBoss JIRA] (WFLY-11479) HTTP Basic Authentication - Silent Operation
by Darran Lofthouse (Jira)
[ https://issues.jboss.org/browse/WFLY-11479?page=com.atlassian.jira.plugin... ]
Darran Lofthouse moved EAP7-1155 to WFLY-11479:
-----------------------------------------------
Project: WildFly (was: EAP 7 Planning Pilot)
Key: WFLY-11479 (was: EAP7-1155)
Issue Type: Feature Request (was: Requirement)
Workflow: GIT Pull Request workflow (was: EAP Agile Workflow 2.0)
Component/s: Security
(was: Security)
Jirban PT Pre-Checked (PC): (was: TODO)
Target Release: (was: 7.2.0.GA)
Jirban PT Community Docs (CD): (was: TODO)
Jirban PT Product Docs (PD): (was: New)
Jirban PT Test Dev (TD): (was: TODO)
Jirban PT Docs Analysis (DA): (was: TODO)
Jirban PT Test Plan (TP): (was: TODO)
Jirban PT Analysis Document (AD): (was: TODO)
> HTTP Basic Authentication - Silent Operation
> --------------------------------------------
>
> Key: WFLY-11479
> URL: https://issues.jboss.org/browse/WFLY-11479
> Project: WildFly
> Issue Type: Feature Request
> Components: Security
> Reporter: Darran Lofthouse
> Assignee: Diana Vilkolakova
> Priority: Major
>
> Using HTTP Basic authentication with Undertow it was possible to switch into a silent mode where an incoming header could be processed but clients would not be challenged - this RFE is to support the same behaviour with WildFly Elytron.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 5 months
[JBoss JIRA] (DROOLS-3234) Add a Donut widget to improve the visualisation of test report screen
by Liz Clayton (Jira)
[ https://issues.jboss.org/browse/DROOLS-3234?page=com.atlassian.jira.plugi... ]
Liz Clayton edited comment on DROOLS-3234 at 12/5/18 10:15 AM:
---------------------------------------------------------------
[~Rikkola][~kkufova]
If the widget and time are constraints - how about this alternative interim solution (A):
!pie2b.png|thumbnail!
- Replace the "# scenarios run" text with the now "scenario status" header, using the bolded header treatment.
- Keep the legend persistent regardless of pass/fail results.
- Show the % metric in the chart, even if the % is 100. It would be better if we could also sneak the word "failed" or "passed" in there. :)
Would this be possible?
was (Author: uxdlc):
[~Rikkola][~kkufova]
If the widget and time are constraints - how about this alternative interim solution (A):
!pie2b.png|thumbnail!
- Replace the "# scenarios run" text with the now "scenario status" header, using the bolded header treatment.
- Keep the legend persistent regardless of pass/fail results.
- Show the % metric in the chart, even if the % is 100.
Would this be possible?
> Add a Donut widget to improve the visualisation of test report screen
> ---------------------------------------------------------------------
>
> Key: DROOLS-3234
> URL: https://issues.jboss.org/browse/DROOLS-3234
> Project: Drools
> Issue Type: Enhancement
> Components: Scenario Simulation and Testing, Test Scenarios Editor
> Reporter: Toni Rikkola
> Assignee: Toni Rikkola
> Priority: Major
> Attachments: donut.png, pie2b.png, screencast-04-12-18.webm
>
>
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 5 months
[JBoss JIRA] (DROOLS-3234) Add a Donut widget to improve the visualisation of test report screen
by Liz Clayton (Jira)
[ https://issues.jboss.org/browse/DROOLS-3234?page=com.atlassian.jira.plugi... ]
Liz Clayton commented on DROOLS-3234:
-------------------------------------
[~Rikkola][~kkufova]
If the widget and time are constraints - how about this alternative interim solution (A):
!pie2b.png|thumbnail!
- Replace the "# scenarios run" text with the now "scenario status" header, using the bolded header treatment.
- Keep the legend persistent regardless of pass/fail results.
- Show the % metric in the chart, even if the % is 100.
Would this be possible?
> Add a Donut widget to improve the visualisation of test report screen
> ---------------------------------------------------------------------
>
> Key: DROOLS-3234
> URL: https://issues.jboss.org/browse/DROOLS-3234
> Project: Drools
> Issue Type: Enhancement
> Components: Scenario Simulation and Testing, Test Scenarios Editor
> Reporter: Toni Rikkola
> Assignee: Toni Rikkola
> Priority: Major
> Attachments: donut.png, screencast-04-12-18.webm
>
>
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 5 months