[JBoss JIRA] (AS7-5815) Upgrading JBossTS to 4.17.2.Final
by Paul Robinson (JIRA)
Paul Robinson created AS7-5815:
----------------------------------
Summary: Upgrading JBossTS to 4.17.2.Final
Key: AS7-5815
URL: https://issues.jboss.org/browse/AS7-5815
Project: Application Server 7
Issue Type: Component Upgrade
Components: Transactions
Reporter: Paul Robinson
Assignee: Paul Robinson
Fix For: 7.2.0.Alpha1
Note: this upgrade is for 7.2 branch, not the 7.1 branch. 7.1 branch must stay on JBossTS 4.16.x.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 5 months
[JBoss JIRA] (AS7-3830) Remote JNDI call does not bind stateful beans
by Ondřej Chaloupka (JIRA)
Ondřej Chaloupka created AS7-3830:
-------------------------------------
Summary: Remote JNDI call does not bind stateful beans
Key: AS7-3830
URL: https://issues.jboss.org/browse/AS7-3830
Project: Application Server 7
Issue Type: Bug
Components: EJB
Affects Versions: 7.1.0.Final
Reporter: Ondřej Chaloupka
Assignee: jaikiran pai
It seems that current ejb remote client is not able to find stateful bean. Exception is thrown instead:
{code}
javax.naming.NamingException: java.lang.IllegalStateException: No EJB client context is available [Root exception is java.lang.RuntimeException: java.lang.IllegalStateException: No EJB client context is available]
at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:135)
at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:74)
at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:177)
at org.jboss.naming.remote.protocol.v1.Protocol$1.handleServerMessage(Protocol.java:124)
at org.jboss.naming.remote.protocol.v1.RemoteNamingServerV1$MessageReciever$1.run(RemoteNamingServerV1.java:70)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
Caused by: java.lang.RuntimeException: java.lang.IllegalStateException: No EJB client context is available
at org.jboss.as.ejb3.remote.RemoteViewManagedReferenceFactory.getReference(RemoteViewManagedReferenceFactory.java:91)
at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:133)
... 7 more
Caused by: java.lang.IllegalStateException: No EJB client context is available
at org.jboss.ejb.client.EJBClientContext.requireCurrent(EJBClientContext.java:233)
at org.jboss.ejb.client.EJBClient.createSession(EJBClient.java:160)
at org.jboss.as.ejb3.remote.RemoteViewManagedReferenceFactory.getReference(RemoteViewManagedReferenceFactory.java:89)
... 8 more
{code}
Please, check my test whether definition of remote context does not contain a mistake. But finding singleton and stateless beans works fine.
https://github.com/ochaloup/jboss-as/blob/ejb-remote-call/testsuite/integ...
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 5 months
[JBoss JIRA] (AS7-3916) Concurrent access leads to empty domain.xml
by Heiko Braun (JIRA)
Heiko Braun created AS7-3916:
--------------------------------
Summary: Concurrent access leads to empty domain.xml
Key: AS7-3916
URL: https://issues.jboss.org/browse/AS7-3916
Project: Application Server 7
Issue Type: Bug
Components: Domain Management
Reporter: Heiko Braun
Assignee: Brian Stansberry
Priority: Critical
Fix For: 7.1.1.Final
Hi Red Hat team. We're still trying to narrow down the trigger but there is a very serious bug when using the admin console in AS 7.1 Final that causes the domain.xml file to be wiped of everything other than the extensions section that is at the top. Have not checked yet if this is a known bug or not but wanted to alert you immediately.
The potential trigger for this is more than one person using the admin
console at the same time. Even if just for monitoring while the other
person is making configuration changes. (Fortunately we had backed up
the config using the CLI.)
We are trying right now to get our QA1 drop out the door but we'll be
giving this a closer look tomorrow. Has anyone else reported this though?
Thanks,
Bill
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 5 months
[JBoss JIRA] (AS7-3828) EJB client tries to invoke EJBs after application was undeployed
by Radoslav Husar (JIRA)
Radoslav Husar created AS7-3828:
-----------------------------------
Summary: EJB client tries to invoke EJBs after application was undeployed
Key: AS7-3828
URL: https://issues.jboss.org/browse/AS7-3828
Project: Application Server 7
Issue Type: Bug
Components: Clustering, EJB
Affects Versions: 7.1.0.Final
Reporter: Radoslav Husar
Assignee: jaikiran pai
Priority: Critical
Fix For: 7.1.1.Final
And this results in NoSuchEJBException.
One more feature that was fully supported in previous version (AS 5.1).
{noformat}
2012/02/20 10:59:11:336 EST [WARN ][Runner - 43] SFCORE_LOG - Error sampling data: <org.jboss.smartfrog.loaddriver.RequestProcessingException: Could not get valid response. Runner: 43.>
org.jboss.smartfrog.loaddriver.RequestProcessingException: Could not get valid response. Runner: 43.
at org.jboss.smartfrog.clustering.ejb3.StatefulSBProcessorFactoryImpl$EJB3RequestProcessor.processRequest(StatefulSBProcessorFactoryImpl.java:79)
at org.jboss.smartfrog.loaddriver.CompoundRequestProcessorFactoryImpl$CompoundRequestProcessor.processRequest(CompoundRequestProcessorFactoryImpl.java:51)
at org.jboss.smartfrog.loaddriver.Runner.run(Runner.java:87)
at java.lang.Thread.run(Thread.java:662)
Caused by: javax.ejb.NoSuchEJBException: No such EJB[appname=clusterbench-ee6,modulename=clusterbench-ee6-ejb,distinctname=,beanname=RemoteStatefulSBImpl]
at org.jboss.ejb.client.remoting.GeneralInvocationFailureResponseHandler.processMessage(GeneralInvocationFailureResponseHandler.java:75)
at org.jboss.ejb.client.remoting.ChannelAssociation$ResponseReceiver.handleMessage(ChannelAssociation.java:385)
at org.jboss.remoting3.remote.RemoteConnectionChannel$4.run(RemoteConnectionChannel.java:371)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
... 1 more
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 5 months
[JBoss JIRA] (AS7-3902) NPE in JGroups on shutting down the server
by Radoslav Husar (JIRA)
Radoslav Husar created AS7-3902:
-----------------------------------
Summary: NPE in JGroups on shutting down the server
Key: AS7-3902
URL: https://issues.jboss.org/browse/AS7-3902
Project: Application Server 7
Issue Type: Bug
Components: Clustering
Affects Versions: 7.1.0.Final
Reporter: Radoslav Husar
Assignee: Paul Ferraro
Priority: Critical
Fix For: 7.1.1.Final
Ran into while manually playing around.
1/ 2 server
2/ client requesting session on #1
3/ #2 is shut down >
Preceeding this log is AS7-3180.
{noformat}
17:23:39,763 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] ISPN000082: Stopping the RpcDispatcher
17:23:40,086 SEVERE [org.jgroups.JChannel] failed destroying the protocol stack: java.lang.NullPointerException
at org.jboss.as.clustering.jgroups.ManagedSocketFactory.close(ManagedSocketFactory.java:174) [jboss-as-clustering-jgroups-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1]
at org.jgroups.stack.DiagnosticsHandler.stop(DiagnosticsHandler.java:76) [jgroups-3.0.4.Final-redhat-0-todo.jar:3.0.4.Final]
at org.jgroups.protocols.TP.stop(TP.java:1010) [jgroups-3.0.4.Final-redhat-0-todo.jar:3.0.4.Final]
at org.jgroups.protocols.UDP.stop(UDP.java:248) [jgroups-3.0.4.Final-redhat-0-todo.jar:3.0.4.Final]
at org.jgroups.stack.ProtocolStack.stopStack(ProtocolStack.java:996) [jgroups-3.0.4.Final-redhat-0-todo.jar:3.0.4.Final]
at org.jgroups.JChannel.stopStack(JChannel.java:923) [jgroups-3.0.4.Final-redhat-0-todo.jar:3.0.4.Final]
at org.jgroups.JChannel.disconnect(JChannel.java:380) [jgroups-3.0.4.Final-redhat-0-todo.jar:3.0.4.Final]
at org.jgroups.JChannel._close(JChannel.java:909) [jgroups-3.0.4.Final-redhat-0-todo.jar:3.0.4.Final]
at org.jgroups.JChannel.close(JChannel.java:389) [jgroups-3.0.4.Final-redhat-0-todo.jar:3.0.4.Final]
at org.jboss.as.clustering.jgroups.subsystem.ChannelService.stop(ChannelService.java:61) [jboss-as-clustering-jgroups-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1]
at org.jboss.as.clustering.msc.AsynchronousService$2.run(AsynchronousService.java:84) [jboss-as-clustering-common-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1]
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_29]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_29]
at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_29]
17:23:40,090 SEVERE [org.jgroups.JChannel] failed destroying the protocol stack: java.lang.NullPointerException
at java.util.concurrent.ConcurrentHashMap.remove(ConcurrentHashMap.java:922) [rt.jar:1.6.0_29]
at org.jgroups.stack.ProtocolStack.stopStack(ProtocolStack.java:980) [jgroups-3.0.4.Final-redhat-0-todo.jar:3.0.4.Final]
at org.jgroups.JChannel.stopStack(JChannel.java:923) [jgroups-3.0.4.Final-redhat-0-todo.jar:3.0.4.Final]
at org.jgroups.JChannel._close(JChannel.java:910) [jgroups-3.0.4.Final-redhat-0-todo.jar:3.0.4.Final]
at org.jgroups.JChannel.close(JChannel.java:389) [jgroups-3.0.4.Final-redhat-0-todo.jar:3.0.4.Final]
at org.jboss.as.clustering.jgroups.subsystem.ChannelService.stop(ChannelService.java:61) [jboss-as-clustering-jgroups-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1]
at org.jboss.as.clustering.msc.AsynchronousService$2.run(AsynchronousService.java:84) [jboss-as-clustering-common-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1]
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_29]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_29]
at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_29]
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 5 months
[JBoss JIRA] (AS7-3796) Remote EJB client seems to be leaking messages MAX_OUTBOUND_MESSAGES (ChannelBusyException: Too many open outbound writes)
by Radoslav Husar (JIRA)
Radoslav Husar created AS7-3796:
-----------------------------------
Summary: Remote EJB client seems to be leaking messages MAX_OUTBOUND_MESSAGES (ChannelBusyException: Too many open outbound writes)
Key: AS7-3796
URL: https://issues.jboss.org/browse/AS7-3796
Project: Application Server 7
Issue Type: Bug
Components: Clustering, EJB, Remoting
Affects Versions: 7.1.0.Final
Reporter: Radoslav Husar
Assignee: David Lloyd
Priority: Critical
Fix For: 7.1.1.Final
David and Jaikiran,
lets revisit this topic. I still think were are leaking messages in remoting3. Badly. Even though I set MAX_O_Ms to 100K it still results in:
{noformat}
2012/02/16 08:34:48:728 EST [WARN ][Runner - 227] SFCORE_LOG - Error sampling data: <org.jboss.smartfrog.loaddriver.RequestProcessingException: Could not get valid response. Runner: 227.>
org.jboss.smartfrog.loaddriver.RequestProcessingException: Could not get valid response. Runner: 227.
at org.jboss.smartfrog.clustering.ejb3.StatefulSBProcessorFactoryImpl$EJB3RequestProcessor.processRequest(StatefulSBProcessorFactoryImpl.java:79)
at org.jboss.smartfrog.loaddriver.CompoundRequestProcessorFactoryImpl$CompoundRequestProcessor.processRequest(CompoundRequestProcessorFactoryImpl.java:51)
at org.jboss.smartfrog.loaddriver.Runner.run(Runner.java:87)
at java.lang.Thread.run(Thread.java:662)
Caused by: java.lang.reflect.UndeclaredThrowableException
at $Proxy0.getSerialAndIncrement(Unknown Source)
at org.jboss.smartfrog.clustering.ejb3.StatefulSBProcessorFactoryImpl$EJB3RequestProcessor.processRequest(StatefulSBProcessorFactoryImpl.java:68)
... 3 more
Caused by: org.jboss.remoting3.ChannelBusyException: Too many open outbound writes
at org.jboss.remoting3.remote.RemoteConnectionChannel.openOutboundMessage(RemoteConnectionChannel.java:111)
at org.jboss.remoting3.remote.RemoteConnectionChannel.writeMessage(RemoteConnectionChannel.java:296)
at org.jboss.ejb.client.remoting.ChannelAssociation.acquireChannelMessageOutputStream(ChannelAssociation.java:235)
at org.jboss.ejb.client.remoting.RemotingConnectionEJBReceiver.processInvocation(RemotingConnectionEJBReceiver.java:193)
at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:173)
at org.jboss.ejb.client.TransactionInterceptor.handleInvocation(TransactionInterceptor.java:43)
at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:175)
at org.jboss.ejb.client.ReceiverInterceptor.handleInvocation(ReceiverInterceptor.java:92)
at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:175)
at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:136)
at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:121)
at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:104)
... 5 more
{noformat}
Here is a snip from the client properties:
{noformat}
remote.connectionprovider.create.options.org.xnio.Options.SSL_ENABLED=false
remote.connections=perf18,perf19,perf20,perf21
remote.connection.perf18.host=perf18
remote.connection.perf18.port=4447
remote.connection.perf18.connect.options.org.xnio.Options.SASL_POLICY_NOANONYMOUS=false
remote.connection.perf18.channel.options.org.jboss.remoting3.RemotingOptions.MAX_OUTBOUND_MESSAGES=100000
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 5 months
[JBoss JIRA] (AS7-5728) ClusteredSingleSignOn doesn't remove ssoId from sso cluster on Request.logout
by Stian Thorgersen (JIRA)
Stian Thorgersen created AS7-5728:
-------------------------------------
Summary: ClusteredSingleSignOn doesn't remove ssoId from sso cluster on Request.logout
Key: AS7-5728
URL: https://issues.jboss.org/browse/AS7-5728
Project: Application Server 7
Issue Type: Bug
Affects Versions: 7.1.3.Final (EAP)
Reporter: Stian Thorgersen
Logging out a user with Request.logout doesn't work with clustered SSO. This is caused by ClusteredSingleSignOn.deregister(String) not remove the ssoId from the SSO cluster. The ClusteredSingleSignOn.sessionEvent removes it from both the local cache and the SSO cluster, so a workaround is to call Session.invalidate() prior to calling Request.logout().
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 5 months