[JBoss JIRA] (WFCORE-48) EOFException when address of a mgmt operation is of a bad data type
by Emmanuel Hugonnet (JIRA)
[ https://issues.jboss.org/browse/WFCORE-48?page=com.atlassian.jira.plugin.... ]
Emmanuel Hugonnet edited comment on WFCORE-48 at 1/28/15 11:46 AM:
-------------------------------------------------------------------
The problem comes from
{code:java}
PathAddress.pathAddress(new ModelNode().set(""));
{code} that throws an IllegalArgumentException
was (Author: ehugonnet):
The problem comes from org.jboss.as.controller.remote.ModelControllerClientOperationHandler.sendPreparedResponse(ModelControllerClientOperationHandler.java:248) that throws an IllegalArgumentException
> EOFException when address of a mgmt operation is of a bad data type
> -------------------------------------------------------------------
>
> Key: WFCORE-48
> URL: https://issues.jboss.org/browse/WFCORE-48
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Ladislav Thon
> Assignee: Emmanuel Hugonnet
>
> (Hopefully this belongs to WildFly Core. If not, please move to WildFly.)
> I'm doing a programmatic invocation of a simple mgmt operation on the root mgmt resource, say e.g. {{:whoami}}. I'm doing this against a freshly built WildFly from master branch (commit {{e2b9ecfb}}) and on the client side, I'm depending on {{org.wildfly.core:wildfly-controller-client:1.0.0.Alpha4}}.
> The code looks like this:
> {code:java}
> ModelControllerClient client = ModelControllerClient.Factory.create("localhost", 9990);
> try {
> ModelNode op = new ModelNode();
> op.get(ClientConstants.OP).set("whoami");
> op.get(ClientConstants.OP_ADDR).set("");
> ModelNode result = client.execute(op);
> System.out.println(result);
> } finally {
> client.close();
> }
> {code}
> This fails with an exception like this:
> {code}
> Exception in thread "main" java.io.IOException: java.util.concurrent.ExecutionException: Operation failed
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:129)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:71)
> at cz.ladicek.wildfly.ErrorReproducer.main(ErrorReproducer.java:17)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at com.intellij.rt.execution.application.AppMain.main(AppMain.java:134)
> Caused by: java.util.concurrent.ExecutionException: Operation failed
> at org.jboss.threads.AsyncFutureTask.operationFailed(AsyncFutureTask.java:74)
> at org.jboss.threads.AsyncFutureTask.get(AsyncFutureTask.java:268)
> at org.jboss.as.controller.client.impl.AbstractDelegatingAsyncFuture.get(AbstractDelegatingAsyncFuture.java:100)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:127)
> ... 7 more
> Caused by: java.io.EOFException
> at java.io.DataInputStream.readByte(DataInputStream.java:267)
> at org.jboss.as.protocol.mgmt.ProtocolUtils.expectHeader(ProtocolUtils.java:83)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient$1.handleRequest(AbstractModelControllerClient.java:167)
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler.handleMessage(AbstractMessageHandler.java:270)
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler.handleRequest(AbstractMessageHandler.java:235)
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler.handleMessage(AbstractMessageHandler.java:113)
> at org.jboss.as.protocol.mgmt.ManagementChannelReceiver$1.handleMessage(ManagementChannelReceiver.java:56)
> at org.jboss.as.protocol.mgmt.ManagementChannelReceiver.handleMessage(ManagementChannelReceiver.java:84)
> at org.jboss.remoting3.remote.RemoteConnectionChannel$5.run(RemoteConnectionChannel.java:452)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> {code}
> However, when I remove the line that sets {{address}} ({{op.get(ClientConstants.OP_ADDR).set("");}}), it works just fine.
> Fine, I made a mistake, but getting an {{EOFException}}? That's hardly an appropriate response. I should get a proper failure ({{"outcome" => "failed"}} etc.).
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (WFLY-4292) Deployment descriptors from a referenced installed library are ignored
by Martin Kouba (JIRA)
Martin Kouba created WFLY-4292:
----------------------------------
Summary: Deployment descriptors from a referenced installed library are ignored
Key: WFLY-4292
URL: https://issues.jboss.org/browse/WFLY-4292
Project: WildFly
Issue Type: Quality Risk
Components: CDI / Weld, EE
Affects Versions: 8.2.0.Final
Reporter: Martin Kouba
Assignee: Stuart Douglas
This is more a question than a bug report. A Weld user run into this issue (see also WELD-1851) and we're not quite sure whether this is something that should work.
There are two separated applications: {{test-ejb-jar}} and {{test-war}}. {{test-ejb-jar}} contains {{persistence.xml}} descriptor. When {{test-war}} is referencing {{test-ejb-jar}} (either by means of jboss-deployment.xml, Dependencies manifest entry or by means of extension mechanism) the deployment of {{test-war}} fails, because a persistence unit is not found during injection.
Now the question is whether the "Library Support" only means access to *classes and resources* or *classes, resources and descriptors*. I believe it's the former but the EE spec is not clear.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (WFCORE-48) EOFException when address of a mgmt operation is of a bad data type
by Emmanuel Hugonnet (JIRA)
[ https://issues.jboss.org/browse/WFCORE-48?page=com.atlassian.jira.plugin.... ]
Emmanuel Hugonnet commented on WFCORE-48:
-----------------------------------------
The problem comes from org.jboss.as.controller.remote.ModelControllerClientOperationHandler.sendPreparedResponse(ModelControllerClientOperationHandler.java:248) that throws an IllegalArgumentException
> EOFException when address of a mgmt operation is of a bad data type
> -------------------------------------------------------------------
>
> Key: WFCORE-48
> URL: https://issues.jboss.org/browse/WFCORE-48
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Ladislav Thon
> Assignee: Emmanuel Hugonnet
>
> (Hopefully this belongs to WildFly Core. If not, please move to WildFly.)
> I'm doing a programmatic invocation of a simple mgmt operation on the root mgmt resource, say e.g. {{:whoami}}. I'm doing this against a freshly built WildFly from master branch (commit {{e2b9ecfb}}) and on the client side, I'm depending on {{org.wildfly.core:wildfly-controller-client:1.0.0.Alpha4}}.
> The code looks like this:
> {code:java}
> ModelControllerClient client = ModelControllerClient.Factory.create("localhost", 9990);
> try {
> ModelNode op = new ModelNode();
> op.get(ClientConstants.OP).set("whoami");
> op.get(ClientConstants.OP_ADDR).set("");
> ModelNode result = client.execute(op);
> System.out.println(result);
> } finally {
> client.close();
> }
> {code}
> This fails with an exception like this:
> {code}
> Exception in thread "main" java.io.IOException: java.util.concurrent.ExecutionException: Operation failed
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:129)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:71)
> at cz.ladicek.wildfly.ErrorReproducer.main(ErrorReproducer.java:17)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at com.intellij.rt.execution.application.AppMain.main(AppMain.java:134)
> Caused by: java.util.concurrent.ExecutionException: Operation failed
> at org.jboss.threads.AsyncFutureTask.operationFailed(AsyncFutureTask.java:74)
> at org.jboss.threads.AsyncFutureTask.get(AsyncFutureTask.java:268)
> at org.jboss.as.controller.client.impl.AbstractDelegatingAsyncFuture.get(AbstractDelegatingAsyncFuture.java:100)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:127)
> ... 7 more
> Caused by: java.io.EOFException
> at java.io.DataInputStream.readByte(DataInputStream.java:267)
> at org.jboss.as.protocol.mgmt.ProtocolUtils.expectHeader(ProtocolUtils.java:83)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient$1.handleRequest(AbstractModelControllerClient.java:167)
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler.handleMessage(AbstractMessageHandler.java:270)
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler.handleRequest(AbstractMessageHandler.java:235)
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler.handleMessage(AbstractMessageHandler.java:113)
> at org.jboss.as.protocol.mgmt.ManagementChannelReceiver$1.handleMessage(ManagementChannelReceiver.java:56)
> at org.jboss.as.protocol.mgmt.ManagementChannelReceiver.handleMessage(ManagementChannelReceiver.java:84)
> at org.jboss.remoting3.remote.RemoteConnectionChannel$5.run(RemoteConnectionChannel.java:452)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> {code}
> However, when I remove the line that sets {{address}} ({{op.get(ClientConstants.OP_ADDR).set("");}}), it works just fine.
> Fine, I made a mistake, but getting an {{EOFException}}? That's hardly an appropriate response. I should get a proper failure ({{"outcome" => "failed"}} etc.).
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (WFLY-3549) Deadlock during shutdown
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-3549?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-3549:
-----------------------------------------------
Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 1184532|https://bugzilla.redhat.com/show_bug.cgi?id=1184532] from NEW to ASSIGNED
> Deadlock during shutdown
> ------------------------
>
> Key: WFLY-3549
> URL: https://issues.jboss.org/browse/WFLY-3549
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 8.1.0.Final
> Reporter: Dan Berindei
> Assignee: David Lloyd
> Fix For: 8.2.0.Final
>
>
> This deadlock appeared in an Arquillian test:
> {noformat}
> Found one Java-level deadlock:
> =============================
> "undefined":
> waiting to lock monitor 0x00007f67a421bfa8 (object 0x00000000e0700480, a org.jboss.as.threads.ScheduledThreadPoolService),
> which is held by "MSC service thread 1-2"
> "MSC service thread 1-2":
> waiting for ownable synchronizer 0x00000000e0700618, (a java.util.concurrent.locks.ReentrantLock$NonfairSync),
> which is held by "undefined"
> Java stack information for the threads listed above:
> ===================================================
> "undefined":
> at org.jboss.as.threads.ScheduledThreadPoolService$ExecutorImpl.terminated(ScheduledThreadPoolService.java:121)
> - waiting to lock <0x00000000e0700480> (a org.jboss.as.threads.ScheduledThreadPoolService)
> at java.util.concurrent.ThreadPoolExecutor.tryTerminate(ThreadPoolExecutor.java:704)
> at java.util.concurrent.ThreadPoolExecutor.processWorkerExit(ThreadPoolExecutor.java:1006)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1163)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:724)
> at org.jboss.threads.JBossThread.run(JBossThread.java:122)
> "MSC service thread 1-2":
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x00000000e0700618> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:867)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1197)
> at java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:214)
> at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:290)
> at java.util.concurrent.ThreadPoolExecutor.interruptIdleWorkers(ThreadPoolExecutor.java:781)
> at java.util.concurrent.ThreadPoolExecutor.tryTerminate(ThreadPoolExecutor.java:695)
> at java.util.concurrent.ThreadPoolExecutor.shutdown(ThreadPoolExecutor.java:1397)
> at java.util.concurrent.ScheduledThreadPoolExecutor.shutdown(ScheduledThreadPoolExecutor.java:759)
> at org.jboss.as.threads.ManagedScheduledExecutorService.internalShutdown(ManagedScheduledExecutorService.java:53)
> at org.jboss.as.threads.ScheduledThreadPoolService.stop(ScheduledThreadPoolService.java:67)
> - locked <0x00000000e0700480> (a org.jboss.as.threads.ScheduledThreadPoolService)
> at org.jboss.msc.service.ServiceControllerImpl$StopTask.stopService(ServiceControllerImpl.java:2056)
> at org.jboss.msc.service.ServiceControllerImpl$StopTask.run(ServiceControllerImpl.java:2017)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:724)
> Found 1 deadlock.
> {noformat}
> Looks like two MSC service threads exited and tried to terminate the thread pool at the same time. And because the MSC threads are not daemon threads, the entire JVM hangs and blocks the Arquillian test that was waiting for the container to shut down.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (JGRP-1898) FD_HOST many false suspect with Full GC
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/JGRP-1898?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on JGRP-1898:
-----------------------------------------------
Dave Stahl <dstahl(a)redhat.com> changed the Status of [bug 1161529|https://bugzilla.redhat.com/show_bug.cgi?id=1161529] from VERIFIED to CLOSED
> FD_HOST many false suspect with Full GC
> ---------------------------------------
>
> Key: JGRP-1898
> URL: https://issues.jboss.org/browse/JGRP-1898
> Project: JGroups
> Issue Type: Enhancement
> Affects Versions: 3.5.1
> Reporter: Takayoshi Kimura
> Assignee: Takayoshi Kimura
> Fix For: 3.4.7, 3.5.2, 3.6.1
>
> Attachments: FD_HOSTTest.java, test-fdhost.zip
>
>
> Currently FD_HOST PingTask has 2 loops, ping loop and cheking timeout loop.
> {code}
> for (h: hosts) { ping_and_update_timestamp(host) }
> current = System.currentTimeMillis();
> for (h: hosts) { compare current and (ping_timestmp + timeout) }
> {code}
> Testing with large number of hosts, after lengthy Full GC during the ping loop, FD_HOST checks timeout and it counts the Full GC time in, sometimes causes many false suspects.
> For example, 1 min Full GC and 50 sec timeout, all hosts are suspected with current implementation.
> To reduce the impact of the Full GC time, we can combine the 2 loops into 1 loop, ping and checking timeout each host, so the Full GC delay only affects to a single host and never affect to other hosts.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (JGRP-1898) FD_HOST many false suspect with Full GC
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/JGRP-1898?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on JGRP-1898:
-----------------------------------------------
Dave Stahl <dstahl(a)redhat.com> changed the Status of [bug 1161529|https://bugzilla.redhat.com/show_bug.cgi?id=1161529] from VERIFIED to CLOSED
> FD_HOST many false suspect with Full GC
> ---------------------------------------
>
> Key: JGRP-1898
> URL: https://issues.jboss.org/browse/JGRP-1898
> Project: JGroups
> Issue Type: Enhancement
> Affects Versions: 3.5.1
> Reporter: Takayoshi Kimura
> Assignee: Takayoshi Kimura
> Fix For: 3.4.7, 3.5.2, 3.6.1
>
> Attachments: FD_HOSTTest.java, test-fdhost.zip
>
>
> Currently FD_HOST PingTask has 2 loops, ping loop and cheking timeout loop.
> {code}
> for (h: hosts) { ping_and_update_timestamp(host) }
> current = System.currentTimeMillis();
> for (h: hosts) { compare current and (ping_timestmp + timeout) }
> {code}
> Testing with large number of hosts, after lengthy Full GC during the ping loop, FD_HOST checks timeout and it counts the Full GC time in, sometimes causes many false suspects.
> For example, 1 min Full GC and 50 sec timeout, all hosts are suspected with current implementation.
> To reduce the impact of the Full GC time, we can combine the 2 loops into 1 loop, ping and checking timeout each host, so the Full GC delay only affects to a single host and never affect to other hosts.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months