[JBoss JIRA] (WFLY-10669) MBean Support
by Karthik Babu (JIRA)
Karthik Babu created WFLY-10669:
-----------------------------------
Summary: MBean Support
Key: WFLY-10669
URL: https://issues.jboss.org/browse/WFLY-10669
Project: WildFly
Issue Type: Bug
Reporter: Karthik Babu
Assignee: Jason Greene
Attachments: DNBIJbossStatisticsService.java
Hi,
I have defined an mbean and deployed the same in .sar file using jboss 7.0.0 . But while accessing the same through jndiName (using org.springframework.jndi.JndiObjectFactoryBean) , it is throwing the following exception. could you please check and provide help in this regard. Same configuration seems to be working fine in jboss 6.3
Attached the java file with the Mbean service defined.
Inside Jboss-service.xml in sar file :
<mbean code="com.dnbgp.monitoring.jmx.DNBIJbossStatisticsService"
name="dnbi.external.dependency.statistics:service=DunsLinkJMXJNDI">
</mbean>
Inside applicationContext.xml :
<bean id="DBCallsStatisticsService" class="org.springframework.jndi.JndiObjectFactoryBean">
<property name="jndiName" value="DBCallsJMXJNDI" />
</bean>
Exception Received during the Jboss start up:
06:25:47,775 ERROR [org.springframework.web.struts.ContextLoaderPlugIn] (ServerService Thread Pool -- 86) Context initialization failed: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'ProductOrderStatisticsService' defined in ServletContext resource [/WEB-INF/monitoringSpringApplicationContext.xml]: Invocation of init method failed; nested exception is javax.naming.NameNotFoundException: ProductOrderJMXJNDI -- service jboss.naming.context.java.ProductOrderJMXJNDI
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1482)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:521)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:458)
at org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:295)
at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:223)
at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:292)
at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:194)
at org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:608)
at org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:932)
at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:479)
at org.springframework.web.struts.ContextLoaderPlugIn.createWebApplicationContext(ContextLoaderPlugIn.java:354)
at org.springframework.web.struts.ContextLoaderPlugIn.initWebApplicationContext(ContextLoaderPlugIn.java:295)
at org.springframework.web.struts.ContextLoaderPlugIn.init(ContextLoaderPlugIn.java:225)
at org.apache.struts.action.ActionServlet.initModulePlugIns(ActionServlet.java:869)
at org.apache.struts.action.ActionServlet.init(ActionServlet.java:350)
at livexp.ui.web.EnhancedLiveXPActionServlet.init(EnhancedLiveXPActionServlet.java:263)
at javax.servlet.GenericServlet.init(GenericServlet.java:244)
at io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:117)
at org.wildfly.extension.undertow.security.RunAsLifecycleInterceptor.init(RunAsLifecycleInterceptor.java:78)
at io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:103)
at io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.start(ManagedServlet.java:239)
at io.undertow.servlet.core.ManagedServlet.createServlet(ManagedServlet.java:133)
at io.undertow.servlet.core.DeploymentManagerImpl.start(DeploymentManagerImpl.java:527)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:101)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:82)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
at org.jboss.threads.JBossThread.run(JBossThread.java:320)
Caused by: javax.naming.NameNotFoundException: ProductOrderJMXJNDI -- service jboss.naming.context.java.ProductOrderJMXJNDI
at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:106)
at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:207)
at org.jboss.as.naming.InitialContext$DefaultInitialContext.lookup(InitialContext.java:235)
at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:193)
at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:189)
at javax.naming.InitialContext.lookup(InitialContext.java:417)
at javax.naming.InitialContext.lookup(InitialContext.java:417)
at org.springframework.jndi.JndiTemplate$1.doInContext(JndiTemplate.java:154)
at org.springframework.jndi.JndiTemplate.execute(JndiTemplate.java:87)
at org.springframework.jndi.JndiTemplate.lookup(JndiTemplate.java:152)
at org.springframework.jndi.JndiTemplate.lookup(JndiTemplate.java:178)
at org.springframework.jndi.JndiLocatorSupport.lookup(JndiLocatorSupport.java:95)
at org.springframework.jndi.JndiObjectLocator.lookup(JndiObjectLocator.java:105)
at org.springframework.jndi.JndiObjectFactoryBean.lookupWithFallback(JndiObjectFactoryBean.java:201)
at org.springframework.jndi.JndiObjectFactoryBean.afterPropertiesSet(JndiObjectFactoryBean.java:187)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1541)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1479)
... 30 more
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (DROOLS-1663) Kie DMN doesn't support IMPORT decisions between DMN files
by Matteo Mortari (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1663?page=com.atlassian.jira.plugi... ]
Matteo Mortari commented on DROOLS-1663:
----------------------------------------
node dependencies which are not coming from the same model, but from an imported model, needs to be prefixed in the dependency-name with the "alias." prefix with the DMN Import name used during import. Was fixed with https://github.com/kiegroup/drools/commit/46970a3707ee2ea3a43f1d82d6b9c0c...
> Kie DMN doesn't support IMPORT decisions between DMN files
> ----------------------------------------------------------
>
> Key: DROOLS-1663
> URL: https://issues.jboss.org/browse/DROOLS-1663
> Project: Drools
> Issue Type: Enhancement
> Components: dmn engine
> Reporter: Stylianos Koussouris
> Assignee: Matteo Mortari
> Attachments: IMG_2197.jpg, IMG_2198.jpg, IMG_2199.jpg, dmn import defaults.odt
>
>
> DMN Spec 1.1
> Page 40.
> import: Import [*] This attribute is used to import externally defined elements and
> make them available for use by elements in this Definitions.
> Section 6.3.3 Import metamodel
> The aim here is to be able to import one Decision defined in a separate DMN into another where it is used as a supporting decision and is referenced (RequiredDecision)
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (DROOLS-1609) Augment FEEL AST node at compilation with return type
by Matteo Mortari (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1609?page=com.atlassian.jira.plugi... ]
Matteo Mortari updated DROOLS-1609:
-----------------------------------
Sprint: 2017 Week 24-25, 2017 Week 26-27, 2017 Week 28-29, 2017 Week 30-31, 2017 Week 32-33, 2017 Week 34-35, 2017 Week 36-37, 2017 Week 38-39, 2017 Week 40-41-42, 2017 Week 43-44, 2017 Week 45-46, 2017 Week 47-48, 2017 Week 49-50, 2017 Week 51-52, 2018 Week 01-02, 2018 Week 03-04, 2018 Week 05-06, 2018 Week 07-08, 2018 Week 09-10, 2018 Week 11-12, 2018 Week 13-14, 2018 Week 15-16, 2018 Week 17-18, 2018 Week 19-22, 2018 Week 23-24, 2018 Week 25-26 (was: 2017 Week 24-25, 2017 Week 26-27, 2017 Week 28-29, 2017 Week 30-31, 2017 Week 32-33, 2017 Week 34-35, 2017 Week 36-37, 2017 Week 38-39, 2017 Week 40-41-42, 2017 Week 43-44, 2017 Week 45-46, 2017 Week 47-48, 2017 Week 49-50, 2017 Week 51-52, 2018 Week 01-02, 2018 Week 03-04, 2018 Week 05-06, 2018 Week 07-08, 2018 Week 09-10, 2018 Week 11-12, 2018 Week 13-14, 2018 Week 15-16, 2018 Week 17-18, 2018 Week 19-22, 2018 Week 23-24, 2018 Week 25-26, 2018 Week 27-29)
> Augment FEEL AST node at compilation with return type
> -----------------------------------------------------
>
> Key: DROOLS-1609
> URL: https://issues.jboss.org/browse/DROOLS-1609
> Project: Drools
> Issue Type: Enhancement
> Components: dmn engine
> Reporter: Matteo Mortari
> Assignee: Matteo Mortari
> Priority: Minor
>
> This is needed so to be able to determine the result of a boxed function at compile time, in turn to be able at compile time to determine a valid compilation without error of a BKM for instance.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (JGRP-1530) TCPConnectionMap$TCPConnection$ConnectionPeerReceiver allocate and hold a 1.6G byte[]
by Bartosz --- (JIRA)
[ https://issues.jboss.org/browse/JGRP-1530?page=com.atlassian.jira.plugin.... ]
Bartosz --- commented on JGRP-1530:
-----------------------------------
The memory leak described in this ticket may still occur if the bind IP address passed to the client socket is null and the resulting source and destination addresses are equal. This is because the local IP address of the client socket after binding and before connecting to the remote server is 0.0.0.0 and it differs from the destination IP address. After connecting the local IP address is being updated to the actual value.
I've commited a [pull request|https://github.com/belaban/JGroups/pull/391].
> TCPConnectionMap$TCPConnection$ConnectionPeerReceiver allocate and hold a 1.6G byte[]
> -------------------------------------------------------------------------------------
>
> Key: JGRP-1530
> URL: https://issues.jboss.org/browse/JGRP-1530
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 2.10
> Environment: Linux (2.6.18-308.13.1.el5)
> Java HotSpot(TM) 64-Bit Server VM (20.10-b01, mixed mode)
> Reporter: Ken Chiu
> Assignee: Bela Ban
> Fix For: 3.3
>
> Attachments: hold_by_jgroups.JPG, hold_by_jgroups.JPG, large_byte_array.JPG, large_byte_array.JPG
>
>
> In our application, after running a few hours of load test we will encounter OutOfMemoryError.
> It is caused by we use TCPPING with port_range and hit a JVM defect:
> http://bugs.sun.com/bugdatabase/view_bug.do;jsessionid=a8f3e6a330c2871287...
> When we use TCPPING with port_range in some linux environments, the application can occasionally connect to a not listened local port.
> This socket will have the same local/destination port.
> If this connection is established, bytes written via this socket's OutputStream will be read from this socket's InputStream.
> In JGroups, a client socket will send cookie({ 'b', 'e', 'l', 'a' }) as its first data and it will be read from the same socket's InputStream at TCPConnectionMap$TCPConnection$ConnectionPeerReceiver.
> This will allocation a 1.6G byte[] and hold it forever because the client socket won't read enough data in its whole life.
> I think a simple solution is to check the connected client socket is a self-connected(local/destination ip and port are the same) and retry next port when this happen.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years