[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)
8 years, 4 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)
8 years, 4 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)
8 years, 4 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)
8 years, 4 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)
8 years, 4 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)
8 years, 4 months
[JBoss JIRA] (WFLY-5913) Add ability to specify external context on JNDI lookup binding
by Guillermo González de Agüero (JIRA)
Guillermo González de Agüero created WFLY-5913:
--------------------------------------------------
Summary: 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)
8 years, 4 months
[JBoss JIRA] (WFLY-4116) WAR deployment fails on missing security domain dependency
by John John (JIRA)
[ https://issues.jboss.org/browse/WFLY-4116?page=com.atlassian.jira.plugin.... ]
John John commented on WFLY-4116:
---------------------------------
Is this pasted anywhere on upgrading from 8.1 to 8.2 that the security-domain has changed in how it's defined in the jboss-web?
I too had 8.1 configs which had full path, but as you mentioned 8.2 seems to have shortened it.
Regards
John
> WAR deployment fails on missing security domain dependency
> ----------------------------------------------------------
>
> Key: WFLY-4116
> URL: https://issues.jboss.org/browse/WFLY-4116
> Project: WildFly
> Issue Type: Feature Request
> Components: Security, Web (JBoss Web), Web (Undertow)
> Affects Versions: 8.2.0.Final
> Environment: Standalone form-based authentication WAR
> Reporter: Lars Hellgren
> Assignee: Darran Lofthouse
> Fix For: 8.2.0.Final
>
>
> Moving WARs using form based authentication from WildFly 8.1 Final to 8.2 Final fails due to a missing security domain dependency.
> *Log*
> {noformat}
> service jboss.security.security-domain.java:/jaas/haa-portal (missing) dependents:
> [service jboss.deployment.unit."haa-security-manager.war".component.SecurityManagerRepositorySessionBean.CREATE,
> service jboss.deployment.unit."haa-security-manager.war".component.UserPrefsRepository.CREATE]
> {noformat}
> *jboss-web.xml*
> {code:xml}
> <jboss-web>
> <security-domain>java:/jaas/haa-portal</security-domain>
> </jboss-web>
> {code}
> *standalone.xml*
> {code:xml}
> <subsystem xmlns="urn:jboss:domain:security:1.2">
> <security-domains>
> ...
> <security-domain name="haa-portal">
> <authentication>
> <login-module code="Database" flag="required">
> ...
> </login-module>
> </authentication>
> </security-domain>
> </security-domains>
> </subsystem>
> {code}
> The datasource is deployed and connected.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 4 months
[JBoss JIRA] (JGRP-1982) RequestCorrelator: use IntHashMap / LongHashmap for request correlation
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1982?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1982:
--------------------------------
Even better: if we keep requests in an array, we don't need to generate request-ids, e.g.:
{noformat}
offset=100 | R100 | R101 | R102 | R103 |
{noformat}
The next request would be R104, then R105 etc. The index into the current array plus the offset (which is adjusted on a compaction) give us a unique and monotonically increasing request-id.
Similar to {{Table}}, the array can grow, but it also can be compacted, e.g. by shifting elements in the array to the left (to index 0)...
> RequestCorrelator: use IntHashMap / LongHashmap for request correlation
> -----------------------------------------------------------------------
>
> Key: JGRP-1982
> URL: https://issues.jboss.org/browse/JGRP-1982
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 3.6.7
>
>
> In RequestCorrelator (and possibly other classes), use an IntHashMap or LongHashmap for the request table. Goal: use less space when we have a lot of requests.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 4 months