[JBoss Web Services] New message: "Re: Out of memory occured on servlet.service()"
by Peter Johnson
User development,
A new message was posted in the thread "Out of memory occured on servlet.service()":
http://community.jboss.org/message/527996#527996
Author : Peter Johnson
Profile : http://community.jboss.org/people/peterj
Message:
--------------------------------------------------------------
As I feared, the manifest doesn't give a clue as to the JBossWS level (manisfests for newer versions of JBossAS are better at identifyiong the version of the component). And the link that Richard provided doesn't help either because it does not go back far enough. Let me see if I have a copy of 4.02 somewhere and if I can figure out which version of JBosWS it uses.
If you cannot reduce the memory usage, your only other option is to increase the max heap size. You will want to do that anyway as a temproray measure while you research other options.
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/527996#527996
16 years, 2 months
[JBoss Microcontainer Development] New message: "Re: JBDEPLOY-226 - DeployerClient change extension"
by Adrian Brock
User development,
A new message was posted in the thread "JBDEPLOY-226 - DeployerClient change extension":
http://community.jboss.org/message/527985#527985
Author : Adrian Brock
Profile : http://community.jboss.org/people/adrian@jboss.org
Message:
--------------------------------------------------------------
alesj wrote:>
> > since I want to be able to do this as well in some of the stuff I'm doing.
> Related to JBKERNEL-54 / JBOSGI-151? :-)
I don't see why resolving circular dependencies needs this feature?
The problem with Thomas's implementation (if it is like what he has done elsewhere)
is that he is doing a checkComplete() too often.
He should check them all at the end, not during/after every single move. :-)
No, it is to implement the refreshPackages() behaviour when using shutdownPolicy=GCI'm implementing it properly inside org.jboss.classloading.spi.dependency.ClassLoading
where none OSGi users can use this feature as well.
It's not strictly required, but width first processing of deployments is preferable for a
number of reasons.
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/527985#527985
16 years, 2 months
[Beginner's Corner] New message: "Re: Port already in use: 1098 - URGENT"
by Peter Johnson
User development,
A new message was posted in the thread "Port already in use: 1098 - URGENT":
http://community.jboss.org/message/527984#527984
Author : Peter Johnson
Profile : http://community.jboss.org/people/peterj
Message:
--------------------------------------------------------------
+"When I sent mail across team most of them replied saying they had this problem, "+
This is an interesting point. I assume that all of your PCs are configured to conform to your corporate networking rules, and if so then it could be something in your corporate PC environment that is causing this phenomenon. Which version of Windows are you using? Are you logged in as an administrator (your user account is in the Administrators group of your PC)? Which firewall of Internet security suite are you using?
Do you have a PC that is not in the corporate environment and does not have the standard corporate software installed? If so, have you run JBoss AS on that PC?
I ask all of this because the problem you have outlined is very unusual. Hence our insistence that most likely there is some other app using the port, but you are just not seeing it. Of course, the fact that when you change to another port it is the new port that gets the error sort of throws that theory out anyway. So it either has to be something internal (like Scott's possibility A) or in the operating system. I have personnally run JBoss AS on more systems than I care to count and have never run into the situation you have described. Sure I have run into port in use errors, but I always found some software using that port.
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/527984#527984
16 years, 2 months
[JNDI and Naming] New message: "JBoss 5.1 -> 4.2 compatibility: javax.naming.Reference cannot be cast to javax.jms.Queue"
by Michał Borowiecki
User development,
A new message was posted in the thread "JBoss 5.1 -> 4.2 compatibility: javax.naming.Reference cannot be cast to javax.jms.Queue":
http://community.jboss.org/message/527976#527976
Author : Michał Borowiecki
Profile : http://community.jboss.org/people/mihbor
Message:
--------------------------------------------------------------
Hi,
We're trying to to lookup a JMS Queue that resides on JBoss-4.2.2 from an ear deployed in JBoss 5.1.0 (specifically sar packaged inside and ear)
We are getting:
java.lang.ClassCastException: javax.naming.Reference cannot be cast to javax.jms.Queue
at pl.bluepay.utils.jms.MDBUtil.getQueue(MDBUtil.java:56)
I understand this is related to incompatible changes in the client libs between the versions.
We tried putting jbossall-client.jar from JBoss-4.2.2 inside the ear (classloader isolation is enabled in the ear-deployer), and referenced it from the sar's MANIFEST file, but this caused the thread to hang.
Does anybody know a solution?
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/527976#527976
16 years, 2 months
[Beginner's Corner] New message: "Re: Port already in use: 1098 - URGENT"
by Sashi Kanth
User development,
A new message was posted in the thread "Port already in use: 1098 - URGENT":
http://community.jboss.org/message/527971#527971
Author : Sashi Kanth
Profile : http://community.jboss.org/people/rockey007
Message:
--------------------------------------------------------------
Yes Scott
You are right. The reason could be A. I tried checking using netstat as explained Zachary also other tools like TCPView, fPort etc... None of those tools showed that some process is binding port *1098*. It's not just about that port, if I go jboss-5.1.0.GA\server\default\conf\bindingservice.beans\META-INF and change the *bindings-jboss-beans.xml* file's rmiPort from 1098 to *11098* or any other random number and then start the jBoss, the server says that port *11098 (*or what ever the new number is) already bound by another process. So that mean JBoss actually not complaning on port 1098. Something else went wrong which complains required port is already bound.
I thought rebooting OS would solve my problem. But no, I tried rebooting for around 10 times for every change I did against the server. As I said there wasn't any definite answer for this, across web everyone has their own way of solving this problem. Thanks to all for your tips those are valuable.
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/527971#527971
16 years, 2 months
[JCA Development] New message: "Re: feedback on JBAS-7195 (WrappedConnection.checkTransactionStatus throws exception when transaction is marked for roll back)"
by Adrian Brock
User development,
A new message was posted in the thread "feedback on JBAS-7195 (WrappedConnection.checkTransactionStatus throws exception when transaction is marked for roll back)":
http://community.jboss.org/message/527970#527970
Author : Adrian Brock
Profile : http://community.jboss.org/people/adrian@jboss.org
Message:
--------------------------------------------------------------
I don't think you'll break anything, but you'll lose the early notification of the failure.
i.e. in a lot of cases you'll be doing useless work which won't fail until it becomes time to commit/rollback.
That's cpu and resources that could be used by something else.
Perhaps you could make it an option in the -ds.xml instead?
The check was added to avoid sql operations leaking into the next transaction because of a race with the tx timeout.
This won't happen if the transaction is just MARKED rolled back only. The transaction hasn't completed yet.
See JBAS-5080, the race goes something like:
a) Thread 1: start running a query
b) Thread 2: timeout -> roll back transaction, which ends the local jdbc transaction
c) Thread 1: original query now reaches the real connection which is in a new local jdbc transaction as far as the jdbc driver is concerned
(b) hasn't happened if the JTA transactions is marked rolled back only
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/527970#527970
16 years, 2 months