July 2008 - jboss-dev-forums - Jboss List Archives

[Design of POJO Server] - Re: Making Creators declare supported annotation types

by alesj

"emuckenhuber" wrote : | Which represents the set of annotations for each Creator... | e.g. the EjbJar30Creator would return @Statful, @Stateless and @MesageDriven as TypeAnnotation and null for Method and Field annotations. | Currently JBoss50Creator returns just this: | 2008-07-30 19:55:50,468 TRACE [org.jboss.deployment.OptAnnotationMetaDataDeployer] (RMI TCP Connection(4)-127.0.0.1) Creator: org.jboss.metadata.annotation.creator.ejb.jboss.JBoss50Creator@b9fa3b, type annotations: [interface org.jboss.ejb3.annotation.Consumer, interface javax.ejb.Stateless, interface javax.ejb.MessageDriven, interface javax.ejb.Stateful, interface javax.ejb.ApplicationException, interface org.jboss.ejb3.annotation.Service] | which I think is not enough, e.g. missing @Local for local business interfaces. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4167705#4167705 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4167705

16 years, 5 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: LinkedList Factor on the Journal...

by clebert.suconic＠jboss.com

"gozilla" wrote : "timfox" wrote : Yes this is a known issue. If you have messages hanging around in a destination for a long time, then sure, they'll stop the file from being reclaimed. | | | | Although I'm not convinced this is a major problem, more of an edge case. | | My point was that having message hanging around in destinations for "long" time is happening frequently with a sized installation. | | Francois I added a patch with a proposed fix on https://jira.jboss.org/jira/browse/JBMESSAGING-1342 We should do it before Beta. Just the fact of having Messages on DLQ for instance would break reclaiming at the moment. So I think it is a major issue. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4167704#4167704 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4167704

16 years, 5 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: LinkedList Factor on the Journal...

by gozilla

"timfox" wrote : Yes this is a known issue. If you have messages hanging around in a destination for a long time, then sure, they'll stop the file from being reclaimed. | | Although I'm not convinced this is a major problem, more of an edge case. My point was that having message hanging around in destinations for "long" time is happening frequently with a sized installation. Francois View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4167702#4167702 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4167702

16 years, 5 months

1
0
0 / 0

[Design of POJO Server] - Re: ProfileService equiv to ServiceBindingManager

by adrian＠jboss.org

"bstansberry(a)jboss.com" wrote : but is there any re-usable code in the MC that deals with any of this (e.g. some java beans that encapsulate parameterType and valueType). The logic for doing this should be either in one of the static methods in the Config helper class or one of its wrapper such as ClassInfo/BeanInfo. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4167689#4167689 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4167689

16 years, 5 months

1
0
0 / 0

[Design of POJO Server] - Re: ProfileService equiv to ServiceBindingManager

by bstansberry＠jboss.com

"bstansberry(a)jboss.com" wrote : 3) Add support for value-factory to the JMX config. Not sure what that entails. Been looking into this, i.e. how it's done for "inject" handling. That seems straightforward enough. The complexity with value-factory comes with parameter handling; matching types to overloaded signatures etc. That can be coded simply enough, but is there any re-usable code in the MC that deals with any of this (e.g. some java beans that encapsulate parameterType and valueType). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4167687#4167687 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4167687

16 years, 5 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: LinkedList Factor on the Journal...

by clebert.suconic＠jboss.com

"gozilla" wrote : Tim, | | Sadly enough, this is not an edge case: when you have a decently sized messaging server, you have easily thousands of destinations used by hundreds of apps. | | We had cases that apps used our MQ server to talk to some batch jobs, which were only triggered once a day. | | Cheers, | | FranÃÂ§ois Francois (user gozilla), The case of many files would be a side effect of one of my suggestions to fix the problem, which I used as an argument to suggest II. That's not a real problem. We already support many destinations without any problem. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4167686#4167686 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4167686

16 years, 5 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: LinkedList Factor on the Journal...

by timfox

I don't understand your point, we can support many hundreds and thousands of destinations. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4167681#4167681 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4167681

16 years, 5 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: LinkedList Factor on the Journal...

by gozilla

Tim, Sadly enough, this is not an edge case: when you have a decently sized messaging server, you have easily thousands of destinations used by hundreds of apps. We had cases that apps used our MQ server to talk to some batch jobs, which were only triggered once a day. Cheers, FranÃ§ois View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4167677#4167677 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4167677

16 years, 5 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: LinkedList Factor on the Journal...

by timfox

Yes this is a known issue. If you have messages hanging around in a destination for a long time, then sure, they'll stop the file from being reclaimed. Although I'm not convinced this is a major problem, more of an edge case. In later JBM versions, we should probably remedy this by adding compacting to files to. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4167657#4167657 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4167657

16 years, 5 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: LinkedList Factor on the Journal...

by clebert.suconic＠jboss.com

Few solutions I have thought for this: I - Separate CurrentFile by Destination type. We would add/delete records per destination. We would still be able to commit without a problem I have written this code already, and it has one side effect. If the customer has 1000 lazy destinations you will have 1000 opened files, what is not possible on AIO. II - Separate CurrentFile by Destination speed. We could have a destination configured as Lazy, what would keep records in separate. We would still be able to commit without a problem, as any commit record aways carries the filesIds and number of elements used. This would use the code I already wrote on (i). III - Depending on the number of dependencies found on Reclaiming, we could start a FullReclaiming logic (think of a fullGC) that would move records around, facilitating how the files are reclaiming. This has performance implications. It's listed here just as a brain storm. I think option II would be a reasonable one. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4167655#4167655 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4167655

16 years, 5 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums July 2008