August 2019 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-4397) Make drools-model-compiler dialect agnostic

by Luca Molteni (Jira)

[ https://issues.jboss.org/browse/DROOLS-4397?page=com.atlassian.jira.plugi... ] Luca Molteni commented on DROOLS-4397: -------------------------------------- so just to re-iterate the goal. 1) we want to kill the MVEL dialect, to only have the Java dialect impl. 2) we need to rewrite all valid MVEL stateements and blocks to Java, so we can force a rule to java dialect. 3) this means all stateemnt rewitting (for valid java statements) is done at the dialect level, and not canonical model. > Make drools-model-compiler dialect agnostic > ------------------------------------------- > > Key: DROOLS-4397 > URL: https://issues.jboss.org/browse/DROOLS-4397 > Project: Drools > Issue Type: Task > Components: executable model > Reporter: Luca Molteni > Assignee: Luca Molteni > Priority: Major > > By preprocessing it with the mvel compiler before going into the drools-executable-model -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4397) Make drools-model-compiler dialect agnostic

by Luca Molteni (Jira)

[ https://issues.jboss.org/browse/DROOLS-4397?page=com.atlassian.jira.plugi... ] Luca Molteni commented on DROOLS-4397: -------------------------------------- sub goal. is to change the JavaDialect to only use JavaParser. and not duplicate parsing, with antlr first and then javaparser later. > Make drools-model-compiler dialect agnostic > ------------------------------------------- > > Key: DROOLS-4397 > URL: https://issues.jboss.org/browse/DROOLS-4397 > Project: Drools > Issue Type: Task > Components: executable model > Reporter: Luca Molteni > Assignee: Luca Molteni > Priority: Major > > By preprocessing it with the mvel compiler before going into the drools-executable-model -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4397) Make drools-model-compiler dialect agnostic

by Luca Molteni (Jira)

[ https://issues.jboss.org/browse/DROOLS-4397?page=com.atlassian.jira.plugi... ] Luca Molteni commented on DROOLS-4397: -------------------------------------- Braindump: @Luca Molteni ok there? look at AbstractASMConsequenceBuilder we rewrite the java string here - String fixedConsequence = KnowledgeHelperFixer.fix( DialectUtil.fixBlockDescr(context, analysis, decls) ); but also see this line above - JavaAnalysisResult analysis = JavaRuleBuilderHelper.createJavaAnalysisResult(context, consequenceName, decls); this does a full java parse, with antlr. see JavaDialect.analyzeBlock @Luca Molteni clearly this is pointless. we can parse with JavaParser once. keep the AST around. in fact you have to reverse the order too. so parse with JavaParser first. rewrite it to pure java. then get the analyser. analyser just returns the variables. which javaparser can do for you. but you can do this one step at a time. first just replace this line. String fixedConsequence = KnowledgeHelperFixer.fix( DialectUtil.fixBlockDescr(context, analysis, decls) ); > Make drools-model-compiler dialect agnostic > ------------------------------------------- > > Key: DROOLS-4397 > URL: https://issues.jboss.org/browse/DROOLS-4397 > Project: Drools > Issue Type: Task > Components: executable model > Reporter: Luca Molteni > Assignee: Luca Molteni > Priority: Major > > By preprocessing it with the mvel compiler before going into the drools-executable-model -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2356) RpcDispatcher#callRemoteMethods does not work while calling MembershipListener#viewAccepted when using ForkChannel.

by Bela Ban (Jira)

[ https://issues.jboss.org/browse/JGRP-2356?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-2356: -------------------------------- Ah, I guess you're seeing this issue only when you start a second of JChannelRunner? > RpcDispatcher#callRemoteMethods does not work while calling MembershipListener#viewAccepted when using ForkChannel. > ------------------------------------------------------------------------------------------------------------------- > > Key: JGRP-2356 > URL: https://issues.jboss.org/browse/JGRP-2356 > Project: JGroups > Issue Type: Bug > Affects Versions: 4.1.0 > Environment: Java: jdk1.8.0_212 > OS: Windows 7 / Linux(ubuntu) > Reporter: Ziro Tanaka > Assignee: Bela Ban > Priority: Major > Fix For: 4.1.3 > > Attachments: JChannelRunner.java, coordinator_log.txt, coordinator_threaddump.txt, joinner_log.txt > > > Create RpcDispatcher that works with ForkChannel and set MembershipListener. > If you make a synchronous call with RpcDispatcher in MembershipListener#viewAccepted, no response will be returned. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2356) RpcDispatcher#callRemoteMethods does not work while calling MembershipListener#viewAccepted when using ForkChannel.

by Bela Ban (Jira)

[ https://issues.jboss.org/browse/JGRP-2356?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-2356: -------------------------------- I cannot reproduce the issue; this works for me! Looking at your log, this also works for *you*: {noformat} MessageDispatcher - dests=null, method_call=boeee(), options=mode=GET_ALL, timeout=0, anycasting=true, flags=OOB, responses: [IM9072-5099: received=true, suspected=false] [INFO ] 2019-07-01 18:15:24.529 [main] JChannelRunner - viewAccepted:end {noformat}, otherwise you wouldn't see {{viewAccepted:end}}, would you? Having said that, it is still a bad idea to invoke a blocking RPC in a {{viewAccepted()}} callback! > RpcDispatcher#callRemoteMethods does not work while calling MembershipListener#viewAccepted when using ForkChannel. > ------------------------------------------------------------------------------------------------------------------- > > Key: JGRP-2356 > URL: https://issues.jboss.org/browse/JGRP-2356 > Project: JGroups > Issue Type: Bug > Affects Versions: 4.1.0 > Environment: Java: jdk1.8.0_212 > OS: Windows 7 / Linux(ubuntu) > Reporter: Ziro Tanaka > Assignee: Bela Ban > Priority: Major > Fix For: 4.1.3 > > Attachments: JChannelRunner.java, coordinator_log.txt, coordinator_threaddump.txt, joinner_log.txt > > > Create RpcDispatcher that works with ForkChannel and set MembershipListener. > If you make a synchronous call with RpcDispatcher in MembershipListener#viewAccepted, no response will be returned. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4398) Freezing test "RemoteKieSessionImplTest" in HA CEP reference implementation

by Jiri Petrlik (Jira)

Jiri Petrlik created DROOLS-4398: ------------------------------------ Summary: Freezing test "RemoteKieSessionImplTest" in HA CEP reference implementation Key: DROOLS-4398 URL: https://issues.jboss.org/browse/DROOLS-4398 Project: Drools Issue Type: Bug Components: Cloud Affects Versions: 7.25.0.Final Reporter: Jiri Petrlik Assignee: Massimiliano Dessi Test "RemoteKieSessionImplTest" in HA CEP reference implementation is freezing time to time. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4397) Make drools-model-compiler dialect agnostic

by Luca Molteni (Jira)

Luca Molteni created DROOLS-4397: ------------------------------------ Summary: Make drools-model-compiler dialect agnostic Key: DROOLS-4397 URL: https://issues.jboss.org/browse/DROOLS-4397 Project: Drools Issue Type: Task Components: executable model Reporter: Luca Molteni Assignee: Luca Molteni By preprocessing it with the mvel compiler before going into the drools-executable-model -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2303) RELAY2: notification when a site is up/down on all cluster nodes

by Bela Ban (Jira)

[ https://issues.jboss.org/browse/JGRP-2303?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-2303: --------------------------- Fix Version/s: 4.1.3 (was: 4.1.2) > RELAY2: notification when a site is up/down on all cluster nodes > ---------------------------------------------------------------- > > Key: JGRP-2303 > URL: https://issues.jboss.org/browse/JGRP-2303 > Project: JGroups > Issue Type: Enhancement > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Minor > Fix For: 4.1.3 > > > Provide a callback that's invoked on *all nodes* when a site is up/down, and possibly an initial view of the sites. Could be something like a 'sites view', e.g. \{"LON", "SFO"\}, \{"LON"\}, \{"LON", "SFO", "NYC\} etc -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2335) Code for determining the coordinator hangs in certain conditions

by Bela Ban (Jira)

[ https://issues.jboss.org/browse/JGRP-2335?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-2335: --------------------------- Fix Version/s: 4.1.3 (was: 4.1.2) > Code for determining the coordinator hangs in certain conditions > ---------------------------------------------------------------- > > Key: JGRP-2335 > URL: https://issues.jboss.org/browse/JGRP-2335 > Project: JGroups > Issue Type: Bug > Reporter: Aieksiei Illarionov > Assignee: Bela Ban > Priority: Major > Fix For: 4.1.3 > > > Affected version: > {code:xml} > <dependency> > <groupId>org.jgroups</groupId> > <artifactId>jgroups</artifactId> > <version>4.0.0.Final</version> > </dependency> > {code} > ClientGmsImpl#joinInternal hangs because #firstOfAllClients always returns false when all of the following conditions are satisfied: > - using JDBC_PING for discovery protocol > - JGROUPSPING table contains data from previous sessions > - all of the previous sessions were killed (kill -9) > - AddressGenerator is not customized > The sorted set > {code:java} > SortedSet<Address> clients=new TreeSet<>(); > {code} > contains the dead servers discovered from JGROUPSPING. When the new server is added to the sorted set, it never becomes the first in the sorted set. > Suggestions: either > a) somehow involve MembershipChangePolicy in ordering strategy, or > b) make the new server (joiner) the first in the sorted set, or > c) make UUID addresses to sort depending on their time of creation. > I've used the following config: > {code:xml} >  > <config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" > xmlns="urn:org:jgroups" > xmlns:fork="fork" > xsi:schemaLocation="urn:org:jgroups http://www.jgroups.org/schema/jgroups.xsd fork http://www.jgroups.org/schema/fork-stacks.xsd"> > <TCP bind_port="7800" > port_range="10" > bind_addr="<placeholder here>" > recv_buf_size="${tcp.recv_buf_size:130k}" > send_buf_size="${tcp.send_buf_size:130k}" > max_bundle_size="64K" > sock_conn_timeout="300" > thread_pool.min_threads="0" > thread_pool.max_threads="20" > thread_pool.keep_alive_time="30000"/> > <JDBC_PING > remove_all_data_on_view_change="true" > connection_driver="com.microsoft.sqlserver.jdbc.SQLServerDriver" > connection_url="jdbc:sqlserver://localhost:1433;databaseName=mydatabase" > connection_username="user" > connection_password="password" > /> > <MERGE3 min_interval="10000" > max_interval="30000"/> > <FD_SOCK/> > <FD timeout="3000" max_tries="3" /> > <VERIFY_SUSPECT timeout="1500" /> > <BARRIER /> > <pbcast.NAKACK2 use_mcast_xmit="false" > discard_delivered_msgs="true"/> > <UNICAST3 > conn_close_timeout="240000" > xmit_interval="5000"/> > <pbcast.STABLE desired_avg_gossip="50000" > max_bytes="4M"/> > <pbcast.GMS print_local_addr="true" join_timeout="2000" > view_bundling="true" > membership_change_policy="ru.illar.AppMembershipChangePolicy"/> > <MFC max_credits="2M" > min_threshold="0.4"/> > <FRAG2 frag_size="60K" /> >  > <pbcast.STATE_TRANSFER/> > </config> > {code} -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2331) Probe does not handle multiple protocols of the same class in the same stack

by Bela Ban (Jira)

[ https://issues.jboss.org/browse/JGRP-2331?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-2331: --------------------------- Fix Version/s: 4.1.3 (was: 4.1.2) > Probe does not handle multiple protocols of the same class in the same stack > ---------------------------------------------------------------------------- > > Key: JGRP-2331 > URL: https://issues.jboss.org/browse/JGRP-2331 > Project: JGroups > Issue Type: Bug > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Optional > Fix For: 4.1.3 > > > When we have multiple protocols of the same type (e.g. FRAG2) in the same stack, probe.sh only dumps information about the first one found. E.g. in > {noformat} > <UDP/> > <PING/> > <FRAG2 id="350".../> > ... > <GMS/> > <FRAG2.../> > {noformat} > , the FRAG2 protocol with id 350 would likely get skipped as the other one was found first in a query like {{probe.sh jmx=FRAG2}} -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 9 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira August 2019