October 2006 - jboss-dev-forums - Jboss List Archives

[TODO - DEVELOPMENT] - JBoss Rules - Concern creating RuleBase using RuleBaseLoader

by vivonpereira

I found there are two ways of creating the Rule base from a given drl source. Each of these ways have a particular problem with them: 1. a) Write the Rules in a DRL File. b) Create a Reader for the DRL c) Create a PackageBuilder and then add the reader to the builder using the method 'addPackageFromDrl' d) Create the rulebase using 'RuleBaseFactory.newRuleBase()' e) Get the package from the builder and then add the package to the rulebase. When using the above to execute the Rules Program, it throws error at the point where we use the method 'addPackageFromDrl' from the builder. This is a peculiar problem because, the error is thrown during the second execution of the program. It works perfectly fine, when i execute it the first time. Also I want to bring it to the notice that, i am able to execute the program any number of times without errors, when I am executing it using command prompt and eclipse. The problem occurs when I am creating the jar and using it as a stand-alone and trying to execute the program from another application. The external application calls the rules method in the jar and executes it properly the first time, on second and further execution it throws me error at : builder.addPackageFromDrl(reader). My program code: Reader source = new InputStreamReader( DroolTest.class.getResourceAsStream( "/Test.drl" ) ); PackageBuilder builder = new PackageBuilder(); builder.addPackageFromDrl( source ); // Program throws error here during second execution from external application Package pkg = builder.getPackage(); RuleBase ruleBase = RuleBaseFactory.newRuleBase(); ruleBase.addPackage( pkg ); 2. a) Write the Rules in a DRL File. b) Create a Reader for the DRL c) Create the rulebase using RuleBaseLoader.getInstance().loadFromReader, and passing the reader to this method. When using this way of creating the rulebase, it works fine even if i execute the program any number of times. The execution of the program is through: command prompt, eclipse and also by External Application. Even by executing the program from an external application any number of times, the program does not throw any error. But there is a Functional problem with this way of creating the rulesbase. If I need to have two drl files, which is the usual case, when I use the line: RuleBaseLoader.getInstance().loadFromReader(reader); the second drl replaces the first drl in the rulebase. ie., I need to have only one rulebase for all working memories. Hence I have the following code: Reader source1 = new InputStreamReader( DroolTest.class.getResourceAsStream(/Test1.drl)); ruleBase = RuleBaseLoader.getInstance().loadFromReader(source1); Reader source2 = new InputStreamReader( DroolTest.class.getResourceAsStream(/Test2.drl)); ruleBase = RuleBaseLoader.getInstance().loadFromReader(source2); Here the rulebase created for the first time is replaced by the rulebase created second time. Hence the rules in the first drl file are all lost. Can anyone give me any suggestion on the above two problems. Appreciate if the response is quick and related to the problem. Thank u in advance View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3980992#3980992 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3980992

19 years, 5 months

1
0
0 / 0

[Design of POJO Server] - Re: VirtualFile.toURL() returning vfsfile:

by sacha.labourey＠jboss.com

What if you add an additional BufferedInputStream to the stream? in my AOP test (reading classfilles annotations), it had a dramatic impact. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3980958#3980958 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3980958

19 years, 5 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Client failover redeliveries discussion

by ovidiu.feodorov＠jboss.com

:) I am at least happy that you finally give a chance to the non-persistent messages. And sure, there are always better solutions. We can continue to talk about that. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3980954#3980954 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3980954

19 years, 5 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Client failover redeliveries discussion

by timfox

"ovidiu.feodorov(a)jboss.com" wrote : | | Because we are not going to modify the client code to NOT send acknowledgments for messages being delivered. The acknowledgment-sending portion of the client-side aspect stack is "unaware" that it just went through a failover and it will dully continue to behave as designed, i.e. sending acknowledgments for messages being consumed. It's the secondary server job to realize that the acknowledgments arriving for deliveries it actually does not have (or better said, did not create by actually sending messages) are legit, and are generated by "salvaged" non-persistent messages. | | Does it make sense? That's a poor solution. So you're going to send unnecessary traffic across the network, plus add fiddly code on the server side to create deliveries for non existent non persistent messages just to avoid changing a few lines of code on the client side? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3980953#3980953 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3980953

19 years, 5 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Client failover redeliveries discussion

by ovidiu.feodorov＠jboss.com

Tim wrote : | Still makes no sense. | What's the point of sending an ack that's just going to be ignored? | It's much easier to just not send it in the first place, you can still process the np messages in the client buffer, just completely pointless to send acks to the server for them. | Because we are not going to modify the client code to NOT send acknowledgments for messages being delivered. The acknowledgment-sending portion of the client-side aspect stack is "unaware" that it just went through a failover and it will dully continue to behave as designed, i.e. sending acknowledgments for messages being consumed. It's the secondary server job to realize that the acknowledgments arriving for deliveries it actually does not have (or better said, did not create by actually sending messages) are legit, and are generated by "salvaged" non-persistent messages. Does it make sense? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3980952#3980952 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3980952

19 years, 5 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Client failover redeliveries discussion

by ovidiu.feodorov＠jboss.com

Tim wrote : I don't think you need to copy anything - just re-use the old one. You're right here. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3980951#3980951 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3980951

19 years, 5 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Client failover redeliveries discussion

by timfox

"ovidiu.feodorov(a)jboss.com" wrote : | To spell this out for you, so you won't go over is again: The current code, that is in the SVN, does not behave this way. This is understandable, it's just a prototype. I was going over the use cases for which we need test cases, so we can make sure the correct behavior is preserved in the future. The correct behavior is "transparently copying the transactional state (the corresponding TxState instance) into the new ResourceManager and send the messages over the new connection when transaction commits." Please note the use of the word "transparent". I don't think you need to copy anything - just re-use the old one. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3980947#3980947 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3980947

19 years, 5 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Client failover redeliveries discussion

by timfox

"ovidiu.feodorov(a)jboss.com" Please consider this simple example: the non-persistent messages N1 (id = 1) and N2 (id=2), sent by the server A, sit in the client-side buffer. The server A fails, the VM goes down. The connection is re-established (transparently) to server B. Server B knows that is a secondary server for the connection that just has established (as a result of the failover protocol). So, it could naturally assume that there are undelivered non-persistent messages in the client-side buffer. Which have not been lost. It also learns that the id of the messages are 1 and 2 (as a result of the fail-over protocol). So, what is stopping the server B (again, knowing that is a secondary server that has just been failed-over to), to accept acknowledgments for non-persistent messages that have been salvaged this way? [/quote wrote : | | Still makes no sense. | | What's the point of sending an ack that's just going to be ignored? | | It's much easier to just not send it in the first place, you can still process the np messages in the client buffer, just completely pointless to send acks to the server for them. | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3980946#3980946 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3980946

19 years, 5 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Client failover redeliveries discussion

by ovidiu.feodorov＠jboss.com

Tim wrote : | This makes no sense. When server A fails and server B takes over, only the persistent messages are resurrected into server B's queues. | The non persistent messages are lost. | Therefore it's not possible that the non persistent messages can be successfully acknowledged on server B, since server B won't know about them. | This is why I said the non persistent messages should be removed from the client state so they don't attempt to be acked. | Please consider this simple example: the non-persistent messages N1 (id = 1) and N2 (id=2), sent by the server A, sit in the client-side buffer. The server A fails, the VM goes down. The connection is re-established (transparently) to server B. Server B knows that is a secondary server for the connection that just has established (as a result of the failover protocol). So, it could naturally assume that there are undelivered non-persistent messages in the client-side buffer. Which have not been lost. It also learns that the id of the messages are 1 and 2 (as a result of the fail-over protocol). So, what is stopping the server B (again, knowing that is a secondary server that has just been failed-over to), to accept acknowledgments for non-persistent messages that have been salvaged this way? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3980943#3980943 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3980943

19 years, 5 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Client failover redeliveries discussion

by ovidiu.feodorov＠jboss.com

Tim wrote : | I thought we had gone over all this already, but here goes again.... | | ovidiu.feodorov(a)jboss.com wrote : | | A client may happen to be sending a message when the failure occurs. If the message is sent individually (not in the context of a transaction), then the on-going synchronous invocation is going to fail, the client code will catch the exception, and most likely will re-try to send the message, | | | | What do you mean the "client code" will catch the exception? | Do you mean the application code? | If so, this is incorrect - JBoss Messaging failover is supposed to be automatic - this is one of our selling points. | Applications shouldn't have to catch connection exceptions and retry like in JBossMQ. | | Ovidiu wrote : | | If the client happens to send message in the context of a transaction when the failure occurs, we could either throw an exception, and discard everything, or go for the more elegant solution of transparently copying the transactional state (the corresponding TxState instance) into the new ResourceManager and send the messages over the new connection when transaction commits. We're probably not doing this right now, but this is what should be doing. | | | | Same reasoning applies as previous comment. It should be transparent. | That is exactly what I am saying: "We're probably not doing this right now, but this is what should be doing." To spell this out for you, so you won't go over is again: The current code, that is in the SVN, does not behave this way. This is understandable, it's just a prototype. I was going over the use cases for which we need test cases, so we can make sure the correct behavior is preserved in the future. The correct behavior is "transparently copying the transactional state (the corresponding TxState instance) into the new ResourceManager and send the messages over the new connection when transaction commits." Please note the use of the word "transparent". View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3980942#3980942 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3980942

19 years, 5 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-dev-forums October 2006