[JBoss JIRA] (AS7-4865) Datasource after creation is in a peculiar state
by Stefano Maestri (JIRA)
[ https://issues.jboss.org/browse/AS7-4865?page=com.atlassian.jira.plugin.s... ]
Stefano Maestri moved JBPAPP-9111 to AS7-4865:
----------------------------------------------
Project: Application Server 7 (was: JBoss Enterprise Application Platform)
Key: AS7-4865 (was: JBPAPP-9111)
Workflow: GIT Pull Request workflow (was: jira)
Affects Version/s: (was: EAP 6.0.0 ER 8)
(was: EAP 6.0.0 ER 7)
Component/s: JCA
(was: Consoles)
(was: JCA)
Security: (was: Public)
Fix Version/s: (was: TBD EAP 6)
Docs QE Status: (was: NEW)
> Datasource after creation is in a peculiar state
> ------------------------------------------------
>
> Key: AS7-4865
> URL: https://issues.jboss.org/browse/AS7-4865
> Project: Application Server 7
> Issue Type: Bug
> Components: JCA
> Reporter: Jan Martiska
> Assignee: Stefano Maestri
> Priority: Critical
>
> Create a (xa)datasource in admin console. Try to disable it using the appropriate button. This error will happen:
> {noformat}
> Request
> {
> "xa-datasource-class" => "org.h2.jdbcx.JdbcDataSource",
> "pad-xid" => false,
> "wrap-xa-resource" => false,
> "same-rm-override" => false,
> "interleaving" => false,
> "name" => "qrh",
> "driver-name" => "h2",
> "password" => "",
> "enabled" => true,
> "user-name" => "",
> "security-domain" => "",
> "jndi-name" => "java:/uyyyy",
> "pool-name" => "",
> "transaction-isolation" => "",
> "new-connection-sql" => "",
> "connection-url" => "",
> "driver-class" => "",
> "valid-connection-checker-class-name" => "",
> "check-valid-connection-sql" => "",
> "background-validation" => false,
> "background-validation-millis" => -1L,
> "validate-on-match" => false,
> "stale-connection-checker-class-name" => "",
> "exception-sorter-class-name" => "",
> "prepared-statements-cache-size" => -1L,
> "share-prepared-statements" => false,
> "use-ccm" => false,
> "operation" => "disable",
> "address" => [
> ("subsystem" => "datasources"),
> ("xa-data-source" => "qrh")
> ],
> "operation-headers" => {"allow-resource-service-restart" => true}
> }
> Response
> Internal Server Error
> {
> "outcome" => "failed",
> "failure-description" => "JBAS010455: Data-source service [qrh] is not enabled",
> "rolled-back" => true,
> "response-headers" => {"process-state" => "restart-required"}
> }
> {noformat}
> It states that "Data-source service [qrh] is not enabled" even though the datasource has property "enabled" equal "true".
> After you disable the datasource in CLI using :disable operation (this works) and then enable it back -> from this point, disabling and enabling in console will work, just the first time (after creation) it doesn't.
> *Also, weird thing is - after you create a datasource, it is not shown in JNDI naming tree, it looks like it is not active, even though CLI says it is enabled.* You have to reload server, only then will the datasource appear in JNDI naming tree - it behaves like datasource creation requires server-reload, but JCA subsystem doesn't indicate this.
> What is the correct behavior?
--
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
14 years, 1 month
[JBoss JIRA] (AS7-4861) Cannot activate OSGi subsystem with fragment bundle deployments
by Thomas Diesler (JIRA)
[ https://issues.jboss.org/browse/AS7-4861?page=com.atlassian.jira.plugin.s... ]
Thomas Diesler commented on AS7-4861:
-------------------------------------
Fixed in framework-1.3.1.CR1
> Cannot activate OSGi subsystem with fragment bundle deployments
> ---------------------------------------------------------------
>
> Key: AS7-4861
> URL: https://issues.jboss.org/browse/AS7-4861
> Project: Application Server 7
> Issue Type: Bug
> Components: OSGi
> Reporter: Rico Neubauer
> Assignee: Thomas Diesler
> Fix For: 7.1.3.Final (EAP), 7.2.0.Alpha1
>
> Attachments: jbosgi-framework_Fragments.patch
>
>
> Occurs with JBoss 7.1.2.Final (EAP) running with jbosgi-framework 1.3.0.Final
> See https://issues.jboss.org/browse/AS7-4814 for an issue in the same area. This bug here happens independently of the other.
> Having OSGi bundles, that are fragments leads to
> {noformat}
> INFO [org.jboss.as.controller] (Controller Boot Thread) JBAS014774: Service status report
> JBAS014775: Neue fehlende/unbefriedigte Abhängigkeiten: (this is German, in English. sth. like Missing/unresolved dependencies)
> service jbosgi.integration.PersistentBundlesHandler.COMPLETE (missing) dependents: [service jbosgi.framework.INIT]
> {noformat}
> This is because when bundle is installed via {noformat}org.jboss.osgi.framework.internal.BundleManagerPlugin.installBundle(Deployment, ServiceListener<Bundle>){noformat} in case of a fragment, the listener is not passed to the FragmentBundleInstalledService (BundleManagerPlugin, line 364).
> In consequence, there is no notification for this bundle in {noformat}org.jboss.osgi.framework.util.ServiceTracker.listenerAdded(ServiceController<? extends S>){noformat} which leads to org.jboss.osgi.framework.util.ServiceTracker.addedNames not containing the bundle and then when org.jboss.osgi.framework.util.ServiceTracker.checkAndComplete() is invoked the check for completeness in {noformat}org.jboss.as.osgi.service.PersistentBundlesIntegration.InitialDeploymentTracker.InitialDeploymentTracker(...).new PersistentBundlesComplete() {...}.allServicesAdded(Set<ServiceName>){noformat} fails due to different sizes of bundleInstallServices and trackedServices.
> I will attach a proposed patch, which resolves the issue by adding the listener also to FragmentBundleInstalledService.
--
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
14 years, 1 month
[JBoss JIRA] (AS7-4863) CLONE - Remote EJB SFSB load balancing still very suboptimal
by Radoslav Husar (JIRA)
Radoslav Husar created AS7-4863:
-----------------------------------
Summary: CLONE - Remote EJB SFSB load balancing still very suboptimal
Key: AS7-4863
URL: https://issues.jboss.org/browse/AS7-4863
Project: Application Server 7
Issue Type: Bug
Components: Clustering, EJB
Affects Versions: 7.1.2.Final (EAP)
Reporter: Radoslav Husar
Assignee: jaikiran pai
Fix For: 7.1.3.Final (EAP)
Looking at the load-balancing again, it seems still wrong. Checking the logs, servers were started *and cluster was formed* ~10 seconds prior to starting the client and load-balancing was roughly:
* node perf18: ~50% of sessions
* node perf19: 0
* node perf20: 0
* node perf21: ~50% of sessions
I let all the session to be created in one minute (not all at once).
The nodes were also specified in the properties.
{noformat}
node perf18
[JBossINF] 07:01:53,991 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (CacheService lifecycle - 1) ISPN000094: Received new cluster view: [perf19/ejb|3] [perf19/ejb, perf21/ejb, perf20/ejb, perf18/ejb]
node perf19
[JBossINF] 07:01:53,781 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-19,null) ISPN000094: Received new cluster view: [perf19/ejb|3] [perf19/ejb, perf21/ejb, perf20/ejb, perf18/ejb]
node perf20
[JBossINF] 07:01:53,781 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-14,null) ISPN000094: Received new cluster view: [perf19/ejb|3] [perf19/ejb, perf21/ejb, perf20/ejb, perf18/ejb]
node perf21
[JBossINF] 07:01:53,780 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-12,null) ISPN000094: Received new cluster view: [perf19/ejb|3] [perf19/ejb, perf21/ejb, perf20/ejb, perf18/ejb]
controller node
2012/05/22 07:02:02:932 EDT [DEBUG][TestController] HOST perf17.mw.lab.eng.bos.redhat.com:rootProcess:c - Setting thread count: 2000, was: 0
2012/05/22 07:02:53:731 EDT [DEBUG][TestController] HOST perf17.mw.lab.eng.bos.redhat.com:rootProcess:c - All runners (2000) started in 50799 milliseconds
{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
14 years, 1 month
[JBoss JIRA] (AS7-4861) Cannot activate OSGi subsystem with fragment bundle deployments
by Thomas Diesler (JIRA)
[ https://issues.jboss.org/browse/AS7-4861?page=com.atlassian.jira.plugin.s... ]
Thomas Diesler updated AS7-4861:
--------------------------------
Fix Version/s: 7.1.3.Final (EAP)
7.2.0.Alpha1
Git Pull Request: https://github.com/jbosgi/jbosgi-framework/pull/3 (was: https://github.com/jbosgi/jbosgi-framework/pull/3)
> Cannot activate OSGi subsystem with fragment bundle deployments
> ---------------------------------------------------------------
>
> Key: AS7-4861
> URL: https://issues.jboss.org/browse/AS7-4861
> Project: Application Server 7
> Issue Type: Bug
> Components: OSGi
> Reporter: Rico Neubauer
> Assignee: Thomas Diesler
> Fix For: 7.1.3.Final (EAP), 7.2.0.Alpha1
>
> Attachments: jbosgi-framework_Fragments.patch
>
>
> Occurs with JBoss 7.1.2.Final (EAP) running with jbosgi-framework 1.3.0.Final
> See https://issues.jboss.org/browse/AS7-4814 for an issue in the same area. This bug here happens independently of the other.
> Having OSGi bundles, that are fragments leads to
> {noformat}
> INFO [org.jboss.as.controller] (Controller Boot Thread) JBAS014774: Service status report
> JBAS014775: Neue fehlende/unbefriedigte Abhängigkeiten: (this is German, in English. sth. like Missing/unresolved dependencies)
> service jbosgi.integration.PersistentBundlesHandler.COMPLETE (missing) dependents: [service jbosgi.framework.INIT]
> {noformat}
> This is because when bundle is installed via {noformat}org.jboss.osgi.framework.internal.BundleManagerPlugin.installBundle(Deployment, ServiceListener<Bundle>){noformat} in case of a fragment, the listener is not passed to the FragmentBundleInstalledService (BundleManagerPlugin, line 364).
> In consequence, there is no notification for this bundle in {noformat}org.jboss.osgi.framework.util.ServiceTracker.listenerAdded(ServiceController<? extends S>){noformat} which leads to org.jboss.osgi.framework.util.ServiceTracker.addedNames not containing the bundle and then when org.jboss.osgi.framework.util.ServiceTracker.checkAndComplete() is invoked the check for completeness in {noformat}org.jboss.as.osgi.service.PersistentBundlesIntegration.InitialDeploymentTracker.InitialDeploymentTracker(...).new PersistentBundlesComplete() {...}.allServicesAdded(Set<ServiceName>){noformat} fails due to different sizes of bundleInstallServices and trackedServices.
> I will attach a proposed patch, which resolves the issue by adding the listener also to FragmentBundleInstalledService.
--
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
14 years, 1 month
[JBoss JIRA] (AS7-4861) Cannot activate OSGi subsystem with fragment bundle deployments
by Thomas Diesler (JIRA)
[ https://issues.jboss.org/browse/AS7-4861?page=com.atlassian.jira.plugin.s... ]
Thomas Diesler moved JBOSGI-555 to AS7-4861:
--------------------------------------------
Project: Application Server 7 (was: JBoss OSGi)
Key: AS7-4861 (was: JBOSGI-555)
Workflow: GIT Pull Request workflow (was: jira)
Component/s: OSGi
(was: Core Framework)
Security: (was: Public)
> Cannot activate OSGi subsystem with fragment bundle deployments
> ---------------------------------------------------------------
>
> Key: AS7-4861
> URL: https://issues.jboss.org/browse/AS7-4861
> Project: Application Server 7
> Issue Type: Bug
> Components: OSGi
> Reporter: Rico Neubauer
> Assignee: Thomas Diesler
> Attachments: jbosgi-framework_Fragments.patch
>
>
> Occurs with JBoss 7.1.2.Final (EAP) running with jbosgi-framework 1.3.0.Final
> See https://issues.jboss.org/browse/AS7-4814 for an issue in the same area. This bug here happens independently of the other.
> Having OSGi bundles, that are fragments leads to
> {noformat}
> INFO [org.jboss.as.controller] (Controller Boot Thread) JBAS014774: Service status report
> JBAS014775: Neue fehlende/unbefriedigte Abhängigkeiten: (this is German, in English. sth. like Missing/unresolved dependencies)
> service jbosgi.integration.PersistentBundlesHandler.COMPLETE (missing) dependents: [service jbosgi.framework.INIT]
> {noformat}
> This is because when bundle is installed via {noformat}org.jboss.osgi.framework.internal.BundleManagerPlugin.installBundle(Deployment, ServiceListener<Bundle>){noformat} in case of a fragment, the listener is not passed to the FragmentBundleInstalledService (BundleManagerPlugin, line 364).
> In consequence, there is no notification for this bundle in {noformat}org.jboss.osgi.framework.util.ServiceTracker.listenerAdded(ServiceController<? extends S>){noformat} which leads to org.jboss.osgi.framework.util.ServiceTracker.addedNames not containing the bundle and then when org.jboss.osgi.framework.util.ServiceTracker.checkAndComplete() is invoked the check for completeness in {noformat}org.jboss.as.osgi.service.PersistentBundlesIntegration.InitialDeploymentTracker.InitialDeploymentTracker(...).new PersistentBundlesComplete() {...}.allServicesAdded(Set<ServiceName>){noformat} fails due to different sizes of bundleInstallServices and trackedServices.
> I will attach a proposed patch, which resolves the issue by adding the listener also to FragmentBundleInstalledService.
--
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
14 years, 1 month
[JBoss JIRA] (AS7-4042) On failed secured connection during EJB invocations from a remote server instance an incorrect error message is shown
by Ondřej Chaloupka (JIRA)
Ondřej Chaloupka created AS7-4042:
-------------------------------------
Summary: On failed secured connection during EJB invocations from a remote server instance an incorrect error message is shown
Key: AS7-4042
URL: https://issues.jboss.org/browse/AS7-4042
Project: Application Server 7
Issue Type: Bug
Components: EJB
Affects Versions: 7.1.0.Final
Reporter: Ondřej Chaloupka
Assignee: jaikiran pai
Priority: Minor
When EJB invocations from a remote server instance is used and remoting connector of the remote server is secured and the attempt to connection fails an incorrect exception is thrown.
In case of version 7.1.0.Final when authentication si not correctly defined then during deployment following exception is thrown:
{code}
ERROR [org.jboss.remoting.remote.connection] (Remoting "clientnode" read-1) JBREM000200: Remote connection failed: javax.security.sasl.SaslException: Authentication failed: all available authentication mechanisms failed
ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC000001: Failed to start service jboss.ejb3.dd-based-ejb-client-context."client-ear.ear": org.jboss.msc.service.StartException in service jboss.ejb3.dd-based-ejb-client-context."client-ear.ear": Failed to start service
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1767) [jboss-msc-1.0.2.GA-redhat-1.jar:1.0.2.GA-redhat-1]
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_23]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_23]
at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_23]
Caused by: java.lang.RuntimeException: javax.security.sasl.SaslException: Authentication failed: all available authentication mechanisms failed
at org.jboss.ejb.client.remoting.IoFutureHelper.get(IoFutureHelper.java:91)
at org.jboss.as.ejb3.remote.DescriptorBasedEJBClientContextService.createRemotingConnections(DescriptorBasedEJBClientContextService.java:124)
at org.jboss.as.ejb3.remote.DescriptorBasedEJBClientContextService.start(DescriptorBasedEJBClientContextService.java:86)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-msc-1.0.2.GA-redhat-1.jar:1.0.2.GA-redhat-1]
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.2.GA-redhat-1.jar:1.0.2.GA-redhat-1]
... 3 more
Caused by: javax.security.sasl.SaslException: Authentication failed: all available authentication mechanisms failed
at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:315) [jboss-remoting-3.2.2.GA-redhat-1.jar:3.2.2.GA-redhat-1]
at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:214) [jboss-remoting-3.2.2.GA-redhat-1.jar:3.2.2.GA-redhat-1]
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72) [xnio-api-3.0.3.GA-redhat-1.jar:3.0.3.GA-redhat-1]
at org.xnio.channels.TranslatingSuspendableChannel.handleReadable(TranslatingSuspendableChannel.java:189) [xnio-api-3.0.3.GA-redhat-1.jar:3.0.3.GA-redhat-1]
at org.xnio.channels.TranslatingSuspendableChannel$1.handleEvent(TranslatingSuspendableChannel.java:103) [xnio-api-3.0.3.GA-redhat-1.jar:3.0.3.GA-redhat-1]
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72) [xnio-api-3.0.3.GA-redhat-1.jar:3.0.3.GA-redhat-1]
at org.xnio.channels.TranslatingSuspendableChannel.handleReadable(TranslatingSuspendableChannel.java:189) [xnio-api-3.0.3.GA-redhat-1.jar:3.0.3.GA-redhat-1]
at org.xnio.ssl.JsseConnectedSslStreamChannel.handleReadable(JsseConnectedSslStreamChannel.java:180) [xnio-api-3.0.3.GA-redhat-1.jar:3.0.3.GA-redhat-1]
at org.xnio.channels.TranslatingSuspendableChannel$1.handleEvent(TranslatingSuspendableChannel.java:103) [xnio-api-3.0.3.GA-redhat-1.jar:3.0.3.GA-redhat-1]
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72) [xnio-api-3.0.3.GA-redhat-1.jar:3.0.3.GA-redhat-1]
at org.xnio.nio.NioHandle.run(NioHandle.java:90)
at org.xnio.nio.WorkerThread.run(WorkerThread.java:184)
at ...asynchronous invocation...(Unknown Source)
at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:270) [jboss-remoting-3.2.2.GA-redhat-1.jar:3.2.2.GA-redhat-1]
at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:251) [jboss-remoting-3.2.2.GA-redhat-1.jar:3.2.2.GA-redhat-1]
at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:349) [jboss-remoting-3.2.2.GA-redhat-1.jar:3.2.2.GA-redhat-1]
at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:337) [jboss-remoting-3.2.2.GA-redhat-1.jar:3.2.2.GA-redhat-1]
at org.jboss.as.remoting.RemoteOutboundConnectionService.connect(RemoteOutboundConnectionService.java:130) [jboss-as-remoting-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1]
{code}
which is correct. But in case that the remote server is shut down, configuration is changed to use security connection then incorrect and confusing exception is thrown:
{code}
{code}
ERROR [org.jboss.ejb3.invocation] (EJB default - 2) JBAS014134: EJB Invocation failed on component CallingBean for method public abstract java.lang.String serverclient.CallingBeanRemote.call(): javax.ejb.EJBException: java.lang.RuntimeException: java.lang.IllegalStateException: No EJB receiver available for handling [appName:,modulename:myejb,distinctname:] combination
at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleExceptionInOurTx(CMTTxInterceptor.java:166) [jboss-as-ejb3-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1]
at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:230) [jboss-as-ejb3-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1]
at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:304) [jboss-as-ejb3-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1]
at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:190) [jboss-as-ejb3-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1]
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final-redhat-1.jar:1.1.1.Final-redhat-1]
at org.jboss.as.ejb3.remote.EJBRemoteTransactionPropogatingInterceptor.processInvocation(EJBRemoteTransactionPropogatingInterceptor.java:80) [jboss-as-ejb3-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1]
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final-redhat-1.jar:1.1.1.Final-redhat-1]
at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) [jboss-as-ejb3-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1]
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final-redhat-1.jar:1.1.1.Final-redhat-1]
at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:59) [jboss-as-ejb3-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1]
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final-redhat-1.jar:1.1.1.Final-redhat-1]
at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50) [jboss-as-ee-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1]
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final-redhat-1.jar:1.1.1.Final-redhat-1]
at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:43) [jboss-as-ejb3-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1]
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final-redhat-1.jar:1.1.1.Final-redhat-1]
at org.jboss.as.ee.component.TCCLInterceptor.processInvocation(TCCLInterceptor.java:45) [jboss-as-ee-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1]
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final-redhat-1.jar:1.1.1.Final-redhat-1]
at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) [jboss-invocation-1.1.1.Final-redhat-1.jar:1.1.1.Final-redhat-1]
at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:165) [jboss-as-ee-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1]
at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.invokeMethod(MethodInvocationMessageHandler.java:300) [jboss-as-ejb3-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1]
at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.access$200(MethodInvocationMessageHandler.java:64) [jboss-as-ejb3-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1]
at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler$1.run(MethodInvocationMessageHandler.java:194) [jboss-as-ejb3-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) [rt.jar:1.6.0_23]
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) [rt.jar:1.6.0_23]
at java.util.concurrent.FutureTask.run(FutureTask.java:138) [rt.jar:1.6.0_23]
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_23]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_23]
at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_23]
at org.jboss.threads.JBossThread.run(JBossThread.java:122)
Caused by: java.lang.RuntimeException: java.lang.IllegalStateException: No EJB receiver available for handling [appName:,modulename:myejb,distinctname:] combination
at serverclient.CallingBean.call(CallingBean.java:39) [serverclient-ejb.jar:]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.6.0_23]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [rt.jar:1.6.0_23]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [rt.jar:1.6.0_23]
at java.lang.reflect.Method.invoke(Method.java:597) [rt.jar:1.6.0_23]
at org.jboss.as.ee.component.ManagedReferenceMethodInterceptorFactory$ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptorFactory.java:72) [jboss-as-ee-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1]
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final-redhat-1.jar:1.1.1.Final-redhat-1]
at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53) [jboss-invocation-1.1.1.Final-redhat-1.jar:1.1.1.Final-redhat-1]
at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:36) [jboss-as-ee-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1]
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final-redhat-1.jar:1.1.1.Final-redhat-1]
at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final-redhat-1.jar:1.1.1.Final-redhat-1]
at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21) [jboss-invocation-1.1.1.Final-redhat-1.jar:1.1.1.Final-redhat-1]
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final-redhat-1.jar:1.1.1.Final-redhat-1]
at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) [jboss-invocation-1.1.1.Final-redhat-1.jar:1.1.1.Final-redhat-1]
at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:53) [jboss-as-ee-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1]
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final-redhat-1.jar:1.1.1.Final-redhat-1]
at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51) [jboss-as-ejb3-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1]
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final-redhat-1.jar:1.1.1.Final-redhat-1]
at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:228) [jboss-as-ejb3-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1]
... 27 more
Caused by: java.lang.IllegalStateException: No EJB receiver available for handling [appName:,modulename:myejb,distinctname:] combination
at org.jboss.ejb.client.EJBClientContext.requireEJBReceiver(EJBClientContext.java:516) [jboss-ejb-client-1.0.4.Final.jar:1.0.4.Final]
at org.jboss.ejb.client.ReceiverInterceptor.handleInvocation(ReceiverInterceptor.java:84) [jboss-ejb-client-1.0.4.Final.jar:1.0.4.Final]
at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:175) [jboss-ejb-client-1.0.4.Final.jar:1.0.4.Final]
at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:136) [jboss-ejb-client-1.0.4.Final.jar:1.0.4.Final]
at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:121) [jboss-ejb-client-1.0.4.Final.jar:1.0.4.Final]
at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:104) [jboss-ejb-client-1.0.4.Final.jar:1.0.4.Final]
at $Proxy15.sayHello(Unknown Source) at serverclient.CallingBean.call(CallingBean.java:34) [serverclient-ejb.jar:]
... 46 more
{code}
The exception seems that everything was connected correctly only module does not exist in remote context.
In case of the AS7 Final version is not so problematic but when you take source codes from git then after deploying of application to client server which would like to connect to a secured remote server then no exception is thrown during deployment. Everything looks fine but after execution of remote call the confusing exception is thrown and it's hard to understand that the problem is in not connected context because of security.
--
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
14 years, 1 month
[JBoss JIRA] (AS7-4859) CLONE - Default value of id-cache-size attribute is potencially dangerous when very small messages are used
by Miroslav Novak (JIRA)
[ https://issues.jboss.org/browse/AS7-4859?page=com.atlassian.jira.plugin.s... ]
Miroslav Novak moved JBPAPP-9100 to AS7-4859:
---------------------------------------------
Project: Application Server 7 (was: JBoss Enterprise Application Platform)
Key: AS7-4859 (was: JBPAPP-9100)
Workflow: GIT Pull Request workflow (was: jira)
Affects Version/s: 7.1.2.Final (EAP)
(was: EAP 6.0.0 ER 8)
Component/s: JMS
(was: HornetQ)
Security: (was: Public)
Fix Version/s: 7.1.3.Final (EAP)
(was: TBD EAP 6)
Docs QE Status: (was: NEW)
> CLONE - Default value of id-cache-size attribute is potencially dangerous when very small messages are used
> -----------------------------------------------------------------------------------------------------------
>
> Key: AS7-4859
> URL: https://issues.jboss.org/browse/AS7-4859
> Project: Application Server 7
> Issue Type: Bug
> Components: JMS
> Affects Versions: 7.1.2.Final (EAP)
> Reporter: Miroslav Novak
> Assignee: Clebert Suconic
> Fix For: 7.1.3.Final (EAP)
>
>
> Hi,
> I hit an issue with HornetQ core bridges. I tried test scenario with 4 nodes where:
> 1) there are two clusters A and B (each contains two nodes)
> 2) there is hornetq core bridge configured from cluster A to cluster B (A1 -> B1, A2 -> B2)
> During sending messages (30KB ByteMessages) to A1 and reading them from B2, node A2 was killed and started a few times. In the end there were duplicated messages. Problem was in low value of id-cache-size attribute which is 2000 by default and confirmation-window-size which is for bridges (1024 * 1024) bytes.
> Can be default value of id-cache-size increased so we can avoid this situation? This is potentially dangerous and hard for admins to realize before the problem occurs.
--
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
14 years, 1 month