[JBoss JIRA] (WFLY-5932) Invalidating a session of an SSO on a different node than where the session was created does not logout the user
by Richard Janík (JIRA)
Richard Janík created WFLY-5932:
-----------------------------------
Summary: Invalidating a session of an SSO on a different node than where the session was created does not logout the user
Key: WFLY-5932
URL: https://issues.jboss.org/browse/WFLY-5932
Project: WildFly
Issue Type: Bug
Components: Clustering
Reporter: Richard Janík
Assignee: Paul Ferraro
Priority: Critical
See steps to reproduce for description. Additional scenario with a failover where we don't need to authenticate with the last request (but where we should be required to authenticate):
* Access A1, authenticate, fail A1 (e.g. shutdown the server), access A2, invalidate session on A2, access A2
Scenarios where the SSO context is destroyed (where we need to authenticate with the last request as expected):
* Access A1, authenticate, invalidate session on A1, access A1
* Access A1, authenticate, access A2, invalidate session on A1, access A1
Possibly related to JBEAP-1228, JBEAP-1282. Note that we always only have a single session bound to an SSO. I'm not flagging this as a blocker, since the issue usually doesn't manifest thanks to sticky sessions on a load balancer.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (WFLY-5795) HA JMS Topic Subscriber of Colocated life backup symmetrical 2 nodes cluster violates Publish-Subscribe pattern.
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-5795?page=com.atlassian.jira.plugin.... ]
Jeff Mesnil commented on WFLY-5795:
-----------------------------------
I don't understand your configuration. Your domain configuration defines only one server while your test is expecting 2 servers.
How do you run your domain?
> HA JMS Topic Subscriber of Colocated life backup symmetrical 2 nodes cluster violates Publish-Subscribe pattern.
> ----------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-5795
> URL: https://issues.jboss.org/browse/WFLY-5795
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 10.0.0.CR4
> Environment: 2 node symmetrical colocated life backup cluster (domain mode). Configuration (domain.xml, host.xml) provided as attachment.
> Reporter: Michal Sudra
> Assignee: Jeff Mesnil
> Priority: Critical
> Attachments: ClusteredTopicTest.java, domain.xml, host.xml
>
>
> Test Client is producing 10 messages on topic on node 1 and 2 consumers connected to node 1 and the other to node 2 are then consuming the messages.
> Expectation: Every consumer receives 10 Messages.
> Result of test: Consumer connected to node 1 is only getting every second message. Consumer connected to node 2 is receiving all 10 messages:
> Output of test program:
> Sent message: This is text message 0
> Sent message: This is text message 1
> Sent message: This is text message 2
> Sent message: This is text message 3
> Sent message: This is text message 4
> Sent message: This is text message 5
> Sent message: This is text message 6
> Sent message: This is text message 7
> Sent message: This is text message 8
> Sent message: This is text message 9
> 0 Recieved message: This is text message 0 from node 0 from java:/jms/topic/ClusterStateTopic
> 1 Recieved message: This is text message 2 from node 0 from java:/jms/topic/ClusterStateTopic
> 2 Recieved message: This is text message 4 from node 0 from java:/jms/topic/ClusterStateTopic
> 3 Recieved message: This is text message 6 from node 0 from java:/jms/topic/ClusterStateTopic
> 4 Recieved message: This is text message 8 from node 0 from java:/jms/topic/ClusterStateTopic
> 5 error receiving message from node 0
> 6 error receiving message from node 0
> 7 error receiving message from node 0
> 8 error receiving message from node 0
> 9 error receiving message from node 0
> 0 Recieved message: This is text message 0 from node 1 from java:/jms/topic/ClusterStateTopic
> 1 Recieved message: This is text message 1 from node 1 from java:/jms/topic/ClusterStateTopic
> 2 Recieved message: This is text message 2 from node 1 from java:/jms/topic/ClusterStateTopic
> 3 Recieved message: This is text message 3 from node 1 from java:/jms/topic/ClusterStateTopic
> 4 Recieved message: This is text message 4 from node 1 from java:/jms/topic/ClusterStateTopic
> 5 Recieved message: This is text message 5 from node 1 from java:/jms/topic/ClusterStateTopic
> 6 Recieved message: This is text message 6 from node 1 from java:/jms/topic/ClusterStateTopic
> 7 Recieved message: This is text message 7 from node 1 from java:/jms/topic/ClusterStateTopic
> 8 Recieved message: This is text message 8 from node 1 from java:/jms/topic/ClusterStateTopic
> 9 Recieved message: This is text message 9 from node 1 from java:/jms/topic/ClusterStateTopic
> The test program is added and the 2 node names are given as parameters for main.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (WFLY-5914) JNDI view ClassNotFoundException with remote entry
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-5914?page=com.atlassian.jira.plugin.... ]
Jeff Mesnil updated WFLY-5914:
------------------------------
Attachment: standalone-full.xml
I can reproduce the issue with a standalone server (configuration is attached).
With a standalone server, I create an external context pointing to the server itself. This is enough to trigger the issue when invoking :jndi-view operation.
The issue is in the configuration of the external-context. If it uses the org.jboss.as.naming module, it is not able to load classes that belongs to Artemis (since org.jboss.as.naming has no dependency to org.apache.activemq.artemis module).
If I use org.wildfly.extension.messaging-activemq as the external-context's module, it fails because it is missing dependency to org.jboss.invocation. If I add this dependency, it fails again because the org.jboss.as.naming module can not load Artemis classes.
[~emmartins] Do you have an idea to fix this configuration? Do we have examples of an external-context pointing to another WildFly server to lookup JNDI resources (JMS resources or others...)?
> JNDI view ClassNotFoundException with remote entry
> --------------------------------------------------
>
> Key: WFLY-5914
> URL: https://issues.jboss.org/browse/WFLY-5914
> Project: WildFly
> Issue Type: Bug
> Components: JMS, Naming
> Affects Versions: 10.0.0.CR5
> Reporter: Guillermo González de Agüero
> Assignee: Jeff Mesnil
> Attachments: domain.xml, domain.zip, standalone-full.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)
10 years, 3 months
[JBoss JIRA] (WFLY-5473) Session.invalidate() does not invalidate SSO context for non-distributable applications
by Richard Janík (JIRA)
[ https://issues.jboss.org/browse/WFLY-5473?page=com.atlassian.jira.plugin.... ]
Richard Janík updated WFLY-5473:
--------------------------------
Attachment: reproducer.zip
I've attached the reproducer. Unzip it into a clean installation of EAP/Wildfly and run the reproducer.sh script.
I've been reproducing the issue manually before. I've been investigating some more while writing the reproducer and found that there are cases where it works - invalidation destroys SSO context - and cases where it doesn't work. It works only if you invalidate the first session of the given SSO context. Here's an example (roughly the same thing the reproducer does):
* Start two servers, each with <single-sign-on/>, a user and a non-distributable deployment. Bind server1 to 127.0.0.1:8080 and server2 to 127.0.0.1:8180.
* Open browser (Firefox), GET 127.0.0.1:8080/deployment, authenticate - we get JSESSIONID "x1" and JSESSIONIDSSO "y1"
* GET 127.0.0.1:8180/deployment, (no need to authenticate), we get JSESSIONID "x2" and JSESSIONIDSSO "y1"
* GET 127.0.0.1:8080/deployment, (no need to authenticate), we get JSESSIONID "x3" and JSESSIONIDSSO "y1"
* invalidate session on 127.0.0.1:8080 (JSESSIONID "x3"), then get 127.0.0.1:8080/deployment - we're not required to authenticate, but we should be
* when I spoofed the cookies in step 4 (before accessing 127.0.0.1:8080 and creating a second session on that server) and invalidated session with JSESSIONID "x1", it worked
> Session.invalidate() does not invalidate SSO context for non-distributable applications
> ---------------------------------------------------------------------------------------
>
> Key: WFLY-5473
> URL: https://issues.jboss.org/browse/WFLY-5473
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, Web (Undertow)
> Reporter: Richard Janík
> Assignee: Paul Ferraro
> Priority: Blocker
> Fix For: 10.0.0.Final
>
> Attachments: reproducer.zip
>
>
> See "Steps to Reproduce" for detailed description.
> According to my limited knowledge, this was also the core issue in https://bugzilla.redhat.com/show_bug.cgi?id=924456 which has been dispatched as a one-off to a customer. Thus, I'm setting the priority to blocker as this is a regression against 6.4.x. No exceptions have been observed in the server output however.
> Adding Clustering component as I've been trying this with standalone-ha.xml and BZ 924456 relates to clustering.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (JGRP-1989) Bundlers: reuse send buffer when transport == sync.
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/JGRP-1989?page=com.atlassian.jira.plugin.... ]
Dan Berindei commented on JGRP-1989:
------------------------------------
[~sannegrinovero], I was just replying to your assertion that 16 bytes is a negligible overhead compared to the buffer size. That's definitely not true in your example of 2-15 byte values, where a {{Buffer}} instance to keep track of off-heap memory is going to be just as big as the original {{byte[]}}.
> Bundlers: reuse send buffer when transport == sync.
> ---------------------------------------------------
>
> Key: JGRP-1989
> URL: https://issues.jboss.org/browse/JGRP-1989
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.6.7
>
>
> With the addition of {{TCP_NIO2}}, all bundlers now create new send buffers for every message (or message list). This generates a lot of memory allocations, perhaps it is better to revert this change for *synchronous transports* such as {{UDP}} and {{TCP}}, and still create new buffers for *asynchronous transports* such as {{TCP_NIO2}}.
> Synchronous transports guarantee a message has been put on the wire when {{TP.send()}} returns, whereas asynchronous transports may only have completed a partial write (so we cannot reuse the buffer).
> The code in the bundler should check for this, and copy if async or not copy if sync.
> Whether or not a transport is sync is determined by a new abstract method that needs to be overridden by every transport.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (WFLY-5922) Cannot exclude java.orb.api module
by John Farrelly (JIRA)
[ https://issues.jboss.org/browse/WFLY-5922?page=com.atlassian.jira.plugin.... ]
John Farrelly commented on WFLY-5922:
-------------------------------------
After applying the changes in your PR to my local wildfly installation, I also had to add {{javax.transaction.api}} as a dependency to {{org.jboss.ejb-client}} to get the dependencies to resolve:
{code:diff}
diff --git a/feature-pack/src/main/resources/modules/system/layers/base/org/jboss/ejb-client/main/module.xml b/feature-pack/src/main/resources/modules/system/layers/base/org/jboss/ejb-client/main/module.xml
index dca715f..086f12b 100644
--- a/feature-pack/src/main/resources/modules/system/layers/base/org/jboss/ejb-client/main/module.xml
+++ b/feature-pack/src/main/resources/modules/system/layers/base/org/jboss/ejb-client/main/module.xml
@@ -29,6 +29,7 @@
<dependencies>
<module name="javax.api"/>
<module name="javax.ejb.api"/>
+ <module name="javax.transaction.api"/>
<module name="javax.interceptor.api"/>
<module name="org.jboss.remoting"/>
<module name="org.jboss.jboss-transaction-spi"/>
{code}
> Cannot exclude java.orb.api module
> ----------------------------------
>
> Key: WFLY-5922
> URL: https://issues.jboss.org/browse/WFLY-5922
> Project: WildFly
> Issue Type: Bug
> Components: Class Loading
> Affects Versions: 10.0.0.CR4
> Environment: Red Hat Enterprise Linux Server release 7.1 (Maipo)
> Linux 3.10.0-229.4.2.el7.x86_64 #1 SMP Wed May 13 10:06:09 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
> java version "1.8.0_60"
> Java(TM) SE Runtime Environment (build 1.8.0_60-b27)
> Java HotSpot(TM) 64-Bit Server VM (build 25.60-b23, mixed mode)
> Reporter: John Farrelly
> Assignee: David Lloyd
> Priority: Blocker
>
> We use Orbacus as our CORBA implementation, and in our application we wish to use CORBA classes only from the orbacus module, and not the JDK/WildFly bundled CORBA.
> In the {{jboss-deployment-structure.xml}} file of our {{ear}} file, we have the following:
> {code:xml}
> <?xml version="1.0" encoding="UTF-8"?>
> <jboss-deployment-structure>
> <ear-subdeployments-isolated>false</ear-subdeployments-isolated>
> <deployment>
> <exclusions>
> <module name="javax.orb.api" />
> <module name="org.omg.api" />
> </exclusions>
> <dependencies>
> <module name="com.ooc.orbacus" export="true"/>
> <module name="org.apache.commons.logging" export="true" />
> <module name="org.apache.commons.collections" export="true" />
> <module name="org.apache.log4j" export="true" />
> <module name="org.dom4j" export="true" />
> <module name="org.jdom" export="true" />
> <module name="javax.faces.api" slot="mojarra-2.1.23" export="true"/>
> <module name="com.sun.jsf-impl" slot="mojarra-2.1.23" export="true"/>
> <module name="org.jboss.ejb-client" export="true" />
> <module name="org.jboss.remote-naming" export="true" />
> <module name="org.jboss.remoting3" export="true" />
> <module name="org.apache.xerces" />
> <!-- dependency for richfaces -->
> <module name="com.google.guava" slot="11.0.2" export="true"/>
> </dependencies>
> </deployment>
> ...
> {code}
> However, despite excluding the {{javax.orb.api}} module, I can see that {{org.omg.PortableServer.Servant}} is loaded from that module instead of being loaded from our {{com.ooc.orbacus}} module. This causes our application to fail.
> Debugging through the jboss module loader, I can see that it considers both {{javax.orb.api}} and {{com.ooc.orbacus}} as prodivers of the {{org/omg/PortableServer}} path. I am not sure why {{javax.orb.api}} is being considered when it has been excluded in the deployment descriptor for the application.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (JGRP-1985) Message: make initial size of headers configurable
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/JGRP-1985?page=com.atlassian.jira.plugin.... ]
Dan Berindei commented on JGRP-1985:
------------------------------------
I didn't actually see header copying in my tests, I was just thinking of {{FRAG2}} because you mentioned fragmentation in the description. But WildFly always uses {{FORK}}, so a default of 4 should be better even without fragmentation.
> Message: make initial size of headers configurable
> --------------------------------------------------
>
> Key: JGRP-1985
> URL: https://issues.jboss.org/browse/JGRP-1985
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.6.7
>
>
> By default a message creates a {{Headers}} instance of 3. This is usually enough (transport, either {{NAKACK2}} or {{UNICAST3}}, and possibly fragmentation). However, if a message needs 4 or more headers, there's a resize which is an additional copy of 2 small arrays.
> Goal: make the initial headers size configurable.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (DROOLS-1016) Too much memory consumption while running code on drools6.
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1016?page=com.atlassian.jira.plugi... ]
Mario Fusco commented on DROOLS-1016:
-------------------------------------
I'm not aware of any reason why the heap memory occupation of drools 6 should be more than the double of the one used by 5. It's hard to reply without a reproducer, can you provide one?
> 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)
10 years, 3 months
[JBoss JIRA] (WFCORE-1267) Changing the max-history attribute value for configuration-changes fails
by ehsavoie Hugonnet (JIRA)
ehsavoie Hugonnet created WFCORE-1267:
-----------------------------------------
Summary: Changing the max-history attribute value for configuration-changes fails
Key: WFCORE-1267
URL: https://issues.jboss.org/browse/WFCORE-1267
Project: WildFly Core
Issue Type: Bug
Components: Domain Management
Affects Versions: 2.0.5.Final
Reporter: ehsavoie Hugonnet
Assignee: ehsavoie Hugonnet
[standalone@localhost:9990 /] /core-service=management/service=configuration-changes:write-attribute(name=max-history,value=20)
{
"outcome" => "failed",
"failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.IllegalStateException: WFLYCTL0188: Stage MODEL is already complete",
"rolled-back" => true
}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months