[JBoss JIRA] (WFLY-2515) JBAS014249 if a fire and forget asynchronous ejb call is made
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-2515?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-2515:
-----------------------------------------------
Dominik Pospisil <dpospisi(a)redhat.com> changed the Status of [bug 1030936|https://bugzilla.redhat.com/show_bug.cgi?id=1030936] from NEW to ASSIGNED
> JBAS014249 if a fire and forget asynchronous ejb call is made
> -------------------------------------------------------------
>
> Key: WFLY-2515
> URL: https://issues.jboss.org/browse/WFLY-2515
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 8.0.0.Beta1, 8.0.0.CR1
> Environment: Beta2 SNAPSHOT
> Reporter: Wolf-Dieter Fink
> Assignee: David Lloyd
>
> If an ejb method
> @Asynchronous void fireAndForget(...)
> is called remote and the client disconnect an Exception JBAS014249 will be thrown if the async method return.
> {noformat}
> ERROR [org.jboss.as.ejb3] (EJB default - 1) JBAS014249: Error invoking method public abstract void org.jboss.as.quickstarts.ejb.asynchronous.AsynchronousAccess.fireAndForget(long) on bean named AsynchronousAccessBean for appname modulename jboss-as-ejb-asynchronous-ejb distinctname : java.lang.NullPointerException
> at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.invokeMethod(MethodInvocationMessageHandler.java:322)
> at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.access$100(MethodInvocationMessageHandler.java:70)
> at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler$1.run(MethodInvocationMessageHandler.java:203)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [rt.jar:1.7.0_25]
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) [rt.jar:1.7.0_25]
> at java.util.concurrent.FutureTask.run(FutureTask.java:166) [rt.jar:1.7.0_25]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
> at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
> at org.jboss.threads.JBossThread.run(JBossThread.java:122)
> 11:30:20,242 ERROR [org.jboss.as.ejb3] (EJB default - 1) JBAS014250: Could not write method invocation failure for method public abstract void org.jboss.as.quickstarts.ejb.asynchronous.AsynchronousAccess.fireAndForget(long) on bean named AsynchronousAccessBean for appname modulename jboss-as-ejb-asynchronous-ejb distinctname due to: java.io.IOException: JBAS014560: Could not open message outputstream for writing to Channel
> at org.jboss.as.ejb3.remote.protocol.AbstractMessageHandler.writeException(AbstractMessageHandler.java:102)
> at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.access$400(MethodInvocationMessageHandler.java:70)
> at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler$1.run(MethodInvocationMessageHandler.java:213)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [rt.jar:1.7.0_25]
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) [rt.jar:1.7.0_25]
> at java.util.concurrent.FutureTask.run(FutureTask.java:166) [rt.jar:1.7.0_25]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
> at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
> at org.jboss.threads.JBossThread.run(JBossThread.java:122)
> Caused by: org.jboss.remoting3.NotOpenException: Writes closed
> at org.jboss.remoting3.remote.RemoteConnectionChannel.openOutboundMessage(RemoteConnectionChannel.java:112)
> at org.jboss.remoting3.remote.RemoteConnectionChannel.writeMessage(RemoteConnectionChannel.java:301)
> at org.jboss.as.ejb3.remote.protocol.versionone.ChannelAssociation.acquireChannelMessageOutputStream(ChannelAssociation.java:68)
> at org.jboss.as.ejb3.remote.protocol.AbstractMessageHandler.writeException(AbstractMessageHandler.java:100)
> ... 9 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years
[JBoss JIRA] (WFLY-904) The property AuthorizationManager is null exceptions and NPE on SimpleSecurityManager when connecting firstly from a remote client
by blass megod (JIRA)
[ https://issues.jboss.org/browse/WFLY-904?page=com.atlassian.jira.plugin.s... ]
blass megod commented on WFLY-904:
----------------------------------
I have the same error (porting from JBoss 5.1 to Jboss 8.1), but the deployment is ok if I'm in debug from Eclipse on Wildfly and I put a breakpoint anywhere in the code before the first ejb method invocation (repeated the test more that 50 times with and without debug).
> The property AuthorizationManager is null exceptions and NPE on SimpleSecurityManager when connecting firstly from a remote client
> ----------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-904
> URL: https://issues.jboss.org/browse/WFLY-904
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Environment: Eclipse Juno SR2 with JBoss Tools, Mac OS X, Sun JDK 6
> Reporter: Fernando Nasser
> Assignee: Darran Lofthouse
> Labels: eap6, investigation_required
> Attachments: NPEinSimpleSecurityManager, PBOX000075, QSecuredEJB.jar, QSecuredEJB.zip, SecurityRelatedSettings
>
>
> Description of problem:
> If one tries and use security enabled EJBs from a remote client (authenticated connection) before connecting first from a servlet both a Server NPE and an erroneous exception are thrown. However, if one uses some servlet-based authentication first, the missing field is "primed" and from that point on the remote application can use the secure EJBs normally, proper Role authorization is checked and enforced etc. With absolutely no changes in configuration, code (incl. annotation) whatsoever. Any number of remote client connections will succeed until you restart the server. Then the errors are back, until you "prime" the Server by connecting using a Servlet.
> More complete data is attached, but here are some info:
> NPE is thrown at:
> org.jboss.as.security.service.SimpleSecurityManager.authenticate(SimpleSecurityManager.java:394)
> Bean method invocation fails with exceptions containing the message:
> JBAS011048: Failed to construct component instance
> I am using the "other" security context for testing.
> I am running the Server in standalone mode.
> When I say remote I mean not in the Server, but I am running my client from localhost.
> Version-Release number of selected component (if applicable): Seen on EAP 6.1.0 alpha (apparently present on AS 7.1.1 as well).
>
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years
[JBoss JIRA] (JGRP-1877) System.nanoTime() can be negative
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1877?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-1877:
---------------------------
Comment: was deleted
(was: [comment by david]
{quote}
now here's one more problem for you, now that you've accepted nanoTime()'s benefits and quirks on some JVMs and some OSes, it uses the CPU's TSC - unfortunately, each CPU has its own, which might be slightly off from each other - so if your thread migrates between CPUs at just the wrong time, and you're on such a JVM on such an OS on such a CPU, you could still get a negative time for your elapsed time
{quote}
Hmm...)
> System.nanoTime() can be negative
> ---------------------------------
>
> Key: JGRP-1877
> URL: https://issues.jboss.org/browse/JGRP-1877
> Project: JGroups
> Issue Type: Bug
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Critical
> Fix For: 3.5.1, 3.6
>
>
> According to the javadoc, {{System.nanoTime()}} should only be used to measure _elapsed time_, but not compute a _target time in the future_, as {{nanoTime()}} might return a a time in the future.
> Code like the one below might fail:
> {code:title=Responses.waitFor()|borderStyle=solid}
> public boolean waitFor(long timeout) {
> long wait_time;
> final long target_time=System.nanoTime() + TimeUnit.NANOSECONDS.convert(timeout, TimeUnit.MILLISECONDS); // ns
> lock.lock();
> try {
> while(!done && (wait_time=target_time - System.nanoTime()) > 0) {
> try {
> cond.await(wait_time,TimeUnit.NANOSECONDS);
> }
> catch(InterruptedException e) {
> }
> }
> return done;
> }
> finally {
> lock.unlock();
> }
> }
> {code}
> When computing {{target_time}}, {{System.nanoTime()}} could return a negative value (numeric overflow) or a value in the future. In the first case, {{target_time}} could be negative, so the method would not block at all. In the latter case, {{target_time}} could be huge, so the method would block for a long time.
> Investigate all occurrences where we use {{nanoTime()}} to compute a time in the future, and see what impact a future value value could have. Possibly replace with {{System.currentTimeMillis()}} or the _time service_.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years
[JBoss JIRA] (WFLY-3839) EjbClient: No cluster node manager found for node XY during server restart
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-3839?page=com.atlassian.jira.plugin.... ]
Radoslav Husar commented on WFLY-3839:
--------------------------------------
Linked jobs are not accessible (404).
> EjbClient: No cluster node manager found for node XY during server restart
> ---------------------------------------------------------------------------
>
> Key: WFLY-3839
> URL: https://issues.jboss.org/browse/WFLY-3839
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, EJB
> Affects Versions: 8.1.0.Final
> Reporter: Dominik Pospisil
> Assignee: Paul Ferraro
>
> Situation: 4-node cluster, one node is failed at a time, during the whole test, clients are accessing stateless clustered EJB3. The failure type in this particular case is simulating server crash: JVM is killed using kill -9.
> When the server was starting, being brought back, we saw this error:
> 16:05:29,966 ERROR [org.jboss.ejb.client.ClusterContext] (ejb-client-cluster-node-connection-creation-2-thread-17) Cannot create EJBReceiver since no cluster node manager found for node perf20 in cluster context for cluster ejb
> Here is the log output again with context, the server was starting:
> 16:05:29,966 INFO [org.jboss.ejb.client.remoting.NoSuchEJBExceptionResponseHandler] (Remoting "config-based-ejb-client-endpoint" task-2) Retrying invocation which failed on node perf20 with exception:
> javax.ejb.NoSuchEJBException: No such EJB[appname=clusterbench-ee6,modulename=clusterbench-ee6-ejb,distinctname=,beanname=RemoteStatelessSBImpl]
> at org.jboss.ejb.client.remoting.NoSuchEJBExceptionResponseHandler.processMessage(NoSuchEJBExceptionResponseHandler.java:64)
> at org.jboss.ejb.client.remoting.ChannelAssociation.processResponse(ChannelAssociation.java:366)
> at org.jboss.ejb.client.remoting.ChannelAssociation$ResponseReceiver.handleMessage(ChannelAssociation.java:458)
> at org.jboss.remoting3.remote.RemoteConnectionChannel$4.run(RemoteConnectionChannel.java:373)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
> at java.lang.Thread.run(Thread.java:662)
> 16:05:29,966 ERROR [org.jboss.ejb.client.ClusterContext] (ejb-client-cluster-node-connection-creation-2-thread-17) Cannot create EJBReceiver since no cluster node manager found for node perf20 in cluster context for cluster ejb
> 16:05:29,974 INFO [org.jboss.ejb.client.remoting.NoSuchEJBExceptionResponseHandler] (Remoting "config-based-ejb-client-endpoint" task-2) Retrying invocation which failed on node perf20 with exception:
> javax.ejb.NoSuchEJBException: No such EJB[appname=clusterbench-ee6,modulename=clusterbench-ee6-ejb,distinctname=,beanname=RemoteStatelessSBImpl]
> at org.jboss.ejb.client.remoting.NoSuchEJBExceptionResponseHandler.processMessage(NoSuchEJBExceptionResponseHandler.java:64)
> at org.jboss.ejb.client.remoting.ChannelAssociation.processResponse(ChannelAssociation.java:366)
> at org.jboss.ejb.client.remoting.ChannelAssociation$ResponseReceiver.handleMessage(ChannelAssociation.java:458)
> at org.jboss.remoting3.remote.RemoteConnectionChannel$4.run(RemoteConnectionChannel.java:373)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
> at java.lang.Thread.run(Thread.java:662)
> 16:05:29,974 ERROR [org.jboss.ejb.client.ClusterContext] (ejb-client-cluster-node-connection-creation-2-thread-18) Cannot create EJBReceiver since no cluster node manager found for node perf20 in cluster context for cluster ejb
> 16:05:29,975 INFO [org.jboss.ejb.client.remoting.NoSuchEJBExceptionResponseHandler] (Remoting "config-based-ejb-client-endpoint" task-2) Retrying invocation which failed on node perf20 with exception:
> javax.ejb.NoSuchEJBException: No such EJB[appname=clusterbench-ee6,modulename=clusterbench-ee6-ejb,distinctname=,beanname=RemoteStatelessSBImpl]
> at org.jboss.ejb.client.remoting.NoSuchEJBExceptionResponseHandler.processMessage(NoSuchEJBExceptionResponseHandler.java:64)
> at org.jboss.ejb.client.remoting.ChannelAssociation.processResponse(ChannelAssociation.java:366)
> at org.jboss.ejb.client.remoting.ChannelAssociation$ResponseReceiver.handleMessage(ChannelAssociation.java:458)
> at org.jboss.remoting3.remote.RemoteConnectionChannel$4.run(RemoteConnectionChannel.java:373)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
> at java.lang.Thread.run(Thread.java:662)
> 16:05:29,975 INFO [org.jboss.ejb.client.remoting.NoSuchEJBExceptionResponseHandler] (Remoting "config-based-ejb-client-endpoint" task-2) Retrying invocation which failed on node perf20 with exception:
> javax.ejb.NoSuchEJBException: No such EJB[appname=clusterbench-ee6,modulename=clusterbench-ee6-ejb,distinctname=,beanname=RemoteStatelessSBImpl]
> at org.jboss.ejb.client.remoting.NoSuchEJBExceptionResponseHandler.processMessage(NoSuchEJBExceptionResponseHandler.java:64)
> at org.jboss.ejb.client.remoting.ChannelAssociation.processResponse(ChannelAssociation.java:366)
> at org.jboss.ejb.client.remoting.ChannelAssociation$ResponseReceiver.handleMessage(ChannelAssociation.java:458)
> at org.jboss.remoting3.remote.RemoteConnectionChannel$4.run(RemoteConnectionChannel.java:373)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
> During the whole test, there were 4 server crashes and startups (1 for each node), but only 3 occurences of the above mentioned error. These cluster nodes are perf18, perf19, perf20, perf21, but this error was seen only for perf20 (two occurences) and perf18 (one occurence).
> I did not find anything suspicious in the server.log of perf20.
> Cache: REPL_ASYNC
> Versions: EAP 6.1.0.ER6, ejb-client 1.0.19.Final
> Link to hudson job:
> https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-6x-failover-ejb-...
> Server log:
> https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-6x-failover-ejb-...
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years
[JBoss JIRA] (JGRP-1877) System.nanoTime() can be negative
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1877?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-1877 at 9/10/14 8:59 AM:
---------------------------------------------------------
[comment by david]
{quote}
now here's one more problem for you, now that you've accepted nanoTime()'s benefits and quirks on some JVMs and some OSes, it uses the CPU's TSC - unfortunately, each CPU has its own, which might be slightly off from each other - so if your thread migrates between CPUs at just the wrong time, and you're on such a JVM on such an OS on such a CPU, you could still get a negative time for your elapsed time
{quote}
Hmm...
was (Author: belaban):
[comment by david]
{quote}
now here's one more problem for you, now that you've accepted nanoTime()'s benefits and quirks on some JVMs and some OSes, it uses the CPU's TSC - unfortunately, each CPU has its own, which might be slightly off from each other - so if your thread migrates between CPUs at just the wrong time, and you're on such a JVM on such an OS on such a CPU, you could still get a negative time for your elapsed time
{quote}
In other words, the thread measuring t0 and t1 has to be the same thread ! Not a problem, IIRC, as t0 and t1 are always measured by the same thread.
> System.nanoTime() can be negative
> ---------------------------------
>
> Key: JGRP-1877
> URL: https://issues.jboss.org/browse/JGRP-1877
> Project: JGroups
> Issue Type: Bug
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Critical
> Fix For: 3.5.1, 3.6
>
>
> According to the javadoc, {{System.nanoTime()}} should only be used to measure _elapsed time_, but not compute a _target time in the future_, as {{nanoTime()}} might return a a time in the future.
> Code like the one below might fail:
> {code:title=Responses.waitFor()|borderStyle=solid}
> public boolean waitFor(long timeout) {
> long wait_time;
> final long target_time=System.nanoTime() + TimeUnit.NANOSECONDS.convert(timeout, TimeUnit.MILLISECONDS); // ns
> lock.lock();
> try {
> while(!done && (wait_time=target_time - System.nanoTime()) > 0) {
> try {
> cond.await(wait_time,TimeUnit.NANOSECONDS);
> }
> catch(InterruptedException e) {
> }
> }
> return done;
> }
> finally {
> lock.unlock();
> }
> }
> {code}
> When computing {{target_time}}, {{System.nanoTime()}} could return a negative value (numeric overflow) or a value in the future. In the first case, {{target_time}} could be negative, so the method would not block at all. In the latter case, {{target_time}} could be huge, so the method would block for a long time.
> Investigate all occurrences where we use {{nanoTime()}} to compute a time in the future, and see what impact a future value value could have. Possibly replace with {{System.currentTimeMillis()}} or the _time service_.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years
[JBoss JIRA] (JGRP-1877) System.nanoTime() can be negative
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1877?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1877:
--------------------------------
[comment by david]
{quote}
now here's one more problem for you, now that you've accepted nanoTime()'s benefits and quirks on some JVMs and some OSes, it uses the CPU's TSC - unfortunately, each CPU has its own, which might be slightly off from each other - so if your thread migrates between CPUs at just the wrong time, and you're on such a JVM on such an OS on such a CPU, you could still get a negative time for your elapsed time
{quote}
In other words, the thread measuring t0 and t1 has to be the same thread ! Not a problem, IIRC, as t0 and t1 are always measured by the same thread.
> System.nanoTime() can be negative
> ---------------------------------
>
> Key: JGRP-1877
> URL: https://issues.jboss.org/browse/JGRP-1877
> Project: JGroups
> Issue Type: Bug
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Critical
> Fix For: 3.5.1, 3.6
>
>
> According to the javadoc, {{System.nanoTime()}} should only be used to measure _elapsed time_, but not compute a _target time in the future_, as {{nanoTime()}} might return a a time in the future.
> Code like the one below might fail:
> {code:title=Responses.waitFor()|borderStyle=solid}
> public boolean waitFor(long timeout) {
> long wait_time;
> final long target_time=System.nanoTime() + TimeUnit.NANOSECONDS.convert(timeout, TimeUnit.MILLISECONDS); // ns
> lock.lock();
> try {
> while(!done && (wait_time=target_time - System.nanoTime()) > 0) {
> try {
> cond.await(wait_time,TimeUnit.NANOSECONDS);
> }
> catch(InterruptedException e) {
> }
> }
> return done;
> }
> finally {
> lock.unlock();
> }
> }
> {code}
> When computing {{target_time}}, {{System.nanoTime()}} could return a negative value (numeric overflow) or a value in the future. In the first case, {{target_time}} could be negative, so the method would not block at all. In the latter case, {{target_time}} could be huge, so the method would block for a long time.
> Investigate all occurrences where we use {{nanoTime()}} to compute a time in the future, and see what impact a future value value could have. Possibly replace with {{System.currentTimeMillis()}} or the _time service_.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years