Skip to main content

Posts

Showing posts from January, 2013

JBoss BRMS - JBoss Rules 引擎規則

JBoss Rules 第一課,
基本功我都喜歡從底層開始,這樣以後寫起來會事半功倍。
所以要看一下這個語言是如何執行的。

JBoss Rules 基本上就是去撰寫一堆的邏輯,然後把收集的資料(Fact)放進去,執行出來的就是結果囉!


因為同時會有很多人在會在上面執行,JBoss Rules 引擎也不可能把大家丟進去的物件全部搞在一起。所以引擎必須要將每個使用者的獨立的位置去存放每個人的Fact。這個空間我們叫它Working memory. 所有在JBoss Rule裡面對於Fact的修改,全部都會在自己的Working memory 做。當你的Fact 因為條件而有所變動時的名詞叫做 Truth Management. 我們建制的規則則被讀取,然後放進引擎的RuleBase。


每次執行的時候,JBoss Rules 引擎就會開始看哪些規則可以被執行,這些符合資格可以被執行的規則就叫做Agenda, 然後決定要執行這些規則順序。被執行的規則就叫做Activation。
例如說,有一堆規則在RuleBase裡面如下,


然後,這次input進去的Fact內容如下,


所以JBoss Rules 引擎就會把可以執行的Rules先找出來,跑出來的Agenda如下面藍色底色的規則



但是這些Agenda 確定執行的順序決定方式如下,也有個名字叫做 Conflict resolution. 衝突管理。


所謂的Salience 就是你在 JBoss Rules 一開始的設定的執行順序,數字越大,表示順序越高。(可以是負數)


rule "Fire in rank order 1,2,.." salience( -$rank ) when Element( $rank : rank,... ) then ... end

如果沒有特別設定,而且排序相同時,他就會看一下這些規則有哪些最近常常被跑到的,會以這個為優先, 如果這些規則的執行次數都差不多的時候,他就會看這些執行規則的複雜程度。越複雜的優先。如果真的不幸每個規則都是一樣複雜的話。那就只好靠誰先load 進來誰就先執行了。

以上為執行的方式。至於計算的演算法。JBoss Rules 是用 RETE. 有機會再上來寫吧!







JON - Security Token 不見怎麼辦!

這個算是FAQ了,安裝JON 的時候,有些東西要特別注意,以免日後要修改很困難,
如你的Agent 的名字,因為JON 會把兩邊的資料存在Agent 與 Server身上,
所以,如果你突然想換那麻煩就大條了。

出問題的地方,有些人重新安裝了Agent之後,出現了無法與Server聯結的問題。
如果,去看一下你的console上與Log中會看到類似以下的error,

The agent will now wait until it has registered with the server..


Cause: [org.rhq.core.clientapi.server.core.AgentRegistrationException:An agent is trying to register with an existing agent name [xxxx] without providing a valid security token. If you are attempting to re-register this agent, please consult an administrator to obtain the agent's proper security token and restart the agent with the option "-Drhq.agent.security-token=<the valid security token>"
這就是因為agent 身上的security token, 已經在重裝的時候被清掉了。 所以只要把token重新裝上去就好。如何安裝咧~
1. 先把Agent停下來。 2. 登入JON 的 server, 請記得這個登入的賬號要有安全設定的security 權限。 3. 按下最上方的Administrator, 左邊選單選擇Agent,找到你要重新安裝security token的agent名字。

4. 接下來的頁面就會有這個agent的資訊,請複製上面的security token.

5. 重新啓動你的agent, 執行的時候,加上  -Drhq.agent.security-token=剛剛複製的securityToken

security tok…

JEAP 6 - HornetQ 的 記事(Journal) 原理說明

有些人問HornetQ 的是不是可以使用Database 當作它的永久儲存,
其實這有點畫蛇添足,因為以現今的技術,資料庫的存取其實是屬於烏龜一族的,
HornetQ 使用更先進的方式,不再去連接慢吞吞有耗資源的資料庫,

這裡要先說明一下 HornetQ 的原理,

HornetQ 是利用自己的記事(Journal)檔案去記錄,靠使用 Linux AIO 或是 Java NIO. 
從官網的部落格看到是用 Linux libaio,直接用Linux 核心的 DMA, 直接寫入 DMA (Direct Memory Access) Buffer ,而不是傳統的CPU Copy,也就是說不透過CPU 獨立地直接快速讀寫系統記憶體。然後儲存在檔案上。有關 Linux AIO IBM 有個文章寫得非常好 ,大家可以進去看看,因為我還是喜歡以 Java 與 J老板為主,因此就不多做說明了。

HornetQ 每次都會把送進來的訊息儲存在記事(Journal)檔案裡面,記事(Journal)檔案是許多事先配給的檔案。每個檔案的大小都可以剛好放在硬碟磁柱上。(大多時候都是 10 MiB, 但是可能會因為你使用的系統而有些不同)。為了要減少磁碟的控制,浪費效能,只能往這些記事(Journal)檔案加入內容,而且永遠只加在現在使用的檔案上。

就算刪除也只是在檔案的最後加上一個刪除的紀錄,系統會看這些刪除的紀錄,如果檔案裡面的資料都被記錄刪除了,這個檔案就可以被重複使用了。 這些記事(Journal)檔案也可以支援交易,要所有的交易內容都完成寫在disk上了,它才會認為commit. 

而讀取這些檔案的方式有兩種: NIO 與 AIO

NIO 是一個Java 的快速存取方式,盡量避免磁碟的移動。如果你用的系統不是 Linux 或是 Libaio, HornetQ 內間就是用這個純 Java 的方法拉!

AIO 可以透過 JNI 與 Linux對話。直接將訊息的bytecode透過libaio 的 aio_write 寫到磁碟裡面,然後就等待Call back回傳。 而且寫這些訊息都是開多條平行執行的Thread (執行緒) 去寫,以前每寫一個進磁碟都要等待sync候才能繼續,這樣太慢了。用平行與 call back 的方式才可以完全利用系統的效能到極限。



至於檔案的極限,只要你的硬碟夠大,HornetQ都…

JEAP 6 - Migration 到JBoss EAP 6 的注意事項

暫時一些遇到的注意事項,以後也會慢慢地補上。
這是從JBoss 文件看到一些內容,把它整理在這裡
===========================================

WebLogic to JBoss

weblogic.xml

Virtual Directories

weblogic.xml 裡面設定<virtual-directory-mapping>,可以讓User可以自訂檔案根目錄的功能,因為這不是JavaEE 的標準,因為隨時可以使用程式或設定達到,所以J老板沒有特別去支援這個功能。但如果你不幸使用到了這個功能,大概也只有以下三種方式 乖乖的把檔案copy到你的應用程式裡面如果是用 Linux or Unix 的話,可以設定 symbolic links (symlinks) 到你想聯結的目錄(注意,目前僅EAP 6.1.0 以上支援,且必須在 jboss-web.xml 裡面加上
symbolic-linking-enabled 為 true)把檔案放到前端的 web server然後連結到 JBoss
WebLogic 自定的 Annotations WebLogic 有自己的 servlet 跟 filter 的annotations.但因為這不是Java EE 的標準。請直接把這個換掉吧! WebLogicJava EE 6 EquivalentJava EE 6 Import@WLServlet@WebServletjavax.servlet.annotation.WebServlet@WLFilter@WebFilterjavax.servlet.annotation.WebFilter@WLInitParam@WebInitParamjavax.servlet.annotation.WebParam
EJB 3 我不想寫EJB2, 如果你是用EJB 2 ,那我真的建議你整個改寫吧,不管是效能上,還是可維護的程度上都不可以比的!所以拜託!先做 EJB 2 到 EJB 3的 migration吧。 EJB 的寫法,請到這裡參考。 唯一要注意一下的部分反倒是 EJB Client 呼叫的時候,要稍微注意一下API。 裡面用 Context.INITIAL_CONTEXT_FACTORY 跟 Context.PROVIDER_URL…