Menu
▾
▴
openjms-developer — List for OpenJMS developer discussions of coding, changes, and architecture
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(3) |
Oct
(8) |
Nov
(25) |
Dec
(4) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(85) |
Feb
(20) |
Mar
(19) |
Apr
(23) |
May
(20) |
Jun
(33) |
Jul
(57) |
Aug
(38) |
Sep
(12) |
Oct
(28) |
Nov
(10) |
Dec
(22) |
| 2004 |
Jan
(42) |
Feb
(8) |
Mar
(11) |
Apr
(6) |
May
(41) |
Jun
(16) |
Jul
(23) |
Aug
(3) |
Sep
(11) |
Oct
(11) |
Nov
(3) |
Dec
(18) |
| 2005 |
Jan
(6) |
Feb
(11) |
Mar
(13) |
Apr
(16) |
May
(20) |
Jun
(29) |
Jul
(21) |
Aug
(14) |
Sep
(4) |
Oct
(9) |
Nov
(3) |
Dec
(15) |
| 2006 |
Jan
(6) |
Feb
(9) |
Mar
|
Apr
(1) |
May
(9) |
Jun
(10) |
Jul
(1) |
Aug
(2) |
Sep
(4) |
Oct
|
Nov
(1) |
Dec
(8) |
| 2007 |
Jan
|
Feb
(3) |
Mar
(8) |
Apr
(17) |
May
(1) |
Jun
(2) |
Jul
(6) |
Aug
|
Sep
|
Oct
(1) |
Nov
(2) |
Dec
|
| 2008 |
Jan
(1) |
Feb
(5) |
Mar
(1) |
Apr
(7) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
|
Dec
|
| 2010 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Tim A. <tm...@ne...> - 2008-10-27 00:23:35
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body bgcolor="#ffffff" text="#000000"> We no longer support JDBM, as we had issues with database corruption.<br> <br> -Tim<br> <br> Florent Gratta wrote: <blockquote cite="mid:E05...@ex..." type="cite"> <meta http-equiv="Content-Type" content="text/html; "> <meta name="Generator" content="MS Exchange Server version 6.5.7652.24"> <title>Usage of JDBM : Experience feedbacks</title> <!-- Converted from text/rtf format --> <p align="left"><span lang="fr"><font face="Arial" size="2">Hi All,</font></span></p> <p align="left"><span lang="en-gb"><font face="Arial" size="2">I am currently Project Lead at Sicap, a Swiss company which designs softwares for mobile operators and the mobile network world in general.</font></span></p> <p align="left"><span lang="en-gb"><font face="Arial" size="2">We are going to use a BTree library to index entries of csv files. We have identified JDBM library (</font></span><span lang="fr"></span><a moz-do-not-send="true" href="http://jdbm.sourceforge.net/%29"><span lang="fr"></span><span lang="fr"></span><u><span lang="en-gb"><font color="#0000ff" face="Arial" size="2">http://jdbm.sourceforge.net/)</font></span></u><span lang="fr"></span></a><span lang="fr"></span><span lang="fr"></span><span lang="en-gb"><font face="Arial" size="2"> and we have seen that you are currently using it in</font></span><span lang="fr"></span><span lang="fr"></span><span lang="en-gb"> <font color="#000000" face="Arial" size="2">Open JMS</font></span><span lang="fr"></span><span lang="fr"></span><span lang="en-gb"><font face="Arial" size="2">.</font></span></p> <p align="left"><span lang="en-gb"><font face="Arial" size="2">As there is no more tracker activity on this project and it seems that it is the same thing for support, we would like to know if JDBM is stable:</font></span></p> <p><span lang="en-gb"><font face="Wingdings" size="2">è<font face="Courier New"> </font></font></span><span lang="en-gb"></span><span lang="fr"></span><span lang="fr"></span><span lang="en-gb"> <font face="Arial" size="2">Have you encountered problems when you use this library in multithreaded mode: Several concurrent inserts at a time?</font></span></p> <p><span lang="en-gb"><font face="Wingdings" size="2">è<font face="Courier New"> </font></font></span><span lang="en-gb"> <font face="Arial" size="2">What is the behaviour of the library when we shut down with emergency? Is it robust? By this way, does BTree file could be corrupted?</font></span></p> <p><span lang="en-gb"><font face="Wingdings" size="2">è<font face="Courier New"> </font></font></span><span lang="en-gb"> <font face="Arial" size="2">Do you encountered performance lack in some cases?</font></span> <br> <span lang="en-gb"><font face="Wingdings" size="2">è<font face="Courier New"> </font></font></span><span lang="en-gb"> <font face="Arial" size="2">Is there some limitations or lacks: Size of the index chain, cache size etc ...</font></span> <br> <span lang="en-gb"><font face="Wingdings" size="2">è<font face="Courier New"> </font></font></span><span lang="en-gb"> <font face="Arial" size="2">Etc ...</font></span> </p> <p align="left"><span lang="en-gb"><font face="Arial" size="2">We are very interested on your feedbacks and experiences on JDBM library usage ?</font></span></p> <p align="left"><span lang="fr-fr"><font face="Arial" size="2">Thank’s a lot,</font></span></p> <p align="left"><span lang="fr-fr"><font face="Arial" size="2">Kind Regards,</font></span></p> <p align="left"><span lang="fr-fr"><font face="Arial" size="2">Florent GRATTA</font></span></p> <p align="left"><span lang="fr-fr"><font face="Arial" size="1">Framework Project Leader, DeVelopment and Operation, Sicap France SAS</font></span></p> <p align="left"><span lang="fr-fr"><font face="Arial" size="1">Phone +334 37 37 69 96, Fax +334 37 37 69 99, Mobile +336 81 76 58 02</font></span></p> <p align="left"><span lang="fr-fr"><font face="Arial" size="1">Postal Address: 50 rue de marseille, 69007 Lyon, France</font></span></p> <p align="left"><span lang="fr-fr"><font face="Arial" size="1">mailto:</font></span><span lang="fr"> </span><a moz-do-not-send="true" href="mailto:flo...@si..."><span lang="fr"></span><span lang="fr"></span><u><span lang="fr-fr"><font color="#0000ff" face="Arial" size="1">flo...@si...</font></span></u><span lang="fr"></span></a><span lang="fr"></span><span lang="fr"></span><span lang="fr-fr"><font face="Arial" size="1">,</font></span><span lang="fr"> </span><a moz-do-not-send="true" href="http://www.sicap.com"><span lang="fr"></span><span lang="fr"></span><u><span lang="fr-fr"><font color="#0000ff" face="Arial" size="1">http://www.sicap.com</font></span></u><span lang="fr"></span></a><span lang="fr"></span><span lang="fr"></span><span lang="fr-fr"><font face="Arial" size="1">, Skype: florent_gratta</font></span></p> <!--[object_id=#sicap-france.com#]--><font face="Tahoma" size="2"><font color="#0000ff"> <div dir="ltr"><span><font color="#000000" face="Arial" size="1"> <hr></font></span></div> <div dir="ltr"><span><font color="#000000" face="Arial" size="1">This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden.</font></span></div> </font></font> <pre wrap=""> </pre> </blockquote> <br> </body> </html> |
|
From: Florent G. <flo...@si...> - 2008-10-22 10:19:51
|
Hi All, I am currently Project Lead at Sicap, a Swiss company which designs softwares for mobile operators and the mobile network world in general. We are going to use a BTree library to index entries of csv files. We have identified JDBM library (http://jdbm.sourceforge.net/) and we have seen that you are currently using it in Open JMS. As there is no more tracker activity on this project and it seems that it is the same thing for support, we would like to know if JDBM is stable: ==> Have you encountered problems when you use this library in multithreaded mode: Several concurrent inserts at a time? ==> What is the behaviour of the library when we shut down with emergency? Is it robust? By this way, does BTree file could be corrupted? ==> Do you encountered performance lack in some cases? ==> Is there some limitations or lacks: Size of the index chain, cache size etc ... ==> Etc ... We are very interested on your feedbacks and experiences on JDBM library usage ? Thank's a lot, Kind Regards, Florent GRATTA Framework Project Leader, DeVelopment and Operation, Sicap France SAS Phone +334 37 37 69 96, Fax +334 37 37 69 99, Mobile +336 81 76 58 02 Postal Address: 50 rue de marseille, 69007 Lyon, France mailto: flo...@si..., http://www.sicap.com, Skype: florent_gratta This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden. |
|
From: SourceForge.net <no...@so...> - 2008-04-30 23:10:13
|
Bugs item #1955171, was opened at 2008-04-30 18:03 Message generated for change (Comment added) made by kashabm You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=474136&aid=1955171&group_id=54559 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: jndi Group: v0.7.7-beta-1 Status: Open Resolution: None Priority: 7 Private: No Submitted By: kashabm (kashabm) Assigned to: Nobody/Anonymous (nobody) Summary: Issue with Hierarchical topics Initial Comment: I am trying to create hierarchical topics and I have the following in the configuration file: <AdministeredTopic name="Topic1.Topic2" /> <AdministeredTopic name="Topic1.Topic2.Topic3" /> The creation of these topics seems to be fine. However, when "Topic1.Topic2.Topic3" is looked up in the JNDI context as follows, there is an exception thrown: Topic topic = (Topic) context.lookup( "Topic1.Topic2.Topic3" ); The exception stackTrace is as follows: javax.naming.NotContextException: Topic1/Topic2 at org.codehaus.spice.jndikit.AbstractLocalContext.lookupSubContext(AbstractLocalContext.java:380) at org.codehaus.spice.jndikit.AbstractLocalContext.lookup(AbstractLocalContext.java:311) at org.codehaus.spice.jndikit.rmi.server.RMINamingProviderImpl.lookup(RMINamingProviderImpl.java:158) at org.exolab.jms.server.net.RemoteNamingProvider.lookup(RemoteNamingProvider.java:126) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.exolab.jms.net.orb.DefaultORB$Handler.invoke(DefaultORB.java:572) at org.exolab.jms.net.orb.DefaultORB$1.run(DefaultORB.java:530) at org.exolab.jms.common.threads.ThreadPool$NotifyingRunnable.run(ThreadPool.java:211) at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Thread.java:619) If "Topic1/Topic2" is not created by having only <AdministeredTopic name="Topic1.Topic2.Topic3" /> in the config file, everything works fine. I am not sure if this is an expected behavior but I was expecting to create hierarchical chain of topics and subscribe to specific topics in the chain. Thanks, K ---------------------------------------------------------------------- >Comment By: kashabm (kashabm) Date: 2008-04-30 18:10 Message: Logged In: YES user_id=1927704 Originator: YES Correction: The hierarchical topic is actually looked up as follows Topic topic = (Topic) context.lookup( "Topic1/Topic2/Topic3" ); However, the hierarchical topic is specified as <AdministeredTopic name="Topic1.Topic2.Topic3" /> in the config file. Thanks, K ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=474136&aid=1955171&group_id=54559 |
|
From: SourceForge.net <no...@so...> - 2008-04-30 23:04:29
|
Bugs item #1955171, was opened at 2008-04-30 18:03 Message generated for change (Settings changed) made by kashabm You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=474136&aid=1955171&group_id=54559 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: jndi Group: v0.7.7-beta-1 Status: Open Resolution: None >Priority: 7 Private: No Submitted By: kashabm (kashabm) Assigned to: Nobody/Anonymous (nobody) Summary: Issue with Hierarchical topics Initial Comment: I am trying to create hierarchical topics and I have the following in the configuration file: <AdministeredTopic name="Topic1.Topic2" /> <AdministeredTopic name="Topic1.Topic2.Topic3" /> The creation of these topics seems to be fine. However, when "Topic1.Topic2.Topic3" is looked up in the JNDI context as follows, there is an exception thrown: Topic topic = (Topic) context.lookup( "Topic1.Topic2.Topic3" ); The exception stackTrace is as follows: javax.naming.NotContextException: Topic1/Topic2 at org.codehaus.spice.jndikit.AbstractLocalContext.lookupSubContext(AbstractLocalContext.java:380) at org.codehaus.spice.jndikit.AbstractLocalContext.lookup(AbstractLocalContext.java:311) at org.codehaus.spice.jndikit.rmi.server.RMINamingProviderImpl.lookup(RMINamingProviderImpl.java:158) at org.exolab.jms.server.net.RemoteNamingProvider.lookup(RemoteNamingProvider.java:126) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.exolab.jms.net.orb.DefaultORB$Handler.invoke(DefaultORB.java:572) at org.exolab.jms.net.orb.DefaultORB$1.run(DefaultORB.java:530) at org.exolab.jms.common.threads.ThreadPool$NotifyingRunnable.run(ThreadPool.java:211) at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Thread.java:619) If "Topic1/Topic2" is not created by having only <AdministeredTopic name="Topic1.Topic2.Topic3" /> in the config file, everything works fine. I am not sure if this is an expected behavior but I was expecting to create hierarchical chain of topics and subscribe to specific topics in the chain. Thanks, K ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=474136&aid=1955171&group_id=54559 |
|
From: SourceForge.net <no...@so...> - 2008-04-30 23:03:50
|
Bugs item #1955171, was opened at 2008-04-30 18:03 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=474136&aid=1955171&group_id=54559 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: jndi Group: v0.7.7-beta-1 Status: Open Resolution: None Priority: 5 Private: No Submitted By: kashabm (kashabm) Assigned to: Nobody/Anonymous (nobody) Summary: Issue with Hierarchical topics Initial Comment: I am trying to create hierarchical topics and I have the following in the configuration file: <AdministeredTopic name="Topic1.Topic2" /> <AdministeredTopic name="Topic1.Topic2.Topic3" /> The creation of these topics seems to be fine. However, when "Topic1.Topic2.Topic3" is looked up in the JNDI context as follows, there is an exception thrown: Topic topic = (Topic) context.lookup( "Topic1.Topic2.Topic3" ); The exception stackTrace is as follows: javax.naming.NotContextException: Topic1/Topic2 at org.codehaus.spice.jndikit.AbstractLocalContext.lookupSubContext(AbstractLocalContext.java:380) at org.codehaus.spice.jndikit.AbstractLocalContext.lookup(AbstractLocalContext.java:311) at org.codehaus.spice.jndikit.rmi.server.RMINamingProviderImpl.lookup(RMINamingProviderImpl.java:158) at org.exolab.jms.server.net.RemoteNamingProvider.lookup(RemoteNamingProvider.java:126) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.exolab.jms.net.orb.DefaultORB$Handler.invoke(DefaultORB.java:572) at org.exolab.jms.net.orb.DefaultORB$1.run(DefaultORB.java:530) at org.exolab.jms.common.threads.ThreadPool$NotifyingRunnable.run(ThreadPool.java:211) at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Thread.java:619) If "Topic1/Topic2" is not created by having only <AdministeredTopic name="Topic1.Topic2.Topic3" /> in the config file, everything works fine. I am not sure if this is an expected behavior but I was expecting to create hierarchical chain of topics and subscribe to specific topics in the chain. Thanks, K ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=474136&aid=1955171&group_id=54559 |
|
From: Tim A. <tm...@ne...> - 2008-04-10 05:53:31
|
Odd. The server shouldn't be trying to establish a separate connection - all data should be multiplexed over the connection initiated by the client. The call to AbstractConnectionManager.allocateConnection() should match the existing ManagedConnection held by the connection pool, and return a reference to it. Any chance you can debug it? Thanks, Tim Dean Anderson wrote: > Hi folks! > > I notice that the internal orb(?) tries to establish a separate TCP/TCPS > connection to NOTIFY the client of a new message. This doesn't work so > well if the client is behind a nat. The client picks all queued > messages on establishing the connection, but no new messages thereafter. > The following exception is seen on the server. > > Any suggestions? http tunneling is umm, undesirable. I need a ssl tcp > connection established by the client that is used for _all_ > communication between client and server during the session. BTW, it > also seems to be a significant performance/time delay hit to establish > separate tcp/tcps connections, anyway. Is this an easy fix? I'm no > expert on RMI, though. > > Thanks! > > --Dean > > > > 21:54:23.456 DEBUG [Scheduler-Worker-3] - Failed to notify client > java.rmi.RemoteException: Failed to connect to 192.168.2.101:54848; > nested exception is: > org.exolab.jms.net.connector.ResourceException: Failed to > connect to 192.168.2.101:54848 > at > org.exolab.jms.client.net.JmsSessionStubImpl__Proxy.onMessageAvailable(JmsSessionStubImpl__Proxy.java:26 > 5) > at > org.exolab.jms.server.SessionConsumer.notifyMessageAvailable(SessionConsumer.java:527) > at > org.exolab.jms.server.SessionConsumer.dispatch(SessionConsumer.java:505) > at > org.exolab.jms.server.SessionConsumer.access$000(SessionConsumer.java:78) > at > org.exolab.jms.server.SessionConsumer$1.run(SessionConsumer.java:155) > at org.exolab.jms.scheduler.SerialTask.run(SerialTask.java:164) > at > org.exolab.jms.common.threads.ThreadPool$NotifyingRunnable.run(ThreadPool.java:211) > at > EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(Unknown > Source) > at java.lang.Thread.run(Thread.java:595) > Caused by: org.exolab.jms.net.connector.ResourceException: Failed to > connect to 192.168.2.101:54848 > at > org.exolab.jms.net.socket.SocketManagedConnection.createSocketProtected(SocketManagedConnection.java:270 > ) > at > org.exolab.jms.net.socket.SocketManagedConnection.createSocket(SocketManagedConnection.java:182) > at > org.exolab.jms.net.tcp.TCPSManagedConnection.createSocket(TCPSManagedConnection.java:113) > at > org.exolab.jms.net.socket.SocketManagedConnection.<init>(SocketManagedConnection.java:114) > at > org.exolab.jms.net.tcp.TCPSManagedConnection.<init>(TCPSManagedConnection.java:79) > at > org.exolab.jms.net.tcp.TCPSManagedConnectionFactory.createManagedConnection(TCPSManagedConnectionFactory > .java:98) > at > org.exolab.jms.net.connector.DefaultConnectionPool.createManagedConnection(DefaultConnectionPool.java:23 > 3) > at > org.exolab.jms.net.connector.AbstractConnectionManager.allocateConnection(AbstractConnectionManager.java > :140) > at > org.exolab.jms.net.connector.AbstractConnectionFactory.getConnection(AbstractConnectionFactory.java:167) > at > org.exolab.jms.net.connector.AbstractConnectionManager.getConnection(AbstractConnectionManager.java:208) > at > org.exolab.jms.net.connector.AbstractConnectionManager.getConnection(AbstractConnectionManager.java:187) > at > org.exolab.jms.net.orb.UnicastDelegate.getConnection(UnicastDelegate.java:189) > at > org.exolab.jms.net.orb.UnicastDelegate.invoke(UnicastDelegate.java:153) > at org.exolab.jms.net.proxy.Proxy.invoke(Proxy.java:102) > at > org.exolab.jms.client.net.JmsSessionStubImpl__Proxy.onMessageAvailable(JmsSessionStubImpl__Proxy.java:25 > 9) > > > |
|
From: Dean A. <de...@av...> - 2008-04-08 17:27:11
|
Hi folks!
I notice that the internal orb(?) tries to establish a separate TCP/TCPS
connection to NOTIFY the client of a new message. This doesn't work so
well if the client is behind a nat. The client picks all queued
messages on establishing the connection, but no new messages thereafter.
The following exception is seen on the server.
Any suggestions? http tunneling is umm, undesirable. I need a ssl tcp
connection established by the client that is used for _all_
communication between client and server during the session. BTW, it
also seems to be a significant performance/time delay hit to establish
separate tcp/tcps connections, anyway. Is this an easy fix? I'm no
expert on RMI, though.
Thanks!
--Dean
21:54:23.456 DEBUG [Scheduler-Worker-3] - Failed to notify client
java.rmi.RemoteException: Failed to connect to 192.168.2.101:54848;
nested exception is:
org.exolab.jms.net.connector.ResourceException: Failed to
connect to 192.168.2.101:54848
at
org.exolab.jms.client.net.JmsSessionStubImpl__Proxy.onMessageAvailable(JmsSessionStubImpl__Proxy.java:26
5)
at
org.exolab.jms.server.SessionConsumer.notifyMessageAvailable(SessionConsumer.java:527)
at
org.exolab.jms.server.SessionConsumer.dispatch(SessionConsumer.java:505)
at
org.exolab.jms.server.SessionConsumer.access$000(SessionConsumer.java:78)
at
org.exolab.jms.server.SessionConsumer$1.run(SessionConsumer.java:155)
at org.exolab.jms.scheduler.SerialTask.run(SerialTask.java:164)
at
org.exolab.jms.common.threads.ThreadPool$NotifyingRunnable.run(ThreadPool.java:211)
at
EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(Unknown
Source)
at java.lang.Thread.run(Thread.java:595)
Caused by: org.exolab.jms.net.connector.ResourceException: Failed to
connect to 192.168.2.101:54848
at
org.exolab.jms.net.socket.SocketManagedConnection.createSocketProtected(SocketManagedConnection.java:270
)
at
org.exolab.jms.net.socket.SocketManagedConnection.createSocket(SocketManagedConnection.java:182)
at
org.exolab.jms.net.tcp.TCPSManagedConnection.createSocket(TCPSManagedConnection.java:113)
at
org.exolab.jms.net.socket.SocketManagedConnection.<init>(SocketManagedConnection.java:114)
at
org.exolab.jms.net.tcp.TCPSManagedConnection.<init>(TCPSManagedConnection.java:79)
at
org.exolab.jms.net.tcp.TCPSManagedConnectionFactory.createManagedConnection(TCPSManagedConnectionFactory
.java:98)
at
org.exolab.jms.net.connector.DefaultConnectionPool.createManagedConnection(DefaultConnectionPool.java:23
3)
at
org.exolab.jms.net.connector.AbstractConnectionManager.allocateConnection(AbstractConnectionManager.java
:140)
at
org.exolab.jms.net.connector.AbstractConnectionFactory.getConnection(AbstractConnectionFactory.java:167)
at
org.exolab.jms.net.connector.AbstractConnectionManager.getConnection(AbstractConnectionManager.java:208)
at
org.exolab.jms.net.connector.AbstractConnectionManager.getConnection(AbstractConnectionManager.java:187)
at
org.exolab.jms.net.orb.UnicastDelegate.getConnection(UnicastDelegate.java:189)
at
org.exolab.jms.net.orb.UnicastDelegate.invoke(UnicastDelegate.java:153)
at org.exolab.jms.net.proxy.Proxy.invoke(Proxy.java:102)
at
org.exolab.jms.client.net.JmsSessionStubImpl__Proxy.onMessageAvailable(JmsSessionStubImpl__Proxy.java:25
9)
--
Av8 Internet Prepared to pay a premium for better service?
www.av8.net faster, more reliable, better service
617 344 9000
|
|
From: Tim A. <tm...@ne...> - 2008-04-03 01:38:47
|
If you can generate a reproducible test case, I can look at it. Christiaan Willemsen wrote: > Hi there, > > First post and quite new on JMS, so please be nice ;) > > Let me explain first how the application works: > > I have two application that talk to each other via JMS. One acting as a > server, one as a client. > > - The client will ask the server for a session via a main JSM queue. In > the replyTo the client puts a reference to a temporary JMS queue. This > queue will be used by the session to send messages from server to client > - The server will send an acknowledge back to the temporary queue made > by the client, and will set the replyTo to a new temporary queue, that > the client thereafter uses to receives messages from the server. > - Client and server now communicate via the two temporary queues. > > This appears to work fine at first, but after the first few messages > back and forth, it looks like messages from server to client never reach > the client. Messages from client to server however appear to work just fine. > > The first few messages are of the question answer kind, anything after > that are mainly events from server to client. Apparently the first event > gets through, and after that nothing. > > I have no clue what could be wrong here.. Sessions are set to > CLIENT_ACKNOWLEDGE and I use asynchronous message handling, and I > acknowledge all packets that come in on both sides. > > Logs don't show any abnormal stuff, so I'm kind of lost right here... > Hope you can help me > > |
|
From: Christiaan W. <cwi...@te...> - 2008-04-01 13:02:27
|
Hi there, First post and quite new on JMS, so please be nice ;) Let me explain first how the application works: I have two application that talk to each other via JMS. One acting as a server, one as a client. - The client will ask the server for a session via a main JSM queue. In the replyTo the client puts a reference to a temporary JMS queue. This queue will be used by the session to send messages from server to client - The server will send an acknowledge back to the temporary queue made by the client, and will set the replyTo to a new temporary queue, that the client thereafter uses to receives messages from the server. - Client and server now communicate via the two temporary queues. This appears to work fine at first, but after the first few messages back and forth, it looks like messages from server to client never reach the client. Messages from client to server however appear to work just fine. The first few messages are of the question answer kind, anything after that are mainly events from server to client. Apparently the first event gets through, and after that nothing. I have no clue what could be wrong here.. Sessions are set to CLIENT_ACKNOWLEDGE and I use asynchronous message handling, and I acknowledge all packets that come in on both sides. Logs don't show any abnormal stuff, so I'm kind of lost right here... Hope you can help me -- Christiaan Willemsen |
|
From: SourceForge.net <no...@so...> - 2008-03-11 13:55:56
|
Bugs item #1892094, was opened at 2008-02-12 14:24 Message generated for change (Settings changed) made by arieluba You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=474136&aid=1892094&group_id=54559 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: client Group: v0.7.7-beta-1 Status: Open Resolution: None >Priority: 7 Private: No Submitted By: arielUBA (arieluba) Assigned to: Jim Alateras (jalateras) Summary: MessageConsumer.receive() get stuck in a server shutdown Initial Comment: If you are receiving messages synchronously (using a consumer) and the server is shutdown, the client still waiting for a message and does not throw any exception (neither returns null) MessageConsumer receiver = session.createConsumer(destination); connection.start(); TextMessage message = (TextMessage) receiver.receive(); If you register an ExceptionListener you realize that an exception is thrown from org.exolab.jms.client.net.JmsServerStubImpl.disconnected(Caller) but it does not have any error code. So, the JmsConnection won't be closed (because it expects JmsErrorCodes.CONNECTION_TO_SERVER_DROPPED as error code). IMHO, JmsServerStubImpl.disconnected(Caller) should be: public void disconnected(Caller caller) { if (_listener != null) { _listener.onException(new JMSException("Lost connection", JmsErrorCodes.CONNECTION_TO_SERVER_DROPPED)); } } ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=474136&aid=1892094&group_id=54559 |
|
From: SourceForge.net <no...@so...> - 2008-02-12 18:32:26
|
Bugs item #1892089, was opened at 2008-02-12 14:13 Message generated for change (Settings changed) made by arieluba You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=474136&aid=1892089&group_id=54559 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: client Group: v0.7.7-beta-1 >Status: Deleted Resolution: None Priority: 5 Private: No Submitted By: arielUBA (arieluba) Assigned to: Jim Alateras (jalateras) Summary: DELETE ME!! (1892094 dupplicate) Initial Comment: If you are receiving messages synchronously (using consumers) and the server is shut down MessageConsumer receiver = session.createConsumer(destination); connection.start(); ... = receiver.receive(); ---------------------------------------------------------------------- Comment By: arielUBA (arieluba) Date: 2008-02-12 14:26 Message: Logged In: YES user_id=1726084 Originator: YES 1892094 ---------------------------------------------------------------------- Comment By: arielUBA (arieluba) Date: 2008-02-12 14:25 Message: Logged In: YES user_id=1726084 Originator: YES By mistake I submitted a partial issue report. Please, delete this a focus on 1892094 Thanks ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=474136&aid=1892089&group_id=54559 |
|
From: SourceForge.net <no...@so...> - 2008-02-12 17:26:22
|
Bugs item #1892089, was opened at 2008-02-12 14:13 Message generated for change (Comment added) made by arieluba You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=474136&aid=1892089&group_id=54559 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: client Group: v0.7.7-beta-1 Status: Open Resolution: None Priority: 5 Private: No Submitted By: arielUBA (arieluba) Assigned to: Jim Alateras (jalateras) >Summary: DELETE ME!! (1892094 dupplicate) Initial Comment: If you are receiving messages synchronously (using consumers) and the server is shut down MessageConsumer receiver = session.createConsumer(destination); connection.start(); ... = receiver.receive(); ---------------------------------------------------------------------- >Comment By: arielUBA (arieluba) Date: 2008-02-12 14:26 Message: Logged In: YES user_id=1726084 Originator: YES 1892094 ---------------------------------------------------------------------- Comment By: arielUBA (arieluba) Date: 2008-02-12 14:25 Message: Logged In: YES user_id=1726084 Originator: YES By mistake I submitted a partial issue report. Please, delete this a focus on 1892094 Thanks ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=474136&aid=1892089&group_id=54559 |
|
From: SourceForge.net <no...@so...> - 2008-02-12 17:25:37
|
Bugs item #1892089, was opened at 2008-02-12 14:13 Message generated for change (Comment added) made by arieluba You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=474136&aid=1892089&group_id=54559 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: client Group: v0.7.7-beta-1 Status: Open Resolution: None Priority: 5 Private: No Submitted By: arielUBA (arieluba) Assigned to: Jim Alateras (jalateras) Summary: MessageConsumer.receive() get stuck in a server shutdown Initial Comment: If you are receiving messages synchronously (using consumers) and the server is shut down MessageConsumer receiver = session.createConsumer(destination); connection.start(); ... = receiver.receive(); ---------------------------------------------------------------------- >Comment By: arielUBA (arieluba) Date: 2008-02-12 14:25 Message: Logged In: YES user_id=1726084 Originator: YES By mistake I submitted a partial issue report. Please, delete this a focus on 1892094 Thanks ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=474136&aid=1892089&group_id=54559 |
|
From: SourceForge.net <no...@so...> - 2008-02-12 17:24:19
|
Bugs item #1892094, was opened at 2008-02-12 14:24 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=474136&aid=1892094&group_id=54559 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: client Group: v0.7.7-beta-1 Status: Open Resolution: None Priority: 5 Private: No Submitted By: arielUBA (arieluba) Assigned to: Jim Alateras (jalateras) Summary: MessageConsumer.receive() get stuck in a server shutdown Initial Comment: If you are receiving messages synchronously (using a consumer) and the server is shutdown, the client still waiting for a message and does not throw any exception (neither returns null) MessageConsumer receiver = session.createConsumer(destination); connection.start(); TextMessage message = (TextMessage) receiver.receive(); If you register an ExceptionListener you realize that an exception is thrown from org.exolab.jms.client.net.JmsServerStubImpl.disconnected(Caller) but it does not have any error code. So, the JmsConnection won't be closed (because it expects JmsErrorCodes.CONNECTION_TO_SERVER_DROPPED as error code). IMHO, JmsServerStubImpl.disconnected(Caller) should be: public void disconnected(Caller caller) { if (_listener != null) { _listener.onException(new JMSException("Lost connection", JmsErrorCodes.CONNECTION_TO_SERVER_DROPPED)); } } ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=474136&aid=1892094&group_id=54559 |
|
From: SourceForge.net <no...@so...> - 2008-02-12 17:13:41
|
Bugs item #1892089, was opened at 2008-02-12 14:13 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=474136&aid=1892089&group_id=54559 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: client Group: v0.7.7-beta-1 Status: Open Resolution: None Priority: 5 Private: No Submitted By: arielUBA (arieluba) Assigned to: Jim Alateras (jalateras) Summary: MessageConsumer.receive() get stuck in a server shutdown Initial Comment: If you are receiving messages synchronously (using consumers) and the server is shut down MessageConsumer receiver = session.createConsumer(destination); connection.start(); ... = receiver.receive(); ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=474136&aid=1892089&group_id=54559 |
|
From: SourceForge.net <no...@so...> - 2008-01-07 12:56:42
|
Bugs item #1865847, was opened at 2008-01-07 23:56 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=474136&aid=1865847&group_id=54559 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: transport Group: v0.7.7-beta-1 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Tim Anderson (tanderson) Assigned to: Tim Anderson (tanderson) Summary: Sessions not GC'ed on abnormal client termination Initial Comment: Originally from http://article.gmane.org/gmane.comp.java.openjms.user/3170 "A java program connects to OpenJMS and is a durable subscriber to various topics. The java program crashes and the connection to OpenJMS server is lost. When the program is run again and tries to connect to the OpenJMS server it catches an exception that the durable subscriber already exists. This only happens when a client does not cleanly disconnect form OpenJMS (that is closing all the sessions, topics ..etc)" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=474136&aid=1865847&group_id=54559 |
|
From: SourceForge.net <no...@so...> - 2007-11-01 12:45:46
|
Feature Requests item #1823333, was opened at 2007-10-31 08:15 Message generated for change (Comment added) made by mkraegeloh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=474139&aid=1823333&group_id=54559 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: enhancement Group: None Status: Open Priority: 5 Private: No Submitted By: martin kraegeloh (mkraegeloh) Assigned to: Jim Alateras (jalateras) Summary: need configurable initial callback delay Initial Comment: since I ran into a situation where the subscribe code has not yet finished when the first callback is started the qhole queueing deadlocks. I could solve this by configuring openjms to wait a few seconds before notifying the client for the first time. patch contains the code to add e.g., -DinvocationDelay=10000 to the java start command. ---------------------------------------------------------------------- >Comment By: martin kraegeloh (mkraegeloh) Date: 2007-11-01 12:45 Message: Logged In: YES user_id=552938 Originator: YES hi, you are right - sorry for that. cvs diff output now properly attached! martin File Added: diff.txt ---------------------------------------------------------------------- Comment By: Tim Anderson (tanderson) Date: 2007-11-01 03:32 Message: Logged In: YES user_id=557161 Originator: NO The patch file doesn't contain any context, so its not clear what you are trying to achieve. See http://openjms.sourceforge.net/devguide/submit.html for instructions on generating patches. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=474139&aid=1823333&group_id=54559 |
|
From: SourceForge.net <no...@so...> - 2007-11-01 03:32:01
|
Feature Requests item #1823333, was opened at 2007-10-31 19:15 Message generated for change (Comment added) made by tanderson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=474139&aid=1823333&group_id=54559 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: enhancement Group: None Status: Open Priority: 5 Private: No Submitted By: martin kraegeloh (mkraegeloh) Assigned to: Jim Alateras (jalateras) Summary: need configurable initial callback delay Initial Comment: since I ran into a situation where the subscribe code has not yet finished when the first callback is started the qhole queueing deadlocks. I could solve this by configuring openjms to wait a few seconds before notifying the client for the first time. patch contains the code to add e.g., -DinvocationDelay=10000 to the java start command. ---------------------------------------------------------------------- >Comment By: Tim Anderson (tanderson) Date: 2007-11-01 14:32 Message: Logged In: YES user_id=557161 Originator: NO The patch file doesn't contain any context, so its not clear what you are trying to achieve. See http://openjms.sourceforge.net/devguide/submit.html for instructions on generating patches. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=474139&aid=1823333&group_id=54559 |
|
From: SourceForge.net <no...@so...> - 2007-10-31 08:15:48
|
Feature Requests item #1823333, was opened at 2007-10-31 08:15 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=474139&aid=1823333&group_id=54559 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: enhancement Group: None Status: Open Priority: 5 Private: No Submitted By: martin kraegeloh (mkraegeloh) Assigned to: Jim Alateras (jalateras) Summary: need configurable initial callback delay Initial Comment: since I ran into a situation where the subscribe code has not yet finished when the first callback is started the qhole queueing deadlocks. I could solve this by configuring openjms to wait a few seconds before notifying the client for the first time. patch contains the code to add e.g., -DinvocationDelay=10000 to the java start command. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=474139&aid=1823333&group_id=54559 |
|
From: Priyadarshan, A. <Ash...@do...> - 2007-07-25 14:15:44
|
Hello: I need to improve performance with Log4j with Open JMS.=20 I am using the standard log4j JMS appender publishing to a Que. Are there any options to to add to OpenJMS and or Log4j to improve performace. Thanks -----Original Message----- From: ope...@li... [mailto:ope...@li...] On Behalf Of ope...@li... Sent: Tuesday, July 17, 2007 3:09 PM To: ope...@li... Subject: openjms-developer Digest, Vol 11, Issue 2 Send openjms-developer mailing list submissions to ope...@li... To subscribe or unsubscribe via the World Wide Web, visit https://lists.sourceforge.net/lists/listinfo/openjms-developer or, via email, send a message with subject or body 'help' to ope...@li... You can reach the person managing the list at ope...@li... When replying, please edit your Subject line so it is more specific than "Re: Contents of openjms-developer digest..." Today's Topics: 1. [ openjms-Bugs-1751688 ] Transaction in progress causes server unresponsive on topic (SourceForge.net) ---------------------------------------------------------------------- Message: 1 Date: Wed, 11 Jul 2007 00:53:56 -0700 From: "SourceForge.net" <no...@so...> Subject: [openjms-developer] [ openjms-Bugs-1751688 ] Transaction in progress causes server unresponsive on topic To: no...@so... Message-ID: <E1I...@sc...> Content-Type: text/plain; charset=3D"UTF-8" Bugs item #1751688, was opened at 2007-07-11 09:53 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting:=20 https://sourceforge.net/tracker/?func=3Ddetail&atid=3D474136&aid=3D175168= 8&gro up_id=3D54559 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: server Group: v0.7.7-beta-1 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Peter De Leuze (stardust) Assigned to: Nobody/Anonymous (nobody) Summary: Transaction in progress causes server unresponsive on topic Initial Comment: There is a problem that occurs frequently but randomly, but I cannot reproduce it. This is the scenario: 1) two jms clients connect to the same server, both on a different topic A and B. Everything works fine.=20 2) two/more additional clients are started and connect to those topics. 3) at one point, "somewhere" a transaction error is caused, and causes all connected clients to the same topic to receive jms messages: the clients send it to server topic, but no messages are propagated. Other connected clients on other topics work fine ! In the serverlog the following logstate is printed: -------------- 2007-07-11 09:29:10,234 ERROR [Scheduler-Worker-5] - Transaction in progress, allocated at java.lang.Exception at java.lang.Throwable.<init>(Throwable.java:181) at java.lang.Exception.<init>(Exception.java:29) at org.exolab.jms.persistence.DatabaseService$State.<init>(DatabaseService. java:321) at org.exolab.jms.persistence.DatabaseService.begin(DatabaseService.java:15 2) at org.exolab.jms.server.SessionConsumer.send(SessionConsumer.java:550) at org.exolab.jms.server.SessionConsumer.dispatch(SessionConsumer.java:498) at org.exolab.jms.server.SessionConsumer.access$000(SessionConsumer.java:78 ) at org.exolab.jms.server.SessionConsumer$1.run(SessionConsumer.java:155) at org.exolab.jms.scheduler.SerialTask.run(SerialTask.java:164) at org.exolab.jms.common.threads.ThreadPool$NotifyingRunnable.run(ThreadPoo l.java:211) at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Thread.java:595) 2007-07-11 09:29:10,315 ERROR [Scheduler-Worker-5] - Failed to release unsent message org.exolab.jms.persistence.PersistenceException: Transaction already in progress at java.lang.Throwable.<init>(Throwable.java:196) at java.lang.Exception.<init>(Exception.java:41) at org.exolab.jms.service.ServiceException.<init>(ServiceException.java:101 ) at org.exolab.jms.service.ServiceException.<init>(ServiceException.java:80) at org.exolab.jms.persistence.PersistenceException.<init>(PersistenceExcept ion.java:71) at org.exolab.jms.persistence.DatabaseService.begin(DatabaseService.java:15 9) at org.exolab.jms.server.SessionConsumer.send(SessionConsumer.java:594) at org.exolab.jms.server.SessionConsumer.dispatch(SessionConsumer.java:498) at org.exolab.jms.server.SessionConsumer.access$000(SessionConsumer.java:78 ) at org.exolab.jms.server.SessionConsumer$1.run(SessionConsumer.java:155) at org.exolab.jms.scheduler.SerialTask.run(SerialTask.java:164) at org.exolab.jms.common.threads.ThreadPool$NotifyingRunnable.run(ThreadPoo l.java:211) at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Thread.java:595) -------------------- 4)When new clients connect/disconnect, this does not change the unresponsiveness on the "faulty" topic. Only when the first connected client disconnects, then suddenly the server becomes again responsive on that topic !!! So, it seems that this transaction error causes the whole topic to be blocked, until the faulty client disconnects. I think it is better that it may never occur that a server just stops (partially) working because of a client error... The topic should stay responsive. ---------------------------------------------------------------------- You can respond by visiting:=20 https://sourceforge.net/tracker/?func=3Ddetail&atid=3D474136&aid=3D175168= 8&gro up_id=3D54559 ------------------------------ ------------------------------------------------------------------------ - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ------------------------------ _______________________________________________ openjms-developer mailing list ope...@li... https://lists.sourceforge.net/lists/listinfo/openjms-developer End of openjms-developer Digest, Vol 11, Issue 2 ************************************************ |
|
From: SourceForge.net <no...@so...> - 2007-07-11 07:53:53
|
Bugs item #1751688, was opened at 2007-07-11 09:53 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=474136&aid=1751688&group_id=54559 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: server Group: v0.7.7-beta-1 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Peter De Leuze (stardust) Assigned to: Nobody/Anonymous (nobody) Summary: Transaction in progress causes server unresponsive on topic Initial Comment: There is a problem that occurs frequently but randomly, but I cannot reproduce it. This is the scenario: 1) two jms clients connect to the same server, both on a different topic A and B. Everything works fine. 2) two/more additional clients are started and connect to those topics. 3) at one point, "somewhere" a transaction error is caused, and causes all connected clients to the same topic to receive jms messages: the clients send it to server topic, but no messages are propagated. Other connected clients on other topics work fine ! In the serverlog the following logstate is printed: -------------- 2007-07-11 09:29:10,234 ERROR [Scheduler-Worker-5] - Transaction in progress, allocated at java.lang.Exception at java.lang.Throwable.<init>(Throwable.java:181) at java.lang.Exception.<init>(Exception.java:29) at org.exolab.jms.persistence.DatabaseService$State.<init>(DatabaseService.java:321) at org.exolab.jms.persistence.DatabaseService.begin(DatabaseService.java:152) at org.exolab.jms.server.SessionConsumer.send(SessionConsumer.java:550) at org.exolab.jms.server.SessionConsumer.dispatch(SessionConsumer.java:498) at org.exolab.jms.server.SessionConsumer.access$000(SessionConsumer.java:78) at org.exolab.jms.server.SessionConsumer$1.run(SessionConsumer.java:155) at org.exolab.jms.scheduler.SerialTask.run(SerialTask.java:164) at org.exolab.jms.common.threads.ThreadPool$NotifyingRunnable.run(ThreadPool.java:211) at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Thread.java:595) 2007-07-11 09:29:10,315 ERROR [Scheduler-Worker-5] - Failed to release unsent message org.exolab.jms.persistence.PersistenceException: Transaction already in progress at java.lang.Throwable.<init>(Throwable.java:196) at java.lang.Exception.<init>(Exception.java:41) at org.exolab.jms.service.ServiceException.<init>(ServiceException.java:101) at org.exolab.jms.service.ServiceException.<init>(ServiceException.java:80) at org.exolab.jms.persistence.PersistenceException.<init>(PersistenceException.java:71) at org.exolab.jms.persistence.DatabaseService.begin(DatabaseService.java:159) at org.exolab.jms.server.SessionConsumer.send(SessionConsumer.java:594) at org.exolab.jms.server.SessionConsumer.dispatch(SessionConsumer.java:498) at org.exolab.jms.server.SessionConsumer.access$000(SessionConsumer.java:78) at org.exolab.jms.server.SessionConsumer$1.run(SessionConsumer.java:155) at org.exolab.jms.scheduler.SerialTask.run(SerialTask.java:164) at org.exolab.jms.common.threads.ThreadPool$NotifyingRunnable.run(ThreadPool.java:211) at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Thread.java:595) -------------------- 4)When new clients connect/disconnect, this does not change the unresponsiveness on the "faulty" topic. Only when the first connected client disconnects, then suddenly the server becomes again responsive on that topic !!! So, it seems that this transaction error causes the whole topic to be blocked, until the faulty client disconnects. I think it is better that it may never occur that a server just stops (partially) working because of a client error... The topic should stay responsive. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=474136&aid=1751688&group_id=54559 |
|
From: Dean A. <de...@av...> - 2007-07-03 13:41:17
|
On Tue, 3 Jul 2007, Tim Anderson wrote: > Not sure what you mean. When using the RMI registry, you need to > connect to it using the rmi protocol. If the tcps connector is also > configured, ConnectionFactory instances bound in the registry will > connect to the server via tcps; you need to configure the tcps > properties as per http://openjms.sourceforge.net/usersguide/tcps.html Yes. Did that: (I think): I had these properties: factoryName=ConnectionFactory destName=queue2 java.naming.factory.initial=com.sun.jndi.rmi.registry.RegistryContextFactory java.naming.provider.url=rmi://localhost:1099 username=test1 password=<deleted> org.exolab.jms.net.tcps.keyStore=client.keystore org.exolab.jms.net.tcps.keyStorePassword=<deleted> org.exolab.jms.net.tcps.trustStore=client.keystore org.exolab.jms.net.tcps.trustStorePassword=<deleted> These properties were passed to the Receiver.java program (slightly modified to load a properties file): context = new InitialContext(appProps); // look up the ConnectionFactory factory = (ConnectionFactory) context.lookup(appProps.getProperty("factoryName")); // look up the Destination dest = (Destination) context.lookup(appProps.getProperty("destName")); // create the connection connection = factory.createConnection(appProps.getProperty("username"), appProps.getProperty("password")); //connection = factory.createConnection(); // create the session session = connection.createSession( false, Session.AUTO_ACKNOWLEDGE); // create the receiver receiver = session.createConsumer(dest); // start the connection, to enable message receipt connection.start(); This works, but only if -Djavax.net.ssl.trustStore=client.keystore is added to run.sh. Otherwise, you get an unknown_certificate error. --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 |
|
From: Tim A. <tm...@ne...> - 2007-07-02 23:55:02
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Dean Anderson wrote:
<blockquote
cite="mid...@ci..."
type="cite">
<pre wrap="">On Mon, 2 Jul 2007, Tim Anderson wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Dean Anderson wrote:
</pre>
<blockquote type="cite">
<pre wrap="">First, thanks for beta 1 release.
I noticed while looking through the code that there can be only one
exception listener. The spec allows multiple listeners to be registered.
This is an easy fix.
</pre>
</blockquote>
<pre wrap="">Not sure what you mean. There can be one exception listener per
javax.jms.Connection instance.
</pre>
</blockquote>
<pre wrap=""><!---->
Hmm. Maybe I misunderstood. I'm going off the old Oreilly Java Message
Service book, which says page 123:
"It is the responsibility of the JMS provider to call the onException()
method of all registered ExceptionListeners after making reasonable
attempts to reestablish the connection automatically"
I take the plural and 'all' to mean that more than one thing (presumably
each sesssion) can register an ExceptionListener on a connection.
OpenJMS only allows one exceptionListener.
</pre>
</blockquote>
No. The Connection interface takes a single exception listener via the <br>
setExceptionListener(ExceptionListener listener) method. You're book is
just saying<br>
that each Connection instance needs to notify its associated listener
when the connection is lost.<br>
<blockquote
cite="mid...@ci..."
type="cite">
<blockquote type="cite">
<pre wrap="">You can also attempt to re-establish the connection if the
publish/subscribe fails. When caching sessions, you just need to
ensure that you synchronize access so only one thread as session at a
time.
</pre>
</blockquote>
<pre wrap=""><!---->
Ok. Thanks.
Is it safe to assume that in a web container, only one thread at a time
works on a given web request? So, if I put the JMS session object in
the web-container session store, is it safe to assume there is only one
thread that handles each web request for a given (web)session? Sorry if
this is web-specific, but any experiences with this is appreciated.
</pre>
</blockquote>
A client can submit simultaneous requests so you still need to
synchronize.<br>
<blockquote
cite="mid...@ci..."
type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">BTW, I also noticed that tcps connections don't work with an external
jndi rmi registry, unless you hard code a property for the new trust
store. Seems like something for SSL in the client doesn't get
initialized properly when using an external jndi provider. Server works
fine.
</pre>
</blockquote>
</blockquote>
<blockquote type="cite">
<pre wrap="">Haven't tried. Typically you wouldn't use an rmi registry and tcps, as
the rmi registry is not secure. You are better off using the embedded
JNDI provider.
</pre>
</blockquote>
<pre wrap=""><!---->
Oops. Good point on the RMI registry--Must make a note of that. However,
the initialization part should _still_ work. Something else might need
initialization...
Thanks!
--Dean
</pre>
</blockquote>
Not sure what you mean. When using the RMI registry, you need to
connect to it using the rmi protocol.<br>
If the tcps connector is also configured, ConnectionFactory instances
bound in the registry will connect<br>
to the server via tcps; you need to configure the tcps properties as
per <a class="moz-txt-link-freetext" href="http://openjms.sourceforge.net/usersguide/tcps.html">http://openjms.sourceforge.net/usersguide/tcps.html</a><br>
<br>
-Tim<br>
<br>
</body>
</html>
|
|
From: Dean A. <de...@av...> - 2007-07-02 20:29:15
|
On Mon, 2 Jul 2007, Tim Anderson wrote: > Dean Anderson wrote: > > First, thanks for beta 1 release. > > > > I noticed while looking through the code that there can be only one > > exception listener. The spec allows multiple listeners to be registered. > > This is an easy fix. > > > Not sure what you mean. There can be one exception listener per > javax.jms.Connection instance. Hmm. Maybe I misunderstood. I'm going off the old Oreilly Java Message Service book, which says page 123: "It is the responsibility of the JMS provider to call the onException() method of all registered ExceptionListeners after making reasonable attempts to reestablish the connection automatically" I take the plural and 'all' to mean that more than one thing (presumably each sesssion) can register an ExceptionListener on a connection. OpenJMS only allows one exceptionListener. > You can also attempt to re-establish the connection if the > publish/subscribe fails. When caching sessions, you just need to > ensure that you synchronize access so only one thread as session at a > time. Ok. Thanks. Is it safe to assume that in a web container, only one thread at a time works on a given web request? So, if I put the JMS session object in the web-container session store, is it safe to assume there is only one thread that handles each web request for a given (web)session? Sorry if this is web-specific, but any experiences with this is appreciated. > > BTW, I also noticed that tcps connections don't work with an external > > jndi rmi registry, unless you hard code a property for the new trust > > store. Seems like something for SSL in the client doesn't get > > initialized properly when using an external jndi provider. Server works > > fine. > > > Haven't tried. Typically you wouldn't use an rmi registry and tcps, as > the rmi registry is not secure. You are better off using the embedded > JNDI provider. Oops. Good point on the RMI registry--Must make a note of that. However, the initialization part should _still_ work. Something else might need initialization... Thanks! --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 |
|
From: Tim A. <tm...@ne...> - 2007-07-01 23:44:23
|
Dean Anderson wrote: > First, thanks for beta 1 release. > > I noticed while looking through the code that there can be only one > exception listener. The spec allows multiple listeners to be registered. > This is an easy fix. > Not sure what you mean. There can be one exception listener per javax.jms.Connection instance. > I noticed this while thinking about handling the case of a cached > connection in a web-app, and restarting the connection (after a jms > server restart), losing (cached) sessions, etc. > > I started thinking about that because I was thinking of using a > temporary queue in a reply-to in a web-app, and the temporary topic only > lasts as long as the connection and session, so 1) connections and > sessions have to be cached. 2) one needs to handle the case of a jms > server restart. > You can also attempt to re-establish the connection if the publish/subscribe fails. When caching sessions, you just need to ensure that you synchronize access so only one thread as session at a time. > I think a container tomcat maybe shouldn't register an exception > handler, either, though I might be able to make it work anyway... Does > anyone have any experiences they'd like to share? EJB is not a happy > choice. > > > BTW, I also noticed that tcps connections don't work with an external > jndi rmi registry, unless you hard code a property for the new trust > store. Seems like something for SSL in the client doesn't get > initialized properly when using an external jndi provider. Server works > fine. > Haven't tried. Typically you wouldn't use an rmi registry and tcps, as the rmi registry is not secure. You are better off using the embedded JNDI provider. > Thanks, > > --Dean > -Tim |
8 messages has been excluded from this view by a project administrator.
