June 2009 - jboss-dev-forums - Jboss List Archives

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Journal Cleanup and Journal Compactor

by clebert.suconic＠jboss.com

Also: It looks like Compacting will be a heavier process thatn what Cleanup would be. If we have both solutions in place. Cleanup would save a few compactations giving a performance boost. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4236501#4236501 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4236501

16 years, 6 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Journal Cleanup and Journal Compactor

by clebert.suconic＠jboss.com

As documented, and as all the JBM developers known, the journal is append-only. When we delete a record we actually append a delete record. When every record of a file has a delete somewhere else, that file is marked as reclaimable. It could then be reused or deleted depending on the number of files in use. However, there is an issue when a record is not deleted. Say..the consumer will need a couple days to come and consume his messages. (DLQs... or I could list a few usecases for this) If a file has any number of records that will never or take a long time to be deleted, the relationship between files will create what I called the "linked-list-effect" on the journal. You would have something like: JournalFile 1: - Add Record1 - AddRecord2 JournalFile 2: - DeleteRecord2 - AddRecord3 JournalFile 3: - DeleteRecord3 - AddREcord4 .... JournalFile 1000: - DeleteRecord 1000 - AddRecord 10001 We need to somehow remove the dependencies between the files for when this happens. My current suggestion is to Update JournalFile1, in a way you don't need any records from other files to process the delete. (I call this as journal cleanup). So you would have: JournalFile 1: - Add Record 1 - AddRecord 2 (XXXXX... removed .... XXXX) By doing this.. you are ready to delete 999 files that were dependent on the JournalFile1. There is another problem also. Say.. that you now have 100 records pending.. but one record on each journal File. You would be using 1GiB of your disk to store about just 10KiB of real data. For that I would need to compact all the 100 records in a single journal-file and saving space this way. (I call this as journal compacting). You may think that journal compacting would solve cleanup, but there are a few tricky situations: I - you may need to move more data than required. II - It doesn't solve the linked-list effect. As soon as you compact, the records will still be there. The linked-list effect will happen again for sure. You are in an infinite loop of compacting.. compacting.. compacting. So.. my conclusion: Both solutions are equally necessary. I - We need to fix the linked-list effect anyway. If not by updating the file.. we need to find some other way. II - We need to fix the compacting issue. It's not acceptable having 1GiB View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4236498#4236498 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4236498

16 years, 6 months

1
0
0 / 0

[Design of JBoss Wiki] - Re: Architecture questions

by piergiorgiolucidi

I have tried to move this properties settings from internal properties file to the portlet.xml, but it is not easy to implement. Some Wiki classes are singletons and it was loaded for first by the classloader, I'm considering the potential useful of a Spring implementation. But I think that before to start to do a similar implementation I need to refactor some source code parts to make more easy the development process. I'll update you on this as soon as possible. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4236479#4236479 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4236479

16 years, 6 months

1
0
0 / 0

[Design of JBossCache] - Re: Evolution of TcpDelegatingCacheLoaders/TcpCacheServers

by galder.zamarreno＠jboss.com

Following on what Manik said, for the Infinispan 4.1.0 release, we're gonna providing a client/server module, see https://jira.jboss.org/jira/browse/ISPN-29 If you're interested in helping out in any way, please let us know. We'll be discussing it in the https://lists.jboss.org/mailman/listinfo/infinispan-dev pretty soon! :) View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4236474#4236474 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4236474

16 years, 6 months

1
0
0 / 0

[Design of JBoss jBPM] - Status / Documentation of gwt-console & report-server

by camunda

Hi! Maybe I just overseen is, but I search for docs, what the gwt-console is able to do (mycurrent installation doesn't do much, I am not sure if I have a installation/user rights problem or if it is just the current status), how I incorporate task forms in it and how I can access the BIRT report server. In the current user/developer docs I haven't found and the wiki seems not to be up to date. If there is no doc, no problem, I will figure that out myself. I just wanted to ask not that I oversee the easy way and save time by this :-) Cheers Bernd View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4236469#4236469 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4236469

16 years, 6 months

1
0
0 / 0

[Design of JBoss ESB] - Re: JBoss Remoting Gateway using bogus HttpMarshaller?

by Kevin.Conner＠jboss.com

Okay, so it sounds as if we should stick with what we currently have until the remoting guys fix it. Why is this an issue now? Why has it come up? Kev View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4236453#4236453 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4236453

16 years, 6 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Unused branches

by clebert.suconic＠jboss.com

I still need BRANCH_JBMESSAGING_1427. I will delete it as soon as I complete the task. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4236442#4236442 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4236442

16 years, 6 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Unused branches

by timfox

There are still two branches you created there, please remove them if they are not needed View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4236395#4236395 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4236395

16 years, 6 months

1
0
0 / 0

[Design of JBoss ESB] - Re: JBoss Remoting Gateway using bogus HttpMarshaller?

by tfennelly

Yeah... that comment would explain that class's handling of the byte[], which was what the class was originally created for. I found out why I added the "special" handling of the InvocationResponse. There's a comment on one of the linked JIRAs on the second commit re the webserive-producer quickstart not working. I tested it out after removing the "special" handling of the InvocationResponse and sure enough, it breaks. The reason is as follows.... The JBoss Remoting HttpClientInvoker uses the HTTPUnMarshaller class to read and decode the response stream (which will be an InvocationResponse when a Remoting Client calls a Remoting Server). Problem is that the HTTPUnMarshaller only uses the Content-Type header to decide whether or not to delegate to the SerializableUnMarshaller (it handles InvocationResponses) to decode the stream. When something on the server side sets the content type to a non-Binary type (e.g. text/xml as with the SOAPProcessor), the HTTPUnMarshaller decides to just read the stream as a raw stream of bytes. This explains why I added the Special handling of the InvocationResponse in the HttpUnmarshaler. It was an invalid fix however IMO. The real issue is with JBR and it's handling of http and InvocationResponse. If JBR Server is going to wrap responses for JBR Clients, then it is effectively changing the content type, in which case it should reset the content type to octetstream (or whatever) in the response and store the original content type somewhere on the InvocationResponse and use it after unwrapping on the client side. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4236394#4236394 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4236394

16 years, 6 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Unused branches

by clebert.suconic＠jboss.com

I see that you already deleted them... Thanks View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4236393#4236393 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4236393

16 years, 6 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums June 2009