[JBoss JIRA] (JGRP-2065) RoundTrip: latency is high compared to RoundTripTcp/RoundTripServer
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2065?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2065:
--------------------------------
Findings:
* Disabling the thread pools in TCP brought the round-trip time down *110 us* down to *99 us*.
> RoundTrip: latency is high compared to RoundTripTcp/RoundTripServer
> -------------------------------------------------------------------
>
> Key: JGRP-2065
> URL: https://issues.jboss.org/browse/JGRP-2065
> Project: JGroups
> Issue Type: Task
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0
>
>
> {{RoundTrip}} is a simple test between 2 members measuring round-trip latency. The sender continually sends a message, the receiver receives it and sends the response, and the sender unblocks when the response is received. Then the sender sends the next message.
> The time for the request is then logged at the sender and a min/avg/max value is computed (probably changed to histograms later).
> {{RoundTrip}} uses a JGroups channel, configured with {{-props}}, e.g. {{-props ~/tcp.xml}}.
> {{RoundTripTcp}} does the same, but uses direct TCP sockets (no JGroups) for communication.
> {{RoundTripServer}} uses the client-server classes of JGroups for communication, but no channel is used.
> Round trip times (both processes on the same box, a Mac mini):
> * {{RoundTrip}} (with {{tcp.xml}} shipped with JGroups): *110 us*
> * {{RoundTripTcp}}: *46 us*
> * {{RoundTripServer}}: *49 us*
> Note that the client/server classes used by {{RoundTripServer}} are also used by the TCP transport (configured in {{tcp.xml}}.
> {{RoundTripServer}} is ~6% slower than {{RoundTripTcp}}, but that can be attributed to the additional work the former has to do (e.g. connection reaping etc). This is something we can focus on later.
> The big difference are the 110 us for {{RoundTrip}}. The goal is to find out what causes this and eliminate it. Since {{RoundTrip}} and {{RoundTripServer}} use the same underlying client/server classes in JGroups, let's compare these 2.
> Tasks:
> * Remove all protocols other than TCP in the running stack: (e.g. {{probe.sh remove-protocol=MFC}}). I already did this and the diff was negligible, but let's run this again
> * Try various bundlers (e.g. NoBundler)
> * Reduce threads in the threadpools, possibly disable (regular and OOB) thread pools (replace with DirectExecutor)
> * The default is 1 sender thread, but try with multiple threads
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (DROOLS-1181) NullPointerException in LogicTransformer
by Sjoerd Cranen (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1181?page=com.atlassian.jira.plugi... ]
Sjoerd Cranen commented on DROOLS-1181:
---------------------------------------
This does not seem to be restricted to enum constants; the following gives the same NPE:
{code}
declare TestThing
value: Integer
end
query TestQuery(Integer val)
TestThing()
end
query NPEQuery(TestThing thing)
(
TestQuery(thing.value;)
) or (
TestQuery(thing.value;)
)
end
{code}
> NullPointerException in LogicTransformer
> ----------------------------------------
>
> Key: DROOLS-1181
> URL: https://issues.jboss.org/browse/DROOLS-1181
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.4.0.Final
> Reporter: Sjoerd Cranen
> Assignee: Mario Fusco
>
> When an enum constant is used in the context of an _or_-operator as a positional argument to a query, a NullPointerException is thrown with the following stack trace:
> {code}
> java.lang.NullPointerException
> at org.drools.core.rule.LogicTransformer.processElement(LogicTransformer.java:230)
> at org.drools.core.rule.LogicTransformer.processElement(LogicTransformer.java:251)
> at org.drools.core.rule.LogicTransformer.fixClonedDeclarations(LogicTransformer.java:154)
> at org.drools.core.rule.LogicTransformer.transform(LogicTransformer.java:97)
> at org.drools.core.definitions.rule.impl.RuleImpl.getTransformedLhs(RuleImpl.java:620)
> at org.drools.core.reteoo.builder.ReteooRuleBuilder.addRule(ReteooRuleBuilder.java:108)
> at org.drools.core.reteoo.ReteooBuilder.addRule(ReteooBuilder.java:106)
> at org.drools.core.impl.KnowledgeBaseImpl.addRule(KnowledgeBaseImpl.java:1567)
> at org.drools.core.impl.KnowledgeBaseImpl.addRule(KnowledgeBaseImpl.java:1547)
> at org.drools.core.impl.KnowledgeBaseImpl.internalAddPackages(KnowledgeBaseImpl.java:920)
> at org.drools.core.impl.KnowledgeBaseImpl.access$000(KnowledgeBaseImpl.java:117)
> at org.drools.core.impl.KnowledgeBaseImpl$1.run(KnowledgeBaseImpl.java:708)
> at org.drools.core.impl.KnowledgeBaseImpl.enqueueModification(KnowledgeBaseImpl.java:716)
> at org.drools.core.impl.KnowledgeBaseImpl.addPackages(KnowledgeBaseImpl.java:705)
> at org.drools.core.impl.KnowledgeBaseImpl.addKnowledgePackages(KnowledgeBaseImpl.java:273)
> at org.drools.compiler.kie.builder.impl.KieContainerImpl.createKieBase(KieContainerImpl.java:510)
> at org.drools.compiler.kie.builder.impl.KieContainerImpl.getKieBase(KieContainerImpl.java:447)
> ...
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (JGRP-2065) RoundTrip: latency is high compared to RoundTripTcp/RoundTripServer
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2065?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2065:
---------------------------
Description:
{{RoundTrip}} is a simple test between 2 members measuring round-trip latency. The sender continually sends a message, the receiver receives it and sends the response, and the sender unblocks when the response is received. Then the sender sends the next message.
The time for the request is then logged at the sender and a min/avg/max value is computed (probably changed to histograms later).
{{RoundTrip}} uses a JGroups channel, configured with {{-props}}, e.g. {{-props ~/tcp.xml}}.
{{RoundTripTcp}} does the same, but uses direct TCP sockets (no JGroups) for communication.
{{RoundTripServer}} uses the client-server classes of JGroups for communication, but no channel is used.
Round trip times (both processes on the same box, a Mac mini):
* {{RoundTrip}} (with {{tcp.xml}} shipped with JGroups): *110 us*
* {{RoundTripTcp}}: *46 us*
* {{RoundTripServer}}: *49 us*
Note that the client/server classes used by {{RoundTripServer}} are also used by the TCP transport (configured in {{tcp.xml}}.
{{RoundTripServer}} is ~6% slower than {{RoundTripTcp}}, but that can be attributed to the additional work the former has to do (e.g. connection reaping etc). This is something we can focus on later.
The big difference are the 110 us for {{RoundTrip}}. The goal is to find out what causes this and eliminate it. Since {{RoundTrip}} and {{RoundTripServer}} use the same underlying client/server classes in JGroups, let's compare these 2.
Tasks:
* Remove all protocols other than TCP in the running stack: (e.g. {{probe.sh remove-protocol=MFC}}). I already did this and the diff was negligible, but let's run this again
* Try various bundlers (e.g. NoBundler)
* Reduce threads in the threadpools, possibly disable (regular and OOB) thread pools (replace with DirectExecutor)
* The default is 1 sender thread, but try with multiple threads
was:
{{RoundTrip}} is a simple test between 2 members where the sender continually sends a message, the receiver receives it and sends the response, and the sender unblocks when the response is received. The time for the request is then logged at the sender and a min/avg/max value is computed (probably changed to histograms later).
{{RoundTrip}} uses a JGroups channel, configured with {{-props}}, e.g. {{-props ~/tcp.xml}}.
{{RoundTripTcp}} does the same, but uses direct TCP sockets (no JGroups) for communication.
{{RoundTripServer}} uses the client-server classes of JGroups for communication, but no channel is used.
Round trip times (both processes on the same box, a Mac mini):
* {{RoundTrip}} (with {{tcp.xml}} shipped with JGroups): *110 us*
* {{RoundTripTcp}}: *46 us*
* {{RoundTripServer}}: *49 us*
> RoundTrip: latency is high compared to RoundTripTcp/RoundTripServer
> -------------------------------------------------------------------
>
> Key: JGRP-2065
> URL: https://issues.jboss.org/browse/JGRP-2065
> Project: JGroups
> Issue Type: Task
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0
>
>
> {{RoundTrip}} is a simple test between 2 members measuring round-trip latency. The sender continually sends a message, the receiver receives it and sends the response, and the sender unblocks when the response is received. Then the sender sends the next message.
> The time for the request is then logged at the sender and a min/avg/max value is computed (probably changed to histograms later).
> {{RoundTrip}} uses a JGroups channel, configured with {{-props}}, e.g. {{-props ~/tcp.xml}}.
> {{RoundTripTcp}} does the same, but uses direct TCP sockets (no JGroups) for communication.
> {{RoundTripServer}} uses the client-server classes of JGroups for communication, but no channel is used.
> Round trip times (both processes on the same box, a Mac mini):
> * {{RoundTrip}} (with {{tcp.xml}} shipped with JGroups): *110 us*
> * {{RoundTripTcp}}: *46 us*
> * {{RoundTripServer}}: *49 us*
> Note that the client/server classes used by {{RoundTripServer}} are also used by the TCP transport (configured in {{tcp.xml}}.
> {{RoundTripServer}} is ~6% slower than {{RoundTripTcp}}, but that can be attributed to the additional work the former has to do (e.g. connection reaping etc). This is something we can focus on later.
> The big difference are the 110 us for {{RoundTrip}}. The goal is to find out what causes this and eliminate it. Since {{RoundTrip}} and {{RoundTripServer}} use the same underlying client/server classes in JGroups, let's compare these 2.
> Tasks:
> * Remove all protocols other than TCP in the running stack: (e.g. {{probe.sh remove-protocol=MFC}}). I already did this and the diff was negligible, but let's run this again
> * Try various bundlers (e.g. NoBundler)
> * Reduce threads in the threadpools, possibly disable (regular and OOB) thread pools (replace with DirectExecutor)
> * The default is 1 sender thread, but try with multiple threads
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (JGRP-2065) RoundTrip: latency is high compared to RoundTripTcp/RoundTripServer
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2065?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2065:
---------------------------
Description:
{{RoundTrip}} is a simple test between 2 members where the sender continually sends a message, the receiver receives it and sends the response, and the sender unblocks when the response is received. The time for the request is then logged at the sender and a min/avg/max value is computed (probably changed to histograms later).
{{RoundTrip}} uses a JGroups channel, configured with {{-props}}, e.g. {{-props ~/tcp.xml}}.
{{RoundTripTcp}} does the same, but uses direct TCP sockets (no JGroups) for communication.
{{RoundTripServer}} uses the client-server classes of JGroups for communication, but no channel is used.
Round trip times (both processes on the same box, a Mac mini):
* {{RoundTrip}} (with {{tcp.xml}} shipped with JGroups): *110 us*
* {{RoundTripTcp}}: *46 us*
* {{RoundTripServer}}: *49 us*
was:
{{RoundTrip}} is a simple test between 2 members where the sender continually sends a message, the receiver receives it and sends the response, and the sender unblocks when the response is received. The time for the request is then logged at the sender and a min/avg/max value is computed (probably changed to histograms later).
RoundTrip uses a JGroups channel, configured with {{-props}}, e.g. {{-props ~/tcp.xml}}.
{{RoundTripTcp}} does the same, but uses direct TCP sockets (no JGroups) for communication.
{{RoundTripServer}} uses the client-server classes of JGroups for communication, but no channel is used.
> RoundTrip: latency is high compared to RoundTripTcp/RoundTripServer
> -------------------------------------------------------------------
>
> Key: JGRP-2065
> URL: https://issues.jboss.org/browse/JGRP-2065
> Project: JGroups
> Issue Type: Task
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0
>
>
> {{RoundTrip}} is a simple test between 2 members where the sender continually sends a message, the receiver receives it and sends the response, and the sender unblocks when the response is received. The time for the request is then logged at the sender and a min/avg/max value is computed (probably changed to histograms later).
> {{RoundTrip}} uses a JGroups channel, configured with {{-props}}, e.g. {{-props ~/tcp.xml}}.
> {{RoundTripTcp}} does the same, but uses direct TCP sockets (no JGroups) for communication.
> {{RoundTripServer}} uses the client-server classes of JGroups for communication, but no channel is used.
> Round trip times (both processes on the same box, a Mac mini):
> * {{RoundTrip}} (with {{tcp.xml}} shipped with JGroups): *110 us*
> * {{RoundTripTcp}}: *46 us*
> * {{RoundTripServer}}: *49 us*
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (DROOLS-1168) notify property change
by Sante Stanisci (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1168?page=com.atlassian.jira.plugi... ]
Sante Stanisci commented on DROOLS-1168:
----------------------------------------
@Modifies annotation is not viable solution because is sparse method that in many class context not maintain brain order that have drl rule files.
> notify property change
> ----------------------
>
> Key: DROOLS-1168
> URL: https://issues.jboss.org/browse/DROOLS-1168
> Project: Drools
> Issue Type: Enhancement
> Components: core engine
> Affects Versions: 6.4.0.Final
> Environment: java 6, eclipse 4, windows 8.1
> Reporter: Sante Stanisci
> Assignee: Mario Fusco
> Priority: Critical
> Attachments: DroolsUtil.java, EntityBase.java, MtbLisvData.java, rules.drl
>
>
> in the then statement instead of modify use a custom function to change the field. This change does not notify the property even if the class is annotated with @PropertyReactive
> How can I manually notify the change?
> Use a stateless session
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (JGRP-2065) RoundTrip: latency is high compared to RoundTripTcp/RoundTripServer
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2065?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2065:
---------------------------
Summary: RoundTrip: latency is high compared to RoundTripTcp/RoundTripServer (was: RoundTrip: performance is slow compared to RoundTripTcp/RoundTripServer)
> RoundTrip: latency is high compared to RoundTripTcp/RoundTripServer
> -------------------------------------------------------------------
>
> Key: JGRP-2065
> URL: https://issues.jboss.org/browse/JGRP-2065
> Project: JGroups
> Issue Type: Task
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0
>
>
> {{RoundTrip}} is a simple test between 2 members where the sender continually sends a message, the receiver receives it and sends the response, and the sender unblocks when the response is received. The time for the request is then logged at the sender and a min/avg/max value is computed (probably changed to histograms later).
> RoundTrip uses a JGroups channel, configured with {{-props}}, e.g. {{-props ~/tcp.xml}}.
> {{RoundTripTcp}} does the same, but uses direct TCP sockets (no JGroups) for communication.
> {{RoundTripServer}} uses the client-server classes of JGroups for communication, but no channel is used.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (JGRP-2065) RoundTrip: performance is slow compared to RoundTripTcp/RoundTripServer
by Bela Ban (JIRA)
Bela Ban created JGRP-2065:
------------------------------
Summary: RoundTrip: performance is slow compared to RoundTripTcp/RoundTripServer
Key: JGRP-2065
URL: https://issues.jboss.org/browse/JGRP-2065
Project: JGroups
Issue Type: Task
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 4.0
{{RoundTrip}} is a simple test between 2 members where the sender continually sends a message, the receiver receives it and sends the response, and the sender unblocks when the response is received. The time for the request is then logged at the sender and a min/avg/max value is computed (probably changed to histograms later).
RoundTrip uses a JGroups channel, configured with {{-props}}, e.g. {{-props ~/tcp.xml}}.
{{RoundTripTcp}} does the same, but uses direct TCP sockets (no JGroups) for communication.
{{RoundTripServer}} uses the client-server classes of JGroups for communication, but no channel is used.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (DROOLS-1168) notify property change
by Sante Stanisci (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1168?page=com.atlassian.jira.plugi... ]
Sante Stanisci updated DROOLS-1168:
-----------------------------------
Description:
in the then statement instead of modify use a custom function to change the field. This change does not notify the property even if the class is annotated with @PropertyReactive
How can I manually notify the change?
Use a stateless session
was:
nel then statement al posto di modify utilizzo una funzione custom per variare il campo. Questo non notifica il property change anche se la classe è annotata con @PropertyReactive
Come posso notificare manualmente il cambiamento?
utilizzo una stateless session
> notify property change
> ----------------------
>
> Key: DROOLS-1168
> URL: https://issues.jboss.org/browse/DROOLS-1168
> Project: Drools
> Issue Type: Enhancement
> Components: core engine
> Affects Versions: 6.4.0.Final
> Environment: java 6, eclipse 4, windows 8.1
> Reporter: Sante Stanisci
> Assignee: Mario Fusco
> Priority: Critical
> Attachments: DroolsUtil.java, EntityBase.java, MtbLisvData.java, rules.drl
>
>
> in the then statement instead of modify use a custom function to change the field. This change does not notify the property even if the class is annotated with @PropertyReactive
> How can I manually notify the change?
> Use a stateless session
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (DROOLS-1168) notify property change
by Sante Stanisci (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1168?page=com.atlassian.jira.plugi... ]
Sante Stanisci updated DROOLS-1168:
-----------------------------------
Attachment: EntityBase.java
rules.drl
DroolsUtil.java
MtbLisvData.java
> notify property change
> ----------------------
>
> Key: DROOLS-1168
> URL: https://issues.jboss.org/browse/DROOLS-1168
> Project: Drools
> Issue Type: Enhancement
> Components: core engine
> Affects Versions: 6.4.0.Final
> Environment: java 6, eclipse 4, windows 8.1
> Reporter: Sante Stanisci
> Assignee: Mario Fusco
> Priority: Critical
> Attachments: DroolsUtil.java, EntityBase.java, MtbLisvData.java, rules.drl
>
>
> nel then statement al posto di modify utilizzo una funzione custom per variare il campo. Questo non notifica il property change anche se la classe è annotata con @PropertyReactive
> Come posso notificare manualmente il cambiamento?
> utilizzo una stateless session
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months