[jira] Commented: (GERONIMO-2880) TransportDisposedIOException occurs when trying to close ActiveMQ queue
[ https://issues.apache.org/jira/browse/GERONIMO-2880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12538426 ] Vamsavardhana Reddy commented on GERONIMO-2880: --- Completed: At revision: 589532 o Thanks to Anish for providing the patch o Use a non XA datasource for activemq persistence **: This commit can use a review. > TransportDisposedIOException occurs when trying to close ActiveMQ queue > --- > > Key: GERONIMO-2880 > URL: https://issues.apache.org/jira/browse/GERONIMO-2880 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: ActiveMQ >Affects Versions: 2.0.x, 2.1 > Environment: Windows XP SP2 >Reporter: Aman Nanner >Assignee: Vamsavardhana Reddy >Priority: Critical > Fix For: 2.0.x, 2.1 > > Attachments: AMQ_NoTxDatasource.patch > > > I have discovered some problems with queues while running unittest in our own > J2EE app. > After sending a message on a queue, when we try to call the close() method on > the queue, we get the following exception: > > org.apache.activemq.transport.TransportDisposedIOException: Peer > (vm://localhost#69) disposed. > > where the number after "localhost" is different every time. > We do not experience this problem with topics. We are using ActiveMQ as part > of an "embedded" configuration with Geronimo. > I've done some debugging and the problem occurs at this line in the > ActiveMQMessageProducer.close() method: > > this.session.asyncSendPacket(info.createRemoveCommand()); > > The queue itself is disposed properly in the dispose() method that is called > in the line before, but this sending of the asynchronous packet fails. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-2880) TransportDisposedIOException occurs when trying to close ActiveMQ queue
[ https://issues.apache.org/jira/browse/GERONIMO-2880?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vamsavardhana Reddy updated GERONIMO-2880: -- Affects Version/s: 2.1 Assignee: Vamsavardhana Reddy > TransportDisposedIOException occurs when trying to close ActiveMQ queue > --- > > Key: GERONIMO-2880 > URL: https://issues.apache.org/jira/browse/GERONIMO-2880 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: ActiveMQ >Affects Versions: 2.0.x, 2.1 > Environment: Windows XP SP2 >Reporter: Aman Nanner >Assignee: Vamsavardhana Reddy >Priority: Critical > Fix For: 2.0.x, 2.1 > > Attachments: AMQ_NoTxDatasource.patch > > > I have discovered some problems with queues while running unittest in our own > J2EE app. > After sending a message on a queue, when we try to call the close() method on > the queue, we get the following exception: > > org.apache.activemq.transport.TransportDisposedIOException: Peer > (vm://localhost#69) disposed. > > where the number after "localhost" is different every time. > We do not experience this problem with topics. We are using ActiveMQ as part > of an "embedded" configuration with Geronimo. > I've done some debugging and the problem occurs at this line in the > ActiveMQMessageProducer.close() method: > > this.session.asyncSendPacket(info.createRemoveCommand()); > > The queue itself is disposed properly in the dispose() method that is called > in the line before, but this sending of the asynchronous packet fails. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Promoting GShell to a real subproject
+1 Jason's +1 On Oct 28, 2007, at 6:21 PM, Jason Dillon wrote: I'm obviously +1 for a sub-project ;-) --jason On Oct 26, 2007, at 10:58 AM, Kevan Miller wrote: On Oct 26, 2007, at 10:35 AM, Prasad Kashyap wrote: I don't see why we shouldn't. But can someone more informed please list the pros and cons. Here's my list: Pro's * Easier for other projects to reuse GShell * Release cycle not tied to Geronimo server release cycle Con's * Small overhead for being a separately released project -- documentation, release voting, etc * Separate source tree can complicate debugging (can make the counterpoint that debugging GShell is easier...) The Geronimo tx-manager components (transaction and connector) is another example where we've done this. Note that prior to (or concurrent with) voting on our last two releases, we've been voting on a tx-manager release. Although it need not be that way, we're falling into a lock-step release cycle... I assume that Guillaume is interested in using GShell outside of Geronimo. I assume that there will be others... I'd support GShell as a subproject... --kevan
Re: TCK access
I sent him a private ping as well just as a heads up. On Oct 27, 2007, at 10:52 AM, Alan D. Cabrera wrote: On Oct 27, 2007, at 5:13 AM, Kevan Miller wrote: On Oct 26, 2007, at 11:57 PM, Alan D. Cabrera wrote: I think that Geir has to ACK that the paperwork was completed. Has he done so? I don't see an ACK on our tck list. I recall that Tim had a lot of problems getting the NDA acked. Geir, Do you have an NDA on file for Jay McHugh? If not, what's the best way for him to get this to you? He may not be reading this list intently. I'll forward to the TCK list. Regards, Alan
Re: Promoting GShell to a real subproject
I'm obviously +1 for a sub-project ;-) --jason On Oct 26, 2007, at 10:58 AM, Kevan Miller wrote: On Oct 26, 2007, at 10:35 AM, Prasad Kashyap wrote: I don't see why we shouldn't. But can someone more informed please list the pros and cons. Here's my list: Pro's * Easier for other projects to reuse GShell * Release cycle not tied to Geronimo server release cycle Con's * Small overhead for being a separately released project -- documentation, release voting, etc * Separate source tree can complicate debugging (can make the counterpoint that debugging GShell is easier...) The Geronimo tx-manager components (transaction and connector) is another example where we've done this. Note that prior to (or concurrent with) voting on our last two releases, we've been voting on a tx-manager release. Although it need not be that way, we're falling into a lock-step release cycle... I assume that Guillaume is interested in using GShell outside of Geronimo. I assume that there will be others... I'd support GShell as a subproject... --kevan
Re: deploying snapshots of the samples to a new location in m2-snapshot-repo
Cool, thanks. Any thoughts on setting up automated builds of Samples at least once a week? Also, maybe a samples project under the server testsuite dir that verifies each sample can be installed and functions? -Donald Jarek Gawor wrote: This should be fixed now plus some other things I've found (i.e. licenses). Jarek On 10/27/07, Donald Woods <[EMAIL PROTECTED]> wrote: I believe there a couple samples still using org.apache.geronimo.applications instead of the new org.apache.geronimo.samples groupId -Donald Paul McMahan wrote: Jarek helped on GERONIMO-2784 by moving the samples from server/trunk to samples/trunk. Now I would like to deploy those samples to the ASF snapshot repo so they can still be downloaded/installed from Geronimo's plugin catalog.This notification starts a 3 day lazy consensus timer for the PMC before I will deploy the snapshots to their new location in the ASF snapshot repo.Up until now the samples have been voted on and deployed concurrently with the server.See the JIRA for details. https://issues.apache.org/jira/browse/GERONIMO-2784 Best wishes, Paul smime.p7s Description: S/MIME Cryptographic Signature
Re: Build problem
Kevan, that was the cure, thanks. On 10/28/07, Kevan Miller <[EMAIL PROTECTED]> wrote: > > > On Oct 28, 2007, at 4:30 AM, Heinz Drews wrote: > > > Hello, > > > > is there any fix or bypass available to get rid of > > > > [INFO] > > > > [ERROR] BUILD ERROR > > [INFO] > > > > [INFO] Failed to resolve artifact. > > > > Missing: > > -- > > 1) castor:castor:jar:0.9.9.0-pre > > > > Heinz > I thought there was a work-around for this in the latest trunk source. > > I'd remove groovy-all from your m2 repo (e.g. rm -rf ~/.m2/repository/ > groovy/groovy-all ) svn up and rebuild. > > --kevan >
Re: Build problem
On Oct 28, 2007, at 4:30 AM, Heinz Drews wrote: Hello, is there any fix or bypass available to get rid of [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve artifact. Missing: -- 1) castor:castor:jar:0.9.9.0-pre Heinz I thought there was a work-around for this in the latest trunk source. I'd remove groovy-all from your m2 repo (e.g. rm -rf ~/.m2/repository/ groovy/groovy-all ) svn up and rebuild. --kevan
Re: Build problem
On 10/28/07, Heinz Drews <[EMAIL PROTECTED]> wrote: > Hello, > > is there any fix or bypass available to get rid of > > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Failed to resolve artifact. > > Missing: > -- > 1) castor:castor:jar:0.9.9.0-pre > > Try downloading the file manually from the project website. > > Then, install it using the command: >mvn install:install-file -DgroupId=castor -DartifactId=castor \ > -Dversion=0.9.9.0-pre -Dpackaging=jar -Dfile=/path/to/file > Alternatively, if you host your own repository you can deploy the file > there: mvn deploy:deploy-file -DgroupId=castor -DartifactId=castor \ > -Dversion=0.9.9.0-pre -Dpackaging=jar -Dfile=/path/to/file \ >-Durl=[url] -DrepositoryId=[id] > > Path to dependency: > 1) org.apache.geronimo:repository:jar:2.1-SNAPSHOT > 2) groovy:groovy-all:jar: 1.0 > 3) openejb:openejb-loader:jar:1.0 > 4) openejb:openejb-core:jar:1.0 > 5) castor:castor:jar:0.9.9.0-pre It appears it's the issue with broken groovy-all artifact in m2 repo. I built Geronimo yesterday without any troubles, but I suspect that m2 downloaded groovy-all long before it got broken and thus I'm not running into it. If I run into the issue, I'd download groovy from its website and install the file manually (replace the broken jar file with the file from groovy distro). Start the build process over. Jacek -- Jacek Laskowski http://www.JacekLaskowski.pl
Build problem
Hello, is there any fix or bypass available to get rid of [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve artifact. Missing: -- 1) castor:castor:jar:0.9.9.0-pre Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=castor -DartifactId=castor \ -Dversion=0.9.9.0-pre -Dpackaging=jar -Dfile=/path/to/file Alternatively, if you host your own repository you can deploy the file there: mvn deploy:deploy-file -DgroupId=castor -DartifactId=castor \ -Dversion=0.9.9.0-pre -Dpackaging=jar -Dfile=/path/to/file \ -Durl=[url] -DrepositoryId=[id] Path to dependency: 1) org.apache.geronimo:repository:jar:2.1-SNAPSHOT 2) groovy:groovy-all:jar:1.0 3) openejb:openejb-loader:jar:1.0 4) openejb:openejb-core:jar:1.0 5) castor:castor:jar:0.9.9.0-pre Best regards, Heinz
