[EJB 3.0] - Re: History Interceptor
by dhartford
Hi jc,
I have not thought about the array scenario...I would imagine that if it is in a relation with another table/entity and both marked for History, it would somehow handle both scenarios.
I know the previous 'Audit' implementation and the 'History' implementation from hibernate both follow a logging approach of just what has changed. I was looking for a more detailed 'History' so that you could get the state of the data during a specific time.
*particularly useful for applications with, say, Jboss Rules and testing retroactive changes.
*Although logging is more efficient space-wise, researching the 'state' of the data during a specific time is more processor and labor efficient if captured in its full state. However, if a mechism was in place to retrieve the entire entity state from just the logged changes, that would be wonderful.
I would be interested in feedback and comments.
not very interesting example:
| Address
| clientId|street|city|state|zip|timestamp
| 32|44 roy drive apt 2|bumsville|ZZ|99999|apr 06
|
| AddressHistory
| autoId|clientId|street|city|state|zip|timestamp
| 1|32|345 summerville road|bumsville|ZZ|99999|jan 04
| 2|32|44 roy drive apt 1|bumsville|ZZ|99999|feb 06
|
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3993383#3993383
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3993383
19 years, 4 months
[Clustering/JBoss] - Re: Clustering NOT working on physical separate boxes.
by rajeshchande
Hello Brian,
As suggested I tried changing the PING and GMS parameters as below in both cluster-service.xml and tc5-cluster-service.xml, keeping other things as before:
<config>
| <UDP bind_addr="172.17.132.140" mcast_addr="228.8.8.8" mcast_port="45577"
| .....
| ... />
| <PING timeout="300000" num_initial_members="3"
| up_thread="false" down_thread="false"/>
| ....
| <pbcast.GMS join_timeout="50000" join_retry_timeout="2000"
| shun="true" print_local_addr="true"/>
| .....
| </config>
The nodes (devl-01 and devl-03)on different servers still dont join each other. Instead the merging also is now not happening after the above changes.
The outputs from each of them is as follows:
output from devl-01 on server-1:
12:14:28,366 INFO [ChannelSocket] JK: ajp13 listening on /0.0.0.0:53041
| 12:14:28,395 INFO [JkMain] Jk running ID=0 time=0/82 config=null
| 12:14:28,414 INFO [Server] JBoss (MX MicroKernel) [4.0.3SP1 (build: CVSTag=JBoss_4_0_3_SP1 date=200510231054)] Started in 10m:45s:134ms
| 12:40:29,541 INFO [TreeCache] viewAccepted(): new members: [server-1-bak:52692, 172.17.132.140:60857]
| 12:51:11,194 WARN [CoordGmsImpl] merge responses from subgroup coordinators <=1 ([sender=server-1-bak:52680 (additional data: 18 bytes), view=[server-1-bak:52680 (additional data: 18 bytes)|0] [server-1-bak:52680 (additional data: 18 bytes)], digest=[server-1-bak:52680 (additional data: 18 bytes): [0 : 4]]).Cancelling merge
| 12:51:53,440 ERROR [CoordGmsImpl] merge_id ([server-1-bak:52680 (additional data: 18 bytes)|1166010661184]) or this.merge_id (null) == null (sender=172.17.132.140:60847 (additional data: 18 bytes)).
output from devl-03 on server-2:
12:25:49,163 INFO [Server] JBoss (MX MicroKernel) [4.0.3SP1 (build: CVSTag=JBoss_4_0_3_SP1 date=200510231054)] Started in 11m:4s:198ms
| 12:40:29,540 INFO [TreeCache] viewAccepted(): new members: [172.17.132.70:52692, server-2_b:60857]
| 12:56:12,328 WARN [NAKACK] [server-2_b:60847 (additional data: 18 bytes)] discarded message from non-member 172.17.132.70:52680 (additional data: 18 bytes)
| 12:56:12,333 WARN [NAKACK] [server-2_b:60847 (additional data: 18 bytes)] discarded message from non-member 172.17.132.70:52680 (additional data: 18 bytes)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3993375#3993375
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3993375
19 years, 4 months