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

[Design of JBossCache] - Re: Need to make enhacements to CacheListener API

by manik.surtani＠jboss.com

1. Even with using a thread pool, notifications for each call or transaction are performed by the same thread (see Notifier.invokeQueuedNotifications()) - a single Runnable is used to loop thru all registered listeners, for all registered notification events. So you will get pre and post events in order, and not concurrently. 2. Hmm, this could be a useful callback - txStarted, txCommitted, txROlledBack (with a Transaction object passed in? Is this useful?) Can't help but feel we're reinventing something here though. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4054725#4054725 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4054725

18 years, 9 months

1
0
0 / 0

[Design of JBossCache] - Need to make enhacements to CacheListener API

by jason.greene＠jboss.com

Do to the recent changes we made with CacheListener behavior I need to refactor the POJO notification implementation. In order for me to deliver reliable detach and collection remove notifications, I have to do some advanced state tracking. To do this I need to know two things: | * Correlate pre and post requests - Since concurrent requests can be delivered from different transactions/threads I might associate the wrong requests. So I need a tx id with every notification. | | * TX end notification - I need to track all changes of a certain type within the lifespan of a TX (since a single pojo operation is always multiple cache operations, and thus always in a transaction) | -Jason View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4054724#4054724 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4054724

18 years, 9 months

1
0
0 / 0

[Design of JBoss Profiler] - Re: JBoss Profiler and EJB

by clebert.suconic＠jboss.com

There is no difference in usage between a web application and an enterprise java beans. A profiler just captures method invocations from the JVM and translate thos invocations as information. When you profile an EJB you will see your invocation going through proxies and that kind of thing. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4054720#4054720 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4054720

18 years, 9 months

1
0
0 / 0

[Design of JBoss Portal] - missing getter/setter in CASAuthenticationValve

by advaittrivedi

Hi, In 2_6_CAS_Integration branch of jboss portal, CASAuthenticationValve has casServiceUrl, for which getter/setter are missing. It allows us to route user to service url after authentication. Due to this, even if i put casServiceUrl in context.xml it was not taking effect. I have added them in local copy, and tested, and it is working, is this issue known? How can i submit the fix? I think author of this class is Sohil Shah. Should i mail him the fix directly? Or somebody who can commit, can make this chage, just need to add getter/setter for casServiceUrl in CASAuthenticationValve. Thanks & Regards, Advait Trivedi View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4054719#4054719 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4054719

18 years, 9 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: DB performances for large number of messages

by timfox

One other thing you should think about is your application design. In general, high volume data is *not* persistent. E.g. market data feed where messages are shot out very fast with low latency, and the application is designed to cope with loss of messages. If it doesn't get a particular message, that's fine it will get another one shortly whose result (the price) will override the previous one anyway. Quite often you can "design out" persistence at the application level. If your data is non persistent then the system will be able to handle much larger volumes and wil scale much better since it doesn't have to persist through the bottleneck - the database. So I'd ask the question - does the data really need to be persistent? How long do your messages live for? Perhaps you could explain your use cases in more detail? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4054653#4054653 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4054653

18 years, 9 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: DB performances for large number of messages

by timfox

Yes, this is all in the roadmap. Please take a look at JIRA. Different persistence managers for different destinations: http://jira.jboss.com/jira/browse/JBMESSAGING-373 Also the following are of interest: http://jira.jboss.com/jira/browse/JBMESSAGING-406 http://jira.jboss.com/jira/browse/JBMESSAGING-574 If you want to volunteer for 373 then be my guest :) It will help it to get done quicker View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4054651#4054651 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4054651

18 years, 9 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Refactoring access to JBPM database

by tom.baeyens＠jboss.com

castor uses a jdbc connection, right ? then why don't you just leverage a single JDBC connection and give that to jbpm and castor. i can't see why would would like to go through all the trouble of trying to implement a new persistence layer on jbpm. i think such tasks are very easy to underestimate and they don't bring value. don't focus too much on simplifying your application architecture. focus on what gives you robust and proven software solutions. your overview schema might become a bit more scattered, but you'll save a heck of a lot of time to go to the beach and the result will be a lot less buggy. that's just my free advice. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4054634#4054634 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4054634

18 years, 9 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: security in the console

by tom.baeyens＠jboss.com

i also removed the comments in the web.xml about the security warning around the gpd deployment servlet. that should be in the documentation, i think. in 3.2.1 it's doing to take to long to fix this as we would have to fork and make a new release of the old designer. so in 3.2.1, i still want an open gpd deployment servlet and a warning is most appropriate in the release notes, i think. then in 3.2.2, i want the GPD to add authentication info to the request that uploads the servlet and the servlet should be secured. then, users can control the authorization by just logging into the webapp and removing the gpd user. this plays out nicely with the users on the login page. cause when people remove the users, then nobody will be allowed to upload a new process definition. btw, it would be good if you could add minimal documentation for the console in the user guide. 2 or 3 pages is already a good start. it could cover deployment and usage. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4054626#4054626 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4054626

18 years, 9 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - DB performances for large number of messages

by garu

Hi all, i'd like to discuss about db organization because i'm concerned that with actual db structure, messaging won't be able to handle the volume of data i'm going to pump within it. More generally speaking i think messaging in its actual incarnation is not well suited to handle large volume data. In a few words i need messaging to become a sort of multiplexer that taking messages from a single source should be able to distribute them to different subscribers. Of these subscribers one will always be active and the others (at least two but could be more) will be active only when needed. This means that i have to guarantee that messages on topics are persisted until the subscribers read them or a certain amount of time has passed. No problem until now, but i have to handle tenth of topics and hundredth million messages a day. It's not a problem of data size, the average message size is less than 200 byte, but just of number of messages. Actually, if i din't miss something, all messages for all queues/topics are handled with only two tables jbm_msg and jbm_msg_ref and this is the limit. I don't know how experienced you are about dbms but i know by experience that doesn't matter what dbms engine you have under the cover, when a table begin to fill with tenths or hundredths millon rows, performances go down the kitchen sink. Now we have a legacy system (non jms, just C programs) that, to avoid performance bottlenecks, divide the message flows in different tables so that each table (partitioned tables) can remain low volume in terms of rows number and insert time can remain low, but to obtain the same subdivision i'd need a messaging instance for each flow. If i'd try to propose such an architecture, i'd be killed on place! Obviously i'm not thinking of a single instance to handle the whole data flow, it would be unsafe to say the least, but on the other side i cannot think to have an instance for each flow. What i'm thinking about and are proposing is a system by which when you deploy a queue/topic you can ask that the queue/topic be allocated on a different tables set than the default one. This means that choosing the queue/topic where i send i implicitly choose the tables where messages are written, allowing for performances tuning for large number of messages. I'd like to know you opinion about that. Thanks, Gabriele View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4054623#4054623 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4054623

18 years, 9 months

1
0
0 / 0

[Design of JBoss jBPM] - security in the console

by tom.baeyens＠jboss.com

i think it is a plus that the webapp can also work without security. but i would like the security to be reinstalled in the console by default. also we should make sure that there is a user for each role: admin, user and manager. only that way we can add some scenarios in the documentation, movies or tutorials and show how the console presents itself to those roles and in those scenarios. especially the task list feature is something that we can't show properly if users don't need to log in. the way i interpreted the feedback of the se's that we should add more focus to admins, not limit the console to administrators as seems to be the case now. i think that exposing the usernames and passwords on the home page is good. then it's good for evaluation purposes. and also people know immediately that you can't put this into production as is. with the god identity management UI that you've added, people can easily delete all users and avoid that security risk. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4054622#4054622 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4054622

18 years, 9 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 June 2007