|
From: Ronald v. K. <rv...@ab...> - 2003-11-06 10:27:43
|
My comments on 1 and 2:
1: Yes, Implementing such an interface would be great and that is just
what I did once before (but lost due to a system crash). I made an
interface DbConnectionPool and had both the original hermes
DbConnectionPool (renamed to DbConnectionPoolHermes) and a
DbConnectionPoolAppServer implement this interface. Via a property in de
config file I could switch from one to the other. Things I'd like to see
for this are:
- a DbConnectionPool interface
- a separate config file for the hermesconnectionpool
- Have the MessageServiceHandler not use the instance variables of the
connectionpool and generate an xml document or use it for debug output
but have the connectionpool generate such a document/output.
In fact, I thinkh we should put all the persistency things in a nice
layer in it's own package, including the file persistency, transaction
things etc..Transaction handling btw could (should?) also be
standardized and so it uses the mechanisms available in app-servers and
Tomcat / Jetty plus (JTA/JTS)
2: The example DbConnectionPool that I have now (a little different than
the one I attached to one of the previous e-mails) works on both JBoss,
Tomcat, Bea and tonight I'll try Jetty plus. So there is no real
specific code in there. The app-server dependend issues will be in the
server specific deployment descriptos, if needed at all.
Regarding the Weblogic cluster question. I have a cluster available and
could give it a try comming weekend. One of the (major) issues I expect
is locking. Hermes requires file access for persistency and thus both
servers need to have access to the same filesystem while locking is
implemented in a non-cluster aware transaction mechanism.
Ronald
-----Oorspronkelijk bericht-----
Van: Bob Koon [mailto:py...@ce...]
Verzonden: donderdag 6 november 2003 7:25
Aan: ebx...@li...
Onderwerp: Re: [ebxmlms-general] freebXML MSH Scalability
No... I haven't tried it out... I just think about the followings:
1) If I get it right, I should make a interface for accessing resource,
like JDBC, JMS and files, and make this customizable to allow user to
implement it through JNDI? (I guess some non-enterprise people may just
use Hermes without JNDI instead)
2) Does the JNDI interface quite standardize for different app. server
like Tomcat, weblogic, etc? You know, although j2ee is quite standard,
developing j2ee will also be dependent to the app. server.
Regards,
Bob Koon
Tripathi, Ajit (GXS) wrote:
Bob,
In an enterprise scale situation, not just connection pools, any
external resources - datasources (and JMS queues/connection factories in
the future... if JMS) should ideally be obtained via the app server's
JNDI enc. That will help developers use the app server's scalability
features.
Has anyone experimented with deploying hermes in a weblogic cluster
yet?
regards,
Ajit
-----Original Message-----
From: Bob Koon [ mailto:py...@ce... <mailto:py...@ce...>
]
Sent: Thursday, November 06, 2003 11:22 AM
To: ebx...@li...
<mailto:ebx...@li...>
Subject: Re: [ebxmlms-general] freebXML MSH Scalability
I am very sorry that I cannot understand the relation between using app
servers' database connection pool and scalability.
As I know, Hermes use its own database connection pooling and what's the
different of this with using app. server's database connection pool?
I can see that different app. server use different database connection
pool, and those interface are very different. So we need to provide
different "war" for different app. server, which make the deployment
difficult, isn't it?
I am very sorry that I don't have enough experience to make things
scalable, therefore if I have some mis-understandings, please point me
out.
Regards,
Bob Koon
Tripathi, Ajit (GXS) wrote:
Ronald,
I too am unfamiliar with administered db connections pools on tomcat
4.x. How does that work?
If Hermes can use connection pools on app servers/weblogic, that would
help the eventual scalability objective.
BTW... why can't authentication also be managed by the server using
JAAS? Consider that.
However, in that case, the db connection pool will need to be
configurable in the deployment descriptor for hermes... wherever.
regards,
Ajit
-----Original Message-----
From: Bob Koon [ mailto:py...@ce... <mailto:py...@ce...>
]
Sent: Wednesday, November 05, 2003 3:04 PM
To: ebx...@li...
<mailto:ebx...@li...>
Subject: Re: [ebxmlms-general] freebXML MSH Scalability
see comment inline.
Ronald van Kuijk wrote:
Ajit,
Regarding point 2, I've already tried once to implement this and it
works. Since all j2ee servers support this and even tomcat and jetty
have connectionpool mechanisms, I'm all in favour of using that what is
provided with the appserver/servlet enginge. What I did not try is to
make it configurable to be able to use both solutions. This would
require a DBConnectionPoolInterface. Since hermes uses a combination of
a connection pool and some direct connections, getRawConnection(), I
mapped the implementation of these methods to the connectionpool.
I am sorry that I am not familar with it. I would like to ask the use on
using connection pool on tomcat/jetty. Is this connection pool just a db
connection pool or it is another thing?
Another thing I was looking at was a real persistency layer (in it's own
package?) as interfaces which would make it possible to also store the
messages in the database as blobs (our ASP does not allow us to store
'things' in a filesystem).
In fact on the design work on Hermes 1.0, we are trying to make a
generalize flow of receiving messages and send messages. Then for each
items on the flow, customization can be done (so persistence part can
also be customized). However the design is in very early stage and I
cannot provide more information on it yet (I can only say that there are
many changes on 1.0)
Unfortunately I had a major system crash and lost all of this code and
did not start over again...
Failover is also not possible (i think) since the message sending
threads (for retries etc) are created on a restart of the server, so if
one crashes you have to restart the other to have it pick up the
messages.
One of the other things (for us) is centralized authentication using an
ldap server where we can manage all users/clients/systems that have
access to the server. I'd like an abstraction layer for this to so we
can implement something that uses the authentication of the application
server / servelet engine (e.g. through jaas)
For this one, I have to do some investigation, because I am also not
familiar with it too.
Ronald
-----Oorspronkelijk bericht-----
Van: Tripathi, Ajit (GXS) [ mailto:Aji...@gx...
<mailto:Aji...@gx...> ]
Verzonden: maandag 3 november 2003 11:06
Aan: ' ebx...@li...
<mailto:ebx...@li...> '
Onderwerp: [ebxmlms-general] freebXML MSH Scalability
Hi,
Hermes MSH is essentially a JAXM servlet with a lot more behind it.
My question is - how does/would hermes scale w.r.t messaging
requirements?
1. Can hermes use administered components such as datasources,
connection pools etc (other than hermes' native connection pools).
2. What conversational state is preserved in a servlet instance of
hermes MSH? Can different instances of Hermes MSH share the same
underlying resources?
3. What are the other key considerations w.r.t deploying hermes MSH
in an app server ( e.g. weblogic) cluster?
Has someone experimented with this?
regards,
Ajit
-----Original Message-----
From: Patrick Yee [ mailto:kc...@ce...
<mailto:kc...@ce...> ]
Sent: Thursday, October 30, 2003 7:47 PM
To: ebx...@li...
<mailto:ebx...@li...>
Subject: Re: [ebxmlms-general] SMTP Port not configurable
Ajit,
Ooops.. you are right. We will include it in our next release. Thanks
for your suggestion.
Regards, -Patrick
By the way, why is the SMTP port not configurable in
msh.properties.xml?
<SMTP>
<Host>localhost</Host>
<User>ajitkt</User>
<Password>nainital</Password>
</SMTP>
|