[Remoting] - Re: EJB3/Socket invoker - connection timeouts
by jahlborn
I do believe there is another possible notification issue. I've seen this pattern in the jdk code. I believe a thread which is waiting can get interrupted at about the same time that it is notified. if the InterruptedException is just thrown, that notification will be lost. If you look in some of the jdk code, they have essentially:
| synchronized(obj) {
| try {
| obj.wait();
| } catch(InterruptedException e) {
| obj.notify();
| throw e;
| }
| }
|
This way an interrupted thread will not cause a notification to be lost. obviously, you can generate spurious notifications, so your code needs to handle that as well. but generally, extra notifications is better than lost notifications.
To bring it back to the referenced code:
(1) SocketServerInvoker could be doing the clientpool.wait()
(2) ServerThread sends a notification
(3) SocketServerInvoker gets interrupted and notified and bails out, swallowing the notification
I'm not sure what scenarios might cause the SocketServerInvoker to be interrupted, but certainly system stress might do it.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4057938#4057938
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4057938
18Â years, 10Â months
[JBoss Seam] - Adding attributes to s:fileUpload
by davidfed
-- Seam 1.2.1 standard setup --
I needed to add onclick, onfocus and onblur events to my s:fileUpload tags but the attributes weren't showing up in the html. So I added them to UIFileUpload.java. Is this the correct way to do this?
| Index: UIFileUpload.java
|
| ===================================================================
|
| --- UIFileUpload.java (revision 5)
|
| +++ UIFileUpload.java (working copy)
|
| @@ -25,7 +25,10 @@
|
|
| private String accept;
| private String styleClass;
| - private String style;
| + private String style;
| + private String onclick;
| + private String onfocus;
| + private String onblur;
|
| @Override
| public void decode(FacesContext context)
| @@ -151,7 +154,22 @@
|
| {
| writer.writeAttribute(HTML.STYLE_ATTR, style, null);
| }
| -
| +
| + if (onclick != null)
| + {
| + writer.writeAttribute(HTML.ONCLICK_ATTR, onclick, null);
| + }
| +
| + if (onfocus != null)
| + {
| + writer.writeAttribute(HTML.ONFOCUS_ATTR, onfocus, null);
| + }
| +
| + if (onblur != null)
| + {
| + writer.writeAttribute(HTML.ONBLUR_ATTR, onblur, null);
| + }
| +
| writer.endElement(HTML.INPUT_ELEM);
| }
|
| @@ -191,4 +209,34 @@
|
| this.styleClass = styleClass;
| }
|
| + public String getOnblur()
| + {
| + return onblur;
| + }
| +
| + public void setOnblur(String onblur)
| + {
| + this.onblur = onblur;
| + }
| +
| + public String getOnclick()
| + {
| + return onfocus;
| + }
| +
| + public void setOnclick(String onclick)
| + {
| + this.onclick = onclick;
| + }
| +
| + public String getOnfocus()
| + {
| + return onfocus;
| + }
| +
| + public void setOnfocus(String onfocus)
| + {
| + this.onfocus = onfocus;
| + }
| +
| }
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4057936#4057936
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4057936
18Â years, 10Â months
[JBoss Seam] - Decorating with a fileUpload tag
by davidfed
--Seam 1.2.1 standard setup--
I have this page source:
| <s:decorate id="uploadDecor_#{idx}" template="/WEB-INF/template/edit.txml">
| <ui:define name="label">
| #{messages.attachFileLabelFile}
| </ui:define>
| <ui:define name="guidance">
| #{messages.attachFileGuidanceFile}
| </ui:define>
| <s:fileUpload id="upload_#{idx}" data="#{doc.fileData}"
| fileName="#{doc.fileName}"
| contentType="#{doc.contentType}"/>
| </s:decorate>
|
with this template:
| <s:div styleClass="prop #{invalid?'errors':''}">
| <s:label styleClass="name">
| <ui:insert name="label"/>
| </s:label>
|
| <s:span styleClass="value">
| <ui:insert/>
| </s:span>
|
| <s:message styleClass="error errors"/>
|
| <s:span styleClass="guidance">
| <s:fragment rendered="#{invalid}">
| <s:message/>
| <br/>
| </s:fragment>
| <ui:insert name="guidance"/>
| </s:span>
| </s:div>
|
And I get these complaints in the console:
| 18:59:50,935 WARN [HtmlLabelRenderer] Attribute 'for' of label component with id attachFile:_id75 is not defined
| 18:59:51,935 ERROR [HtmlMessageRendererBase] Attribute 'for' of UIMessage must not be null
|
When I break into HtmlMessageDecoration.getInputId() I see that it walks through the subtree of the decorate tag looking for an EditableValueHolder subclass to get the id to insert in the 'for' tag. It doesn't think the fileUpload qualifies and doesn't set a 'for' attribute. HtmlLabelDecoration has the same problem.
The result is that clicking on the label doesn't focus the input field and the field specific error messages don't show up.
Is there an easy way to solve this?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4057933#4057933
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4057933
18Â years, 10Â months
[Remoting] - Re: EJB3/Socket invoker - connection timeouts
by gurgstar
Not sure how we got into this state, but its clearly a deadlock...
(1) SocketServerInvoker is stuck on clientpool.wait()
(2) maxPoolSize ServerThreads are all stuck on this.wait()
(3) At least one ServerThread must call clientpool.notify() to wake up the SocketServerInvoker
(4) SocketServerInvoker must be woken up in order to call notify on at least one ServerThread.
The deadlock is clear enough, but not sure how we got there other than what appears to be a very small chance of a lost wakeup...
ServerSocketInvoker:
| while (thread == null) {
| synchronized (threadpool) {
| if (threadpool.size() > 0) {
| thread = (ServerThread) threadpool.removeFirst();
| }
| }
| if (thread == null) {
| synchronized (clientpool) {
| if (clientpool.size() < maxPoolSize) {
| thread = new ServerThread(socket, this, clientpool, threadpool, getTimeout(), serverSocketClass);
| newThread = true;
| }
| if (thread == null) {
| clientpool.evict();
| if (trace) {
| log.trace("Waiting for a thread...");
| }
| clientpool.wait();
| if (trace) {
| log.trace("Notified of available thread");
| }
| }
| }
| }
| }
|
ServerThread:
| synchronized (this) {
| synchronized (clientpool) {
| synchronized (threadpool) {
| if (shutdown) {
| invoker = null;
| return; // exit thread
| } else {
| clientpool.remove(this);
| threadpool.add(this);
| Thread.interrupted(); // clear any interruption so that we can be pooled.
| clientpool.notify(); //273
| }
| }
| }
| try {
| log.debug("begin thread wait");
| this.wait(); // 280
| log.debug("WAKEUP in SERVER THREAD");
| } catch (InterruptedException e) {
| if (shutdown) {
| invoker = null;
| return; // exit thread
| }
|
| throw e;
| }
| }
|
There is the potential for lost wakeups in both directions. The ServerSocketInvoker can miss the ServerThread notifies, and the ServerThreads can miss the ServerSocketInvoker's notifies.
This is how the ServerSocketInvoker could miss the notifies form the ServerThreads (seems very unlikely):
(1) ServerSocketInvoker sees that the threadpool is empty
(2) All the ServerThreads then finish processing and call clientpool.notify()
(3) ServerSocketInvoker calls clientpool.wait() and will wait forever cause it missed the notifies
This is how the ServerThreads could miss the notifies from the ServerSocketInvoker (seems much more likely):
(1) A ServerThread finishes processing, calls clientpool.notify() and is then suspended by the scheduler
(2) ServerSocketInvoker wakes up and calls ServerThread.notify
(3) The ServerThread then calls this.wait() and waits forever because it missed the ServerSocketInvoker's notify
Each time this happens, it would take a ServerThread out of comission. Eventually you'd run out of ServerThreads.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4057930#4057930
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4057930
18Â years, 10Â months
[JBoss Seam] - Re: Layering / overloading resources approach
by utiba_davidr
Hey,
Thanks heaps for this. I believe overloading the ResourceResolver is the best option for layering XHTML files. With a method simmilar to:
public URL resolveUrl(String resource) {
| String[] locations = {"", "/true/umarket", "/umarket"};
|
| URL url = null;
| for (String resourcePrefix: locations) {
| url = getClass().getClassLoader().getResource(resourcePrefix + resource);
|
| if (url != null)
| break;
| }
|
| if (url == null) {
| url = super.resolveUrl(resource);
| }
|
| return url;
| }
|
| ... elsewhere ... for the request ...
|
| resolveUrl("/agent/list_agents.wt");
This will traverse the class path, scanning under 3 prefixes. Of course I will make the prefixes configurable (perhaps inside the MANIFEST.MF of each XHTML jar file).
As for laying the pages/components xml files - I will have to wait until I have time to play around to see what works best there. Thanks for letting me know that worst case scenario I can overload the Pages component.
Cheers,
David
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4057928#4057928
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4057928
18Â years, 10Â months