[JBoss JIRA] (JGRP-816) TP: avoid copying when receiving data
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-816?page=com.atlassian.jira.plugin.s... ]
Bela Ban resolved JGRP-816.
---------------------------
Resolution: Duplicate
> TP: avoid copying when receiving data
> -------------------------------------
>
> Key: JGRP-816
> URL: https://issues.jboss.org/browse/JGRP-816
> Project: JGroups
> Issue Type: Sub-task
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0
>
>
> Currently, we receive data into a byte[] buffer, e.g. from DatagramSocket.receive(), but then have to COPY buffer when passing it to a worker from the thread pool. The copy is needed because the next DatargamSocket.receive() will overwrite the contents of buffer, and if the worker thread is still unmarshalling the data from the buffer, it might read corrupt contents.
> To overcome this, investigate the following:
> - Every worker thread has it own buffer
> - When the thread has been idle for N seconds and is removed from the pool, that buffer will be discarded
> - We create DatagramChannels from the socket(s) (DatagramSocket, MulticastSocket or Socket)
> - A selector is called when new data is available on the socket
> - The key returned by the selector points to the right channel
> - We pass the channel to a thread pool worker thread and continue with the select() loop
> - The worker then reads the data into its own buffer, unmarshalls it and passed it up the stack
> ==> No copy of the buffer is required as the thread's buffer is available until the message has been processed (usually until message unmarshalling)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (JGRP-816) TP: avoid copying when receiving data
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-816?page=com.atlassian.jira.plugin.s... ]
Bela Ban commented on JGRP-816:
-------------------------------
https://issues.jboss.org/browse/JGRP-1998 already addressed this issue, closing as moot
> TP: avoid copying when receiving data
> -------------------------------------
>
> Key: JGRP-816
> URL: https://issues.jboss.org/browse/JGRP-816
> Project: JGroups
> Issue Type: Sub-task
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0
>
>
> Currently, we receive data into a byte[] buffer, e.g. from DatagramSocket.receive(), but then have to COPY buffer when passing it to a worker from the thread pool. The copy is needed because the next DatargamSocket.receive() will overwrite the contents of buffer, and if the worker thread is still unmarshalling the data from the buffer, it might read corrupt contents.
> To overcome this, investigate the following:
> - Every worker thread has it own buffer
> - When the thread has been idle for N seconds and is removed from the pool, that buffer will be discarded
> - We create DatagramChannels from the socket(s) (DatagramSocket, MulticastSocket or Socket)
> - A selector is called when new data is available on the socket
> - The key returned by the selector points to the right channel
> - We pass the channel to a thread pool worker thread and continue with the select() loop
> - The worker then reads the data into its own buffer, unmarshalls it and passed it up the stack
> ==> No copy of the buffer is required as the thread's buffer is available until the message has been processed (usually until message unmarshalling)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (JGRP-1844) Remove shared transport
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1844?page=com.atlassian.jira.plugin.... ]
Bela Ban resolved JGRP-1844.
----------------------------
Resolution: Done
The shared transport feature has been removed. Rich: if you run into problems converting your code to run on fork channels, let me know and I can help you with the conversion.
> Remove shared transport
> -----------------------
>
> Key: JGRP-1844
> URL: https://issues.jboss.org/browse/JGRP-1844
> Project: JGroups
> Issue Type: Task
> Affects Versions: 3.5
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0
>
>
> I'm thinking of deprecating the shared transport [1] and remove it in 4.0. The replacement would be fork channels [2].
> Here's my reasoning:
> * Shared transports are quite a complex beast: initialization (ref counting), cluster-name and local-addr are not used in TP when shared, duplicate logic. Removing this will make the code base smaller
> * All protocols *above* shared transports are not shared, e.g. FD_SOCK, NAKACK, UNICAST etc all maintain their own threads, retransmission tables, sockets etc. With fork channels, everything up to the FORK protocol *is* shared
> * TUNNEL doesn't work with shared transports (throws an exception)
> * Hidden insertion of TP$ProtocolAdapter into the stack when shared transports are used
> * Unneeded cost of sending N-1 messages (e.g. with TCP). Currently we send a message with dest null and no IP multicast capable transport to all physical addresses in the transport, which is a waste
> Thoughts ? My +100 for removing shared transports in 4.0...
> [1] http://www.jgroups.org/manual/html/user-advanced.html#SharedTransport
> [2] http://www.jgroups.org/manual/html/user-advanced.html#ForkChannel
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (DROOLS-1028) Drools 6.3.0.Final - high memory usage
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1028?page=com.atlassian.jira.plugi... ]
Mario Fusco commented on DROOLS-1028:
-------------------------------------
Sorry, but not having your domain model that rule is unusable for me and I haven't been able to recreate this memory leak (I'm pretty sure there's one) on my own. Do you think you could provide one including the rule that causes the leak?
> Drools 6.3.0.Final - high memory usage
> --------------------------------------
>
> Key: DROOLS-1028
> URL: https://issues.jboss.org/browse/DROOLS-1028
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.1.0.Final, 6.3.0.Final
> Environment: Drools 6.3.0.Final on Windows, AIX and Linux
> Reporter: Bill Tuminaro
> Assignee: Mario Fusco
> Attachments: newSampleFile.drl, SampleRuleFile.drl, screenshot-1.png
>
>
> We have an application that completely wraps the drools run-time. The code creates rules, compiles them and manages the run-time. We are experiencing very high memory utilization in an environment with about 1000 rules. Memory continuously grows as we insert facts, I know this is expected, however the amount of growth seems unusually large. In one scenario, memory consumption jumps 200 MB after inserting about 4800 facts (each fact consumes about 200 bytes) and calling fireallrules. We are currently running with the phreak algorithm. I wrote some code that iterates over the facthandles to count the number of right tuple references once the insertion and fireallrules has completed. It shows over 10 million references. Can someone review the attached code to tell me if the approach is sound? Also, how do I identify the entire set of right tuples in memory, I would like to write some code to produce some data about them to give me some insight into what is causing so many right tuples and right tuple references to be created. If we can narrow this down, I would like to write a reproducer to isolate the large memory usage.
> for (Object obj : kSession.getObjects()) {
> if (obj == null) {
> RuleLogger.traceDebug( className, methodName,"Null object");
> }
> DefaultFactHandle factHandle = (DefaultFactHandle)kSession.getFactHandle(obj);
> if (factHandle != null) {
> RightTuple previous = factHandle.getLastRightTuple();
> int rtCount = 0;
> if (previous != null ) {
> ++rtCount;
> while (true) {
> previous = (RightTuple) previous.getNext();
> if (previous == null)
> break;
> ++rtCount;
> }
> }
> totalRighttuples += rtCount;
> }
> }
> ...
> String msg = "printStats() - WM has " +nm.length() + " nodes in NM array, " + activeNodesInNm + " active nodes, " + totalsmNetworkNodes+ " network nodes, " + totalsmPathMemories + " path memories, " +
> + totalRighttuples + " rightTuple references";
> Sample output:
> printStats() - WM has 14328 nodes in NM array, 4711 active nodes, 26396 network nodes, 4640 path memories, 10754655 rightTuple references
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (WFLY-6061) Deployment error after reboot [WFLYSRV0137]
by Tobi Tobias (JIRA)
Tobi Tobias created WFLY-6061:
---------------------------------
Summary: Deployment error after reboot [WFLYSRV0137]
Key: WFLY-6061
URL: https://issues.jboss.org/browse/WFLY-6061
Project: WildFly
Issue Type: Bug
Components: ConfigAdmin
Affects Versions: 9.0.2.Final
Environment: Ubuntu 14.04 LTS 64bit, jre-1.8.0_65
Several deployed (JavaEE) web applications including non XA datasources that connect to a MySQL instance.
Reporter: Tobi Tobias
Assignee: Thomas Diesler
Priority: Critical
I have a working configuration on wildfly 9.0.2 final with several web applications (JavaEE).
After a couple of days, I deployed another war file via jboss CLI. This application worked correctly and no deployment error occurred.
But if I restart the server now, I get following error message:
10:36:01,893 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([("deployment" => "MM-Controller-0.1.0-SNAPSHOT.war")]) - failure description: "WFLYSRV0137: No deployment content with hash 966847a6f5f5bf8c3470f07ea9e65b7bbcdcd7b7 is available in the deployment content repository for deployment 'MM-Controller-0.1.0-SNAPSHOT.war'. This is a fatal boot error. To correct the problem, either restart with the --admin-only switch set and use the CLI to install the missing content or remove it from the configuration, or remove the deployment from the xml configuration file and restart."
10:36:01,990 FATAL [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0056: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details.
I reproduced this at least 30 times - even with different jars. I always get this error. The server works fine as long as I don't reboot.
The only way to fix the configuration is to manually remove the deployments from the standalone.xml.
But this is not an option for me as I want to have the wildfly running as production server where I have several automatic deployments every day.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (DROOLS-787) getProcessRuntimeFactoryService method of ProcessRuntimeFactory is synchronized.
by Petr Široký (JIRA)
[ https://issues.jboss.org/browse/DROOLS-787?page=com.atlassian.jira.plugin... ]
Petr Široký updated DROOLS-787:
-------------------------------
Fix Version/s: 7.0.0.Final
(was: 6.4.0.CR1)
> getProcessRuntimeFactoryService method of ProcessRuntimeFactory is synchronized.
> --------------------------------------------------------------------------------
>
> Key: DROOLS-787
> URL: https://issues.jboss.org/browse/DROOLS-787
> Project: Drools
> Issue Type: Bug
> Affects Versions: 6.3.0.Final, 6.4.0.Beta1
> Environment: software platform
> Reporter: vipul gajara
> Assignee: Petr Široký
> Fix For: 7.0.0.Final
>
>
> getProcessRuntimeFactoryService is getter method of singleton class "org.drools.core.runtime.process.ProcessRuntimeFactory" but this method is static synchronized so at a time only one thread can call it .
> Due to above issue when we are using drools in multi threaded enviorenment threads are getting locked at this method and performance degrades when creating KSession objects.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (DROOLS-787) getProcessRuntimeFactoryService method of ProcessRuntimeFactory is synchronized.
by Petr Široký (JIRA)
[ https://issues.jboss.org/browse/DROOLS-787?page=com.atlassian.jira.plugin... ]
Petr Široký updated DROOLS-787:
-------------------------------
Affects Version/s: 6.4.0.Beta1
6.3.0.Final
> getProcessRuntimeFactoryService method of ProcessRuntimeFactory is synchronized.
> --------------------------------------------------------------------------------
>
> Key: DROOLS-787
> URL: https://issues.jboss.org/browse/DROOLS-787
> Project: Drools
> Issue Type: Bug
> Affects Versions: 6.3.0.Final, 6.4.0.Beta1
> Environment: software platform
> Reporter: vipul gajara
> Assignee: Petr Široký
> Fix For: 7.0.0.Final
>
>
> getProcessRuntimeFactoryService is getter method of singleton class "org.drools.core.runtime.process.ProcessRuntimeFactory" but this method is static synchronized so at a time only one thread can call it .
> Due to above issue when we are using drools in multi threaded enviorenment threads are getting locked at this method and performance degrades when creating KSession objects.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months