Menu
▾
▴
ebxmlms-general — General discussions
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
(20) |
Nov
(11) |
Dec
(27) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(11) |
Feb
(8) |
Mar
(17) |
Apr
(11) |
May
(9) |
Jun
(30) |
Jul
(18) |
Aug
|
Sep
(4) |
Oct
(34) |
Nov
(83) |
Dec
(28) |
| 2004 |
Jan
(4) |
Feb
|
Mar
(13) |
Apr
(20) |
May
(4) |
Jun
(26) |
Jul
(5) |
Aug
(2) |
Sep
(3) |
Oct
(7) |
Nov
(10) |
Dec
(24) |
| 2005 |
Jan
(7) |
Feb
(44) |
Mar
(9) |
Apr
(16) |
May
(9) |
Jun
(64) |
Jul
(48) |
Aug
(36) |
Sep
(27) |
Oct
(24) |
Nov
(20) |
Dec
(11) |
| 2006 |
Jan
(12) |
Feb
(13) |
Mar
(7) |
Apr
|
May
(16) |
Jun
(5) |
Jul
(2) |
Aug
(7) |
Sep
(19) |
Oct
(5) |
Nov
(9) |
Dec
(13) |
| 2007 |
Jan
(21) |
Feb
(12) |
Mar
(6) |
Apr
|
May
(2) |
Jun
(14) |
Jul
(1) |
Aug
(1) |
Sep
(1) |
Oct
(1) |
Nov
|
Dec
|
| 2008 |
Jan
|
Feb
(1) |
Mar
(2) |
Apr
(5) |
May
(2) |
Jun
(1) |
Jul
(6) |
Aug
|
Sep
(9) |
Oct
(3) |
Nov
(25) |
Dec
(32) |
| 2009 |
Jan
(11) |
Feb
(12) |
Mar
(18) |
Apr
(19) |
May
(31) |
Jun
(23) |
Jul
(35) |
Aug
(7) |
Sep
(2) |
Oct
|
Nov
|
Dec
(8) |
| 2010 |
Jan
(3) |
Feb
(3) |
Mar
(3) |
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
(1) |
Sep
(1) |
Oct
(1) |
Nov
|
Dec
|
| 2013 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2016 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Robert A. S. <ro...@no...> - 2005-06-22 22:08:45
|
After several more hours of testing and packet sniffing - it looks like
Hermes bombs out anytime a server tries to switch to SSL v3... How do I =
get
Hermes to connect to a SSL3 server? It seems like it tries to use TLS
protocol because it doesn=92t support SSL3?????
PLEASE help - I really want Hermes to work????!
From packet sniffer: (192.168.20.165 =3D Hermes, 192.168.10.101 =3D =
Cyclone)
--------------------------------------------------------------
No. Time Source Destination Protocol
Info
34 9.128011 192.168.20.165 192.168.10.101 TCP
1453 > https [SYN] Seq=3D0 Ack=3D0 Win=3D65535 Len=3D0 MSS=3D1460
36 9.197628 192.168.10.101 192.168.20.165 TCP
https > 1453 [SYN, ACK] Seq=3D0 Ack=3D1 Win=3D16560 Len=3D0 MSS=3D1380
37 9.197767 192.168.20.165 192.168.10.101 TCP
1453 > https [ACK] Seq=3D1 Ack=3D1 Win=3D65535 [TCP CHECKSUM INCORRECT] =
Len=3D0
38 9.199660 192.168.20.165 192.168.10.101 SSLv2
Client Hello
39 9.293068 192.168.10.101 192.168.20.165 TLS
Server Hello, Certificate, Certificate Request, Server Hello Done
40 9.484113 192.168.20.165 192.168.10.101 TCP
1453 > https [ACK] Seq=3D101 Ack=3D1323 Win=3D64213 [TCP CHECKSUM =
INCORRECT] Len=3D0
41 9.498985 192.168.20.165 192.168.10.101 TLS
Certificate, Client Key Exchange
42 9.512283 192.168.20.165 192.168.10.101 TLS
Change Cipher Spec
43 9.540430 192.168.20.165 192.168.10.101 TLS
Encrypted Handshake Message
44 9.601759 192.168.10.101 192.168.20.165 TLS
Alert (Level: Fatal, Description: Handshake Failure)
45 9.602017 192.168.10.101 192.168.20.165 TCP
https > 1453 [FIN, ACK] Seq=3D1330 Ack=3D247 Win=3D16560 Len=3D0
46 9.602096 192.168.20.165 192.168.10.101 TCP
1453 > https [ACK] Seq=3D290 Ack=3D1331 Win=3D64206 [TCP CHECKSUM =
INCORRECT] Len=3D0
47 9.602259 192.168.20.165 192.168.10.101 TCP
1453 > https [FIN, ACK] Seq=3D290 Ack=3D1331 Win=3D64206 [TCP CHECKSUM =
INCORRECT]
Len=3D0
48 9.602378 192.168.10.101 192.168.20.165 TCP
https > 1453 [RST] Seq=3D1331 Ack=3D3694123473 Win=3D0 Len=3D0
--------------------------------------------------------------
________________________________________
From: Robert A. Stockfleth [mailto:ro...@no...]=20
Sent: Monday, June 20, 2005 3:27 PM
To: 'ebx...@li...'
Subject: SSLHandshakeException (SSL PROBLEM)
Hello, I hope someone out there would be kind enough to help me out =96 =
I have
been struggling with this problem for a couple weeks now.
I am running Hermes 1.0 on a Windows 2003 Server using Java 1.5.0_03
runtime.=A0 Every time I attempt to send a message to =
=93othercompany=94=92s MSH
server (not hermes, Cyclone I think) I receive the =
SSLHandshakeException.=A0 I
have all the necessary trusted certs installed in my cacerts file that
Hermes is using as it=92s TrustedAnchor.=A0 I am able to sign messages =
with the
test09 private key with no problem from the Monitor app.
=93othercompany=94=92s MSH server requires that I send my certificate =
for
authentication.=A0 I have tested the authentication process in a browser =
with
no problems.
I have also tried the 9.31 version of Hermes with the same result.=A0 My
private key originally came in a .pfx file =96 I was able to sign =
messages
from the Monitor application using the .pfx file, but when I put that as =
my
keystore in the config file for SSL, it would always say =93Cannot load =
the
keystore on SSL client authentication : Cannot load keystore : Invalid
keystore format=94.=A0 So I programmatically put the private key into =
the JKS
format.
Is there a good way to debug the whole SSL handshaking process, I=92ve =
seen
posts about "-Djavax.net.debug=3Dall" =96 but can somebody elaborate and =
be more
specific about what I need to do?
Please help =96 I=92ve included as much pertinent information below as I =
can
think of!!!!!!=20
-Rob
-- from log ----------
Add SSL Client Authentication entry : https://othercompany/msh/
\hermes\test.keystore
Sending message to https://othercompany/msh/
Connection class : class
com.sun.net.ssl.internal.www.protocol.https.HttpsURLConnectionOldImpl
Instance of HttpsURLConnection : true
Configuration to a HTTPS connection
use key manager for url : https://othercompany/msh/
[10505] Cannot send SOAP message Exception:
javax.net.ssl.SSLHandshakeException Message: Received fatal alert:
handshake_failure
------------------------------------
-- from config file -------
<SSL>
=A0=A0=A0=A0=A0 <!-- Optional property specifying the implementation =
class name of
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 com.sun.net.ssl.HostnameVerifier from =
JSSE 1.0 which handle the
case
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 when the URL's hostname and the server's =
identification hostname
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 mismatch-->
=A0=A0=A0=A0=A0 <!-- <HostnameVerifier>Verifier</HostnameVerifier> -->
=A0=A0=A0=A0=A0 <TrustedAnchor>
=A0=A0=A0=A0=A0=A0=A0 <!-- Trust keystore for SSL Server Authentication =
-->
=A0=A0=A0=A0=A0=A0=A0 <KeyStore>
=A0=A0=A0=A0=A0=A0=A0=A0=A0 <Path>/hermes</Path>
=A0=A0=A0=A0=A0=A0=A0=A0=A0 <File>cacerts</File>
=A0=A0=A0=A0=A0=A0=A0=A0=A0 <Password>changeit</Password>
=A0=A0=A0=A0=A0=A0=A0 </KeyStore>
=A0=A0=A0=A0=A0 </TrustedAnchor>
=A0=A0=A0=A0=A0 <ClientAuth>
=A0=A0=A0=A0=A0=A0=A0 <URL>https://othercompany/msh/</URL>
=A0=A0=A0=A0=A0=A0=A0 <KeyStore>
=A0=A0=A0=A0=A0=A0=A0=A0=A0 <Path>/hermes</Path>
=A0=A0=A0=A0=A0=A0=A0=A0=A0 <File>test.keystore</File>
=A0=A0=A0=A0=A0=A0=A0=A0=A0 <Alias>test09</Alias>
=A0=A0=A0=A0=A0=A0=A0=A0=A0 <Password>password</Password>
=A0=A0=A0=A0=A0=A0=A0 </KeyStore>
=A0=A0=A0=A0=A0 </ClientAuth>
</SSL>
------------------------------------
-- from keytool ------
D:\jdk1.5.0_03\bin>keytool -list -keystore test.keystore
Enter keystore password:=A0 password
Keystore type: jks
Keystore provider: SUN
Your keystore contains 1 entries
test09, Jun 13, 2005, keyEntry,
Certificate fingerprint (MD5):
5D:69:75:75:7C:6D:4A:E9:C6:82:4B:9F:A8:E6:52:05
------------------------------------
|
|
From: Steven H. <sh...@te...> - 2005-06-21 23:52:22
|
Okay, I didn't want to go into too much detail in my initial post because I was just hoping to feel out if anybody else had had this experience. My gut feel this is a 'hard' problem, and unless it was a known issue, I could be in for some very hard diagnosis in house. For what its worth, we run Oracle 9i Enterprise Edition as our database server Attached are the load graphs for the machine, as you can see, in the last three weeks, things have been kind of quiet, we moved a major (non hermes) related application off the box a few weeks back. The problem occurred during the 'quiet' period. Our operations team assures me nothing was running at that time, and besides, we've never had an incident of delayed queries during database maintenance activities - one of the benefits of Oracle I guess. If there is any information or documentation about the inner workings of Hermes that could be contributed, or any similar experiences that could be shared, that's all I'm really hoping for. Kind Regards Steven Herod -----Original Message----- From: ebx...@li... [mailto:ebx...@li...] On Behalf Of R. van Kuijk (Ronald) Sent: Tuesday, 21 June 2005 2:22 AM To: ebx...@li... Subject: RE: [ebxmlms-general] Again, unreliable execution of message handlers. What db is used? Hsqldb processes all requests sequential, so an export of a db with a large number of records can hold things up quite easily. Ronald -----Oorspronkelijk bericht----- Van: ebx...@li... [mailto:ebx...@li...] Namens David Webber (XML) Verzonden: maandag 20 juni 2005 16:48 Aan: ebx...@li... Onderwerp: Re: [ebxmlms-general] Again, unreliable execution of message handlers. On the serious side - yes - I was thinking the same thing - that maybe some housekeeping / compaction service in the DB server occurred that took ten minutes to complete. DW ----- Original Message ----- From: "Mattias J" <mj...@ex...> To: <ebx...@li...> Sent: Monday, June 20, 2005 10:01 AM Subject: Re: [ebxmlms-general] Again, unreliable execution of message handlers. > Maybe also the RDBMS in use may be relevant? > > At 2005-06-20 15:37, you wrote: > >Steven, > >How many records are there in the database? In particular, how many > >records in mshconfig table? in messagestore table? I am still not sure > >about the reason, just wondering whether the number of records in database > >is one of the factors determining speed or not.. > >Regards, -Patrick > > > > > >Steven Herod wrote: > > > >>About a week ago, we had another incident of message handler not executing > >>on message arrival. > >> > >>In this case however, it wasn't a complete failure, instead, it seemed to > >>take about 10 minutes between hermes receiving the file and the message > >>handler picking it up. > >> > >>Normal behaviour has this occuring within a few seconds, however, in this > >>case, about 10 minute passed before the handler fired. Our messages are > >>time sensitive, so this pushed the response time window outside of normal > >>and raised an error with our customer. > >> > >>There are no log files indications of a reason for a delay, the message > >>handler usually fires off within a few seconds of the message arriving. > >> > >>I realise this is a little vague, but I'm wondering if anybody else has had > >>this experience or observed this behaviour? > > > > ------------------------------------------------------- > SF.Net email is sponsored by: Discover Easy Linux Migration Strategies > from IBM. Find simple to follow Roadmaps, straightforward articles, > informative Webcasts and more! Get everything you need to get up to > speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click > _______________________________________________ > ebxmlms-general mailing list > ebx...@li... > https://lists.sourceforge.net/lists/listinfo/ebxmlms-general > ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click _______________________________________________ ebxmlms-general mailing list ebx...@li... https://lists.sourceforge.net/lists/listinfo/ebxmlms-general ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click _______________________________________________ ebxmlms-general mailing list ebx...@li... https://lists.sourceforge.net/lists/listinfo/ebxmlms-general |
|
From: Steven H. <sh...@te...> - 2005-06-21 23:13:43
|
Sorry for the late response, had a busy day yesterday. Regarding your questions, there are only about 6 records in mshconfig, but there are 16000 in messagestore If database speed was a problem, I would expect that all activities would be affected (that is, it if went slow this time, it'd still be slow now and would have gotten worse). -----Original Message----- From: ebx...@li... [mailto:ebx...@li...] On Behalf Of Patrick Yee Sent: Monday, 20 June 2005 11:37 PM To: ebx...@li... Subject: Re: [ebxmlms-general] Again, unreliable execution of message handlers. Steven, How many records are there in the database? In particular, how many records in mshconfig table? in messagestore table? I am still not sure about the reason, just wondering whether the number of records in database is one of the factors determining speed or not.. Regards, -Patrick Steven Herod wrote: >About a week ago, we had another incident of message handler not >executing on message arrival. > >In this case however, it wasn't a complete failure, instead, it seemed >to take about 10 minutes between hermes receiving the file and the >message handler picking it up. > >Normal behaviour has this occuring within a few seconds, however, in this >case, about 10 minute passed before the handler fired. Our messages are >time sensitive, so this pushed the response time window outside of >normal and raised an error with our customer. > >There are no log files indications of a reason for a delay, the >message handler usually fires off within a few seconds of the message arriving. > >I realise this is a little vague, but I'm wondering if anybody else has >had this experience or observed this behaviour? > > > > >------------------------------------------------------- >SF.Net email is sponsored by: Discover Easy Linux Migration Strategies >from IBM. Find simple to follow Roadmaps, straightforward articles, >informative Webcasts and more! Get everything you need to get up to >speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click >_______________________________________________ >ebxmlms-general mailing list >ebx...@li... >https://lists.sourceforge.net/lists/listinfo/ebxmlms-general > > ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click _______________________________________________ ebxmlms-general mailing list ebx...@li... https://lists.sourceforge.net/lists/listinfo/ebxmlms-general |
|
From: Steven H. <sh...@te...> - 2005-06-21 22:40:23
|
Check the email headers on the email you receive from the list, you'll see the instructions: List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/ebxmlms-general>, <mailto:ebx...@li...?subject=unsubscribe> -----Original Message----- From: ebx...@li... [mailto:ebx...@li...] On Behalf Of Lucia Melotti Sent: Wednesday, 22 June 2005 3:21 AM To: ebx...@li... Subject: [ebxmlms-general] Mailing list I would like to ususcribe from this Mailing list.. how can i do? Thanks Lucia ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click _______________________________________________ ebxmlms-general mailing list ebx...@li... https://lists.sourceforge.net/lists/listinfo/ebxmlms-general |
|
From: Lucia M. <lme...@cs...> - 2005-06-21 17:21:28
|
I would like to ususcribe from this Mailing list.. how can i do? Thanks Lucia |
|
From: Kenneth P. <tr...@ho...> - 2005-06-21 07:40:09
|
Hi If I loose the connection to my database for a short time (1-2minutes), MSH do not operate properly afterwards. When the connection is lost this occurs in the MSH_client.log: 2005-06-21 09:13:34,384 DEBUG [Thread-8]: => DbConnectionPool.getConnection 2005-06-21 09:13:34,384 DEBUG [Thread-8]: <= DbConnectionPool.getConnection 2005-06-21 09:13:34,384 ERROR [Thread-8]: [10002] Unknown error Exception: java.sql.SQLException Message: I/O Error: Connection reset by peer: socket write error 2005-06-21 09:13:34,384 DEBUG [Thread-8]: => Transaction.rollback (txID: #2321) 2005-06-21 09:13:34,384 ERROR [Thread-8]: [10315] Cannot rollback DB changes Exception: java.sql.SQLException Message: Invalid state, the Connection object is closed. 2005-06-21 09:13:34,384 DEBUG [Thread-8]: => DbConnectionPool.freeConnection 2005-06-21 09:13:34,384 DEBUG [Thread-8]: <= DbConnectionPool.freeConnection 2005-06-21 09:13:34,384 DEBUG [Thread-8]: <= Transaction.rollback 2005-06-21 09:13:34,384 DEBUG [Thread-8]: => MessageServiceHandler.getNextUndeliveredMessage 2005-06-21 09:13:34,384 DEBUG [Thread-8]: => MessageServer.getUndeliveredMessages 2005-06-21 09:13:34,384 DEBUG [Thread-8]: => DbConnectionPool.getConnection 2005-06-21 09:13:34,384 DEBUG [Thread-8]: => DbConnectionPool.createConnection 2005-06-21 09:13:35,352 ERROR [Thread-8]: [10306] Cannot create DB connection Exception: java.sql.SQLException Message: Network error IOException: Connection refused: connect 2005-06-21 09:13:35,352 DEBUG [Thread-8]: => Transaction.rollback (txID: #2323) 2005-06-21 09:13:35,352 DEBUG [Thread-8]: <= Transaction.rollback 2005-06-21 09:13:35,352 DEBUG [Thread-8]: => MessageServiceHandler.getNextUndeliveredMessage 2005-06-21 09:13:35,352 DEBUG [Thread-8]: => MessageServer.getUndeliveredMessages 2005-06-21 09:13:35,352 DEBUG [Thread-8]: => DbConnectionPool.getConnection 2005-06-21 09:13:35,352 DEBUG [Thread-8]: => DbConnectionPool.createConnection After the connection is restored MSH do not seem to get a proper connection. This occurs then in the MSH_Client.log: 2005-06-21 09:13:42,384 ERROR [Thread-8]: [10306] Cannot create DB connection Exception: java.sql.SQLException Message: Network error IOException: Connection refused: connect 2005-06-21 09:13:42,384 DEBUG [Thread-8]: => Transaction.rollback (txID: #2338) 2005-06-21 09:13:42,384 DEBUG [Thread-8]: <= Transaction.rollback 2005-06-21 09:13:42,384 DEBUG [Thread-8]: => MessageServiceHandler.getNextUndeliveredMessage 2005-06-21 09:13:42,384 DEBUG [Thread-8]: => MessageServer.getUndeliveredMessages 2005-06-21 09:13:42,384 DEBUG [Thread-8]: => DbConnectionPool.getConnection 2005-06-21 09:13:42,384 DEBUG [Thread-8]: => DbConnectionPool.createConnection 2005-06-21 09:13:43,384 ERROR [Thread-8]: [10306] Cannot create DB connection Exception: java.sql.SQLException Message: Network error IOException: Connection refused: connect When i try to send a message through MSH i get this: hk.hku.cecid.phoenix.message.handler.RequestException: Failed to send query to MSH. HTTP response code = 200 HTTP response message = OK at hk.hku.cecid.phoenix.message.handler.Request.expectMapResponse(Unknown Source) at hk.hku.cecid.phoenix.message.handler.Request.sendMessageServiceHandlerConfig(Unknown Source) at hk.hku.cecid.phoenix.message.handler.Request.register(Unknown Source) at hk.hku.cecid.phoenix.message.handler.Request.<init>(Unknown Source) at hk.hku.cecid.phoenix.message.handler.Request.<init>(Unknown Source) at com.mysupply.ebxi.msh.MessageManager.sendMessage(MessageManager.java:149) And of course I can not receive any messages through MSH either. Does anybody have the same problems, after a lost database connection? The other part of my application that uses MSH, is right back in action when the database connection is restored, but not MSH. The app is running on jboss-4.0.1 (Tomcat 5.0.28), Java jdk1.5.0_01. The database is Microsofts MSSQL 2000. The driver for MSSQL is JTDS 1.0. I have added this: <check-valid-connection-sql>select * from some_table</check-valid-connection-sql> to my datasource file: mssql-ds.xml which is deployed along with msh.war. Everything is working fine, for days, until I loose the database connection for a few minutes. _________________________________________________________________ Del din verden med MSN Spaces http://spaces.msn.com |
|
From: Steven H. <sh...@te...> - 2005-06-20 23:25:29
|
Thanks so much for your reply. No, there was no message such as this because we deleted the contents of the mshconfig table. 'TRUNC msh.mshconfig' is sql for deleting the contents of the table (TRUNC = TRUNCATE) So, it wouldn't have had any errors in trying to load missing objects because we removed the config table which tells it which objects to load. After starting hermes we restarted the app handler, and that resent both the config and serialised objects to hermes and all was fine. -----Original Message----- From: ebx...@li... [mailto:ebx...@li...] On Behalf Of Patrick Yee Sent: Monday, 20 June 2005 11:35 PM To: ebx...@li... Subject: Re: [ebxmlms-general] Triggering a Incoming Listener Steven, I am not sure about the effect of 'Trunc msh.mshconfig". Could you give me more information on that? However, it seems a bit strange to me that you can still restart Hermes successfully for moving aside the "objects*" files. The reason is: during Hermes starts up, it will read the mshconfig table, each entry there contains a file name which points to a serialized object. Hermes will then read the serialized object in the objectStore folder. If it cannot find the object, exceptions will be thrown. Did you aware of that in the log file? Regards, -Patrick Steven Herod wrote: >Last night, after reading through the source code and gaining a >stronger understanding of the system, we executed the following steps: > >Hermes shutdown >Apphandler shutdown >Ran the SQL: 'Trunc msh.mshconfig' >move aside of the 'objects*' files in '~msh/objectStore' >Start of hermes >Start of apphandler > > > ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click _______________________________________________ ebxmlms-general mailing list ebx...@li... https://lists.sourceforge.net/lists/listinfo/ebxmlms-general |
|
From: Robert A. S. <ro...@no...> - 2005-06-20 22:28:03
|
Hello, I hope someone out there would be kind enough to help me out - I have
been struggling with this problem for a couple weeks now.
I am running Hermes 1.0 on a Windows 2003 Server using Java 1.5.0_03
runtime. Every time I attempt to send a message to "othercompany"'s MSH
server (not hermes, Cyclone I think) I receive the SSLHandshakeException. I
have all the necessary trusted certs installed in my cacerts file that
Hermes is using as it's TrustedAnchor. I am able to sign messages with the
test09 private key with no problem from the Monitor app.
"othercompany"'s MSH server requires that I send my certificate for
authentication. I have tested the authentication process in a browser with
no problems.
I have also tried the 9.31 version of Hermes with the same result. My
private key originally came in a .pfx file - I was able to sign messages
from the Monitor application using the .pfx file, but when I put that as my
keystore in the config file for SSL, it would always say "Cannot load the
keystore on SSL client authentication : Cannot load keystore : Invalid
keystore format". So I programmatically put the private key into the JKS
format.
Is there a good way to debug the whole SSL handshaking process, I've seen
posts about "-Djavax.net.debug=all" - but can somebody elaborate and be more
specific about what I need to do?
Please help - I've included as much pertinent information below as I can
think of!!!!!!
-Rob
-- from log ----------
Add SSL Client Authentication entry : https://othercompany/msh/
\hermes\test.keystore
Sending message to https://othercompany/msh/
Connection class : class
com.sun.net.ssl.internal.www.protocol.https.HttpsURLConnectionOldImpl
Instance of HttpsURLConnection : true
Configuration to a HTTPS connection
use key manager for url : https://othercompany/msh/
[10505] Cannot send SOAP message Exception:
javax.net.ssl.SSLHandshakeException Message: Received fatal alert:
handshake_failure
------------------------------------
-- from config file -------
<SSL>
<!-- Optional property specifying the implementation class name of
com.sun.net.ssl.HostnameVerifier from JSSE 1.0 which handle the
case
when the URL's hostname and the server's identification hostname
mismatch-->
<!-- <HostnameVerifier>Verifier</HostnameVerifier> -->
<TrustedAnchor>
<!-- Trust keystore for SSL Server Authentication -->
<KeyStore>
<Path>/hermes</Path>
<File>cacerts</File>
<Password>changeit</Password>
</KeyStore>
</TrustedAnchor>
<ClientAuth>
<URL>https://othercompany/msh/</URL>
<KeyStore>
<Path>/hermes</Path>
<File>test.keystore</File>
<Alias>test09</Alias>
<Password>password</Password>
</KeyStore>
</ClientAuth>
</SSL>
------------------------------------
-- from keytool ------
D:\jdk1.5.0_03\bin>keytool -list -keystore test.keystore
Enter keystore password: password
Keystore type: jks
Keystore provider: SUN
Your keystore contains 1 entries
test09, Jun 13, 2005, keyEntry,
Certificate fingerprint (MD5):
5D:69:75:75:7C:6D:4A:E9:C6:82:4B:9F:A8:E6:52:05
------------------------------------
|
|
From: R. v. K. \(Ronald\) <rv...@ab...> - 2005-06-20 16:22:33
|
What db is used? Hsqldb processes all requests sequential, so an export of a db with a large number of records can hold things up quite easily. Ronald -----Oorspronkelijk bericht----- Van: ebx...@li... [mailto:ebx...@li...] Namens David Webber (XML) Verzonden: maandag 20 juni 2005 16:48 Aan: ebx...@li... Onderwerp: Re: [ebxmlms-general] Again, unreliable execution of message handlers. On the serious side - yes - I was thinking the same thing - that maybe some housekeeping / compaction service in the DB server occurred that took ten minutes to complete. DW ----- Original Message ----- From: "Mattias J" <mj...@ex...> To: <ebx...@li...> Sent: Monday, June 20, 2005 10:01 AM Subject: Re: [ebxmlms-general] Again, unreliable execution of message handlers. > Maybe also the RDBMS in use may be relevant? > > At 2005-06-20 15:37, you wrote: > >Steven, > >How many records are there in the database? In particular, how many > >records in mshconfig table? in messagestore table? I am still not sure > >about the reason, just wondering whether the number of records in database > >is one of the factors determining speed or not.. > >Regards, -Patrick > > > > > >Steven Herod wrote: > > > >>About a week ago, we had another incident of message handler not executing > >>on message arrival. > >> > >>In this case however, it wasn't a complete failure, instead, it seemed to > >>take about 10 minutes between hermes receiving the file and the message > >>handler picking it up. > >> > >>Normal behaviour has this occuring within a few seconds, however, in this > >>case, about 10 minute passed before the handler fired. Our messages are > >>time sensitive, so this pushed the response time window outside of normal > >>and raised an error with our customer. > >> > >>There are no log files indications of a reason for a delay, the message > >>handler usually fires off within a few seconds of the message arriving. > >> > >>I realise this is a little vague, but I'm wondering if anybody else has had > >>this experience or observed this behaviour? > > > > ------------------------------------------------------- > SF.Net email is sponsored by: Discover Easy Linux Migration Strategies > from IBM. Find simple to follow Roadmaps, straightforward articles, > informative Webcasts and more! Get everything you need to get up to > speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click > _______________________________________________ > ebxmlms-general mailing list > ebx...@li... > https://lists.sourceforge.net/lists/listinfo/ebxmlms-general > ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click _______________________________________________ ebxmlms-general mailing list ebx...@li... https://lists.sourceforge.net/lists/listinfo/ebxmlms-general |
|
From: Patrick Y. <kc...@ce...> - 2005-06-20 16:08:30
|
Hohoho... in that case, 10 minutes is a pretty good performance... :-D ..p David Webber (XML) wrote: >Perhaps there was a pretty girl walking past the window? > >DW > >----- Original Message ----- >From: "Patrick Yee" <kc...@ce...> >To: <ebx...@li...> >Sent: Monday, June 20, 2005 9:37 AM >Subject: Re: [ebxmlms-general] Again, unreliable execution of message >handlers. > > > > >>Steven, >>How many records are there in the database? In particular, how many >>records in mshconfig table? in messagestore table? I am still not sure >>about the reason, just wondering whether the number of records in >>database is one of the factors determining speed or not.. >>Regards, -Patrick >> >> >>Steven Herod wrote: >> >> >> >>>About a week ago, we had another incident of message handler not >>> >>> >executing > > >>>on message arrival. >>> >>>In this case however, it wasn't a complete failure, instead, it seemed to >>>take about 10 minutes between hermes receiving the file and the message >>>handler picking it up. >>> >>>Normal behaviour has this occuring within a few seconds, however, in this >>>case, about 10 minute passed before the handler fired. Our messages are >>>time sensitive, so this pushed the response time window outside of normal >>>and raised an error with our customer. >>> >>>There are no log files indications of a reason for a delay, the message >>>handler usually fires off within a few seconds of the message arriving. >>> >>>I realise this is a little vague, but I'm wondering if anybody else has >>> >>> >had > > >>>this experience or observed this behaviour? >>> >>> >>> >>> >>>------------------------------------------------------- >>>SF.Net email is sponsored by: Discover Easy Linux Migration Strategies >>> >>> >>>from IBM. Find simple to follow Roadmaps, straightforward articles, >> >> >>>informative Webcasts and more! Get everything you need to get up to >>>speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click >>>_______________________________________________ >>>ebxmlms-general mailing list >>>ebx...@li... >>>https://lists.sourceforge.net/lists/listinfo/ebxmlms-general >>> >>> >>> >>> >> >>------------------------------------------------------- >>SF.Net email is sponsored by: Discover Easy Linux Migration Strategies >>from IBM. Find simple to follow Roadmaps, straightforward articles, >>informative Webcasts and more! Get everything you need to get up to >>speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click >>_______________________________________________ >>ebxmlms-general mailing list >>ebx...@li... >>https://lists.sourceforge.net/lists/listinfo/ebxmlms-general >> >> >> > > > >------------------------------------------------------- >SF.Net email is sponsored by: Discover Easy Linux Migration Strategies >from IBM. Find simple to follow Roadmaps, straightforward articles, >informative Webcasts and more! Get everything you need to get up to >speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click >_______________________________________________ >ebxmlms-general mailing list >ebx...@li... >https://lists.sourceforge.net/lists/listinfo/ebxmlms-general > > |
|
From: Christine Z. <chr...@gm...> - 2005-06-20 15:39:37
|
> RunLoopBack launches a Hermes client, which will need a configuration
> file to locate the Hermes server. The configuration is located at
> msh_client.properties.xml. You can find that file in your download
> package and you should put it in the classpath or current working
> directory when launching Hermes client.
I found that file, configured it and put it in the classpath, but nevertheless I get
this error.
And when deploying Hermes on Tomcat 5.5, it says:
Hermes is alive. However, Hermes does not respond to HTTP GET method.
msh.log says:
2005-06-20 17:34:15,234 DEBUG [Thread-31]: polling mail server for messages
2005-06-20 17:34:15,234 DEBUG [Thread-31]: => Mail.receive
2005-06-20 17:34:15,234 INFO [Thread-31]: Receiving pop3 messages from pop.web.de<INBOX>
2005-06-20 17:34:18,375 ERROR [Thread-31]: [10105] Invalid POP/IMAP server - Server: pop.web.de, Port: 110, Folder: INBOX, User: chr...@we...
User: chr...@we... Exception: javax.mail.MessagingException
Message: Connect failed;
nested exception is:
java.net.SocketTimeoutException: Read timed out
I did not specify a server "pop.web.de" or an user "christine.obrien".
Regards
Christine
|
|
From: David W. \(XML\) <da...@dr...> - 2005-06-20 14:48:15
|
On the serious side - yes - I was thinking the same thing - that maybe some housekeeping / compaction service in the DB server occurred that took ten minutes to complete. DW ----- Original Message ----- From: "Mattias J" <mj...@ex...> To: <ebx...@li...> Sent: Monday, June 20, 2005 10:01 AM Subject: Re: [ebxmlms-general] Again, unreliable execution of message handlers. > Maybe also the RDBMS in use may be relevant? > > At 2005-06-20 15:37, you wrote: > >Steven, > >How many records are there in the database? In particular, how many > >records in mshconfig table? in messagestore table? I am still not sure > >about the reason, just wondering whether the number of records in database > >is one of the factors determining speed or not.. > >Regards, -Patrick > > > > > >Steven Herod wrote: > > > >>About a week ago, we had another incident of message handler not executing > >>on message arrival. > >> > >>In this case however, it wasn't a complete failure, instead, it seemed to > >>take about 10 minutes between hermes receiving the file and the message > >>handler picking it up. > >> > >>Normal behaviour has this occuring within a few seconds, however, in this > >>case, about 10 minute passed before the handler fired. Our messages are > >>time sensitive, so this pushed the response time window outside of normal > >>and raised an error with our customer. > >> > >>There are no log files indications of a reason for a delay, the message > >>handler usually fires off within a few seconds of the message arriving. > >> > >>I realise this is a little vague, but I'm wondering if anybody else has had > >>this experience or observed this behaviour? > > > > ------------------------------------------------------- > SF.Net email is sponsored by: Discover Easy Linux Migration Strategies > from IBM. Find simple to follow Roadmaps, straightforward articles, > informative Webcasts and more! Get everything you need to get up to > speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click > _______________________________________________ > ebxmlms-general mailing list > ebx...@li... > https://lists.sourceforge.net/lists/listinfo/ebxmlms-general > |
|
From: David W. \(XML\) <da...@dr...> - 2005-06-20 14:28:59
|
Perhaps there was a pretty girl walking past the window? DW ----- Original Message ----- From: "Patrick Yee" <kc...@ce...> To: <ebx...@li...> Sent: Monday, June 20, 2005 9:37 AM Subject: Re: [ebxmlms-general] Again, unreliable execution of message handlers. > Steven, > How many records are there in the database? In particular, how many > records in mshconfig table? in messagestore table? I am still not sure > about the reason, just wondering whether the number of records in > database is one of the factors determining speed or not.. > Regards, -Patrick > > > Steven Herod wrote: > > >About a week ago, we had another incident of message handler not executing > >on message arrival. > > > >In this case however, it wasn't a complete failure, instead, it seemed to > >take about 10 minutes between hermes receiving the file and the message > >handler picking it up. > > > >Normal behaviour has this occuring within a few seconds, however, in this > >case, about 10 minute passed before the handler fired. Our messages are > >time sensitive, so this pushed the response time window outside of normal > >and raised an error with our customer. > > > >There are no log files indications of a reason for a delay, the message > >handler usually fires off within a few seconds of the message arriving. > > > >I realise this is a little vague, but I'm wondering if anybody else has had > >this experience or observed this behaviour? > > > > > > > > > >------------------------------------------------------- > >SF.Net email is sponsored by: Discover Easy Linux Migration Strategies > >from IBM. Find simple to follow Roadmaps, straightforward articles, > >informative Webcasts and more! Get everything you need to get up to > >speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click > >_______________________________________________ > >ebxmlms-general mailing list > >ebx...@li... > >https://lists.sourceforge.net/lists/listinfo/ebxmlms-general > > > > > > > > ------------------------------------------------------- > SF.Net email is sponsored by: Discover Easy Linux Migration Strategies > from IBM. Find simple to follow Roadmaps, straightforward articles, > informative Webcasts and more! Get everything you need to get up to > speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click > _______________________________________________ > ebxmlms-general mailing list > ebx...@li... > https://lists.sourceforge.net/lists/listinfo/ebxmlms-general > |
|
From: Mattias J <mj...@ex...> - 2005-06-20 14:27:44
|
Maybe also the RDBMS in use may be relevant? At 2005-06-20 15:37, you wrote: >Steven, >How many records are there in the database? In particular, how many >records in mshconfig table? in messagestore table? I am still not sure >about the reason, just wondering whether the number of records in database >is one of the factors determining speed or not.. >Regards, -Patrick > > >Steven Herod wrote: > >>About a week ago, we had another incident of message handler not executing >>on message arrival. >> >>In this case however, it wasn't a complete failure, instead, it seemed to >>take about 10 minutes between hermes receiving the file and the message >>handler picking it up. >> >>Normal behaviour has this occuring within a few seconds, however, in this >>case, about 10 minute passed before the handler fired. Our messages are >>time sensitive, so this pushed the response time window outside of normal >>and raised an error with our customer. >> >>There are no log files indications of a reason for a delay, the message >>handler usually fires off within a few seconds of the message arriving. >> >>I realise this is a little vague, but I'm wondering if anybody else has had >>this experience or observed this behaviour? |
|
From: Patrick Y. <kc...@ce...> - 2005-06-20 14:01:34
|
RunLoopBack launches a Hermes client, which will need a configuration file to locate the Hermes server. The configuration is located at msh_client.properties.xml. You can find that file in your download package and you should put it in the classpath or current working directory when launching Hermes client. Regards, -Patrick Christine Zimmer wrote: >Hi, >I've installed Hermes 1.0. But when I run RunLoopBack I get the >following error: >hk.hku.cecid.phoenix.message.handler.RequestException: Cannot open >property file msh_client.properties.xml > at hk.hku.cecid.phoenix.message.handler.Request.<init>(Unkown > Source) > at hk.hku.cecid.phoenix.message.handler.Request.<init>(Unkown > Source) > at LoopBack.run(LoopBack.java:29) > at LoopBack.main(LoopBack.java:11) > >Can anybody help me? > > > |
|
From: Patrick Y. <kc...@ce...> - 2005-06-20 13:59:12
|
Sm9lLA0KDQpDb25zaWRlciB0aGlzOg0KSGVybWVzICAtLS1tYWtlIFNTTCBjb25uZWN0aW9u IHRvLS0tPiAgQW5vdGhlciBNU0gNCg0KSW4gdGhpcyBjYXNlLCBIZXJtZXMgaXMgYSBjbGll bnQgdG8gIkFub3RoZXIgTVNIIi4gT25jZSBzZXQgdXAsIEhlcm1lcyANCndpbGwgaW5jbHVk ZSB0aGUga2V5IHNwZWNpZmllZCBpbiB0aGUgPENsaWVudEF1dGg+IGJpdHMgd2hlbiBtYWtp bmcgdGhlIA0KU1NMIGNvbm5lY3Rpb24uIEZvciB5b3VyIHJlZmVyZW5jZSwgd2UgYXJlIHVz aW5nIEpTU0UgbGlicmFyeS4gWW91IGNhbiANCmZpbmQgc29tZSByZWZlcmVuY2VzIGF0IGh0 dHA6Ly93d3cuamd1cnUuY29tL2ZhcS92aWV3LmpzcD9FSUQ9NTMyMjA1Lg0KDQpSZWdhcmRz LCAtUGF0cmljaw0KDQoNClBvcnRlbGxpLCBKb2UgRiB3cm90ZToNCg0KPlBhdHJpY2ssDQo+ CUZpcnN0IG9mIGFsbCB0aGFua3MgZm9yIHRoZSByZXBseS4NCj4NCj4JV2hhdCB5b3Ugc3Vn Z2VzdGVkIEkgaGF2ZSBhbHJlYWR5IHRyaWVkLiBFeGFjdGx5IGFzIHlvdSBzdWdnZXN0ZWQu IEkgY3JlYXRlZCBhIGtleXN0b3JlIGZvciBjbGllbnQgYXV0aGVudGljYXRpb24gYW5kIGNy ZWF0ZWQgYSA8Q2xpZW50QXV0aD4gInNlY3Rpb24iIGZvciBlYWNoIGNsaWVudCBjb25uZWN0 aW5nIG92ZXIgaHR0cHMgYW5kIHBvcHVsYXRlZCBlYWNoIHNlY3Rpb24gd2l0aCB0aGUgY2xp ZW50IGRldGFpbHMgcmVsZXZhbnQgdG8gdGhhdCBjbGllbnQuIEkgZGlkIHNvbWV0aGluZyBz aW1pbGFyIGZvciBTU0wgU2VydmVyIEF1dGhlbnRpY2F0aW9uICh3aGljaCBpcyB3b3JraW5n IGZpbmUpLiBJbiBmYWN0IEkndmUgc2V0IHVwIGFsbCBvdGhlciBzZWN1cml0eVxub24tcmVw dWRpYXRpb24gc2V0dGluZ3MgYW5kIGl0J3MgYWxsIHdvcmtpbmcgZmluZS4gQWxsIG90aGVy IHNldHRpbmdzLCB0aGF0IGlzLCBleGNlcHQgY2xpZW50IGF1dGhlbnRpY2F0aW9uLg0KPg0K PglUaGlzIGxlYWRzIG1lIHRvIHRoZSB3b25kZXIgd2hldGhlciBteSB1bmRlcnN0YW5kaW5n IG9mIHdoYXQgYSBjbGllbnQgaXMgaXMgY29ycmVjdC4gQnkgY2xpZW50IGRvIHlvdSB1bmRl cnN0YW5kIHNvbWV0aGluZyB3aGljaCBpcyBhdHRlbXB0aW5nIHRvIGNvbm5lY3QgdG8gYW4g TVNIIHNvIHRoYXQgaXQgY2FuIHNlbmQgbWVzc2FnZXMgdG8gYW5vdGhlciBNU0ggKGllIHRo ZSBjbGllbnQgaXMgdGhlIGVudGl0eSB3aGljaCBpcyB1c2luZyBhbiBNU0ggYXMgYSBzZXJ2 aWNlKT8gT3IgaXMgYSBjbGllbnQgdG8gYW4gTVNIIGFub3RoZXIgTVNIIHdoaWNoIGlzIGlu aXRpYXRpbmcgYSBjb25uZWN0aW9uIHRvIHRoZSBmaXJzdCBNU0g/IE9yIGl0IGNhbiBiZSBl aXRoZXI/DQo+DQo+CUNhbiB5b3UgKG9yIGFueSBvbmUgaW4gdGhpcyBncm91cCkgc2hlZCBh bnkgbGlnaHQ/IElmIGl0IGhlbHBzIEknbSB1c2luZyBUb21jYXQ1LjAuMjggYXMgdGhlIHNl cnZsZXQgY29udGFpbmVyIGFuZCBKYXZhIFNESyAxLjUuMF8wMy1iMDcuDQo+DQo+UmVnYXJk cw0KPkpvZSBQLg0KPg0KPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+RnJvbTogZWJ4 bWxtcy1nZW5lcmFsLWFkbWluQGxpc3RzLnNvdXJjZWZvcmdlLm5ldCBbbWFpbHRvOmVieG1s bXMtZ2VuZXJhbC1hZG1pbkBsaXN0cy5zb3VyY2Vmb3JnZS5uZXRdIA0KPlNlbnQ6IFNhdHVy ZGF5LCAxOCBKdW5lIDIwMDUgMToyNiBQTQ0KPlRvOiBlYnhtbG1zLWdlbmVyYWxAbGlzdHMu c291cmNlZm9yZ2UubmV0DQo+U3ViamVjdDogUmU6IFtlYnhtbG1zLWdlbmVyYWxdIFJlcXVl c3RpbmcgQ2xpZW50IEF1dGhlbnRpY2F0aW9uDQo+DQo+SGkgSm9zZXBoLA0KPg0KPllvdSBj YW4gZmluZCB0aGlzIGZyYWdtZW50IGluIG1zaC5wcm9wZXJ0aWVzLnhtbDoNCj4NCj48Q2xp ZW50QXV0aD4NCj48VVJMPmh0dHBzOi8vMTQ3LjguMTc4LjE1OTo4NDQzL21zaC88L1VSTD4N Cj48S2V5U3RvcmU+DQo+PFBhdGg+PC9QYXRoPg0KPjxGaWxlPm15X2tleXN0b3JlPC9GaWxl Pg0KPjxBbGlhcz5hY2trZXk8L0FsaWFzPg0KPjxQYXNzd29yZD5jaGFuZ2VpdDwvUGFzc3dv cmQ+DQo+PC9LZXlTdG9yZT4NCj48L0NsaWVudEF1dGg+DQo+DQo+VGhlIDxDbGllbnRBdXRo PiBlbGVtZW50IGNhbiBiZSByZXBlYXRpbmcsIGZvciBlYWNoIG91dGdvaW5nIFVSTCBIZXJt ZXMgDQo+aXMgdHJ5aW5nIHRvIGNvbm5lY3QgdXNpbmcgY2xpZW50IGF1dGhlbnRpY2F0aW9u LiBBcyB5b3Ugc2VlLCB5b3UgDQo+c3BlY2lmeSB0aGUgb3V0Z29pbmcgVVJMIG9uIHdoaWNo IGNsaWVudCBhdXRoZW50aWNhdGlvbiBzaG91bGQgYmUgdXNlZCwgDQo+dGhlIHBhdGgsIGZp bGUgbmFtZSwgYWxpYXMgYW5kIHBhc3N3b3JkIG9mIHRoZSBrZXlzdG9yZSBmaWxlIGhvbGRp bmcgdGhlIA0KPmtleS4NCj4NCj5Ib3BlIHRoaXMgaGVscHMuDQo+DQo+UmVnYXJkcywgLVBh dHJpY2sNCj4NCj4NCj4NCj5Qb3J0ZWxsaSwgSm9lIEYgd3JvdGU6DQo+DQo+ICANCj4NCj4+ SGVybWVz4oCZIGNvbmZpZ3VyYXRpb24gZmlsZSAobXNoLnByb3BlcnRpZXMueG1sKSBhbGxv d3MgZm9yIFNTTCBTZXJ2ZXIgDQo+PmFuZCBDbGllbnQgQXV0aGVudGljYXRpb24uIEkgZGVm aW5lZCB0aGUgZW50cmllcyBpbiANCj4+PE1TSD5TU0g8VHJ1c3RlZEFuY2hvcj48S2V5c3Rv cmU+IGFuZCBlbmFibGVkIHNlcnZlciBhdXRoZW50aWNhdGlvbiDigJMgDQo+PnRoYXQgaXMg SGVybWVzIG5vdyBhdXRoZW50aWNhdGVzIG90aGVyIE1TSOKAmXMgKHNlcnZlcnMpIGl0IGlz IA0KPj5hdHRlbXB0aW5nIHRvIHNldCB1cCBhIHNlc3Npb24gd2l0aC4NCj4+DQo+PldoYXQg SSB3b3VsZCBsaWtlIHRvIGtub3cgaXMgaG93IHRvIGFjdGl2YXRlIENsaWVudCBBdXRoZW50 aWNhdGlvbiBpbiANCj4+SGVybWVzIGllIGhvdyB0byBnZXQgSGVybWVzIHRvIGluaXRpYXRl IGEgcmVtb3RlIGNsaWVudCBhdXRoZW50aWNhdGlvbiANCj4+cHJvY2Vzcy4NCj4+DQo+PlJl Z2FyZHMNCj4+DQo+Pkpvc2VwaCBGLiBQb3J0ZWxsaQ0KPj4NCj4+VGVsc3RyYSBSZXNlYXJj aCBMYWJvcmF0b3JpZXMNCj4+DQo+PiggKzYxICgwKTIgODI1NSAzMDk5DQo+Pg0KPj43ICs2 MSAoMCkyIDgyNTUgMzE1Mw0KPj4NCj4+xZMgMy80MDAgR2VvcmdlIFN0cmVldCwgU3lkbmV5 LCBOU1cgMjAwMA0KPj4NCj4+xaEgXzxfbWFpbHRvOmpvZS5wb3J0ZWxsaTFAdGVhbS50ZWxz dHJhLmNvbV8+X19fDQo+Pg0KPj4gICAgDQo+Pg0KPg0KPg0KPg0KPi0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj5TRi5OZXQgZW1h aWwgaXMgc3BvbnNvcmVkIGJ5OiBEaXNjb3ZlciBFYXN5IExpbnV4IE1pZ3JhdGlvbiBTdHJh dGVnaWVzDQo+ZnJvbSBJQk0uIEZpbmQgc2ltcGxlIHRvIGZvbGxvdyBSb2FkbWFwcywgc3Ry YWlnaHRmb3J3YXJkIGFydGljbGVzLA0KPmluZm9ybWF0aXZlIFdlYmNhc3RzIGFuZCBtb3Jl ISBHZXQgZXZlcnl0aGluZyB5b3UgbmVlZCB0byBnZXQgdXAgdG8NCj5zcGVlZCwgZmFzdC4g aHR0cDovL2Fkcy5vc2RuLmNvbS8/YWRfaWR0NzcmYWxsb2NfaWQWNDkyJm9wPWljaw0KPl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ZWJ4bWxt cy1nZW5lcmFsIG1haWxpbmcgbGlzdA0KPmVieG1sbXMtZ2VuZXJhbEBsaXN0cy5zb3VyY2Vm b3JnZS5uZXQNCj5odHRwczovL2xpc3RzLnNvdXJjZWZvcmdlLm5ldC9saXN0cy9saXN0aW5m by9lYnhtbG1zLWdlbmVyYWwNCj7vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73v v73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73v v73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv70X77+9Xu+/vemailjvv73v v73vv70n77+977+977+9de+/ve+/vQ4rHO+/ve+/vRHvv70yLinvv73vv73IoO+/ve+/vWLv v71077+977+977+9Xu+/vSfvv71+77+9JiAT77+9Findsinvv73vv73vv71ofu+/vWXvv70E aGnZmu+/ve+/vey2tu+/ve+/vRtf77+977+9Gu+/vdar77+9JyV677+977+977+9K++/ve+/ vWLvv73vv71txqzvv73Gp3ZqK3vvv73vv73eryth77+9eDLvv73vv73vv71577+9aO+/ve+/ vW7vv73vv70s77+977+977+977+977+9be+/ve+/ve+/ve+/vWzvv73vv70d77+977+9KO+/ ve+/ve+/vXfvv73vv73vv73vv73vv73vv71277+977+9cljvv73vv73vv73vv73vv73vv73v v73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73v v73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv71577+9Zu+/vWvvv73vv73v v73ere+/vWZqKWLvv70JYu+/vdeb77+9aWbvv73vv70e77+977+92pfvv71i77+977+977+9 77+977+977+9ce+/ve+/vQfvv73vv73vv71h77+977+9bO+/ve+/ve+/ve+/vWzvv73vv70u 77+9x5/vv73vv70e77+9d++/ve+/vVjvv73vv73vv73vv73vv71i77+977+9P3nvv71m77+9 a++/ve+/ve+/ve+/vQ0KPg0KPiAgDQo+DQoNCg== |
|
From: Patrick Y. <kc...@ce...> - 2005-06-20 13:39:38
|
Yes, Hermes will response with a PONG message when receiving a PING message. The PING message should have a service as "urn:oasis:names:tc:ebxml-msg:service" and action as "Ping". Generally, it doesn't care about CPA ID and Conversation ID for PING/PONG messages. Regards, -Patrick em...@og... wrote: > > Does the MSH monitor support the Ping service as described in Section > 8 of Message Service Spec. 2.0? What are the Action(s) supported. Is > there any limitations on the MessageHeader Element i.e. Conv. ID, CPA > ID, ... imposed by the MSH montor? > > Thank you! |
|
From: Patrick Y. <kc...@ce...> - 2005-06-20 13:37:08
|
Steven, How many records are there in the database? In particular, how many records in mshconfig table? in messagestore table? I am still not sure about the reason, just wondering whether the number of records in database is one of the factors determining speed or not.. Regards, -Patrick Steven Herod wrote: >About a week ago, we had another incident of message handler not executing >on message arrival. > >In this case however, it wasn't a complete failure, instead, it seemed to >take about 10 minutes between hermes receiving the file and the message >handler picking it up. > >Normal behaviour has this occuring within a few seconds, however, in this >case, about 10 minute passed before the handler fired. Our messages are >time sensitive, so this pushed the response time window outside of normal >and raised an error with our customer. > >There are no log files indications of a reason for a delay, the message >handler usually fires off within a few seconds of the message arriving. > >I realise this is a little vague, but I'm wondering if anybody else has had >this experience or observed this behaviour? > > > > >------------------------------------------------------- >SF.Net email is sponsored by: Discover Easy Linux Migration Strategies >from IBM. Find simple to follow Roadmaps, straightforward articles, >informative Webcasts and more! Get everything you need to get up to >speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click >_______________________________________________ >ebxmlms-general mailing list >ebx...@li... >https://lists.sourceforge.net/lists/listinfo/ebxmlms-general > > |
|
From: Patrick Y. <kc...@ce...> - 2005-06-20 13:34:44
|
Steven, I am not sure about the effect of 'Trunc msh.mshconfig". Could you give me more information on that? However, it seems a bit strange to me that you can still restart Hermes successfully for moving aside the "objects*" files. The reason is: during Hermes starts up, it will read the mshconfig table, each entry there contains a file name which points to a serialized object. Hermes will then read the serialized object in the objectStore folder. If it cannot find the object, exceptions will be thrown. Did you aware of that in the log file? Regards, -Patrick Steven Herod wrote: >Last night, after reading through the source code and gaining a stronger >understanding of the system, we executed the following steps: > >Hermes shutdown >Apphandler shutdown >Ran the SQL: 'Trunc msh.mshconfig' >move aside of the 'objects*' files in '~msh/objectStore' >Start of hermes >Start of apphandler > > > |
|
From: Christine Z. <chr...@gm...> - 2005-06-20 12:27:43
|
Hi,
I've installed Hermes 1.0. But when I run RunLoopBack I get the
following error:
hk.hku.cecid.phoenix.message.handler.RequestException: Cannot open
property file msh_client.properties.xml
at hk.hku.cecid.phoenix.message.handler.Request.<init>(Unkown
Source)
at hk.hku.cecid.phoenix.message.handler.Request.<init>(Unkown
Source)
at LoopBack.run(LoopBack.java:29)
at LoopBack.main(LoopBack.java:11)
Can anybody help me?
--
Regards
Christine Zimmer
mailto:chr...@gm...
|
|
From: Portelli, J. F <Joe...@te...> - 2005-06-20 04:13:39
|
UGF0cmljaywNCglGaXJzdCBvZiBhbGwgdGhhbmtzIGZvciB0aGUgcmVwbHkuDQoNCglXaGF0IHlv dSBzdWdnZXN0ZWQgSSBoYXZlIGFscmVhZHkgdHJpZWQuIEV4YWN0bHkgYXMgeW91IHN1Z2dlc3Rl ZC4gSSBjcmVhdGVkIGEga2V5c3RvcmUgZm9yIGNsaWVudCBhdXRoZW50aWNhdGlvbiBhbmQgY3Jl YXRlZCBhIDxDbGllbnRBdXRoPiAic2VjdGlvbiIgZm9yIGVhY2ggY2xpZW50IGNvbm5lY3Rpbmcg b3ZlciBodHRwcyBhbmQgcG9wdWxhdGVkIGVhY2ggc2VjdGlvbiB3aXRoIHRoZSBjbGllbnQgZGV0 YWlscyByZWxldmFudCB0byB0aGF0IGNsaWVudC4gSSBkaWQgc29tZXRoaW5nIHNpbWlsYXIgZm9y IFNTTCBTZXJ2ZXIgQXV0aGVudGljYXRpb24gKHdoaWNoIGlzIHdvcmtpbmcgZmluZSkuIEluIGZh Y3QgSSd2ZSBzZXQgdXAgYWxsIG90aGVyIHNlY3VyaXR5XG5vbi1yZXB1ZGlhdGlvbiBzZXR0aW5n cyBhbmQgaXQncyBhbGwgd29ya2luZyBmaW5lLiBBbGwgb3RoZXIgc2V0dGluZ3MsIHRoYXQgaXMs IGV4Y2VwdCBjbGllbnQgYXV0aGVudGljYXRpb24uDQoNCglUaGlzIGxlYWRzIG1lIHRvIHRoZSB3 b25kZXIgd2hldGhlciBteSB1bmRlcnN0YW5kaW5nIG9mIHdoYXQgYSBjbGllbnQgaXMgaXMgY29y cmVjdC4gQnkgY2xpZW50IGRvIHlvdSB1bmRlcnN0YW5kIHNvbWV0aGluZyB3aGljaCBpcyBhdHRl bXB0aW5nIHRvIGNvbm5lY3QgdG8gYW4gTVNIIHNvIHRoYXQgaXQgY2FuIHNlbmQgbWVzc2FnZXMg dG8gYW5vdGhlciBNU0ggKGllIHRoZSBjbGllbnQgaXMgdGhlIGVudGl0eSB3aGljaCBpcyB1c2lu ZyBhbiBNU0ggYXMgYSBzZXJ2aWNlKT8gT3IgaXMgYSBjbGllbnQgdG8gYW4gTVNIIGFub3RoZXIg TVNIIHdoaWNoIGlzIGluaXRpYXRpbmcgYSBjb25uZWN0aW9uIHRvIHRoZSBmaXJzdCBNU0g/IE9y IGl0IGNhbiBiZSBlaXRoZXI/DQoNCglDYW4geW91IChvciBhbnkgb25lIGluIHRoaXMgZ3JvdXAp IHNoZWQgYW55IGxpZ2h0PyBJZiBpdCBoZWxwcyBJJ20gdXNpbmcgVG9tY2F0NS4wLjI4IGFzIHRo ZSBzZXJ2bGV0IGNvbnRhaW5lciBhbmQgSmF2YSBTREsgMS41LjBfMDMtYjA3Lg0KDQpSZWdhcmRz DQpKb2UgUC4NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGVieG1sbXMtZ2Vu ZXJhbC1hZG1pbkBsaXN0cy5zb3VyY2Vmb3JnZS5uZXQgW21haWx0bzplYnhtbG1zLWdlbmVyYWwt YWRtaW5AbGlzdHMuc291cmNlZm9yZ2UubmV0XSANClNlbnQ6IFNhdHVyZGF5LCAxOCBKdW5lIDIw MDUgMToyNiBQTQ0KVG86IGVieG1sbXMtZ2VuZXJhbEBsaXN0cy5zb3VyY2Vmb3JnZS5uZXQNClN1 YmplY3Q6IFJlOiBbZWJ4bWxtcy1nZW5lcmFsXSBSZXF1ZXN0aW5nIENsaWVudCBBdXRoZW50aWNh dGlvbg0KDQpIaSBKb3NlcGgsDQoNCllvdSBjYW4gZmluZCB0aGlzIGZyYWdtZW50IGluIG1zaC5w cm9wZXJ0aWVzLnhtbDoNCg0KPENsaWVudEF1dGg+DQo8VVJMPmh0dHBzOi8vMTQ3LjguMTc4LjE1 OTo4NDQzL21zaC88L1VSTD4NCjxLZXlTdG9yZT4NCjxQYXRoPjwvUGF0aD4NCjxGaWxlPm15X2tl eXN0b3JlPC9GaWxlPg0KPEFsaWFzPmFja2tleTwvQWxpYXM+DQo8UGFzc3dvcmQ+Y2hhbmdlaXQ8 L1Bhc3N3b3JkPg0KPC9LZXlTdG9yZT4NCjwvQ2xpZW50QXV0aD4NCg0KVGhlIDxDbGllbnRBdXRo PiBlbGVtZW50IGNhbiBiZSByZXBlYXRpbmcsIGZvciBlYWNoIG91dGdvaW5nIFVSTCBIZXJtZXMg DQppcyB0cnlpbmcgdG8gY29ubmVjdCB1c2luZyBjbGllbnQgYXV0aGVudGljYXRpb24uIEFzIHlv dSBzZWUsIHlvdSANCnNwZWNpZnkgdGhlIG91dGdvaW5nIFVSTCBvbiB3aGljaCBjbGllbnQgYXV0 aGVudGljYXRpb24gc2hvdWxkIGJlIHVzZWQsIA0KdGhlIHBhdGgsIGZpbGUgbmFtZSwgYWxpYXMg YW5kIHBhc3N3b3JkIG9mIHRoZSBrZXlzdG9yZSBmaWxlIGhvbGRpbmcgdGhlIA0Ka2V5Lg0KDQpI b3BlIHRoaXMgaGVscHMuDQoNClJlZ2FyZHMsIC1QYXRyaWNrDQoNCg0KDQpQb3J0ZWxsaSwgSm9l IEYgd3JvdGU6DQoNCj4gSGVybWVz4oCZIGNvbmZpZ3VyYXRpb24gZmlsZSAobXNoLnByb3BlcnRp ZXMueG1sKSBhbGxvd3MgZm9yIFNTTCBTZXJ2ZXIgDQo+IGFuZCBDbGllbnQgQXV0aGVudGljYXRp b24uIEkgZGVmaW5lZCB0aGUgZW50cmllcyBpbiANCj4gPE1TSD5TU0g8VHJ1c3RlZEFuY2hvcj48 S2V5c3RvcmU+IGFuZCBlbmFibGVkIHNlcnZlciBhdXRoZW50aWNhdGlvbiDigJMgDQo+IHRoYXQg aXMgSGVybWVzIG5vdyBhdXRoZW50aWNhdGVzIG90aGVyIE1TSOKAmXMgKHNlcnZlcnMpIGl0IGlz IA0KPiBhdHRlbXB0aW5nIHRvIHNldCB1cCBhIHNlc3Npb24gd2l0aC4NCj4NCj4gV2hhdCBJIHdv dWxkIGxpa2UgdG8ga25vdyBpcyBob3cgdG8gYWN0aXZhdGUgQ2xpZW50IEF1dGhlbnRpY2F0aW9u IGluIA0KPiBIZXJtZXMgaWUgaG93IHRvIGdldCBIZXJtZXMgdG8gaW5pdGlhdGUgYSByZW1vdGUg Y2xpZW50IGF1dGhlbnRpY2F0aW9uIA0KPiBwcm9jZXNzLg0KPg0KPiBSZWdhcmRzDQo+DQo+IEpv c2VwaCBGLiBQb3J0ZWxsaQ0KPg0KPiBUZWxzdHJhIFJlc2VhcmNoIExhYm9yYXRvcmllcw0KPg0K PiAoICs2MSAoMCkyIDgyNTUgMzA5OQ0KPg0KPiA3ICs2MSAoMCkyIDgyNTUgMzE1Mw0KPg0KPiDF kyAzLzQwMCBHZW9yZ2UgU3RyZWV0LCBTeWRuZXksIE5TVyAyMDAwDQo+DQo+IMWhIF88X21haWx0 bzpqb2UucG9ydGVsbGkxQHRlYW0udGVsc3RyYS5jb21fPl9fXw0KPg0KDQoNCg0KLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KU0YuTmV0IGVt YWlsIGlzIHNwb25zb3JlZCBieTogRGlzY292ZXIgRWFzeSBMaW51eCBNaWdyYXRpb24gU3RyYXRl Z2llcw0KZnJvbSBJQk0uIEZpbmQgc2ltcGxlIHRvIGZvbGxvdyBSb2FkbWFwcywgc3RyYWlnaHRm b3J3YXJkIGFydGljbGVzLA0KaW5mb3JtYXRpdmUgV2ViY2FzdHMgYW5kIG1vcmUhIEdldCBldmVy eXRoaW5nIHlvdSBuZWVkIHRvIGdldCB1cCB0bw0Kc3BlZWQsIGZhc3QuIGh0dHA6Ly9hZHMub3Nk bi5jb20vP2FkX2lkdDc3JmFsbG9jX2lkFjQ5MiZvcD1pY2sNCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQplYnhtbG1zLWdlbmVyYWwgbWFpbGluZyBsaXN0 DQplYnhtbG1zLWdlbmVyYWxAbGlzdHMuc291cmNlZm9yZ2UubmV0DQpodHRwczovL2xpc3RzLnNv dXJjZWZvcmdlLm5ldC9saXN0cy9saXN0aW5mby9lYnhtbG1zLWdlbmVyYWwNCg== |
|
From: Ronald v. K. <rtv...@xs...> - 2005-06-18 08:36:24
|
Well, In our case it was a test about the preformance capabilities of hermes. We do not use it in production yet (I still have to convince some people to upgrade our messaging infrastructure to ebxml). The test was purly to see if it would fit our needs and it did. Ronald Patrick Yee probeerde me het volgende duidelijk te maken: > Steven and Ronald, good to know that.. really encouraging. > Regards, -Patrick > > Ronald van Kuijk wrote: > >>3000 documents a week? Each document is? 10-100k ? Easilly. Even in one hour I think. >> >>Ronald >> >>Steven Herod probeerde me het volgende duidelijk te maken: >> >> >>>Who out there uses Hermes in a real life production environment? >>> >>>If so, what kind of volumes do you process with it? >>> >>>In our case, we do use it in a production environment, transacting about >>>3000 documents a week. >>> >>>Anybody else? >>> >>> >>> >>> >>>------------------------------------------------------- >>>SF.Net email is sponsored by: Discover Easy Linux Migration Strategies >>>from IBM. Find simple to follow Roadmaps, straightforward articles, >>>informative Webcasts and more! Get everything you need to get up to >>>speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click >>>_______________________________________________ >>>ebxmlms-general mailing list >>>ebx...@li... >>>https://lists.sourceforge.net/lists/listinfo/ebxmlms-general >>> >>> >>> >> >> >> >> > > > > ------------------------------------------------------- > SF.Net email is sponsored by: Discover Easy Linux Migration Strategies > from IBM. Find simple to follow Roadmaps, straightforward articles, > informative Webcasts and more! Get everything you need to get up to > speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click > _______________________________________________ > ebxmlms-general mailing list > ebx...@li... > https://lists.sourceforge.net/lists/listinfo/ebxmlms-general > -- Kijk niet terug, maar kijk naar mij Against all odds |
|
From: Patrick Y. <kc...@ce...> - 2005-06-18 03:26:17
|
Hi Joseph, You can find this fragment in msh.properties.xml: <ClientAuth> <URL>https://147.8.178.159:8443/msh/</URL> <KeyStore> <Path></Path> <File>my_keystore</File> <Alias>ackkey</Alias> <Password>changeit</Password> </KeyStore> </ClientAuth> The <ClientAuth> element can be repeating, for each outgoing URL Hermes=20 is trying to connect using client authentication. As you see, you=20 specify the outgoing URL on which client authentication should be used,=20 the path, file name, alias and password of the keystore file holding the=20 key. Hope this helps. Regards, -Patrick Portelli, Joe F wrote: > Hermes=92 configuration file (msh.properties.xml) allows for SSL Server= =20 > and Client Authentication. I defined the entries in=20 > <MSH>SSH<TrustedAnchor><Keystore> and enabled server authentication =96= =20 > that is Hermes now authenticates other MSH=92s (servers) it is=20 > attempting to set up a session with. > > What I would like to know is how to activate Client Authentication in=20 > Hermes ie how to get Hermes to initiate a remote client authentication=20 > process. > > Regards > > Joseph F. Portelli > > Telstra Research Laboratories > > ( +61 (0)2 8255 3099 > > 7 +61 (0)2 8255 3153 > > =9C 3/400 George Street, Sydney, NSW 2000 > > =9A _<_mailto:joe...@te....com_>___ > |
|
From: Patrick Y. <kc...@ce...> - 2005-06-18 03:14:28
|
Steven and Ronald, good to know that.. really encouraging. Regards, -Patrick Ronald van Kuijk wrote: >3000 documents a week? Each document is? 10-100k ? Easilly. Even in one hour I think. > >Ronald > >Steven Herod probeerde me het volgende duidelijk te maken: > > >>Who out there uses Hermes in a real life production environment? >> >>If so, what kind of volumes do you process with it? >> >>In our case, we do use it in a production environment, transacting about >>3000 documents a week. >> >>Anybody else? >> >> >> >> >>------------------------------------------------------- >>SF.Net email is sponsored by: Discover Easy Linux Migration Strategies >>from IBM. Find simple to follow Roadmaps, straightforward articles, >>informative Webcasts and more! Get everything you need to get up to >>speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click >>_______________________________________________ >>ebxmlms-general mailing list >>ebx...@li... >>https://lists.sourceforge.net/lists/listinfo/ebxmlms-general >> >> >> > > > > |
|
From: Mattias J <mj...@ex...> - 2005-06-16 16:05:08
|
Not sure I understand your question. As detailed in my initially referenced bug report (http://issues.apache.org/jira/browse/AXIS-1469) Axis cannot handle first calling saveChanges() and then, after making further changes, calling writeTo(); which is exactly what Hermes does. At 2005-06-16 16:11, you wrote: >What information does AXIS need? Can you just not create a default AXIS >delta? > >DW > >----- Original Message ----- >From: "Mattias J" <mj...@ex...> >To: <ebx...@li...> >Sent: Thursday, June 16, 2005 7:45 AM >Subject: Re: [ebxmlms-general] Axis incompatibilities > > > > At 2005-06-16 13:25, you wrote: > > >...or also passing the full content via jms/webservice/file is possible. > > > > > >Look at how the monitor application communicates with the server. Two > > >different jvm's and it > > >works. That is the main part of the solution, two different jvm's > > > > (But then again, I cannot create the full content - i.e. the SOAP message > > with ebXML header - because of the Axis incompatibiltiy...) > > > > > > > > > > ------------------------------------------------------- > > SF.Net email is sponsored by: Discover Easy Linux Migration Strategies > > from IBM. Find simple to follow Roadmaps, straightforward articles, > > informative Webcasts and more! Get everything you need to get up to > > speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click > > _______________________________________________ > > ebxmlms-general mailing list > > ebx...@li... > > https://lists.sourceforge.net/lists/listinfo/ebxmlms-general > > > > > >------------------------------------------------------- >SF.Net email is sponsored by: Discover Easy Linux Migration Strategies >from IBM. Find simple to follow Roadmaps, straightforward articles, >informative Webcasts and more! Get everything you need to get up to >speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click >_______________________________________________ >ebxmlms-general mailing list >ebx...@li... >https://lists.sourceforge.net/lists/listinfo/ebxmlms-general |
266 messages has been excluded from this view by a project administrator.
