[JBoss JIRA] (WFCORE-4034) RuntimeException when call key-store=ks:revoke-certificate
by Claudio Miranda (JIRA)
Claudio Miranda created WFCORE-4034:
---------------------------------------
Summary: RuntimeException when call key-store=ks:revoke-certificate
Key: WFCORE-4034
URL: https://issues.jboss.org/browse/WFCORE-4034
Project: WildFly Core
Issue Type: Bug
Components: Security
Reporter: Claudio Miranda
Assignee: Darran Lofthouse
There is a RuntimeException when call a key-store=keys:revoke-certificate on a existing alias, but having failed to obtain certificate from CA
Steps to reproduce
{code}
/subsystem=elytron/key-store=keyst2:add(credential-reference={clear-text=senha},type=JKS,path=keyst2.jks)
/subsystem=elytron/certificate-authority-account=ca_letsenc2:add(alias=www.cnn.com,key-store=keyst2)
/subsystem=elytron/key-store=keyst2:obtain-certificate(alias=www.cnn.com,certificate-authority-account=ca_letsenc2,domain-names=["www.cnn.com"],agree-to-terms-of-service,algorithm=RSA)
/subsystem=elytron/key-store=keyst2:revoke-certificate(alias=www.cnn.com,certificate-authority-account=ca_letsenc2)
{code}
obtain-certificate results in an exception, then call revoke-certificate
{code}
/subsystem=elytron/key-store=keyst2:obtain-certificate(alias=www.cnn.com,certificate-authority-account=ca_letsenc2,domain-names=["www.cnn.com"],agree-to-terms-of-service,algorithm=RSA)
{
"outcome" => "failed",
"failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.RuntimeException: org.wildfly.security.x500.cert.acme.AcmeException: ELY10048: Challenge response failed validation by the ACME ser
ver",
"rolled-back" => true
}
[standalone@localhost:9990 /] /subsystem=elytron/key-store=keyst2:revoke-certificate(alias=www.cnn.com,certificate-authority-account=ca_letsenc2)
{
"outcome" => "failed",
"failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.RuntimeException: org.wildfly.security.x500.cert.acme.AcmeException: No such certificate",
"rolled-back" => true
}
{code}
I understand it make no sense to revoke a certificate that doesn't exist in CA provider, but it was more an accident to discover it as I was playing with the operations.
Probably a WARN message would be more appropriate than a RuntimeException.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFCORE-3996) GC logging is not working on Java 9
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3996?page=com.atlassian.jira.plugi... ]
James Perkins commented on WFCORE-3996:
---------------------------------------
For completeness too so we know our other options here's the help output ({{java -Xlog:help}}).
{code}
-Xlog Usage: -Xlog[:[what][:[output][:[decorators][:output-options]]]]
where 'what' is a combination of tags and levels of the form tag1[+tag2...][*][=level][,...]
Unless wildcard (*) is specified, only log messages tagged with exactly the tags specified will be matched.
Available log levels:
off, trace, debug, info, warning, error
Available log decorators:
time (t), utctime (utc), uptime (u), timemillis (tm), uptimemillis (um), timenanos (tn), uptimenanos (un), hostname (hn), pid (p), tid (ti), level (l), tags (tg)
Decorators can also be specified as 'none' for no decoration.
Available log tags:
add, age, alloc, aot, annotation, arguments, attach, barrier, biasedlocking, blocks, bot, breakpoint, cds, census, class, classhisto, cleanup, codecache, compaction, compilation, constraints, constantpool, container, coops, cpu, cset, data, datacreation, defaultmethods, dump, ergo, exceptions, exit, fingerprint, freelist, gc, handshake, hashtables, heap, humongous, ihop, iklass, init, inlining, interpreter, itables, jit, jni, jvmti, liveness, load, loader, logging, mark, marking, membername, memops, methodcomparator, metadata, metaspace, mmu, module, monitorinflation, monitormismatch, nmethod, normalize, objecttagging, obsolete, oopmap, os, pagesize, patch, path, perf, phases, plab, promotion, preorder, protectiondomain, ref, redefine, refine, region, remset, purge, resolve, safepoint, scavenge, scrub, smr, stacktrace, stackwalk, start, startuptime, state, stats, stringdedup, stringtable, stackmap, subclass, survivor, sweep, table, task, thread, tlab, time, timer, update, unload, unshareable, verification, verify, vmoperation, vmthread, vtables, workgang
Specifying 'all' instead of a tag combination matches all tag combinations.
Described tag combinations:
logging: Logging for the log framework itself
Available log outputs:
stdout, stderr, file=<filename>
Specifying %p and/or %t in the filename will expand to the JVM's PID and startup timestamp, respectively.
Some examples:
-Xlog
Log all messages using 'info' level to stdout with 'uptime', 'levels' and 'tags' decorations.
(Equivalent to -Xlog:all=info:stdout:uptime,levels,tags).
-Xlog:gc
Log messages tagged with 'gc' tag using 'info' level to stdout, with default decorations.
-Xlog:gc,safepoint
Log messages tagged either with 'gc' or 'safepoint' tags, both using 'info' level, to stdout, with default decorations.
(Messages tagged with both 'gc' and 'safepoint' will not be logged.)
-Xlog:gc+ref=debug
Log messages tagged with both 'gc' and 'ref' tags, using 'debug' level, to stdout, with default decorations.
(Messages tagged only with one of the two tags will not be logged.)
-Xlog:gc=debug:file=gc.txt:none
Log messages tagged with 'gc' tag using 'debug' level to file 'gc.txt' with no decorations.
-Xlog:gc=trace:file=gctrace.txt:uptimemillis,pids:filecount=5,filesize=1m
Log messages tagged with 'gc' tag using 'trace' level to a rotating fileset of 5 files of size 1MB,
using the base name 'gctrace.txt', with 'uptimemillis' and 'pid' decorations.
-Xlog:gc::uptime,tid
Log messages tagged with 'gc' tag using 'info' level to output 'stdout', using 'uptime' and 'tid' decorations.
-Xlog:gc*=info,safepoint*=off
Log messages tagged with at least 'gc' using 'info' level, but turn off logging of messages tagged with 'safepoint'.
(Messages tagged with both 'gc' and 'safepoint' will not be logged.)
-Xlog:disable -Xlog:safepoint=trace:safepointtrace.txt
Turn off all logging, including warnings and errors,
and then enable messages tagged with 'safepoint' using 'trace' level to file 'safepointtrace.txt'.
{code}
> GC logging is not working on Java 9
> -----------------------------------
>
> Key: WFCORE-3996
> URL: https://issues.jboss.org/browse/WFCORE-3996
> Project: WildFly Core
> Issue Type: Bug
> Components: Scripts
> Reporter: Rostislav Svoboda
> Assignee: Radovan Stancel
> Priority: Blocker
> Labels: Java11, blocker-WF14
>
> GC logging is not working on Java 9. This is related to the fact G1 GC is default and there are changes in configuration option.
> {code}
> GC_LOG="true" ./standalone.sh
> {code}
> Java 8:
> {code}
> JAVA_OPTS: -server -verbose:gc -Xloggc:"/Users/rsvoboda/TESTING/7.2.0.CD12.CR1/jboss-eap-7.2/standalone/log/gc.log"
> -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=5
> -XX:GCLogFileSize=3M -XX:-TraceClassUnloading -Xms1303m -Xmx1303m -XX:MetaspaceSize=96M
> -XX:MaxMetaspaceSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true
> {code}
> Java 9:
> {code}
> JAVA_OPTS: -server -Xms1303m -Xmx1303m -XX:MetaspaceSize=96M -XX:MaxMetaspaceSize=256m
> -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFCORE-3996) GC logging is not working on Java 9
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3996?page=com.atlassian.jira.plugi... ]
James Perkins commented on WFCORE-3996:
---------------------------------------
I think this is what we want for the {{JAVA_OPTS}} on Java 9+
{code}
-Xlog:gc*:file=$JBOSS_LOG_DIR/gc.log:time,uptimemillis:filecount=5,filesize=3M
{code}
We need to remove the {{-verbose:gc}} which will stop the stderr output. We could also do something like:
{code}
-Xlog:gc*=$GC_LOG_LEVEL:file=$JBOSS_LOG_DIR/gc.log:time,uptimemillis:filecount=5,filesize=3M
{code}
which would default {{GC_LOG_LEVEL}} to {{info}} so if we need {{debug}} or {{trace}} it could be overridden without requiring a script change.
Also because this was part of a JEP all JVM vendors must support the flags so we shouldn't need to test if the options exist, e.g. {{"$JAVA" $JVM_OPTVERSION -Xlog:gc*:file="$JBOSS_LOG_DIR/gc.log":time,uptimemillis:filecount=5,filesize=3M -version >/dev/null 2>&1 &&}} can go away for Java 9+.
> GC logging is not working on Java 9
> -----------------------------------
>
> Key: WFCORE-3996
> URL: https://issues.jboss.org/browse/WFCORE-3996
> Project: WildFly Core
> Issue Type: Bug
> Components: Scripts
> Reporter: Rostislav Svoboda
> Assignee: Radovan Stancel
> Priority: Blocker
> Labels: Java11, blocker-WF14
>
> GC logging is not working on Java 9. This is related to the fact G1 GC is default and there are changes in configuration option.
> {code}
> GC_LOG="true" ./standalone.sh
> {code}
> Java 8:
> {code}
> JAVA_OPTS: -server -verbose:gc -Xloggc:"/Users/rsvoboda/TESTING/7.2.0.CD12.CR1/jboss-eap-7.2/standalone/log/gc.log"
> -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=5
> -XX:GCLogFileSize=3M -XX:-TraceClassUnloading -Xms1303m -Xmx1303m -XX:MetaspaceSize=96M
> -XX:MaxMetaspaceSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true
> {code}
> Java 9:
> {code}
> JAVA_OPTS: -server -Xms1303m -Xmx1303m -XX:MetaspaceSize=96M -XX:MaxMetaspaceSize=256m
> -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFLY-10814) Clustered singleton MDB doesn't get activated after master node is shutdown
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFLY-10814?page=com.atlassian.jira.plugin... ]
James Perkins commented on WFLY-10814:
--------------------------------------
[~rhusar] Okay. I'm mostly curious because it's listed as a blocker.
> Clustered singleton MDB doesn't get activated after master node is shutdown
> ---------------------------------------------------------------------------
>
> Key: WFLY-10814
> URL: https://issues.jboss.org/browse/WFLY-10814
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 14.0.0.CR1
> Reporter: Erich Duda
> Assignee: Paul Ferraro
> Priority: Blocker
>
> *Scenario*
> * There are two Wildfly servers configured in cluster
> * Both servers have deployment with clustered singleton MDB
> * Start both servers
> * Check that MDB is active only on one server
> * Shutdown server with active MDB
> * Check that MDB get activated on the second server.
> Sometimes happens that MDB doesn't get activated on the second server. The test waits 60 seconds for it. Always when this issue happens, I can see following exception in the log of the second server which is logged after the first server is shutdown.
> The issue was hit with WildFly master built on 9th August (6675410).
> *Blocker* priority was set because it is regression against WF 13.
> {code}
> 09:12:45,274 WARN [org.wildfly.clustering.server] (DistributedSingletonService - 1) WFLYCLSV0012: Failed to notify server/default service provider registration listener of new providers: [node-2]: java.util.con
> current.CompletionException: java.util.concurrent.RejectedExecutionException: Task java.util.concurrent.FutureTask@151e803d rejected from java.util.concurrent.ThreadPoolExecutor@46fff41f[Terminated, pool size =
> 0, active threads = 0, queued tasks = 0, completed tasks = 2]
> at java.util.concurrent.CompletableFuture.reportJoin(CompletableFuture.java:375) [rt.jar:1.8.0_171]
> at java.util.concurrent.CompletableFuture.join(CompletableFuture.java:1934) [rt.jar:1.8.0_171]
> at org.jgroups.blocks.UnicastRequest.lambda$join$0(UnicastRequest.java:110) [jgroups-4.0.13.Final.jar:4.0.13.Final]
> at org.jgroups.blocks.UnicastRequest.around(UnicastRequest.java:137) [jgroups-4.0.13.Final.jar:4.0.13.Final]
> at org.jgroups.blocks.UnicastRequest.join(UnicastRequest.java:110) [jgroups-4.0.13.Final.jar:4.0.13.Final]
> at org.wildfly.clustering.server.singleton.AbstractDistributedSingletonService.providersChanged(AbstractDistributedSingletonService.java:121) [wildfly-clustering-server-14.0.0.Beta2-SNAPSHOT.jar:14.0.0.B
> eta2-SNAPSHOT]
> at org.wildfly.clustering.server.provider.CacheServiceProviderRegistry.lambda$modified$5(CacheServiceProviderRegistry.java:285) [wildfly-clustering-server-14.0.0.Beta2-SNAPSHOT.jar:14.0.0.Beta2-SNAPSHOT]
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [rt.jar:1.8.0_171]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) [rt.jar:1.8.0_171]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [rt.jar:1.8.0_171]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [rt.jar:1.8.0_171]
> at org.wildfly.clustering.service.concurrent.ClassLoaderThreadFactory.lambda$newThread$0(ClassLoaderThreadFactory.java:47) [wildfly-clustering-service-14.0.0.Beta2-SNAPSHOT.jar:14.0.0.Beta2-SNAPSHOT]
> at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_171]
> at org.jboss.threads.JBossThread.run(JBossThread.java:485) [jboss-threads-2.3.2.Final.jar:2.3.2.Final]
> Caused by: java.util.concurrent.RejectedExecutionException: Task java.util.concurrent.FutureTask@151e803d rejected from java.util.concurrent.ThreadPoolExecutor@46fff41f[Terminated, pool size = 0, active threads
> = 0, queued tasks = 0, completed tasks = 2]
> at java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2063) [rt.jar:1.8.0_171]
> at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:830) [rt.jar:1.8.0_171]
> at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1379) [rt.jar:1.8.0_171]
> at java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:112) [rt.jar:1.8.0_171]
> at org.wildfly.clustering.server.dispatcher.ChannelCommandDispatcherFactory.handle(ChannelCommandDispatcherFactory.java:143) [wildfly-clustering-server-14.0.0.Beta2-SNAPSHOT.jar:14.0.0.Beta2-SNAPSHOT]
> at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:383) [jgroups-4.0.13.Final.jar:4.0.13.Final]
> at org.jgroups.blocks.RequestCorrelator.dispatch(RequestCorrelator.java:356) [jgroups-4.0.13.Final.jar:4.0.13.Final]
> at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:307) [jgroups-4.0.13.Final.jar:4.0.13.Final]
> at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:582) [jgroups-4.0.13.Final.jar:4.0.13.Final]
> at org.jgroups.JChannel.up(JChannel.java:816) [jgroups-4.0.13.Final.jar:4.0.13.Final]
> at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:893) [jgroups-4.0.13.Final.jar:4.0.13.Final]
> at org.jgroups.protocols.FORK.up(FORK.java:130) [jgroups-4.0.13.Final.jar:4.0.13.Final]
> at org.jgroups.protocols.FRAG3.up(FRAG3.java:171) [jgroups-4.0.13.Final.jar:4.0.13.Final]
> at org.jgroups.protocols.FlowControl.up(FlowControl.java:351) [jgroups-4.0.13.Final.jar:4.0.13.Final]
> at org.jgroups.protocols.FlowControl.up(FlowControl.java:359) [jgroups-4.0.13.Final.jar:4.0.13.Final]
> at org.jgroups.protocols.pbcast.GMS.up(GMS.java:873) [jgroups-4.0.13.Final.jar:4.0.13.Final]
> at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:240) [jgroups-4.0.13.Final.jar:4.0.13.Final]
> at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:375) [jgroups-4.0.13.Final.jar:4.0.13.Final]
> at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:600) [jgroups-4.0.13.Final.jar:4.0.13.Final]
> at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:130) [jgroups-4.0.13.Final.jar:4.0.13.Final]
> at org.jgroups.protocols.FD_ALL.up(FD_ALL.java:203) [jgroups-4.0.13.Final.jar:4.0.13.Final]
> at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:253) [jgroups-4.0.13.Final.jar:4.0.13.Final]
> at org.jgroups.protocols.MERGE3.up(MERGE3.java:280) [jgroups-4.0.13.Final.jar:4.0.13.Final]
> at org.jgroups.protocols.Discovery.up(Discovery.java:269) [jgroups-4.0.13.Final.jar:4.0.13.Final]
> at org.jgroups.protocols.TP.passMessageUp(TP.java:1248) [jgroups-4.0.13.Final.jar:4.0.13.Final]
> at org.jgroups.util.SubmitToThreadPool$SingleMessageHandler.run(SubmitToThreadPool.java:87) [jgroups-4.0.13.Final.jar:4.0.13.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [rt.jar:1.8.0_171]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [rt.jar:1.8.0_171]
> at org.jboss.as.clustering.jgroups.ClassLoaderThreadFactory.lambda$newThread$0(ClassLoaderThreadFactory.java:52)
> at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_171]
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFLY-10814) Clustered singleton MDB doesn't get activated after master node is shutdown
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-10814?page=com.atlassian.jira.plugin... ]
Radoslav Husar commented on WFLY-10814:
---------------------------------------
[~jamezp] This test still fails with current upstream master (385e172e0fa2c20766533f1300731e7825075863).
> Clustered singleton MDB doesn't get activated after master node is shutdown
> ---------------------------------------------------------------------------
>
> Key: WFLY-10814
> URL: https://issues.jboss.org/browse/WFLY-10814
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 14.0.0.CR1
> Reporter: Erich Duda
> Assignee: Paul Ferraro
> Priority: Blocker
>
> *Scenario*
> * There are two Wildfly servers configured in cluster
> * Both servers have deployment with clustered singleton MDB
> * Start both servers
> * Check that MDB is active only on one server
> * Shutdown server with active MDB
> * Check that MDB get activated on the second server.
> Sometimes happens that MDB doesn't get activated on the second server. The test waits 60 seconds for it. Always when this issue happens, I can see following exception in the log of the second server which is logged after the first server is shutdown.
> The issue was hit with WildFly master built on 9th August (6675410).
> *Blocker* priority was set because it is regression against WF 13.
> {code}
> 09:12:45,274 WARN [org.wildfly.clustering.server] (DistributedSingletonService - 1) WFLYCLSV0012: Failed to notify server/default service provider registration listener of new providers: [node-2]: java.util.con
> current.CompletionException: java.util.concurrent.RejectedExecutionException: Task java.util.concurrent.FutureTask@151e803d rejected from java.util.concurrent.ThreadPoolExecutor@46fff41f[Terminated, pool size =
> 0, active threads = 0, queued tasks = 0, completed tasks = 2]
> at java.util.concurrent.CompletableFuture.reportJoin(CompletableFuture.java:375) [rt.jar:1.8.0_171]
> at java.util.concurrent.CompletableFuture.join(CompletableFuture.java:1934) [rt.jar:1.8.0_171]
> at org.jgroups.blocks.UnicastRequest.lambda$join$0(UnicastRequest.java:110) [jgroups-4.0.13.Final.jar:4.0.13.Final]
> at org.jgroups.blocks.UnicastRequest.around(UnicastRequest.java:137) [jgroups-4.0.13.Final.jar:4.0.13.Final]
> at org.jgroups.blocks.UnicastRequest.join(UnicastRequest.java:110) [jgroups-4.0.13.Final.jar:4.0.13.Final]
> at org.wildfly.clustering.server.singleton.AbstractDistributedSingletonService.providersChanged(AbstractDistributedSingletonService.java:121) [wildfly-clustering-server-14.0.0.Beta2-SNAPSHOT.jar:14.0.0.B
> eta2-SNAPSHOT]
> at org.wildfly.clustering.server.provider.CacheServiceProviderRegistry.lambda$modified$5(CacheServiceProviderRegistry.java:285) [wildfly-clustering-server-14.0.0.Beta2-SNAPSHOT.jar:14.0.0.Beta2-SNAPSHOT]
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [rt.jar:1.8.0_171]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) [rt.jar:1.8.0_171]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [rt.jar:1.8.0_171]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [rt.jar:1.8.0_171]
> at org.wildfly.clustering.service.concurrent.ClassLoaderThreadFactory.lambda$newThread$0(ClassLoaderThreadFactory.java:47) [wildfly-clustering-service-14.0.0.Beta2-SNAPSHOT.jar:14.0.0.Beta2-SNAPSHOT]
> at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_171]
> at org.jboss.threads.JBossThread.run(JBossThread.java:485) [jboss-threads-2.3.2.Final.jar:2.3.2.Final]
> Caused by: java.util.concurrent.RejectedExecutionException: Task java.util.concurrent.FutureTask@151e803d rejected from java.util.concurrent.ThreadPoolExecutor@46fff41f[Terminated, pool size = 0, active threads
> = 0, queued tasks = 0, completed tasks = 2]
> at java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2063) [rt.jar:1.8.0_171]
> at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:830) [rt.jar:1.8.0_171]
> at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1379) [rt.jar:1.8.0_171]
> at java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:112) [rt.jar:1.8.0_171]
> at org.wildfly.clustering.server.dispatcher.ChannelCommandDispatcherFactory.handle(ChannelCommandDispatcherFactory.java:143) [wildfly-clustering-server-14.0.0.Beta2-SNAPSHOT.jar:14.0.0.Beta2-SNAPSHOT]
> at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:383) [jgroups-4.0.13.Final.jar:4.0.13.Final]
> at org.jgroups.blocks.RequestCorrelator.dispatch(RequestCorrelator.java:356) [jgroups-4.0.13.Final.jar:4.0.13.Final]
> at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:307) [jgroups-4.0.13.Final.jar:4.0.13.Final]
> at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:582) [jgroups-4.0.13.Final.jar:4.0.13.Final]
> at org.jgroups.JChannel.up(JChannel.java:816) [jgroups-4.0.13.Final.jar:4.0.13.Final]
> at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:893) [jgroups-4.0.13.Final.jar:4.0.13.Final]
> at org.jgroups.protocols.FORK.up(FORK.java:130) [jgroups-4.0.13.Final.jar:4.0.13.Final]
> at org.jgroups.protocols.FRAG3.up(FRAG3.java:171) [jgroups-4.0.13.Final.jar:4.0.13.Final]
> at org.jgroups.protocols.FlowControl.up(FlowControl.java:351) [jgroups-4.0.13.Final.jar:4.0.13.Final]
> at org.jgroups.protocols.FlowControl.up(FlowControl.java:359) [jgroups-4.0.13.Final.jar:4.0.13.Final]
> at org.jgroups.protocols.pbcast.GMS.up(GMS.java:873) [jgroups-4.0.13.Final.jar:4.0.13.Final]
> at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:240) [jgroups-4.0.13.Final.jar:4.0.13.Final]
> at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:375) [jgroups-4.0.13.Final.jar:4.0.13.Final]
> at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:600) [jgroups-4.0.13.Final.jar:4.0.13.Final]
> at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:130) [jgroups-4.0.13.Final.jar:4.0.13.Final]
> at org.jgroups.protocols.FD_ALL.up(FD_ALL.java:203) [jgroups-4.0.13.Final.jar:4.0.13.Final]
> at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:253) [jgroups-4.0.13.Final.jar:4.0.13.Final]
> at org.jgroups.protocols.MERGE3.up(MERGE3.java:280) [jgroups-4.0.13.Final.jar:4.0.13.Final]
> at org.jgroups.protocols.Discovery.up(Discovery.java:269) [jgroups-4.0.13.Final.jar:4.0.13.Final]
> at org.jgroups.protocols.TP.passMessageUp(TP.java:1248) [jgroups-4.0.13.Final.jar:4.0.13.Final]
> at org.jgroups.util.SubmitToThreadPool$SingleMessageHandler.run(SubmitToThreadPool.java:87) [jgroups-4.0.13.Final.jar:4.0.13.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [rt.jar:1.8.0_171]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [rt.jar:1.8.0_171]
> at org.jboss.as.clustering.jgroups.ClassLoaderThreadFactory.lambda$newThread$0(ClassLoaderThreadFactory.java:52)
> at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_171]
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFLY-10835) Connection factory with discovery-group doesn't work
by ehsavoie Hugonnet (JIRA)
[ https://issues.jboss.org/browse/WFLY-10835?page=com.atlassian.jira.plugin... ]
ehsavoie Hugonnet updated WFLY-10835:
-------------------------------------
Attachment: firefox.desktop
> Connection factory with discovery-group doesn't work
> ----------------------------------------------------
>
> Key: WFLY-10835
> URL: https://issues.jboss.org/browse/WFLY-10835
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 13.0.0.Final
> Reporter: Martin Styk
> Assignee: Jeff Mesnil
> Priority: Critical
> Attachments: firefox.desktop, server-trace.log, standalone-full-ha.xml
>
>
> Jms client can not use remote connection factory defined as follows
> {noformat}
> <discovery-group name="dg-group1" jgroups-cluster="activemq-cluster"/>
> <connection-factory name="RemoteConnectionFactory" entries="java:jboss/exported/jms/RemoteConnectionFactory" discovery-group="dg-group1" ha="true" block-on-acknowledge="true" reconnect-attempts="-1"/>
> {noformat}
> Following exception is thrown on client
> {noformat}
> Exception in thread "main" java.lang.RuntimeException: javax.naming.CommunicationException: WFNAM00020: Remote naming operation failed [Root exception is java.io.EOFException: Read past end of file]
> at client.ProducerJms11.sendMessages(ProducerJms11.java:67)
> at client.Producer.run(Producer.java:34)
> at client.Producer.sendAllSync(Producer.java:25)
> at client.ProducerJms11.main(ProducerJms11.java:14)
> Caused by: javax.naming.CommunicationException: WFNAM00020: Remote naming operation failed [Root exception is java.io.EOFException: Read past end of file]
> at org.wildfly.naming.client.remote.RemoteClientTransport.lookup(RemoteClientTransport.java:261)
> at org.wildfly.naming.client.remote.RemoteContext.lambda$lookupNative$0(RemoteContext.java:190)
> at org.wildfly.naming.client.NamingProvider.performExceptionAction(NamingProvider.java:222)
> at org.wildfly.naming.client.remote.RemoteContext.performWithRetry(RemoteContext.java:100)
> at org.wildfly.naming.client.remote.RemoteContext.lookupNative(RemoteContext.java:188)
> at org.wildfly.naming.client.AbstractFederatingContext.lookup(AbstractFederatingContext.java:74)
> at org.wildfly.naming.client.store.RelativeFederatingContext.lookupNative(RelativeFederatingContext.java:58)
> at org.wildfly.naming.client.AbstractFederatingContext.lookup(AbstractFederatingContext.java:74)
> at org.wildfly.naming.client.AbstractFederatingContext.lookup(AbstractFederatingContext.java:60)
> at org.wildfly.naming.client.AbstractFederatingContext.lookup(AbstractFederatingContext.java:66)
> at org.wildfly.naming.client.WildFlyRootContext.lookup(WildFlyRootContext.java:144)
> at javax.naming.InitialContext.lookup(InitialContext.java:417)
> at client.ProducerJms11.sendMessages(ProducerJms11.java:43)
> ... 3 more
> Caused by: java.io.EOFException: Read past end of file
> at org.jboss.marshalling.SimpleDataInput.eofOnRead(SimpleDataInput.java:151)
> at org.jboss.marshalling.SimpleDataInput.readUnsignedByteDirect(SimpleDataInput.java:294)
> at org.jboss.marshalling.SimpleDataInput.readUnsignedByte(SimpleDataInput.java:249)
> at org.jboss.marshalling.river.BlockUnmarshaller.readUnsignedByte(BlockUnmarshaller.java:258)
> at org.jboss.marshalling.river.BlockUnmarshaller.readInt(BlockUnmarshaller.java:296)
> at org.jboss.marshalling.river.BlockUnmarshaller.readUTF(BlockUnmarshaller.java:326)
> at org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.readExternal(ActiveMQConnectionFactory.java:186)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1414)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:272)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:205)
> at org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:41)
> at org.wildfly.naming.client.remote.RemoteClientTransport.lookup(RemoteClientTransport.java:243)
> ... 15 more
> Caused by: an exception which occurred:
> in object of type org.apache.activemq.artemis.jms.client.ActiveMQJMSConnectionFactory
> {noformat}
> It fails on attempt to look up RemoteCF
> {noformat}
> ConnectionFactory connectionFactory = (ConnectionFactory) namingContext.lookup(ClientDefaults.CONNECTION_FACTORY);
> {noformat}
> Same scenario with connector works well.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFWIP-108) OpenTracing modules need jboss-api=private in module.xml
by Juraci Paixão Kröhling (JIRA)
[ https://issues.jboss.org/browse/WFWIP-108?page=com.atlassian.jira.plugin.... ]
Juraci Paixão Kröhling reassigned WFWIP-108:
--------------------------------------------
Assignee: Juraci Paixão Kröhling
> OpenTracing modules need jboss-api=private in module.xml
> --------------------------------------------------------
>
> Key: WFWIP-108
> URL: https://issues.jboss.org/browse/WFWIP-108
> Project: WildFly WIP
> Issue Type: Bug
> Components: MP Request Tracing
> Reporter: Brian Stansberry
> Assignee: Juraci Paixão Kröhling
> Priority: Blocker
>
> The 3 modules added in https://github.com/wildfly/wildfly/pull/11454 need this in their module.xml:
> {code}
> <properties>
> <property name="jboss.api" value="private"/>
> </properties>
> {code}
> This ensures that we log a WARN if the user tries to _directly_ use these modules as application dependencies. (Directly == via their own deployment configuration, not via our subsystem wiring them in as a dependency. See [1] for the impl.)
> These log WARNs and the setting in the file itself are important both to prevent the user making mistakes and as the formal the mechanism by which we control how we support use of the various libraries we ship in the appserver. Marking modules private, deprecated etc gives us the freedom to rework implementations without worrying about breaking unexpected uses of things.
> [1] https://github.com/wildfly/wildfly-core/blob/master/server/src/main/java/...
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months