[JBoss JIRA] (WFLY-5916) jackson-datatype-jsr310 and jackson-datatype-jdk8 are missing
by Juergen Zimmermann (JIRA)
Juergen Zimmermann created WFLY-5916:
----------------------------------------
Summary: jackson-datatype-jsr310 and jackson-datatype-jdk8 are missing
Key: WFLY-5916
URL: https://issues.jboss.org/browse/WFLY-5916
Project: WildFly
Issue Type: Bug
Components: REST
Affects Versions: 10.0.0.CR5
Reporter: Juergen Zimmermann
Assignee: Stuart Douglas
WildFly doesn't provide jackson-datatype-jsr310 and jackson-datatype-jdk8 for RESTEasy. jackson-datatype-jsr310 supports the new JDK 8 time API, and jackson-datatype-jdk8 supports the new JDK 8 Optional type.
The GAVs are:
com.fasterxml.jackson.datatype:jackson-datatype-jsr310:2.6.3
com.fasterxml.jackson.datatype:jackson-datatype-jdk8:2.6.3
The latest Jackson GA version is 2.6.4. Please see also https://issues.jboss.org/browse/WFLY-5915.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (DROOLS-1016) Too much memory consumption while running code on drools6.
by Vivek Hingorani (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1016?page=com.atlassian.jira.plugi... ]
Vivek Hingorani updated DROOLS-1016:
------------------------------------
Summary: Too much memory consumption while running code on drools6. (was: Too much memory consumpition while running code on drools6.)
> Too much memory consumption while running code on drools6.
> ----------------------------------------------------------
>
> Key: DROOLS-1016
> URL: https://issues.jboss.org/browse/DROOLS-1016
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.2.0.Final
> Reporter: Vivek Hingorani
> Assignee: Mario Fusco
>
> The memory usage on drools6 is far more then drools 5. Can we run the drools6 code with Rete algorithm?
> We recently migrated our project from Drools 5.3.0.Final version to Drools 6.2.0.Final version. In production we can see a significant increase in the memory consumption per node. we are using java 1.7. We increased the permgen space as well for drools6 from 0.5 GB to 1 GB but still the increase is too much. Is there any solution for the same.
> Drools5 memory usage was 0.5GB per node with 0.5GB permgen space
> Drools6 memory usage is 1.3GB per node with 1GB permgen space.
> Node here is a jvm as we are using oracle coherence.
> If further details are needed , let me know.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (DROOLS-1016) Too much memory consumpition while running code on drools6.
by Vivek Hingorani (JIRA)
Vivek Hingorani created DROOLS-1016:
---------------------------------------
Summary: Too much memory consumpition while running code on drools6.
Key: DROOLS-1016
URL: https://issues.jboss.org/browse/DROOLS-1016
Project: Drools
Issue Type: Bug
Components: core engine
Affects Versions: 6.2.0.Final
Reporter: Vivek Hingorani
Assignee: Mario Fusco
The memory usage on drools6 is far more then drools 5. Can we run the drools6 code with Rete algorithm?
We recently migrated our project from Drools 5.3.0.Final version to Drools 6.2.0.Final version. In production we can see a significant increase in the memory consumption per node. we are using java 1.7. We increased the permgen space as well for drools6 from 0.5 GB to 1 GB but still the increase is too much. Is there any solution for the same.
Drools5 memory usage was 0.5GB per node with 0.5GB permgen space
Drools6 memory usage is 1.3GB per node with 1GB permgen space.
Node here is a jvm as we are using oracle coherence.
If further details are needed , let me know.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFCORE-591) revertReloadRequired() throws a NPE is reloadRequired has not been called
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFCORE-591?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration updated WFCORE-591:
-------------------------------------------
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1294591
Bugzilla Update: Perform
> revertReloadRequired() throws a NPE is reloadRequired has not been called
> -------------------------------------------------------------------------
>
> Key: WFCORE-591
> URL: https://issues.jboss.org/browse/WFCORE-591
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 1.0.0.Alpha19
> Reporter: Jeff Mesnil
> Assignee: Jeff Mesnil
> Fix For: 1.0.0.Beta1
>
>
> If an operation step handler calls org.jboss.as.controller.OperationContext#revertReloadRequired() when org.jboss.as.controller.OperationContext#reloadRequired() has not been called, it throws a NPE:
> {noformat}
> java.lang.NullPointerException
> at org.jboss.as.controller.ControlledProcessState.revertReloadRequired(ControlledProcessState.java:181)
> at org.jboss.as.controller.AbstractOperationContext.revertReloadRequired(AbstractOperationContext.java:1037)
> at org.jboss.as.controller.test.RevertReloadRequiredTestCase$TestResourceAddHandler.rollbackRuntime(RevertReloadRequiredTestCase.java:98)
> at org.jboss.as.controller.AbstractAddStepHandler$1$1.handleRollback(AbstractAddStepHandler.java:133)
> at org.jboss.as.controller.AbstractOperationContext$RollbackDelegatingResultHandler.handleResult(AbstractOperationContext.java:1419)
> at org.jboss.as.controller.AbstractOperationContext$Step.invokeResultHandler(AbstractOperationContext.java:1385)
> at org.jboss.as.controller.AbstractOperationContext$Step.handleResult(AbstractOperationContext.java:1367)
> at org.jboss.as.controller.AbstractOperationContext$Step.finalizeInternal(AbstractOperationContext.java:1323)
> at org.jboss.as.controller.AbstractOperationContext$Step.finalizeStep(AbstractOperationContext.java:1283)
> at org.jboss.as.controller.AbstractOperationContext$Step.access$300(AbstractOperationContext.java:1172)
> at org.jboss.as.controller.AbstractOperationContext.finishStep(AbstractOperationContext.java:929)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:877)
> at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:601)
> at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:354)
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:330)
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1182)
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:362)
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:205)
> {noformat}
> The NPE is caused by this.activeStep.restartStamp field which is set only when reloadRequired() (or restartRequired()) is called.
> My OSH may call reloadRequired() or not depending on some runtime state and I could add some logic to make sure I call
> I can fix my handle to check that I call context.revertReloadRequired() only I had previously called reloadRequired () first.
> However, in order to make the OperationContext more robust, I think that the revertReloadRequired() method should instead be a no-op if there is no reload required.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-5914) JNDI view ClassNotFoundException with remote entry
by Guillermo González de Agüero (JIRA)
Guillermo González de Agüero created WFLY-5914:
--------------------------------------------------
Summary: JNDI view ClassNotFoundException with remote entry
Key: WFLY-5914
URL: https://issues.jboss.org/browse/WFLY-5914
Project: WildFly
Issue Type: Bug
Affects Versions: 10.0.0.CR5
Reporter: Guillermo González de Agüero
Assignee: Jason Greene
Attachments: domain.xml
When a binding to a remote Artemis Topic/ConnectionFactory is created, JNDI view fails with a ClassNotFoundException. Both servers are running the "full" profile.
I attach my domain.xml for reference porpuses. No application needs to be deployed.
Full operation result:
[domain@localhost:9990 /] /host=master/server=app-ins01/subsystem=naming:jndi-view()
{
"outcome" => "failed",
"result" => {"java: contexts" => {
"java:" => {
"ConnectionFactory" => {
"class-name" => "org.apache.activemq.artemis.jms.client.ActiveMQJMSConnectionFactory",
"value" => "ActiveMQConnectionFactory [serverLocator=ServerLocatorImpl [initialConnectors=[TransportConfiguration(name=in-vm, factory=org-apache-activemq-artemis-core-remoting-impl-invm-InVMConnectorFactory) ?serverId=0], discoveryGroupConfiguration=null], clientID=null, consumerWindowSize = 1048576, dupsOKBatchSize=1048576, transactionBatchSize=1048576, readOnly=false]"
},
"JmsXA" => {
"class-name" => "java.lang.Object",
"value" => "?"
},
"TransactionManager" => {
"class-name" => "com.arjuna.ats.jbossatx.jta.TransactionManagerDelegate",
"value" => "com.arjuna.ats.jbossatx.jta.TransactionManagerDelegate@27b3c7"
},
"jms" => {
"class-name" => "javax.naming.Context",
"children" => {"queue" => {
"class-name" => "javax.naming.Context",
"children" => {
"DLQ" => {
"class-name" => "org.apache.activemq.artemis.jms.client.ActiveMQQueue",
"value" => "ActiveMQQueue[DLQ]"
},
"ExpiryQueue" => {
"class-name" => "org.apache.activemq.artemis.jms.client.ActiveMQQueue",
"value" => "ActiveMQQueue[ExpiryQueue]"
}
}
}}
},
"jboss" => {
"class-name" => "javax.naming.Context",
"value" => "org.jboss.as.naming.WritableServiceBasedNamingStore@d2c52f"
},
"global" => {
"class-name" => "javax.naming.Context",
"value" => "org.jboss.as.naming.WritableServiceBasedNamingStore@932e80"
},
"ejb" => {
"class-name" => "javax.naming.Context",
"children" => {"mgmt" => {
"class-name" => "javax.naming.Context",
"children" => {"MEJB" => {
"class-name" => "javax.management.j2ee.ManagementHome",
"value" => "Proxy for remote EJB EJBHomeLocator for \"jsr-77/jsr-77/EJB\", view is interface javax.management.j2ee.ManagementHome, affinity is None"
}}
}}
}
},
"java:jboss" => {
"ORB" => {
"class-name" => "com.sun.corba.se.impl.orb.ORBImpl",
"value" => "com.sun.corba.se.impl.orb.ORBImpl@1306d15"
},
"TransactionManager" => {
"class-name" => "com.arjuna.ats.jbossatx.jta.TransactionManagerDelegate",
"value" => "com.arjuna.ats.jbossatx.jta.TransactionManagerDelegate@27b3c7"
},
"TransactionSynchronizationRegistry" => {
"class-name" => "org.jboss.as.txn.service.internal.tsr.TransactionSynchronizationRegistryWrapper",
"value" => "org.jboss.as.txn.service.internal.tsr.TransactionSynchronizationRegistryWrapper@206b4c"
},
"UserTransaction" => {
"class-name" => "javax.transaction.UserTransaction",
"value" => "UserTransaction"
},
"corbanaming" => {
"class-name" => "org.omg.CosNaming._NamingContextExtStub",
"value" => "IOR:000000000000002b49444c3a6f6d672e6f72672f436f734e616d696e672f4e616d696e67436f6e746578744578743a312e300000000000010000000000000110000102000000000a3132372e302e302e31000e3600000039afabcb00000000220000000100000001000000000000000200000008526f6f74504f4100000000074e616d696e67000000000004726f6f741400000000000005000000010000002000000000000100010000000205010001000100200001010900000001000101000000002600000002000200000000000300000014000000000000000a3132372e302e302e31000e3700000014000000080000001a00000e370000002100000050000000000000000100000000000000220000000000400000000000080606678102010101000000170401000806066781020101010000000744656661756c740000000000000000000000000000000000"
},
"irpoa" => {
"class-name" => "com.sun.corba.se.impl.oa.poa.POAImpl",
"value" => "POA[ObjectAdapterID[RootPOA/IRPOA], uniquePOAId=2, state=RUN, invocationCount=0]"
},
"jaas" => {
"class-name" => "com.sun.proxy.$Proxy58",
"value" => "java:jboss/jaas/ Context proxy"
},
"poa" => {
"class-name" => "com.sun.corba.se.impl.oa.poa.POAImpl",
"value" => "POA[ObjectAdapterID[RootPOA], uniquePOAId=0, state=RUN, invocationCount=0]"
},
"ee" => {
"class-name" => "javax.naming.Context",
"children" => {"concurrency" => {
"class-name" => "javax.naming.Context",
"children" => {
"scheduler" => {
"class-name" => "javax.naming.Context",
"children" => {"default" => {
"class-name" => "java.lang.Object",
"value" => "?"
}}
},
"factory" => {
"class-name" => "javax.naming.Context",
"children" => {"default" => {
"class-name" => "java.lang.Object",
"value" => "?"
}}
},
"executor" => {
"class-name" => "javax.naming.Context",
"children" => {"default" => {
"class-name" => "java.lang.Object",
"value" => "?"
}}
},
"context" => {
"class-name" => "javax.naming.Context",
"children" => {"default" => {
"class-name" => "java.lang.Object",
"value" => "?"
}}
}
}
}}
},
"infinispan" => {
"class-name" => "javax.naming.Context",
"children" => {"container" => {
"class-name" => "javax.naming.Context",
"children" => {
"ejb" => {
"class-name" => "org.jboss.as.clustering.infinispan.DefaultCacheContainer",
"value" => "ejb"
},
"hibernate" => {
"class-name" => "org.jboss.as.clustering.infinispan.DefaultCacheContainer",
"value" => "hibernate"
},
"server" => {
"class-name" => "org.jboss.as.clustering.infinispan.DefaultCacheContainer",
"value" => "server"
},
"web" => {
"class-name" => "org.jboss.as.clustering.infinispan.DefaultCacheContainer",
"value" => "web"
}
}
}}
},
"datasources" => {
"class-name" => "javax.naming.Context",
"children" => {"ExampleDS" => {
"class-name" => "org.jboss.as.connector.subsystems.datasources.WildFlyDataSource",
"value" => "org.jboss.as.connector.subsystems.datasources.WildFlyDataSource@c79ae8"
}}
},
"mail" => {
"class-name" => "javax.naming.Context",
"children" => {"Default" => {
"class-name" => "javax.mail.Session",
"value" => "javax.mail.Session@1e9f277"
}}
},
"clustering" => {
"class-name" => "javax.naming.Context",
"children" => {"registry" => {
"class-name" => "javax.naming.Context",
"children" => {"ejb" => {
"class-name" => "javax.naming.Context",
"children" => {"client-mappings" => {
"class-name" => "org.wildfly.clustering.server.registry.CacheRegistryFactory",
"value" => "org.wildfly.clustering.server.registry.CacheRegistryFactory@12ac291"
}}
}}
}}
}
},
"java:jboss/exported" => {"jms" => {
"class-name" => "javax.naming.Context",
"children" => {"RemoteConnectionFactory" => {
"class-name" => "org.apache.activemq.artemis.jms.client.ActiveMQJMSConnectionFactory",
"value" => "ActiveMQConnectionFactory [serverLocator=ServerLocatorImpl [initialConnectors=[TransportConfiguration(name=http-connector, factory=org-apache-activemq-artemis-core-remoting-impl-netty-NettyConnectorFactory) ?httpUpgradeEnabled=true&httpPpgradeEndpoint=http-acceptor&port=8190&host=127-0-0-1], discoveryGroupConfiguration=null], clientID=null, consumerWindowSize = 1048576, dupsOKBatchSize=1048576, transactionBatchSize=1048576, readOnly=false]"
}}
}},
"java:global" => undefined
}},
"failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.RuntimeException: org.jboss.naming.remote.protocol.NamingIOException: Failed to lookup [Root exception is java.io.IOException: java.lang.ClassNotFoundException: org.apache.activemq.artemis.jms.client.ActiveMQJMSConnectionFactory from [Module \"org.jboss.as.naming:main\" from local module loader @130015a (finder: local module finder @9f0666 (roots: c:\\wildfly-10.0.0.CR5\\modules,c:\\wildfly-10.0.0.CR5\\modules\\system\\layers\\base))]]",
"rolled-back" => true
}
Injection of the resources via @Resource in an application works as expected. I found this same problem where manually doing the remote lookup from application code, which I resolved adding a dependency to Artemis module in META-INF.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 12 months
[JBoss JIRA] (WFLY-5913) Add ability to specify external context on JNDI lookup binding
by Guillermo González de Agüero (JIRA)
[ https://issues.jboss.org/browse/WFLY-5913?page=com.atlassian.jira.plugin.... ]
Guillermo González de Agüero resolved WFLY-5913.
------------------------------------------------
Resolution: Done
My fault. It's already possible to do a remote lookup by appending the path to the lookup of the remote context.
For reference porpuses, my configuration currently is:
{code:xml}
<subsystem xmlns="urn:jboss:domain:naming:2.0">
<bindings>
<external-context name="java:/global/mqserver" module="org.jboss.as.naming" class="javax.naming.InitialContext" cache="true">
<environment>
<property name="java.naming.factory.initial" value="org.jboss.naming.remote.client.InitialContextFactory"/>
<property name="java.naming.provider.url" value="http-remoting://localhost:8290"/>
<property name="java.naming.security.principal" value="remote"/>
<property name="java.naming.security.credentials" value="remote"/>
</environment>
</external-context>
<lookup name="java:global/ExportedTopic" lookup="java:/global/mqserver/jms/topic/prueba"/>
<lookup name="java:global/ExportedFactory" lookup="java:/global/mqserver/jms/RemoteConnectionFactory"/>
</bindings>
<remote-naming/>
</subsystem>
{code}
Maybe an explanation could be added to the docs.
> Add ability to specify external context on JNDI lookup binding
> --------------------------------------------------------------
>
> Key: WFLY-5913
> URL: https://issues.jboss.org/browse/WFLY-5913
> Project: WildFly
> Issue Type: Feature Request
> Components: Naming
> Affects Versions: 10.0.0.CR5
> Reporter: Guillermo González de Agüero
>
> The Naming subsystem allows to create alias to JNDI lookups on the local context, and also allows to bind an external context to an entry. However, it isn't possible to bind a lookup to an external context.
> My personal use case is that I have an exported JMS Topic on a Remote WildFly. I'd like to be able to use it from my application like if it where local.
> For now, I've created an Object Factory that lookups the external context and then lookups the topic.
> An attribute indicating the context could be added. If none specified, local context should be used. Something like this:
> {code:xml}
> <bindings>
> <external-context name="java:/global/mqserver" module="org.jboss.as.naming" class="javax.naming.InitialContext" cache="true">
> <environment>
> <property name="java.naming.factory.initial" value="org.jboss.naming.remote.client.InitialContextFactory"/>
> <property name="java.naming.provider.url" value="http-remoting://localhost:8290"/>
> <property name="java.naming.security.principal" value="remote"/>
> <property name="java.naming.security.credentials" value="remote"/>
> </environment>
> </external-context>
> <lookup name="java:/jms/topic/ImportedTopic" lookup="java:/jms/topic/MyTopic" externalContext="java:/global/mqserver"/>
> </bindings>
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 12 months
[JBoss JIRA] (WFLY-5913) Add ability to specify external context on JNDI lookup binding
by Guillermo González de Agüero (JIRA)
[ https://issues.jboss.org/browse/WFLY-5913?page=com.atlassian.jira.plugin.... ]
Guillermo González de Agüero updated WFLY-5913:
-----------------------------------------------
Description:
The Naming subsystem allows to create alias to JNDI lookups on the local context, and also allows to bind an external context to an entry. However, it isn't possible to bind a lookup to an external context.
My personal use case is that I have an exported JMS Topic on a Remote WildFly. I'd like to be able to use it from my application like if it where local.
For now, I've created an Object Factory that lookups the external context and then lookups the topic.
An attribute indicating the context could be added. If none specified, local context should be used. Something like this:
{code:xml}
<bindings>
<external-context name="java:/global/mqserver" module="org.jboss.as.naming" class="javax.naming.InitialContext" cache="true">
<environment>
<property name="java.naming.factory.initial" value="org.jboss.naming.remote.client.InitialContextFactory"/>
<property name="java.naming.provider.url" value="http-remoting://localhost:8290"/>
<property name="java.naming.security.principal" value="remote"/>
<property name="java.naming.security.credentials" value="remote"/>
</environment>
</external-context>
<lookup name="java:/jms/topic/ImportedTopic" lookup="java:/jms/topic/MyTopic" externalContext="java:/global/mqserver"/>
</bindings>
{code}
was:
The Naming subsystem allows to create alias to JNDI lookups on the local context, and also allows to bind an external context to an entry. However, it isn't possible to bind a lookup to an external context.
My personal use case is that I have an exported JMS Topic on a Remote WildFly. I'd like to be able to use it from my application like if it where local.
For now, I've created an Object Factory that lookups the external context and then lookups the topic.
An attribute indicating the context could be added. If none specified, local context should be used. Something like this:
{code:xml}
<bindings>
<external-context name="java:/global/mqserver" module="org.jboss.as.naming" class="javax.naming.InitialContext" cache="true">
<environment>
<property name="java.naming.factory.initial" value="org.jboss.naming.remote.client.InitialContextFactory"/>
<property name="java.naming.provider.url" value="http-remoting://localhost:8290"/>
<property name="java.naming.security.principal" value="remote"/>
<property name="java.naming.security.credentials" value="remote"/>
</environment>
</external-context>
<lookup name="java:/jms/topic/ImportedTopic" lookup="java:/jms/topic/MyTopic" externalContext="java:/global/mqserver"/>
</bindings>
{code}
> Add ability to specify external context on JNDI lookup binding
> --------------------------------------------------------------
>
> Key: WFLY-5913
> URL: https://issues.jboss.org/browse/WFLY-5913
> Project: WildFly
> Issue Type: Feature Request
> Components: Naming
> Affects Versions: 10.0.0.CR5
> Reporter: Guillermo González de Agüero
>
> The Naming subsystem allows to create alias to JNDI lookups on the local context, and also allows to bind an external context to an entry. However, it isn't possible to bind a lookup to an external context.
> My personal use case is that I have an exported JMS Topic on a Remote WildFly. I'd like to be able to use it from my application like if it where local.
> For now, I've created an Object Factory that lookups the external context and then lookups the topic.
> An attribute indicating the context could be added. If none specified, local context should be used. Something like this:
> {code:xml}
> <bindings>
> <external-context name="java:/global/mqserver" module="org.jboss.as.naming" class="javax.naming.InitialContext" cache="true">
> <environment>
> <property name="java.naming.factory.initial" value="org.jboss.naming.remote.client.InitialContextFactory"/>
> <property name="java.naming.provider.url" value="http-remoting://localhost:8290"/>
> <property name="java.naming.security.principal" value="remote"/>
> <property name="java.naming.security.credentials" value="remote"/>
> </environment>
> </external-context>
> <lookup name="java:/jms/topic/ImportedTopic" lookup="java:/jms/topic/MyTopic" externalContext="java:/global/mqserver"/>
> </bindings>
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 12 months